Application Gateway の HTTP 応答コード

概要

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

注

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

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

クライアント要求が、リダイレクトが構成されているアプリケーションゲートウェイルールと一致すると、Application Gateway から 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 応答コード (クライアントエラー)

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

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

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 要求に Content-Length ヘッダーがない	説明不要
HTTP メソッドが無効	GET123 /index.html HTTP/1.1
ヘッダーが重複している	認可:<base64 エンコードされたコンテンツ>、認可: <base64 エンコードされたコンテンツ>
Content-Length の値が無効	Content-Length: abc、Content-Length: -10

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

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

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

401 – 認証されていません

クライアントがリソースへのアクセスを許可されていない場合、Application Gateway はクライアントに HTTP 401 未承認の応答を返します。 401 が返される理由はいくつかあります。次の一覧では、修正の可能性があるいくつかの理由を示します。

クライアントにアクセス権がある場合は、古いブラウザーキャッシュが存在する可能性があります。ブラウザーキャッシュをクリアし、もう一度アプリケーションにアクセスしてみてください。

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

バックエンドプールでの匿名アクセスを許可します。
NTLM を必要としない別の "偽" サイトに要求を送信するようにプローブを構成します。
このソリューションでは、アプリケーションゲートウェイの背後にある実際のサイトがアクティブかどうかが示されないため、お勧めしません。
プローブに対して有効な 401 応答を許可するようにアプリケーションゲートウェイを構成します。プローブの一致条件。

403 – 禁止

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

WAF の誤検知 (WAF ルールによってブロックされた正当な要求) をトラブルシューティングするには:

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

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

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

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

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

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

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 つのシナリオで確認できます。 1 番目のシナリオは、大きな応答がクライアントに返され、サーバーが大きな応答の送信を完了する前に、クライアントがアプリケーションを閉じるか、更新したような場合です。 2 番目のシナリオは、クライアント側のタイムアウトが低く、サーバーからの応答を受信するのに十分な時間待機しない場合です。この場合は、クライアントのタイムアウトを増やす方が良いです。 v1 SKU を使用するアプリケーションゲートウェイでは、サーバーの応答が完了する前に、クライアントが接続を閉じるために HTTP 0 応答コードが発生する可能性があります。

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

500 から 599 の応答コードは、要求の実行中にアプリケーションゲートウェイまたはバックエンドサーバーに問題があることを示します。

500 – 内部サーバーエラー

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

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

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

NSG (ネットワークセキュリティグループ)、UDR (ユーザー定義ルート)、またはカスタム DNS がバックエンドプールメンバーへのアクセスをブロックしています。
バックエンド VM または仮想マシンスケールセットのインスタンスが既定の正常性プローブに応答していない。
カスタム正常性プローブの構成が無効または不適切である。
Azure Application Gatewayのバックエンドプールが構成されていないか、空ではありません。
仮想マシンスケールセット内に正常な VM またはインスタンスがない。
ユーザー要求におけるタイムアウトまたは接続の問題により、Azure Application Gateway V1 SKU は、バックエンドの応答時間がバックエンド設定で構成されたタイムアウト値を超えた場合に HTTP 502 エラーを送信します。

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

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

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

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

503 エラーをトラブルシューティングするには:

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

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

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

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

IIS (Internet Information Services Web サーバー)

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

Nginx

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

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

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

問題: バックエンド応答コード (serverStatus) が 200 であっても、アクセスログに要求の "ERRORINFO_INVALID_HEADER" エラーが表示されます。それ以外の場合、バックエンドサーバーは 500 を返します。

原因: クライアントは CR LF 文字を含むヘッダーを送信します。

解決策: CR LF 文字を SP (空白) に置き換え、Application Gateway に要求を再送信します。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-03-27