次の方法で共有


Application Gateway の HTTP 応答コード

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

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

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

301 Permanent Redirect (301 永続的なリダイレクト)

HTTP 301 応答は、リダイレクト ルールが Permanent の値を使用して指定されたときに表示されます。

302 検出

HTTP 302 応答は、リダイレクト ルールが Found の値を使用して指定されたときに表示されます。

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 (Content Delivery Network) やその他の認証プロバイダーなどです。 詳しくは、以下の記事をご覧ください。

Application Gateway V2 SKU でサポートされるメトリック診断ログ

400 – 不正な要求

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

  • HTTP または HTTPS リスナーを含むアプリケーション ゲートウェイに対して、HTTP/HTTPS 以外のトラフィックが開始されました。
  • リダイレクトが構成されていない状態で、HTTPS を使用してリスナーに対する HTTP トラフィックが開始されました。
  • 相互認証が構成されていて、適切にネゴシエートできません。
  • 要求が 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 (オンライン証明書ステータス プロトコル) クライアント失効チェックは有効ですが、接続できません。
  • OCSP (オンライン証明書ステータス プロトコル) クライアント失効チェックが有効になっていますが、OCSP レスポンダーは証明書で提供されません。

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

401 – 認証されていません

HTTP 401 未承認応答は、クライアントがリソースへのアクセスを認可されていない場合にクライアントに返されます。 401 が返される理由は複数あります。 いくつかの理由と考えられる解決策を次に示します。

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

バックエンド プールが NTLM 認証で構成されている場合、HTTP 401 未承認応答が AppGW プローブ要求に返される可能性があります。 このシナリオでは、バックエンドは正常としてマークされます。 この問題を解決する方法はいくつかあります。

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

403 – 禁止

HTTP 403 Forbidden は、お客様が WAF (Web アプリケーション ファイアウォール) 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 応答は、構成されているマルチサイト リスナーのいずれにも対応しないホスト名を持つ Application Gateway (V2 SKU) に対して要求が行われ、Basic リスナーが存在しない場合に生成されます。 リスナーの種類の詳細を確認します。

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 エラーには、次のようないくつかの根本原因が考えられます。

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

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

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

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

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

エンジックス

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

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

Access ログの "ERRORINFO_INVALID_HEADER" エラー

問題: バックエンド応答コード (serverStatus) が 200 であるにもかかわらず、 アクセス ログ に要求の "ERRORINFO_INVALID_HEADER" エラーが表示されます。 それ以外の場合は、バックエンド サーバーから 500 が返される可能性があります。

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

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

次のステップ

この記事の情報を参照しても問題を解決できない場合は、サポート チケットを送信してください。