トレーニング
モジュール
Front Door を使用して Web サービスのトラフィックの負荷を分散する - Training
Web トラフィックを複数の Web サーバーに分散することで、Web アプリケーションの配信を高速化し、高可用性を維持します。
このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
この記事では、Azure Front Door の構成で、よく発生する可能性のあるルーティングの問題をトラブルシューティングする方法について説明します。
Azure Front Door に追加のデバッグ HTTP 応答ヘッダーを返すように要求できます。 詳細については、省略可能な応答ヘッダーに関するページを参照してください。
この問題の原因は、次の 3 つのいずれかである可能性があります。
要求を Azure Front Door を経由することなく、配信元に直接送信します。 配信元からの応答に通常かかる時間を確認します。
Azure Front Door 経由で要求を送信し、何らかの 503 応答を受け取るかどうかを確認します。 そうでない場合は、タイムアウトの問題ではない可能性があります。 さらに問題のトラブルシューティングを行うには、サポート リクエストを作成します。
Azure Front Door 経由の要求により 503 エラー応答コードが発生する場合は、Azure Front Door の [Origin response timeout] (配信元の応答タイムアウト) を構成します。 既定のタイムアウトは、最大 4 分 (240 秒) まで増やすことができます。 設定を構成するには、Azure Front Door プロファイルの概要ページに移動します。 [配信元の応答タイムアウト] を選択し、16 秒から 240 秒の間の値を入力します。
注意
配信元の応答タイムアウトを構成する機能は、Azure Front Door Standard/Premium でのみ使用できます。
タイムアウトを増やしても問題が解決しない場合は、Fiddler のようなツールやブラウザーの開発者ツールを使用して、クライアントから Accept-Encoding ヘッダーと共にバイト範囲要求を送信しているかどうかを確認します。 このオプションを使用すると、配信元がさまざまなコンテンツの長さに対応することになります。
クライアントが、Accept Encoding ヘッダーを使用してバイト範囲要求を送信している場合には、2 つのオプションがあります。 最初のオプションは、配信元または Azure Front Door で圧縮を無効にすることです。 2 つ目のオプションは、バイト範囲要求の要求から Accept-Encoding を削除するルール セット ルールを作成することです。
この問題の原因は、次の 3 つのいずれかである可能性があります。
バックエンド プールが 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 つのオプションがあります。
EnforceCertificateNameCheck
を無効にする必要があります。バックエンド プールが Azure Web Apps サーバーです。
OPENSSL を使用して、返される証明書を確認します。 この確認を行うには、-servername
を使用してバックエンドに接続します。 バクエンドは SNI を返す必要があります。SNI はバックエンド プールの FQDN と一致している必要があります。
openssl s_client -connect backendvm.contoso.com:443 -servername backendvm.contoso.com
この問題は、フロントエンド ホストとして追加されたカスタム ドメインに対してルーティング規則を構成しなかった場合に発生します。 そのフロントエンド ホストに対して明示的にルーティング規則を追加する必要があります。 Azure Front Door サブドメイン (*.azurefd.net) 下でフロントエンド ホストに対してルーティング規則が既に構成されていた場合でも、ルールを作成する必要があります。
カスタム ドメインに対して、選択した配信元グループにトラフィックを送信するルーティング規則を追加します。
Azure Front Door には HTTP を HTTPS にリダイレクトするルーティング規則がありますが、ドメインへのアクセスではプロトコルとして HTTP が維持されます。
この動作は、Azure Front Door のルーティング規則を正しく構成していない場合に発生する可能性があります。 現在の構成は固有ではなく、規則が競合している可能性があります。
Azure Front Door の Standard/Premium インスタンスを作成し、次のように構成しました。
構成したフロントエンド ホストに要求を送信しても、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 要求で要件が満たされている必要があります。
配信元が IP アドレスとして構成されています。 配信元は正常ですが、Azure Front Door からの要求を拒否しています。
Azure Front Door では、SSL ハンドシェイク中に SNI ヘッダーとして配信元ホスト名が使用されます。 配信元が IP アドレスとして構成されているため、次のいずれかの理由で失敗する場合があります。
配信元を IP アドレスから、配信元証明書と一致する有効な証明書が発行される FQDN に変更します。
トレーニング
モジュール
Front Door を使用して Web サービスのトラフィックの負荷を分散する - Training
Web トラフィックを複数の Web サーバーに分散することで、Web アプリケーションの配信を高速化し、高可用性を維持します。