IIS / URL Rewrite / Front Door / AppGW リダイレクト調査メモ｜302・404・ループの確認ポイント

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

IISでWebサイトを運用していると、想定外の302、404、リダイレクトループに遭遇することがあります。

原因はIISだけとは限りません。

IIS HTTPリダイレクト、URL Rewrite、web.config、アプリケーション側のログイン処理、Azure Front Door、Application Gateway、CDN側のリダイレクトが重なっていることがあります。

この記事では、詳しい理論よりも、実務で使える確認順序を中心に整理します。

「まず何を見るか」「次にどこを疑うか」「顧客にどう説明するか」を短くまとめたメモです。

想定外の302・404を短時間で切り分ける確認ポイント

はじめに

IISでWebサイトを運用していると、想定外の302や404が発生することがあります。

たとえば、以下のようなケースです。

• アクセスすると別URLへ302される

• /aa-bb は正常だが /aa-bb/ は404になる

• HTTPからHTTPSへのリダイレクトが何度も発生する

• AppGW経由では正常だが、Front Door経由では異常になる

• IISログに記録がない

• web.configに古いリダイレクト設定が残っている

このとき、IISマネージャーの「HTTPリダイレクト」だけを見ても原因が分からないことがあります。

IISのhttpRedirectは、クライアント要求を別の場所へリダイレクトする設定です。一方、URL Rewriteは、要求URLやHTTPヘッダー、サーバー変数などを条件に、書き換えやリダイレクトを行うIIS拡張機能です。

この記事では、細かい理論ではなく、実務で短時間に切り分けるための確認ポイントを整理します。

本記事で分かること

この記事では、以下を整理します。

• 302が出たときに最初に見る場所

• 404が出たときに疑う場所

• IIS HTTPリダイレクトとURL Rewriteの違い

• web.configで見るポイント

• Front Door / AppGW / CDN側との重複確認

• curlでLocationヘッダーを見る方法

• IISログで見る項目

• 顧客向けの説明文テンプレ

深い設計論ではなく、現場で使う確認メモとして読める内容にしています。

想定構成

この記事では、以下のような構成を想定します。

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

この構成では、リダイレクトや404の原因が複数レイヤーに分散します。

主な発生箇所です。

• Azure Front Door

  • ルールセット

  • URLリダイレクト

  • WAF

  • オリジン設定

• Application Gateway

  • リダイレクト構成

  • WAF

  • パスベースルール

  • バックエンド設定

• IIS

  • HTTPリダイレクト

  • URL Rewrite

  • web.config

  • サイトバインド

• Webアプリケーション

  • ログインリダイレクト

  • ルーティング

  • セッション

  • 認証処理

Azure Front Doorは、プロトコル、ホスト名、パス、クエリ文字列のリダイレクトをサポートします。Application Gatewayも、リスナー間や外部サイトへのリダイレクトを構成できます。

まず見るポイント

302、404、リダイレクトループが発生したら、最初に見るポイントは以下です。

• Locationヘッダー

• IISログに記録があるか

• HTTPとHTTPSで結果が違うか

• 末尾スラッシュ有無で結果が違うか

• Front Door / AppGW経由時だけ発生するか

• IISへ直接アクセスしても発生するか

• web.configに設定が残っていないか

特に重要なのは2つです。

• 302の場合

  • Locationヘッダーを見る

• 404の場合

  • IISログに到達しているかを見る

IISログに記録がない場合、IISまで到達していない可能性があります。

この場合は、Front Door、AppGW、CDN、WAF、ルート、オリジン設定を先に確認します。

IIS HTTPリダイレクトとURL Rewriteの違い

IIS HTTPリダイレクトとURL Rewriteは、どちらもURLの転送に関係します。

ただし、役割が違います。

HTTPリダイレクトは、比較的シンプルです。

一方、URL Rewriteは、条件、正規表現、サーバー変数などを使えるため、想定外の302や404の原因になりやすいです。

URL Rewriteでは、リダイレクト、カスタム応答、要求中止も定義できます。

302や404は、ステータスコードだけでは原因を判断できません。

IIS、URL Rewrite、web.config、Front Door、AppGW、CDN、アプリ側のどこで発生しているかを見る必要があります。

ここから先では、事象別に以下を整理します。

• 最初に見る場所

• 次に疑う場所

• 確認コマンド

• IISログの見方

• よくある原因

• 顧客向け説明文

302が出たときの切り分け

302は、一時的なリダイレクトを示します。

必ずしも障害ではありません。

ただし、想定外のURLへ飛ぶ場合は、どこがLocationヘッダーを返しているかを確認します。