次の方法で共有

要求とルート構成のマッチング方法

  • [アーティクル]

Azure Front Door の "ルート" は、受信要求が Azure Front Door エッジに着信したときのトラフィックの処理方法を定義します。 ルート設定が、ドメインと配信元グループとの間の関連付けを定義します。 [一致させるパターン] や [ルール セット] などの高度な機能を使用することで、バックエンド リソースへのトラフィックをきめ細かく制御できます。

Note

Front Door ルール セットを使用する場合は、要求の配信元グループをオーバーライドするルールを構成できます。 ルール セットによって設定される配信元グループによって、この記事で説明しているルーティング処理がオーバーライドされます。

重要

Azure Front Door (クラシック) は、2027 年 3 月 31 日に廃止されます。 サービスの中断を回避するには、2027 年 3 月までに Azure Front Door の Standard または Premium レベルに Azure Front Door (クラシック) プロファイルを移行することが重要です。 詳細については、Azure Front Door (クラシック) の廃止に関するページを参照してください。

Azure Front Door (クラシック) エッジに要求が着信したときの最初の手順の 1 つは、一致する要求をバックエンド リソースにルーティングする方法を決定することであり、その後にルーティング構成で定義されているアクションを実行します。 このドキュメントでは、要求を処理するときに、使用するルート構成を Front Door が判定する方法について説明します。

Front Door のルート構成の構造

Front Door のルーティング規則は、"左側" と "右側" の 2 つの主要部分で構成されています。 Front Door が、受信要求をルートの左側と照合する一方、右側は、その要求の処理方法を定義します。

着信の照合 (左側)

次のプロパティが、着信要求がルーティング規則 (左側) と一致するかどうかを決定します。

  • HTTP プロトコル (HTTP または HTTPS)
  • ドメイン (例: www.foo.com、*.bar.com)
  • パス (例: /*、/users/*、/file.gif)

これらのプロパティは内部で展開されるため、プロトコル/ドメイン/パスのすべての組み合わせが照合対象になる可能性があります。

ルーティングの決定 (右側)

要求の処理方法についての決定は、ルートに対してキャッシュが有効になっているかどうかで変わります。 キャッシュされた応答を使用できない場合、要求は該当する配信元に転送されます。

ルートの照合

このセクションでは、Front Door が要求をルーティング規則と照合する方法について説明します。 基本的な原則として、Front Door は、プロトコル、ドメイン、パスという "左側" のプロパティをその順序で評価することによって、常に最も限定的な要求と照合します。

フロント エンド ホストの照合

Azure Front Door は、次の手順を使用してフロントエンド ホストを照合します。

  1. フロントエンド ホストで、完全一致のルートを確認します。
  2. 完全一致が見つからない場合、要求は 404: Bad Request エラーで拒否されます。

次の表に、フロントエンド ホストおよびパスとともに 3 つの異なるルーティング規則を示します。

ルーティング ルール フロント エンド ホスト Path
A foo.contoso.com /*
B foo.contoso.com /users/*
C www.fabrikam.com、foo.adventure-works.com /*、/images/*

次の表に、前の表のルーティング規則に対する照合結果を示します。

着信のフロント エンド ホスト 一致したルーティング規則
foo.contoso.com A、B
www.fabrikam.com C
images.fabrikam.com Error 404: Bad Request
foo.adventure-works.com C
contoso.com Error 404: Bad Request
www.adventure-works.com Error 404: Bad Request
www.northwindtraders.com Error 404: Bad Request

Path の照合

Azure Front Door は、特定のフロントエンド ホストを決定し、可能なルーティング規則をフィルターで抽出したら、要求されたパスに基づいてルーティング規則を選択します。 次のロジックが使用されます。

  1. 要求パスと完全一致のルーティング規則を確認します。
  2. 完全一致が見つからない場合、一致するワイルドカード パスが含まれるルーティング規則を探します。
  3. 一致するパスが見つからない場合、要求は 404: Bad Request エラーで拒否されます。

Note

ワイルドカード文字 * は、その後に他の文字がないパスでのみ有効です。 さらに、ワイルドカード文字 * の前にスラッシュ / を付ける必要があります。 ワイルドカードがないパスは、完全一致のパスとみなされます。 スラッシュ / で終わるパスも完全一致パスです。 エラーを回避するには、パスをこれらの規則に従うように設定します。

Note

  • ワイルドカードがないパスは、完全一致のパスとみなされます。 / で終わるパスも完全一致です。
  • パスのパターンでは大文字と小文字が区別されません。 たとえば、/FOO と /foo は重複として扱われ、[照合するパターン] 設定では使用できません。

次の表に、フロントエンド ホストとパスの組み合わせとともに、ルーティング規則を示します。

ルーティング ルール フロントエンド ホスト Path
A www.contoso.com /
B www.contoso.com /*
C www.contoso.com /ab
D www.contoso.com /abc
E www.contoso.com /abc/
F www.contoso.com /abc/*
G www.contoso.com /abc/def
H www.contoso.com /path/

次の表に、Azure Front Door エッジでの着信要求と一致するルーティング規則を示します。

着信要求 一致するルート
www.contoso.com/ A
www.contoso.com/a B
www.contoso.com/ab C
www.contoso.com/abc D
www.contoso.com/abzzz B
www.contoso.com/abc/ E
www.contoso.com/abc/d F
www.contoso.com/abc/def G
www.contoso.com/abc/defzzz| F
www.contoso.com/abc/def/ghi| F
www.contoso.com/path B
www.contoso.com/path/ H
www.contoso.com/path/zzz B

警告

キャッチオール ルート パス (/*) がない完全一致のフロントエンド ホストに対するルーティング規則が存在しない場合、どのルーティング規則とも照合されません。

構成の例

ルート Host Path
A profile.contoso.com /api/*

照合テーブル

着信要求 一致するルート
profile.domain.com/other なし。 Error 404: Bad Request

ルーティングの決定

Azure Front Door は、ルーティング規則を照合したら、要求の処理方法を決定します。 キャッシュされた応答が使用可能な場合は、それがクライアントに返されます。

一致したルーティング規則に対してルール セットが構成されている場合は、それが順番に処理されます。 ルール セットは、トラフィックを特定の配信元グループに転送するために、ルートをオーバーライドできます。 ルール セットが定義されていない場合、要求は変更されることなく配信元グループに転送されます。

Azure Front Door (クラシック) にキャッシュされた応答がない場合は、URL 書き換え構成が確認されます。 カスタム転送パスが定義されていない場合、その要求は、構成されているバックエンド プール内の該当するバックエンドに転送されます。 カスタム転送パスが定義されている場合、それに従って要求パスが更新されてから、バックエンドに転送されます。

次のステップ