Application Gateway の HTTP 応答コード
この記事では、Azure Application Gateway から特定の HTTP 応答コードが返される理由について説明します。 エラー HTTP 応答コードの根本原因を特定するのに役立つ一般的な原因とトラブルシューティング手順を示します。 バックエンド ターゲットへの接続が開始されたかどうかにかかわらず、クライアント要求に対して HTTP 応答コードが返される可能性があります。
3XX 応答コード (リダイレクト)
リダイレクトが構成されたアプリケーション ゲートウェイ ルールとクライアント要求が一致すると、300 から 399 の応答が表示されます。 リダイレクトは、ルールでそのまま構成することも、パス マップ ルールを使用して構成することもできます。 リダイレクトの詳細については、「Application Gateway のリダイレクトの概要」を参照してください。
301 Permanent Redirect (301 永続的なリダイレクト)
HTTP 301 応答は、リダイレクト ルールが Permanent の値を使用して指定されたときに表示されます。
302 Found (302 検出)
HTTP 302 応答は、リダイレクト ルールが Found の値を使用して指定されたときに表示されます。
303 See Other (303 他を参照)
HTTP 302 応答は、リダイレクト ルールが See Other の値を使用して指定されたときに表示されます。
307 Temporary Redirect (307 一時的なリダイレクト)
HTTP 307 応答は、リダイレクト ルールが Temporary の値を使用して指定されたときに表示されます。
4XX 応答コード (クライアント エラー)
400 から 499 の応答コードは、クライアントで開始された問題を示します。 これらの問題は、クライアントが開始する要求から、ホスト名の不一致、要求のタイムアウト、認証されない要求、悪意のある要求など、さまざまなものに及びます。
Application Gateway は、4xx/5xx 状態コードの分布をキャプチャするメトリックを収集し、URI クライアント IP アドレスなどの情報を応答コードでキャプチャするログ メカニズムを備えています。 メトリックとログを使って、さらなるトラブルシューティングが可能です。 クライアントは、クライアント デバイスと Application Gateway の間の他のプロキシから 4xx 応答を受信することもできます。 たとえば、CDN やその他の認証プロバイダーなどです。 詳しくは、以下の記事をご覧ください。
Application Gateway V2 SKU でサポートされるメトリック診断ログ
400 – 不正な要求
HTTP 400 応答コードは、一般に、次の場合に検出されます。
- HTTP または HTTPS リスナーを含むアプリケーション ゲートウェイに対して、HTTP/HTTPS 以外のトラフィックが開始されました。
- リダイレクトが構成されていない状態で、HTTPS を使用してリスナーに対する HTTP トラフィックが開始されました。
- 相互認証が構成されていて、適切にネゴシエートできません。
- 要求が RFC に準拠していません。
要求が RFC に準拠していない一般的な理由には、次のものがあります。
| カテゴリ | 例 |
|---|---|
| 要求行のホストが無効 | ホストにコロンが 2 つ含まれる (example.com:8090:8080) |
| ホスト ヘッダーがない | 要求にホスト ヘッダーがない |
| 形式に誤りがある、または無効な文字がある | 予約文字は &,!. 回避策は、パーセンテージでコーディングすることです。 例: %& |
| HTTP バージョンが無効 | Get /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 クライアント失効チェックは有効になっていますが、そこに接続できません。
- OCSP クライアント失効チェックは有効になっていますが、OCSP レスポンダーが証明書に記載されていません。
相互認証のトラブルシューティングの詳細については、「エラー コードのトラブルシューティング」を参照してください。
401 – 未承認
HTTP 401 未承認応答は、クライアントがリソースへのアクセスを認可されていない場合にクライアントに返されます。 401 が返される理由は複数あります。 いくつかの理由と考えられる解決策を次に示します。
- クライアントにアクセス権がある場合は、古いブラウザー キャッシュが存在する可能性があります。 ブラウザー キャッシュをクリアし、もう一度アプリケーションにアクセスしてみてください。
バックエンド プールが NTLM 認証で構成されている場合、HTTP 401 未承認応答が AppGW プローブ要求に返される可能性があります。 このシナリオでは、バックエンドは正常としてマークされます。 この問題を解決する方法はいくつかあります。
- バックエンド プールでの匿名アクセスを許可します。
- NTLM を必要としない別の "偽" サイトに要求を送信するようにプローブを構成します。
- これは、アプリケーション ゲートウェイの背後にある実際のサイトがアクティブかどうかがわからないため、お勧めしません。
- プローブに対して有効な 401 応答を許可するようにアプリケーション ゲートウェイを構成します。プローブの一致条件。
403 – 使用不可能
HTTP 403 (使用不可能) は、顧客が WAF SKU を利用していて、WAF が防止モードで構成されている場合に表示されます。 有効な WAF ルールセットまたはカスタムの拒否の WAF ルールが受信要求の特性と一致する場合、クライアントには 403 禁止応答が表示されます。
クライアントが 403 応答を受信するその他の理由は次のとおりです。
- App Service をバックエンドとして使用しており、Application Gateway からのアクセスのみを許可するように構成されています。 この場合、App Services から 403 エラーが返される可能性があります。 これは通常、Application Gateway の IP アドレスを指すのではなく、App Services を直接指すリダイレクト/href リンクが原因で発生します。
- ストレージ ブログにアクセスしていて、Application Gateway とストレージ エンドポイントが異なるリージョンにある場合、Application Gateway のパブリック IP アドレスが許可リストにないと、403 エラーが返されます。 「インターネットの IP 範囲からのアクセスを許可する」を参照してください。
404 - ページが見つかりません
要求が次のようなアプリケーション ゲートウェイに送信された場合、HTTP 404 応答が返される可能性があります。
- v2 SKU を使用している。
- どのマルチサイト リスナーでもホスト名の一致が定義されていない。
- 基本リスナーを使用して構成されていない。
408 - 要求タイムアウト
HTTP 408 応答は、アプリケーション ゲートウェイのフロントエンド リスナーに対するクライアント要求が 60 秒以内に応答しない場合に表示される可能性があります。 このエラーが表示される原因として、オンプレミス ネットワークと Azure の間のトラフィックの輻輳、仮想アプライアンスによるトラフィックの検査、またはクライアント自体が過負荷になったことが考えられます。
413 – 要求エンティティが大きすぎる
HTTP 413 応答は、Application Gateway 上の Azure Web Application Firewall を使用していて、クライアント要求サイズが最大要求本文サイズの制限を超えている場合に表示される可能性があります。 最大要求本文サイズ フィールドを使って、要求全体 (ファイルのアップロードは除く) のサイズ制限を制御します。 要求本文のサイズの既定値は 128 KB です。 詳細については、「Web Application Firewall 要求サイズ制限」を参照してください。
499 – クライアントが接続を閉じた
HTTP 499 応答が表示されるのは、v2 SKU を使用してアプリケーション ゲートウェイに送信されたクライアント要求が、サーバーによる応答が終了する前に閉じられた場合です。 このエラーは、2 つのシナリオで表示される可能性があります。 1 番目のシナリオは、大きな応答がクライアントに返され、サーバーが大きな応答の送信を完了する前に、クライアントがアプリケーションを閉じるか、更新したような場合です。 2 番目のシナリオは、クライアント側のタイムアウトが短く、サーバーからの応答の受信に十分な時間待機しなかった場合です。 この場合は、クライアントのタイムアウトを増やすことをお勧めします。 v1 SKU を使うアプリケーション ゲートウェイでは、サーバーの応答が完了する前に、クライアントが接続を閉じると、HTTP 0 応答コードも発生する可能性があります。
5XX 応答コード (サーバー エラー)
500 から 599 の応答コードは、要求の実行中にアプリケーション ゲートウェイまたはバックエンド サーバーで問題が発生したことを示します。
500 - 内部サーバー エラー
Azure Application Gateway で 500 の応答コードが表示されてはなりません。 この問題はサービスの内部エラーであるため、このコードが表示された場合はサポート リクエストを開いてください。 サポート ケースを開く方法については、「Azure サポート リクエストを作成する」を参照してください。
502 - 無効なゲートウェイ
HTTP 502 エラーには、次のようないくつかの根本原因が考えられます。
- NSG、UDR、またはカスタム DNS が、バックエンド プールのメンバーへのアクセスをブロックしている。
- バックエンド VM または仮想マシン スケール セットのインスタンスが既定の正常性プローブに応答していない。
- カスタムの正常性プローブの構成が無効または不適切である。
- Azure Application Gateway のバックエンド プールが構成されていないか、空である。
- 仮想マシン スケール セット内に正常な VM またはインスタンスがない。
- 要求のタイムアウトまたはユーザー要求の接続の問題 - バックエンドの応答時間がバックエンド設定で構成されているタイムアウト値を超えた場合、Azure Application Gateway V1 SKU から HTTP 502 エラーが送信されます。
502 エラーが発生するシナリオとそのトラブルシューティングの実行方法については、「無効なゲートウェイ エラーのトラブルシューティング」を参照してください。
504 - ゲートウェイ タイムアウト
バックエンドの応答時間がバックエンド設定で構成されているタイムアウト値を超えた場合、Azure Application Gateway V2 SKU から HTTP 504 エラーが送信されます。
IIS
バックエンド サーバーが IIS の場合は、「Web サイトの既定の制限」を参照して、タイムアウト値を設定します。 詳細については、connectionTimeout 属性を参照してください。 IIS の接続タイムアウトがバックエンド設定で設定されたタイムアウトと一致するか、超えないようにします。
nginx
バックエンド サーバーが nginx または nginx イングレス コントローラーであり、アップストリーム サーバーがある場合は、nginx:proxy_read_timeout の値がバックエンド設定で設定されたタイムアウト値と一致するか、超えないようにします。
次のステップ
この記事の情報を参照しても問題を解決できない場合は、サポート チケットを送信してください。