Azure Front Door 切替時の 403・404・302 切り分け実務メモ

AppGW 経由から Azure Front Door 経由へ変更する際の確認ポイント

この記事はSmart IT & AI Hubが公開しているコンテンツです。
他の記事は目的別インデックスからどうぞ。

はじめに

本記事は、既存の Azure Application Gateway 経由の Web 公開構成を、Azure Front Door 経由に切り替える際に発生しやすい 403、404、302 の切り分け観点をまとめた実務メモです。

既存環境では、以下のように Application Gateway を入口として IIS Web サーバーへアクセスしている構成を想定します。

利用者
  ↓
Azure Application Gateway
  ↓
IIS Web サーバー
  ↓
Web アプリケーション

切替後は、Azure Front Door を入口として利用します。

利用者
  ↓
Azure Front Door
  ↓
IIS Web サーバー
  ↓
Web アプリケーション

または、移行期間中や構成上の都合により、以下のように Front Door の配信元として Application Gateway を残す構成も考えられます。

利用者
  ↓
Azure Front Door
  ↓
Azure Application Gateway
  ↓
IIS Web サーバー
  ↓
Web アプリケーション

本記事では、主に AppGW 経由で正常だったアクセスを Front Door 経由に切り替えた際に、なぜ 403・404・302 が発生するのか を整理します。

403、404、302 は、単なるアプリケーションエラーではなく、以下のような差分によって発生することがあります。

• 入口が Application Gateway から Front Door に変わった

• Host ヘッダーの扱いが変わった

• パスの転送方法が変わった

• HTTP / HTTPS の扱いが変わった

• WAF の判定レイヤーが変わった

• リダイレクトの発生箇所が変わった

• IIS に到達する前に Front Door 側で応答している

• IIS には到達しているが、AppGW 経由時と異なる Host / Path で届いている

そのため、切替時の調査では、単に「403 が出た」「404 が出た」と見るのではなく、AppGW 経由ではどうだったか、Front Door 経由では何が変わったかを比較することが重要です。

Azure Front Door の一般的なトラブルシューティングでは、カスタムドメイン、ルート、オリジン、証明書名チェックなどの確認が必要とされています。また、Application Gateway はバックエンドへ接続する前後に関わらず HTTP 応答コードを返す場合があります。

目次

1. 本記事の対象範囲

2. 切替前後の構成

3. まず比較すること

4. 403 の切り分け

5. 404 の切り分け

6. 302 の切り分け

7. Front Door 側で見るポイント

8. AppGW 側で見るポイント

9. IIS 側で見るポイント

10. curl での確認例

11. よくある原因パターン

12. 顧客向け説明文

13. まとめ

14. 免責事項

1. 本記事の対象範囲

本記事では、以下のような切替作業を対象とします。

• 既存は Application Gateway 経由で Web サイトを公開している

• 切替後は Azure Front Door 経由で Web サイトを公開する

• バックエンドは IIS Web サーバーを想定する

• 切替後に 403、404、302 が発生している

• AppGW 経由では正常だったが、Front Door 経由で事象が発生している

• Front Door、AppGW、IIS のどこで応答が変わったかを切り分けたい

本記事では、アプリケーション内部の詳細なバグ解析までは扱いません。

主に、インフラ運用・保守の観点で、以下を確認するためのメモです。

• Front Door のルーティングが正しいか

• Front Door のオリジン設定が正しいか

• Host ヘッダーが想定どおりか

• パスが想定どおり転送されているか

• HTTP / HTTPS のリダイレクトが重複していないか

• IIS に到達しているか

• IIS 側で想定したサイトに入っているか

2. 切替前後の構成

2.1 切替前の構成

切替前は、Application Gateway を入口として IIS へアクセスしている構成を想定します。

利用者
  ↓
Azure Application Gateway
  ↓
IIS Web サーバー
  ↓
Web アプリケーション

この場合、主な確認ポイントは以下です。

• Application Gateway のリスナー

• Application Gateway のルール

• Application Gateway のバックエンドプール

• Application Gateway の HTTP 設定

• Application Gateway の WAF

• IIS のサイトバインド

• IIS の URL Rewrite

• IIS ログ

2.2 切替後の構成

切替後は、Azure Front Door を入口として IIS へアクセスする構成を想定します。

利用者
  ↓
Azure Front Door
  ↓
IIS Web サーバー
  ↓
Web アプリケーション

この場合、主な確認ポイントは以下です。

• Azure Front Door のエンドポイント

• Azure Front Door のカスタムドメイン

• Azure Front Door のルート

• Azure Front Door のオリジングループ

• Azure Front Door のオリジン

• Azure Front Door のルールセット

• Azure Front Door の WAF

• IIS のサイトバインド

• IIS の URL Rewrite

• IIS ログ

2.3 移行中にあり得る構成

移行期間中や構成上の都合により、Front Door の配信元として Application Gateway を指定するケースもあります。

利用者
  ↓
Azure Front Door
  ↓
Azure Application Gateway
  ↓
IIS Web サーバー
  ↓
Web アプリケーション

この構成では、Front Door と Application Gateway の両方で以下が発生する可能性があります。

• WAF ブロック

• HTTP / HTTPS リダイレクト

• Host ヘッダー変更

• パスベースルーティング

• URL 書き換え

• 証明書チェック

• バックエンド正常性の失敗

そのため、Front Door へ切り替えたつもりでも、実際には AppGW 側の設定差分が影響している場合があります。

3. まず比較すること

切替時のトラブルでは、Front Door 単体を見るのではなく、AppGW 経由時と Front Door 経由時の差分を見ることが重要です。

最初に確認することは以下です。

• AppGW 経由では正常にアクセスできるか

• Front Door 経由では何のステータスコードになるか

• 403、404、302 が特定パスだけで発生するか

• トップページでも発生するか

• Host ヘッダーは同じか

• パスは同じ形で IIS に届いているか

• HTTP と HTTPS で結果が変わるか

• Location ヘッダーの向き先はどこか

• IIS ログにリクエストが記録されているか

• Front Door のログにリクエストが記録されているか

• WAF ログにブロック記録があるか

特に重要なのは、以下の 3 点です。

• IIS に届いているか

• IIS に届いている場合、Host と Path が AppGW 経由時と同じか

• IIS に届いていない場合、Front Door 側で止まっているのか

切替後だけを見ると原因が分かりにくいため、必ず切替前の AppGW 経由の正常時と比較します。

ここまで整理すると、Front Door 切替時の調査では「どこを見ればよいか」はある程度見えてきます。

ただし、実際の現場で困るのはここからです。

403 が出たときに Front Door WAF を先に見るべきなのか、IIS ログを見るべきなのか。
404 が出たときにルート設定を疑うべきなのか、Host ヘッダーや IIS バインドを疑うべきなのか。
302 が出たときに正常なリダイレクトなのか、設定差分による想定外のリダイレクトなのか。

この判断を誤ると、Front Door 側を調べ続けたものの、実際には IIS 側の Host バインド差分だった、というように調査時間が大きく伸びます。

ここから先では、403・404・302 それぞれについて、
「最初に見るべき場所」
「Front Door / AppGW / IIS のどこを疑うべきか」
「curl やログで何を確認するか」
「顧客向けにどう説明するか」
を実務メモとして整理します。

4. 403 の切り分け