次の方法で共有

Azure Front Door の一般的な問題のトラブルシューティング

  • [アーティクル]

この記事では、Azure Front Door の構成で、よく発生する可能性のあるルーティングの問題をトラブルシューティングする方法について説明します。

その他のデバッグ HTTP ヘッダー

Azure Front Door に追加のデバッグ HTTP 応答ヘッダーを返すように要求できます。 詳細については、省略可能な応答ヘッダーに関するページを参照してください。

数秒後に Azure Front Door から 503 または 504 応答

症状

  • Azure Front Door を経由しないでバックエンドに送信される通常の要求は成功します。 Azure Front Door を経由すると、503 または 504 エラー応答が返されます。
  • Azure Front Door からのエラーは、通常約 30 秒後に表示されます。
  • 間欠的な 503 エラーは "ErrorInfo: OriginInvalidResponse" と共に表示されます。

原因

この問題の原因は、次の 3 つのいずれかである可能性があります。

  • 配信元で、Azure Front Door から要求を受信するために構成されているタイムアウトよりも長い時間がかかっています。 既定のタイムアウトは 30 秒です。
  • Azure Front Door からの要求に対して応答を送信するのに、タイムアウト値よりも長い時間がかかっています。
  • クライアントは、バイト範囲要求を Accept-Encoding ヘッダーと共に送信しました。これは、圧縮が有効になっていることを意味します。

トラブルシューティングの手順

  • 要求を Azure Front Door を経由することなく、配信元に直接送信します。 配信元からの応答に通常かかる時間を確認します。

  • Azure Front Door 経由で要求を送信し、何らかの 503 応答を受け取るかどうかを確認します。 そうでない場合は、タイムアウトの問題ではない可能性があります。 さらに問題のトラブルシューティングを行うには、サポート リクエストを作成します。

  • Azure Front Door 経由の要求により 503 エラー応答コードが発生する場合は、Azure Front Door の [Origin response timeout] (配信元の応答タイムアウト) を構成します。 既定のタイムアウトは、最大 4 分 (240 秒) まで増やすことができます。 設定を構成するには、Azure Front Door プロファイルの概要ページに移動します。 [配信元の応答タイムアウト] を選択し、16 秒から 240 秒の間の値を入力します。

    Note

    配信元の応答タイムアウトを構成する機能は、Azure Front Door Standard/Premium でのみ使用できます。

    Azure Front Door プロファイルの [概要] ページでの配信元のタイムアウト設定のスクリーンショット。

  • タイムアウトを増やしても問題が解決しない場合は、Fiddler のようなツールやブラウザーの開発者ツールを使用して、クライアントから Accept-Encoding ヘッダーと共にバイト範囲要求を送信しているかどうかを確認します。 このオプションを使用すると、配信元がさまざまなコンテンツの長さに対応することになります。

    クライアントが、Accept Encoding ヘッダーを使用してバイト範囲要求を送信している場合には、2 つのオプションがあります。 最初のオプションは、配信元または Azure Front Door で圧縮を無効にすることです。 2 つ目のオプションは、バイト範囲要求の要求から Accept-Encoding を削除するルール セット ルールを作成することです。

    ルール セット内の Accept-Encoding ルールを示すスクリーンショット。

HTTPS に対してのみ Azure Front Door からの 503 応答

症状

  • 503 応答は、Azure Front Door の HTTPS が有効なエンドポイントに対してのみ返されます。
  • Azure Front Door を経由しないでバックエンドに送信される通常の要求は成功します。 Azure Front Door を経由すると、503 エラー応答が返されます。
  • 間欠的な 503 エラーは "ErrorInfo: OriginInvalidResponse" と共に表示されます。

原因

この問題の原因は、次の 3 つのいずれかである可能性があります。

  • バックエンドが IP アドレスである。
  • バックエンド サーバーは、Azure Front Door バックエンドの完全修飾ドメイン名 (FQDN) と一致しない証明書を返します。
  • バックエンドが Azure Web Apps サーバーである。

トラブルシューティングの手順

  • バックエンドが IP アドレスである。

    EnforceCertificateNameCheck を無効にする必要があります。

    Azure Front Door には、EnforceCertificateNameCheck というスイッチがあります。 既定では、この設定が有効になっています。 有効にすると、バックエンドのホスト名の FQDN が、バックエンド サーバー証明書の証明書名、またはサブジェクトの別名拡張のいずれかのエントリと一致していることが Azure Front Door によって確認されます。

    • Azure portal から EnforceCertificateNameCheck を無効にする方法:

      ポータルで、トグル ボタンを使用して、Azure Front Door (クラシック) の[デザイン] ペインのこの設定をオンまたはオフにします。

      トグル ボタンを示すスクリーンショット。

      Azure Front Door の Standard と Premium レベルの場合、配信元グループに配信元を追加したり、ルートを構成したりすると、この設定が [配信元の設定] に表示されます。

      証明書のサブジェクト名の検証チェックボックスのスクリーンショット。

  • バックエンド サーバーは、Azure Front Door バックエンドの FQDN と一致しない証明書を返します。 この問題を解決するには、次の 2 つのオプションがあります。

    • 返される証明書は FQDN と一致している必要があります。
    • EnforceCertificateNameCheck を無効にする必要があります。

  • バックエンドが Azure Web Apps サーバーである。

    • Azure Web アプリが SNI (Server Name Indication) ベースではなく IP ベースの SSL で構成されているかどうかを調べます。 Web アプリが IP ベースとして構成されている場合は、SNI に変更する必要があります。
    • 証明書のエラーが原因でバックエンドが異常な場合は、503 エラー メッセージが返されます。 ポート 80 および 443 のバックエンドの正常性を確認できます。 443 だけが異常な場合は、SSL に問題がある可能性があります。 バックエンドは FQDN を使用するように構成されているため、SNI を送信していることがわかっています。

    OPENSSL を使用して、返される証明書を確認します。 この確認を行うには、-servername を使用してバックエンドに接続します。 バクエンドは SNI を返す必要があります。SNI はバックエンド プールの FQDN と一致している必要があります。

    openssl s_client -connect backendvm.contoso.com:443 -servername backendvm.contoso.com

カスタム ドメインに送信された要求で状態コード 400 が返される

症状

  • Azure Front Door インスタンスを作成しました。 ドメインまたはフロントエンド ホストへの要求は、HTTP 400 の状態コードを返します。
  • カスタム ドメインに対して、構成したフロントエンド ホストへの DNS (ドメイン ネーム サーバー) マッピングを作成しました。 カスタム ドメインのホスト名に要求を送信すると、HTTP 400 の状態コードが返されます。 構成したバックエンドにルーティングされているようには見えません。

原因

この問題は、フロントエンド ホストとして追加されたカスタム ドメインに対してルーティング規則を構成しなかった場合に発生します。 そのフロントエンド ホストに対して明示的にルーティング規則を追加する必要があります。 Azure Front Door サブドメイン (*.azurefd.net) 下でフロントエンド ホストに対してルーティング規則が既に構成されていた場合でも、ルールを作成する必要があります。

トラブルシューティングの手順

カスタム ドメインに対して、選択した配信元グループにトラフィックを送信するルーティング規則を追加します。

Azure Front Door によって HTTP が HTTPS にリダイレクトされない

症状

Azure Front Door には HTTP を HTTPS にリダイレクトするルーティング規則がありますが、ドメインへのアクセスではプロトコルとして HTTP が維持されます。

原因

この動作は、Azure Front Door のルーティング規則を正しく構成していない場合に発生する可能性があります。 現在の構成は固有ではなく、規則が競合している可能性があります。

トラブルシューティングの手順

フロントエンドのホスト名の要求で状態コード 411 が返される

症状

Azure Front Door の Standard/Premium インスタンスを作成し、次のように構成しました。

  • フロントエンド ホスト。
  • 少なくとも 1 つの配信元を持つ配信元グループ。
  • フロントエンド ホストを配信元のグループに接続するルーティング規則。

構成したフロントエンド ホストに要求を送信しても、HTTP 411 の状態コードが返されるのでコンテンツを利用できないようです。

これらの要求に対する応答には、説明文が記載された HTML エラー ページが応答本文に含まれる場合もあります。 一例は、"HTTP エラー 411。 要求がチャンクされているか、コンテンツの長さが指定されている必要があります。" というものです。

原因

この現象には、以下のような複数の原因が考えられます。 全体的な理由は、HTTP 要求が RFC に完全には準拠していないことです。

非準拠の例として、Content-Length ヘッダーまたは Transfer-Encoding ヘッダーなしで送信される POST 要求があります。 たとえば、curl -X POST https://example-front-door.domain.com を使用したものです。 この要求は RFC 7230 で設定されている要件を満たしていません。 それは Azure Front Door により HTTP 411 応答でブロックされます。 このような要求はログされません。

この動作は、Azure Front Door の Web アプリケーション ファイアウォール (WAF) 機能とは別のものです。 現時点では、この動作を無効にする方法はありません。 WAF の機能が使用されていない場合でも、すべての HTTP 要求で要件が満たされている必要があります。

トラブルシューティングの手順

  • 要求が、必要な RFC に規定されている要件に準拠していることを確認します。
  • 要求への応答として返された HTML メッセージの本文を記録しておきます。 多くの場合、メッセージ本文には、要求が "どのように" 非準拠であるかが説明されています。

配信元が IP アドレスとして構成されている。

症状

配信元が IP アドレスとして構成されています。 配信元は正常ですが、Azure Front Door からの要求を拒否しています。

原因

Azure Front Door では、SSL ハンドシェイク中に SNI ヘッダーとして配信元ホスト名が使用されます。 配信元が IP アドレスとして構成されているため、次のいずれかの理由で失敗する場合があります。

  • 証明書名のチェックが無効になっている場合、配信元の証明書ロジックが問題の原因である可能性があります。 このロジックで、証明書と一致する有効なホスト ヘッダーを持たない要求が拒否されている可能性があります。

トラブルシューティングの手順

配信元を IP アドレスから、配信元証明書と一致する有効な証明書が発行される FQDN に変更します。

Azure Front Door からの 429 の応答

症状

  • 429:の応答によってエラー表示を開始した要求の割合: 要求が多すぎます。

原因

  • Azure Front Door には、既定のプラットフォーム レート制限があります。 トラフィックが上限を超えると、AFD はトラフィックのレート制限を開始し、429 の応答を返します。

トラブルシューティングの手順

  • 正当なトラフィックに 429 表示が開始され、クォータ上限を上げる必要がある場合は、Azure サポート要求を作成します。

次のステップ