0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

2026年!初アウトプットをしよう
@tetsuya-oooooinパーソルクロステクノロジー株式会社

Azure Front Door をアプリケーションの唯一の入口にする:アプリ改修編

0
Last updated at Posted at 2026-01-25

前回の振り返り

前回の記事では、Azure CDN from Microsoft のリタイアに備えて、既存の構成を Azure Front Door Standard へ移行したプロセスをまとめました。

単なる CDN の置き換えではなく、今後のサイト運用を Azure Front Door に集約するための土台づくりがテーマでした。

具体的には、次のような内容を扱いました。

  • Azure CDN from Microsoft のサービス終了に伴う移行判断の背景
    現状の構成 (AsIs) と、Azure Front Door を中心に据えた将来像 (ToBe) を整理し、移行の意図を明確にしました。
  • Azure Front Door への移行手順
    マネージド ID の有効化、Azure Key Vault の権限付与、移行の実行など、実際の作業ステップを詳しく紹介しました。
  • 移行後の作業
    旧 Azure CDN エンドポイントの整理についてまとめました。

前回は「Azure Front Door を導入するところまで」がゴールでしたが、Azure Front Door をアプリケーションの入口として本格的に活用するためには、まだ重要な作業が残っています。

本記事では

Azure Front Door をアプリケーションの唯一の入口として利用するためには、アプリ側でいくつかの補正が必要になります。

本記事ではその第一歩として、

  • HTTPS 判定の補正
  • ホスト名の補正

など、WordPress と ASP.NET Core の改修ポイントにフォーカスします。

※ Azure Front Door 側の構築 (バックエンド設定、アクセス制御など) は次回の記事で詳しく扱います。

Copilot_20260122_105253.png

全体アーキテクチャのゴール

このシリーズ全体の最終的なゴールは、アプリケーション全体を Azure Front Door が唯一の入口として守る構成に進化させることです。

静的コンテンツ・動的コンテンツの両方を Azure Front Door に統合し、パフォーマンス・セキュリティ・運用を Front Door に集約した構成を目指します。

Before

前回の記事で Azure CDN from Microsoft から Azure Front Door への移行は完了し、静的コンテンツの配信はすでに Azure Front Door に統合されている状態になっています。

ただし、アプリケーション全体として見ると、まだ次の課題が残っています。

  • App Service がインターネットに直接公開されている
    セキュリティリスクが高く、アクセス制限を Azure Front Door 側に集約できていない。
  • アプリケーションの入口が Azure Front Door、App Service と複数に分かれている
    どちら経由でアクセスされるかによって挙動が変わり、統一した制御ができない。
  • HTTPS の終端が App Service 側に残っている
    ドメイン・証明書管理が Azure Front Door に集約されていない (分散している)。

image.png

上図のとおり、静的コンテンツ配信は Azure Front Door に統合されたものの、アプリケーション全体の入口としてはまだ Azure Front Door が機能しきれていない状態が「Before」です。

After

「After」では、Azure Front Door を アプリケーションの唯一の入口 として配置し、静的・動的コンテンツの両方を Azure Front Door 経由に統一します。

image.png

上図のとおり、Azure Front Door がアプリケーションの前段に立つことで、パフォーマンス・セキュリティ・運用のすべてが Azure Front Door に集約された構成が実現します。

そして、この構成により、次のメリットが得られます。
※前回の記事より再掲

パフォーマンス向上

  • グローバルエッジで高速化
    • 静的コンテンツを最寄りのエッジ拠点 (キャッシュサーバー) に置いておけるため、毎回 Azure のデータセンターまで取りに行くより圧倒的に速くなる
    • 動的コンテンツも最寄りの POP (Azure Front Door の入口) から Microsoft の専用バックボーンネットワークを通って App Service に到達するため、公共インターネットを経由するよりも遅延が少なく、安定した通信ができる

セキュリティ強化

  • App Service の露出を最小限に
    • App Service のアクセス制限で、Azure Front Door 経由以外のアクセスを遮断

運用の集約

  • 静的コンテンツと Web アプリの入口を一本化
    • すべてのリクエストが Azure Front Door を経由する構造になり、管理ポイントがひとつにまとまる
  • 運用がシンプルに
    • ドメイン管理、証明書管理、ルーティングが Azure Front Door に集約される
  • 監視・ログの統合
    • Azure Front Door と App Service のログを一元的に分析できる

After を実現するために必要な対応

なお、After の構成では、Azure Front Door が HTTPS を終端し、App Service との通信は内部的に HTTP になります。また、App Service に届く Host ヘッダーが本来のホスト名と異なっている場合があります。よって、アプリ側で次の対応が必要になります。

  • アプリ側で HTTPS アクセスの判定を正しくする
  • アプリ側でホスト名を正しく認識させる

Web アプリの改修

Azure Front Door を経由すると、App Service に届くリクエスト情報（プロトコル・ホスト名）が変わるため、どの Web アプリでも補正が必要になります。

ここでは WordPress と ASP.NET Core の 2 つのアプリについて、Azure Front Door 配下で正しく動作させるための改修ポイントを紹介します。

WordPress の改修

Azure Front Door を経由して App Service 上の WordPress にアクセスする場合、アプリ側では HTTPS とホスト名を正しく認識できるように補正する処理が必要になります。Azure Front Door と App Service 間の通信は内部的に HTTP になるため、WordPress は本来の HTTPS アクセスを正しく認識できません。

今回の構成では、wp-config.php の冒頭に次のコードを入れています。

wp-config.php
if (isset($_SERVER["HTTP_X_FORWARDED_PROTO"]) && $_SERVER["HTTP_X_FORWARDED_PROTO"] === "https") {
    $_SERVER["HTTPS"] = "on";
    $_SERVER["SERVER_PORT"] = 443;
}

if (isset($_SERVER["HTTP_X_FORWARDED_HOST"])) {
    $_SERVER["HTTP_HOST"] = $_SERVER["HTTP_X_FORWARDED_HOST"];
}

if (isset($_SERVER["HTTP_X_FORWARDED_FOR"])) {
    $xff_parts = explode(",", $_SERVER["HTTP_X_FORWARDED_FOR"]);
    $xff = trim($xff_parts[0]);
    if (filter_var($xff, FILTER_VALIDATE_IP)) {
        $_SERVER["REMOTE_ADDR"] = $xff;
    }
}

ここでは、Azure Front Door が付与する次のヘッダー値を取得しています。

  • X-Forwarded-Proto: 元のプロトコル
  • X-Forwarded-Host: 元のホスト名
  • X-Forwarded-For: クライアント IP1

HTTPS アクセスの判定を正しくする

Azure Front Door は HTTPS を終端し、App Service との通信は HTTP で行います。そのため、WordPress が受け取るリクエストは 「HTTP でアクセスされた」 と誤認されます。

これを補正するために、Azure Front Door が付与する X-Forwarded-Proto: https を見て、

  • $_SERVER["HTTPS"] = "on"
  • $_SERVER["SERVER_PORT"] = 443

に書き換えています。
この処理がないと、WordPress 内部で次のような問題が発生します。

  • HTTPS → HTTP への誤ったリダイレクト
  • ログイン時の無限リダイレクト
  • 絶対 URL が http:// で生成される
  • Mixed Content2 警告が出る

Azure Front Door 配下で WordPress を動かす場合、この補正は必須です。

ホスト名を正しく認識させる

Azure Front Door 経由のアクセスでは、App Service に届く Host ヘッダーが <appname>.azurewebsites.net になる場合があります。そのままだと、WordPress が生成する URL が https://<appname>.azurewebsites.net になってしまいます。

これを防ぐために、Azure Front Door が付与する X-Forwarded-Host を使って、

  • $_SERVER["HTTP_HOST"] を正しいホスト名に書き換えます。

WordPress は内部で URL を多用するため、この補正がないと

  • Canonical URL3
  • リダイレクト先
  • 絶対 URL
  • プラグインの動作

などがすべてズレてしまいます。

これらの補正により、Azure Front Door 配下でも WordPress が HTTPS と正しいホスト名を認識し、リダイレクトや URL 生成のトラブルを防ぐことができます。

APS.NET Core アプリの改修

前述の WordPress と同様、Azure Front Door を経由すると App Service に届くリクエスト情報 (プロトコルやホスト名) が変わるため、アプリ側で補正が必要になります。

ASP.NET Core には、この補正を自動で行う Forwarded Headers Middleware が用意されており、Azure Front Door が付与する X-Forwarded-* ヘッダーを正しく解釈できるように設定します。

Forwarded Headers を受け入れる

ASP.NET Core が Azure Front Door 配下で受け取るリクエストは、次のようにズレた状態になります。

  • 本来は HTTPS なのに、アプリ側では HTTP と認識される
  • 本来のホスト名が、<appname>.azurewebsites.net として届く

これを補正しないと、

  • HTTPS → HTTP への誤ったリダイレクト
  • 絶対 URL が azurewebsites.net で生成される
  • 認証フローが失敗する
  • リダイレクトループが発生する

といった問題が起こります。

WordPress では wp-config.php で手動補正しましたが、ASP.NET Core では Forwarded Headers Middleware を使うことで、同じ補正をフレームワーク側で自動的に行えます。

Startup.cs の改修内容

  1. ConfigureServices で ForwardedHeadersOptions を設定する

    Startup.cs (ConfigureServices)
    services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders =
        ForwardedHeaders.XForwardedFor |
        ForwardedHeaders.XForwardedProto |
        ForwardedHeaders.XForwardedHost;
        
    // Azure Front Door の IP を KnownProxies に登録する方法もあるが、
    // 今回はすべてのプロキシを受け入れる
    options.KnownNetworks.Clear();
    options.KnownProxies.Clear();
});

    ここでは、Azure Front Door が付与する

    • X-Forwarded-Proto: 元のプロトコル
    • X-Forwarded-Host: 元のホスト名
    • X-Forwarded-For: クライアント IP1

    を ASP.NET Core が信頼して使えるように設定しています。

  2. Configure の先頭付近で UseForwardedHeaders を実行する

    Startup.cs (Configure)
    // プロキシが付与するヘッダーを処理する
app.UseForwardedHeaders();

    これをできるだけ早い段階に置くことが重要です。
    その理由は、

    • HTTPS 判定が正しくなる
    • URL 生成が正しくなる
    • 認証やリダイレクトが正常に動作する

    ASP.NET Core のミドルウェアは上から順に実行されるため、補正は最初に行うのが鉄則です。

.NET 6 以降では、Startup.cs と Program.cs を 1 つの Program.cs にまとめる Minimal Hosting Model という書き方が追加されました。4

この書き方で実装する場合、Forwarded Headers の設定は builder.Services.Configure<ForwardedHeadersOptions>() に、ミドルウェアの実行は app.UseForwardedHeaders() に対応します。

書く場所が変わるだけで、やっていることは Startup.cs と同じです。

特に UseForwardedHeaders() をパイプラインの早い段階に置く点は、Startup.cs の場合と変わりません。

Program.cs
var builder = WebApplication.CreateBuilder(args);

// Forwarded Headers の設定
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders =
        ForwardedHeaders.XForwardedFor |
        ForwardedHeaders.XForwardedProto |
        ForwardedHeaders.XForwardedHost;

    // Azure Front Door の IP を KnownProxies に登録する方法もあるが、
    // 今回はすべてのプロキシを受け入れる
    options.KnownNetworks.Clear();
    options.KnownProxies.Clear();
});

var app = builder.Build();

// Forwarded Headers をパイプラインの早い段階で適用
app.UseForwardedHeaders();

// ここから先は通常のミドルウェア
// app.UseStaticFiles();
// app.UseRouting();
// app.MapControllers();
// ...

app.Run();

これらの設定により、Azure Front Door 配下でも ASP.NET Core アプリが HTTPS と正しいホスト名を認識し、リダイレクトや URL 生成の不具合を防ぐことができます。

最後に

本記事では、Azure Front Door をアプリケーションの唯一の入口として機能させるために必要な、WordPress と ASP.NET Core のアプリ側の改修ポイントをまとめました。

次回の記事は、Azure Front Door 側の構築手順（バックエンド設定、ルーティング、アクセス制限、証明書管理など）を詳しく紹介します。

アプリ改修とインフラ構築の両方が揃うことで、Azure Front Door を中心に据えたセキュアでシンプルな Web アーキテクチャが完成します。

(つづく)

  1. X-Forwarded-For: クライアント IP はアプリの動作には必須ではありませんが、ログや監査で必要な場合は受け入れる設定を追加できます。 ↩ ↩2

  2. HTTPS ページは暗号化されて安全に通信されますが、もしそのページ内で HTTP (暗号化されていない) 画像・スクリプト・CSS などを読み込むと、通信の一部が暗号化されずに送られてしまいます。これが Mixed Content (混在コンテンツ) です。 ↩

  3. 複数の URL で同じ (または非常に似た) 内容が存在する場合に、検索エンジンへ「評価を集約すべき代表 URL」を伝えるための仕組み。HTML の <link rel="canonical" href="https://example.com/page/"> というタグで指定します。 ↩

  4. Startup.cs を使い続ける構成も正式にサポートされており、Program.cs への統合は必須ではありません。 ↩

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?