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

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

注

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

重要

Azure Front Door(classic)は2027年3月31日に廃止されます。 サービスが終了するため、プロファイル作成、新規ドメインオンボーディング、管理証明書のサポートは終了しています。 サービスの中断を回避するには、Azure Front Door Standard または Premium に移行してください。 詳細については、「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: 無効な要求エラーで要求が拒否されます。

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

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

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

インカミング フロントエンドホスト 一致したルーティング規則
foo.contoso.com A、B
www.fabrikam.com C
images.fabrikam.com エラー 404: 要求が正しくありません
foo.adventure-works.com C
contoso.com エラー 404: 要求が正しくありません
www.adventure-works.com エラー 404: 要求が正しくありません
www.northwindtraders.com エラー 404: 要求が正しくありません

Path の照合

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

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

注

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

注

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

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

ルーティング ルール フロントエンド ホスト 経路
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 経路
A profile.contoso.com /api/*

マッチングテーブル

受信リクエスト 一致するルート
profile.domain.com/other なし。 エラー 404: 要求が正しくありません

ルーティングの決定

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

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

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

次のステップ

  • Last updated on