Azure Application Gatewayの HTTP 応答コード

概要

この記事では、Azure Application Gateway が特定の HTTP 応答コードを返す理由について説明します。 エラー HTTP 応答コードの根本原因を特定するのに役立つ一般的な原因とトラブルシューティング手順を示します。 Application Gateway は、バックエンド ターゲットへの接続を開始するかどうかに関係なく、クライアント要求に HTTP 応答コードを返すことができます。

注

Application Gateway が HTTP 応答を返す前にクライアント接続が失敗した場合、障害はトランスポート層セキュリティ (TLS) ハンドシェイクエラーである可能性があります。 一般的な原因には、TLS バージョンの不一致 (たとえば、クライアントは TLS 1.0 または 1.1 を使用し、ゲートウェイには TLS 1.2 以上が必要) とサポートされていない暗号スイートが含まれます。 Azure Application Gateway は、2025 年 8 月 31 日をもって TLS 1.0 および 1.1 のサポートを終了しました。 詳細については、「 Application Gateway TLS ポリシーの概要 」および「 TLS ポリシーのバージョンと暗号スイートを構成する」を参照してください。

3XX 応答コード (リダイレクト)

クライアント要求が、リダイレクトが構成されているアプリケーション ゲートウェイルールと一致すると、Application Gateway は HTTP 300-399 応答を返します。 リダイレクトは、ルール as-is またはパス マップ ルールを使用して構成できます。 リダイレクトの詳細については、「Application Gateway のリダイレクトの概要」を参照してください。

301 パーマネント

永続的な値を使用してリダイレクトルールを指定すると、Application Gateway は HTTP 301 応答を返します。

302 検出

[検出] 値を使用してリダイレクト ルールを指定すると、Application Gateway から HTTP 302 応答が返されます。

303 他を参照

Application Gateway は、リダイレクトルールに See Other 値を指定した場合、HTTP 303 応答を返します。

307 一時的リダイレクト

一時値を使用してリダイレクトルールを指定すると、Application Gateway は HTTP 307 応答を返します。

4XX 応答コード (クライアント エラー)

HTTP 400-499 応答コードは、クライアントが開始する問題を示します。 これらの問題は、クライアントが要求を開始する場合から、一致しないホスト名、要求タイムアウト、認証されていない要求、悪意のある要求などです。

Application Gateway は、HTTP 4xx および 5xx 状態コードの分布をキャプチャするメトリックを収集し、URI クライアントの IP アドレスなどの情報を応答コードでキャプチャするログメカニズムを備えています。 メトリックとログを使って、さらなるトラブルシューティングが可能です。 クライアントは、Content Delivery Network (CDN) やその他の認証プロバイダーなど、クライアント デバイスと Application Gateway の間の他のプロキシから HTTP 4xx 応答を受信することもできます。 詳しくは、以下の記事をご覧ください。

400 – 要求が正しくありません

HTTP 400 応答コードは、次の場合に一般的に表示されます。

  • HTTP または HTTPS リスナーを使用して、アプリケーション ゲートウェイへの HTTP または HTTPS 以外のトラフィックを開始します。
  • リダイレクトが構成されていない状態で、HTTPS を使用してリスナーへの HTTP トラフィックを開始します。
  • 相互認証を構成しますが、Application Gateway は適切にネゴシエートできません。
  • 要求がコメント要求 (RFC) に準拠していません。

次の表に、要求が RFC に準拠していない一般的な理由をいくつか示します。

カテゴリ 例示
要求行のホストが無効です ホストにコロンが 2 つ含まれる (example.com:8090:8080)
ホスト ヘッダーがありません 要求にホスト ヘッダーがない
形式に誤りがあるか、無効な文字が存在する 予約されている文字は &、! です。回避策は、パーセントでコード化することです。 例: %&
HTTP バージョンが無効 /content.css HTTP/0.3 を取得する
ヘッダー フィールド名と URI に ASCII 以外の文字が含まれる GET /«úü○»¿.doc HTTP/1.1
POST 要求のコンテンツ長ヘッダーがありません 一目瞭然
HTTP メソッドが無効です GET123 /index.html HTTP/1.1
重複するヘッダー 認可:<base64 エンコードされたコンテンツ>、認可: <base64 エンコードされたコンテンツ>
content-length の値が無効です コンテンツの長さ: abc、Content-length: -10

相互認証を構成すると、次の一覧を含め、いくつかのシナリオで HTTP 400 応答がクライアントに返される可能性があります。

  • 相互認証を有効にしても、クライアント証明書が表示されませんでした。
  • 識別名 (DN) 検証を有効にすると、クライアント証明書の DN が指定された証明書チェーンの DN と一致しません。
  • クライアント証明書チェーンが、定義済みの Secure Sockets Layer (SSL) ポリシーで構成された証明書チェーンと一致しません。
  • クライアント証明書の有効期限が切れています。
  • オンライン証明書状態プロトコル (OCSP) クライアント失効チェックを有効にすると、証明書が失効します。
  • OCSP クライアント失効チェックを有効にしても、Application Gateway は OCSP レスポンダーに接続できません。
  • OCSP クライアント失効チェックを有効にしても、OCSP レスポンダーが証明書に指定されていません。

相互認証のトラブルシューティングの詳細については、「エラー コードのトラブルシューティング」を参照してください。

401 – 認証されていません

クライアントがリソースへのアクセスを許可されていない場合、Application Gateway はクライアントに HTTP 401 未承認の応答を返します。 401 が返される理由はいくつかあります。 クライアントにアクセス権がある場合は、古いブラウザー キャッシュが存在する可能性があります。 ブラウザー キャッシュをクリアし、もう一度アプリケーションにアクセスしてみてください。

NTLM 認証を使用してバックエンド プールを構成すると、Application Gateway は Application Gateway プローブ要求に HTTP 401 未承認の応答を返すことができます。 このシナリオでは、Application Gateway によってバックエンドが正常としてマークされます。 次のいずれかの方法を使用して、この問題を解決します。

  • バックエンド プールでの匿名アクセスを許可します。
  • NTLM 認証を必要としない別の "偽" サイトに要求を送信するようにプローブを構成します。
  • プローブに対して有効な HTTP 401 応答を許可するように Application Gateway を構成します。 詳細については、「 プローブの一致条件」を参照してください。

403 – 禁止

Application Gateway では、Azure Web Application Firewall (WAF) SKU を使用し、WAF が防止モードで構成されている場合、HTTP 403 Forbidden が表示されます。 有効にした場合、WAF ルールセットまたはカスタム拒否 WAF 規則は、受信要求の特性と一致します。 Application Gateway は、クライアントに対して HTTP 403 禁止応答を提示します。

WAF の誤検知 (WAF ルールによってブロックされる正当な要求) をトラブルシューティングするには、次の手順に従います。

  1. WAF 診断ログを有効にし、ruleId_s フィールドを確認して、要求をブロックしているルールを特定します。
  2. WAF を 検出モード に一時的に切り替えて、トラフィックをブロックせずに一致するルールをログに記録します。 この方法は、ルールを変更する前に誤検知を確認するのに役立ちます。 詳細については、WAF ポリシーの設定 に関するページをご覧ください。
  3. 誤検知をトリガーする特定の要求属性 (ヘッダー、Cookie、または引数) の WAF 除外 を作成します。
  4. マネージド ルールによって誤検知が一貫して発生し、除外が十分でない場合は、WAF ポリシーで 個々のルールを無効にします 。

詳細なガイダンスについては、 Application Gateway と WAF のベスト プラクティスに関する WAF のトラブルシューティング を参照 してください。

クライアントが HTTP 403 応答を受信するその他の理由は次のとおりです。

  • h2c プロトコルのアップグレード試行。 クライアントが h2c プロトコル (HTTP/2 Cleartext) を使用して HTTP/1.1 から HTTP/2.0 にアップグレードしようとすると、Application Gateway から HTTP 403 エラーが返されます。 Application Gateway では、トランスポート層セキュリティ (TLS) (HTTPS リスナー) 経由の HTTP/2 のみがサポートされます。 HTTP リスナー経由での h2c プロトコルのアップグレードはサポートされていません。 この動作は、WAF モードに関係なく発生します。 クライアントは、HTTPS 経由でネイティブ HTTP/2 接続を使用するか、アップグレードを試みずに HTTP/1.1 に残る必要があります。
  • バックエンドとしてAzure App Serviceを使用しており、Application Gateway からのアクセスのみを許可するように構成しました。 この構成では、App Services によって HTTP 403 エラーが返される可能性があります。 通常、このエラーは、Application Gateway の IP アドレスを指すのではなく、App Services を直接指すリダイレクトまたは href リンクが原因で発生します。
  • ストレージ BLOB にアクセスしていて、Application Gateway とストレージ エンドポイントが異なるリージョンにある場合は、Application Gateway のパブリック IP アドレスが許可されていない場合、HTTP 403 エラーが返されます。 詳細については、「 インターネット IP 範囲からのアクセスを許可する」を参照してください。

404 - ページが見つかりません

Application Gateway (v2 SKU) は、構成されているマルチサイト リスナーのいずれにも対応せず、基本的なリスナーが存在しないホスト名で要求を行うと、HTTP 404 応答を生成します。 詳細については、 リスナーの種類を参照してください。

408 – リクエスト タイムアウト

Application Gateway のフロントエンド リスナーに対するクライアント要求が 60 秒以内に応答しない場合、HTTP 408 応答が発生します。 このエラーは、オンプレミス ネットワークとAzure間のトラフィックの輻輳、仮想アプライアンスによるトラフィックの検査、またはクライアント自体の負荷が大きくなるために発生する可能性があります。

413 – 要求エンティティが大きすぎます

Application Gateway でAzure Web Application Firewallを使用しているときに HTTP 413 応答が発生し、クライアント要求サイズが最大要求本文サイズの制限を超えています。 最大要求本文サイズ フィールドを使って、要求全体 (ファイルのアップロードは除く) のサイズ制限を制御します。 要求本文のサイズの既定値は 128 KB です。 詳細については、「Web Application Firewall要求サイズの制限」を参照>。

499 – クライアントが接続を閉じた

v2 SKU を使用してアプリケーション ゲートウェイに送信したクライアント要求がサーバーの応答を終了する前に閉じられた場合、HTTP 499 応答が発生します。 このエラーは、次の 2 つのシナリオで発生します。

  • 大きな応答がクライアントに返され、サーバーが大きな応答の送信を完了する前に、クライアントがアプリケーションを閉じたか更新したとき。
  • クライアント側のタイムアウトが低く、サーバーからの応答を受信するのに十分な時間待機しない場合。 この場合は、クライアントのタイムアウトを増やす方が良いです。 v1 SKU を使用するアプリケーション ゲートウェイでは、サーバーが応答を終了する前に、クライアントが接続を閉じるために HTTP 0 応答コードが発生する可能性があります。

5XX 応答コード (サーバー エラー)

HTTP 500-599 応答コードは、要求の実行中に Application Gateway またはバックエンド サーバーに問題があることを示します。

500 – 内部サーバー エラー

Azure Application Gateway は、500 個の応答コードを返すべきではありません。 この問題はサービスの内部エラーであるため、このコードが表示される場合は、サポート リクエストを開きます。 サポート ケースを開く方法については、「Azure サポート 要求を作成するを参照してください。

502 – ゲートウェイが正しくありません

HTTP 502 エラーには、次のようないくつかの根本原因が考えられます。

HTTP 502 エラーが発生するシナリオとそのトラブルシューティング方法については、「 無効なゲートウェイ エラーのトラブルシューティング」を参照してください。

503 – サービスを利用できない

HTTP 503 応答は、Application Gateway またはバックエンド サーバーが一時的に要求を処理できないことを示します。 一般的な原因は次のとおりです。

  • すべてのバックエンド プール メンバーは正常性プローブによって不健康と判断され、要求を処理できる健康なサーバーはありません。
  • バックエンド サーバーが過負荷になっているか、メンテナンスが行われ、HTTP 503 が Application Gateway に直接返されます。
  • Application Gateway v2 の自動スケールが進行中であり、新しいインスタンスはまだトラフィックを処理する準備ができていません。
  • Application Gateway またはバックエンド サーバーで接続の制限に達しました。

503 エラーのトラブルシューティングを行うには、次の手順に従います。

  1. Azure portal の [バックエンドの正常性 ] ウィンドウで、バックエンド プールのメンバーの状態を確認します。
  2. 正常性プローブの構成を確認して、プローブが正常なバックエンドを異常として誤ってマークしていないことを確認します。 詳細については、ヘルスプローブの概要を参照してください。
  3. Application Gateway をバイパスして、バックエンド アプリケーションに直接アクセスして、バックエンド アプリケーションが動作していることを確認します。
  4. Azure Monitor での接続数と容量ユニットの使用率については、Application Gateway のメトリックを確認します。
  5. v2 SKU の場合は、自動スケール設定を確認して、トラフィックの急増時に十分な最小インスタンス数を確認します。

詳細については、「 Application Gateway でのバックエンドの正常性に関する問題のトラブルシューティング」を参照してください。

504 – ゲートウェイのタイムアウト

バックエンドの応答時間がバックエンド設定で構成したタイムアウト値を超えた場合、Application Gateway v2 SKU は HTTP 504 エラーを送信します。

インターネット インフォメーション サービス (IIS) Web サーバー

バックエンド サーバーが IIS の場合は、「 Web サイトの既定の制限 」を参照してタイムアウト値を設定します。 詳細については、connectionTimeout 属性を参照してください。 IIS の接続タイムアウトが、バックエンド設定で設定されたタイムアウトと一致するか、超えていないことを確認します。

Nginx

バックエンド サーバーが Nginx または Nginx イングレス コントローラーであり、アップストリーム サーバーがある場合は、 nginx:proxy_read_timeout の値がバックエンド設定で設定されたタイムアウト値と一致するか超えていないことを確認します。

トラブルシューティングのシナリオ

アクセス ログの "ERRORINFO_INVALID_HEADER" エラー

問題

バックエンド応答コード (serverStatus) が200されている場合でも、Access ログには要求のERRORINFO_INVALID_HEADER エラーが表示されます。 それ以外の場合、バックエンド サーバーは 500を返します。

原因

クライアントは、キャリッジリターン (CR) 文字とラインフィード (LF) 文字を含むヘッダーを送信します。

Solution

CR LF 文字を Space (SP) に置き換え、Application Gateway に要求を再送信します。

  • Last updated on