Azure Front Door ルール エンジンのシナリオと構成

Azure Front Door ルール エンジンを使用すると、ユーザーは一致条件とアクションのペアを構成することで、Front Door エッジでの処理とルーティングロジックを簡単にカスタマイズできます。

受信要求からサポートされている 19 個の一致条件の組み合わせに基づいて、さまざまなルール アクション を定義できます。 これらのルールを使用すると、次のことができるようになります。

1. キャッシュ ポリシーを動的に管理する

2. 異なる配信元またはバージョンに要求を転送する

3. 要求ヘッダーまたは応答ヘッダーを変更して、機密情報を非表示にしたり、重要な情報をヘッダー経由でパススルーしたりします。 たとえば、次のようなブラウザーベースの脆弱性を防ぐためにセキュリティ ヘッダーを実装します。

   • HTTP strict-transport-security (HSTS)（HTTP厳格トランスポートセキュリティ）
   • X-XSS-protection
   • コンテンツセキュリティポリシー
   • X フレーム オプション
   • クロスオリジン リソース共有 (CORS) シナリオの Access-Control-Allow-Origin ヘッダー。 セキュリティベースの属性は、Cookie でも定義できます。

4. URL パスを書き換えるか、要求を新しい宛先にリダイレクトする

5. 正規表現変数とサーバー変数を使用して複雑なシナリオを有効にします。受信した要求または応答から動的な値をキャプチャし、静的文字列またはその他の変数と組み合わせます。

この記事では、Azure Front Door ルール エンジンでサポートされる一般的なユース ケースについて説明し、さまざまなビジネス要件と技術要件を満たす詳細な構成例を示します。

シナリオ 1: クエリ文字列、URL パス セグメント、または受信ホスト名キャプチャを使用してリダイレクトする

リダイレクトの管理は、検索エンジンの最適化 (SEO)、ユーザー エクスペリエンス、Web サイトの適切な機能にとって重要です。 Azure Front Door のルール エンジンとサーバー変数を使用すると、さまざまなパラメーターに基づいてバッチ リダイレクトを効率的に管理できます。

• クエリ文字列パラメーターに基づくリダイレクト: 特定のクエリ文字列キーの値を {http_req_arg_<key>}形式でキャプチャすることで、受信 URL のクエリ フィールドを使用して要求をリダイレクトできます。

  たとえば、 cdpb クエリ キーの値を受信 URL https://example.mydomain.com/testcontainer/123.zip?sig=fffff&cdpb=teststorageaccount から抽出し、それを使用して 送信先ホスト を送信 URL https://teststorageaccount.blob.core.windows.net/testcontainer/123.zip?sig=fffff&cdpb=teststorageaccountに構成します。

  この方法では、 cdpb 値ごとに個別のルールを作成しなくても動的リダイレクトが可能になり、必要なルールの数が大幅に減ります。

  ポータル

  

  腕

  {
      "type": "Microsoft.Cdn/profiles/rulesets/rules",
      "apiVersion": "2025-04-15",
      "name": "[concat(parameters('profiles_rulesengineblog_name'), '/RulesBlogScenarios/RedirectQueryStringCapture')]",
      "dependsOn": [
          "[resourceId('Microsoft.Cdn/profiles/rulesets', parameters('profiles_rulesengineblog_name'), 'RulesBlogScenarios')]",
          "[resourceId('Microsoft.Cdn/profiles', parameters('profiles_rulesengineblog_name'))]"
      ],
      "properties": {
          "order": 100,
          "conditions": [],
          "actions": [
              {
                  "name": "UrlRedirect",
                  "parameters": {
                      "typeName": "DeliveryRuleUrlRedirectActionParameters",
                      "redirectType": "PermanentRedirect",
                      "destinationProtocol": "MatchRequest",
                      "customHostname": "{http_req_arg_cdpb}.blob.core.windows.net"
                  }
              }
          ],
          "matchProcessingBehavior": "Continue"
      }
  }
  

• 固定長 URL パス セグメントに基づくリダイレクト:{variable:offset:length}を使用して URL セグメントをキャプチャすることで、固定長 URL パス セグメントに基づいて異なる配信元に要求をリダイレクトできます。 詳細については、「 サーバー変数の形式」を参照してください。

  たとえば、テナント ID が URL セグメントに埋め込まれており、常に 6 文字の長さ ( https://api.contoso.com/{tenantId}/xyzなど) であるシナリオを考えてみましょう。 URL から {tenantId} を抽出し、 tenantId.backend.com/xyzの形式で使用する正しいリダイレクトを決定します。

  この方法では、テナント ID ごとに個別のルールを作成する必要がなくなります。これにより、少ないルールで動的ルーティングを処理できます。

  ポータル

  

  腕

  {
      "type": "Microsoft.Cdn/profiles/rulesets/rules",
      "apiVersion": "2025-04-15",
      "name": "[concat(parameters('profiles_rulesengineblog_name'), '/RulesBlogScenarios/RedirectURLSegmentCapture')]",
      "dependsOn": [
          "[resourceId('Microsoft.Cdn/profiles/rulesets', parameters('profiles_rulesengineblog_name'), 'RulesBlogScenarios')]",
          "[resourceId('Microsoft.Cdn/profiles', parameters('profiles_rulesengineblog_name'))]"
      ],
      "properties": {
          "order": 101,
          "conditions": [],
          "actions": [
              {
                  "name": "UrlRedirect",
                  "parameters": {
                      "typeName": "DeliveryRuleUrlRedirectActionParameters",
                      "redirectType": "PermanentRedirect",
                      "destinationProtocol": "MatchRequest",
                      "customPath": "/xyz",
                      "customHostname": "{url_path:0:6}.backend.com"
                  }
              }
          ],
          "matchProcessingBehavior": "Continue"
      }
  }
  

• 動的長 URL パス セグメントに基づくリダイレクト: URL パス セグメントの長さが動的な場合は、 {url_path:seg#}を使用して抽出できます。 詳細については、「 サーバー変数の形式」を参照してください。

  たとえば、テナント ID または場所が URL セグメントに埋め込まれている場合(https://api.contoso.com/{tenantId}/xyzなど)、URL から{tenantId}を抽出し、リダイレクト先ホストのサーバー変数tenantId.backend.com/xyz{url_path:seg0}.backend.comの形式で適切なリダイレクトを決定できます。

  この方法では、テナント ID ごとに個別のルールを作成することを回避し、より効率的な構成を可能にします。

  ポータル

  なし

  腕

  {
      "type": "Microsoft.Cdn/profiles/rulesets/rules",
      "apiVersion": "2025-04-15",
      "name": "[concat(parameters('profiles_rulesengineblog_name'), '/RulesBlogScenarios/RedirectURLSegmentCapture')]",
      "dependsOn": [
          "[resourceId('Microsoft.Cdn/profiles/rulesets', parameters('profiles_rulesengineblog_name'), 'RulesBlogScenarios')]",
          "[resourceId('Microsoft.Cdn/profiles', parameters('profiles_rulesengineblog_name'))]"
      ],
      "properties": {
          "order": 101,
          "conditions": [],
          "actions": [
              {
                  "name": "UrlRedirect",
                  "parameters": {
                      "typeName": "DeliveryRuleUrlRedirectActionParameters",
                      "redirectType": "PermanentRedirect",
                      "destinationProtocol": "MatchRequest",
                      "customPath": "/xyz",
                      "customHostname": "{url_path:seg0}.backend.com"
                  }
              }
          ],
          "matchProcessingBehavior": "Continue"
      }
  }
  

• 受信ホスト名の一部に基づいてリダイレクトします。 受信ホスト名の一部を抽出することで、異なる配信元に要求をリダイレクトできます。

  たとえば、tenantNameからhttps://[tenantName].poc.contoso.com/GBをキャプチャして、サーバー変数のオフセットと長さをs1.example.com/Buyer/Main?realm=[tenantName]&examplename=example1の形式で使用して、要求を{hostname:0:-16}にリダイレクトできます。 詳細については、「 サーバー変数の形式」を参照してください。

  ポータル

  

  腕

  {
      "type": "Microsoft.Cdn/profiles/rulesets/rules",
      "apiVersion": "2025-04-15",
      "name": "[concat(parameters('profiles_rulesengineblog_name'), '/RulesBlogScenarios/RedirectHostnameCapture')]",
      "dependsOn": [
          "[resourceId('Microsoft.Cdn/profiles/rulesets', parameters('profiles_rulesengineblog_name'), 'RulesBlogScenarios')]",
          "[resourceId('Microsoft.Cdn/profiles', parameters('profiles_rulesengineblog_name'))]"
      ],
      "properties": {
          "order": 102,
          "conditions": [
              {
                  "name": "HostName",
                  "parameters": {
                      "typeName": "DeliveryRuleHostNameConditionParameters",
                      "operator": "EndsWith",
                      "negateCondition": false,
                      "matchValues": [
                          "poc.contoso.com"
                      ],
                      "transforms": []
                  }
              }
          ],
          "actions": [
              {
                  "name": "UrlRedirect",
                  "parameters": {
                      "typeName": "DeliveryRuleUrlRedirectActionParameters",
                      "redirectType": "PermanentRedirect",
                      "destinationProtocol": "MatchRequest",
                      "customQueryString": "realm={hostname:0:-16}&examplename=example1",
                      "customPath": "/Buyer/Main",
                      "customHostname": "s1.example.com"
                  }
              }
          ],
          "matchProcessingBehavior": "Continue"
      }
  }
  

シナリオ 2: 要求ヘッダー値に基づいて応答ヘッダーを設定または変更する

シナリオによっては、要求ヘッダー値に基づいて応答ヘッダーを設定または変更することが必要になる場合があります。

たとえば、同じ CDN ドメインの複数の配信元でスクリプトを提供するために必要な場合は CORS ヘッダーを追加できます。また、応答には、すべてのドメイン (*) がセキュリティを強化できるようにワイルドカードではなく、要求元ヘッダーと同じ FQDN Access-Control-Allow-Origin ヘッダーに含まれている必要があります。 これを実現するには、 {http_req_header_Origin} サーバー変数を使用して応答ヘッダーを設定します。

ポータル

腕

{
    "type": "Microsoft.Cdn/profiles/rulesets/rules",
    "apiVersion": "2025-04-15",
    "name": "[concat(parameters('profiles_rulesengineblog_name'), '/RulesBlogScenarios/OverwriteRespHeaderUsingReqHeaderCapture')]",
    "dependsOn": [
        "[resourceId('Microsoft.Cdn/profiles/rulesets', parameters('profiles_rulesengineblog_name'), 'RulesBlogScenarios')]",
        "[resourceId('Microsoft.Cdn/profiles', parameters('profiles_rulesengineblog_name'))]"
    ],
    "properties": {
        "order": 103,
        "conditions": [
            {
                "name": "RequestHeader",
                "parameters": {
                    "typeName": "DeliveryRuleRequestHeaderConditionParameters",
                    "operator": "Contains",
                    "selector": "Origin",
                    "negateCondition": false,
                    "matchValues": [
                        "my-domain-01.com"
                    ],
                    "transforms": []
                }
            }
        ],
        "actions": [
            {
                "name": "ModifyResponseHeader",
                "parameters": {
                    "typeName": "DeliveryRuleHeaderActionParameters",
                    "headerAction": "Overwrite",
                    "headerName": "Access-Control-Allow-Origin",
                    "value": "{http_req_header_Origin}"
                }
            }
        ],
        "matchProcessingBehavior": "Continue"
    }
}

シナリオ 3: 応答ヘッダーの名前をブランド固有のものに変更する

クラウド プロバイダーによって生成された応答ヘッダーの名前を変更するには、新しいカスタム応答ヘッダーを追加し、元の応答ヘッダーを削除します。

たとえば、応答ヘッダー X-Azure-Backend-ID をブランド固有のヘッダー X-Contoso-Scale-IDに置き換えることができます。

ポータル

腕

{
    "type": "Microsoft.Cdn/profiles/rulesets/rules",
    "apiVersion": "2025-04-15",
    "name": "[concat(parameters('profiles_rulesengineblog_name'), '/RulesBlogScenarios/RenameResponseHeaders')]",
    "dependsOn": [
        "[resourceId('Microsoft.Cdn/profiles/rulesets', parameters('profiles_rulesengineblog_name'), 'RulesBlogScenarios')]",
        "[resourceId('Microsoft.Cdn/profiles', parameters('profiles_rulesengineblog_name'))]"
    ],
    "properties": {
        "order": 104,
        "conditions": [],
        "actions": [
            {
                "name": "ModifyResponseHeader",
                "parameters": {
                    "typeName": "DeliveryRuleHeaderActionParameters",
                    "headerAction": "Append",
                    "headerName": "X-Contoso-Scale-ID",
                    "value": "{http_resp_header_X-Azure-Backend-ID}"
                }
            },
            {
                "name": "ModifyResponseHeader",
                "parameters": {
                    "typeName": "DeliveryRuleHeaderActionParameters",
                    "headerAction": "Delete",
                    "headerName": "X-Azure-Backend-ID"
                }
            }
        ],
        "matchProcessingBehavior": "Continue"
    }
}

シナリオ 4: A/B テスト (実験)

受信トラフィックを 2 つの配信元グループに分割すると、A/B テスト、ローリング デプロイ、または複雑なバックエンド ロジックを使用しない負荷分散に役立ちます。

たとえば、クライアント ポート番号に基づいて受信トラフィックを分割できます。 ルールは、1、3、5、7、または 9 で終わるクライアント ポートと一致し、それらの要求を 実験オリジン グループに転送できます。 他のすべてのトラフィックは、ルート設定ごとに既定の配信元グループに引き続き送信されます。 前の正規表現は単なる例です。 regex101 などのツールを使用して、独自の式を調べてテストできます。

注

クライアント ポートはランダムであるため、通常、この方法では約 50/50 トラフィックが分割されます。 ただし、接続の再利用やソース ポートの書き換えなどの要因により、クライアントと Front Door の間にプロキシまたはロード バランサーが存在すると、この想定に影響する可能性があります。 ログまたはメトリックを使用して、環境内の実際の動作を検証します。

ポータル

腕

{
    "type": "Microsoft.Cdn/profiles/rulesets/rules",
    "apiVersion": "2025-04-15",
    "name": "[concat(parameters('profiles_rulesengineblog_name'), '/RulesBlogScenarios/ABExperimentation')]",
    "dependsOn": [
        "[resourceId('Microsoft.Cdn/profiles/rulesets', parameters('profiles_rulesengineblog_name'), 'RulesBlogScenarios')]",
        "[resourceId('Microsoft.Cdn/profiles', parameters('profiles_rulesengineblog_name'))]",
        "[resourceId('Microsoft.Cdn/profiles/origingroups', parameters('profiles_rulesengineblog_name'), 'experiment-origin-group')]"
    ],
    "properties": {
        "order": 105,
        "conditions": [
            {
                "name": "ClientPort",
                "parameters": {
                    "typeName": "DeliveryRuleClientPortConditionParameters",
                    "operator": "RegEx",
                    "negateCondition": false,
                    "matchValues": [
                        "^.*[13579]$"
                    ],
                    "transforms": []
                }
            }
        ],
        "actions": [
            {
                "name": "RouteConfigurationOverride",
                "parameters": {
                    "typeName": "DeliveryRuleRouteConfigurationOverrideActionParameters",
                    "originGroupOverride": {
                        "originGroup": {
                            "id": "[resourceId('Microsoft.Cdn/profiles/origingroups', parameters('profiles_rulesengineblog_name'), 'experiment-origin-group')]"
                        },
                        "forwardingProtocol": "MatchRequest"
                    }
                }
            }
        ],
        "matchProcessingBehavior": "Continue"
    }
}

シナリオ 5: URL パスを変更してリダイレクトし、機能を保持する

一部のシナリオでは、URL パスの残りの部分を保持しながら、新しいセグメントを追加したり、一部のセグメントを削除したりする必要がある場合があります。

たとえば、 https://domain.com/seg0/seg1/seg2/seg3 を https://example.com/seg0/insert/seg2/seg3にリダイレクトする場合です。 このシナリオでは、URL パスの {seg1} を /insert/ に置き換えながら、残りの URL パスを保持します。 Azure Front Door では、サーバー変数 (URL セグメント) から抽出された値を組み合わせ、静的な文字列セグメント /insert/を組み合わせることによって、目的のリダイレクトを実現します。 URL セグメントの長さフィールドに Int32.Max (2147483647) を使用して、すべてのセグメントを seg2 から segn に保持できます。 詳細については、「 サーバー変数の形式」を参照してください。

注

URL 書き換えアクションに対して同様の構成を行うには、次のポータルの例に示すように、リダイレクト アクションの/としてソース パターンを/{url_path:seg0}/insert/{url_path:seg2:2147483647}として入力し、宛先を入力します。

ポータル

腕

{
    "type": "Microsoft.Cdn/profiles/rulesets/rules",
    "apiVersion": "2025-04-15",
    "name": "[concat(parameters('profiles_rulesengineblog_name'), '/RulesBlogScenarios/redirectWithSegCap01')]",
    "dependsOn": [
        "[resourceId('Microsoft.Cdn/profiles/rulesets', parameters('profiles_rulesengineblog_name'), 'RulesBlogScenarios')]",
        "[resourceId('Microsoft.Cdn/profiles', parameters('profiles_rulesengineblog_name'))]"
    ],
    "properties": {
        "order": 106,
        "conditions": [],
        "actions": [
            {
                "name": "UrlRedirect",
                "parameters": {
                    "typeName": "DeliveryRuleUrlRedirectActionParameters",
                    "redirectType": "Found",
                    "destinationProtocol": "Https",
                    "customPath": "/{url_path:seg0}/insert/{url_path:seg2:2147483647}"
                }
            }
        ],
        "matchProcessingBehavior": "Continue"
    }
}

シナリオ 6: URL パスの固定部分を削除してリダイレクトする

URL パスの残りの部分を保持したまま、国コード (us) やロケール (en-us) など、既知のサイズの固定セグメントを URL パスから削除できます。

たとえば、 https://domain.com/us/seg1/seg2/seg3/ を https://example.com/seg1/seg2/seg3/にリダイレクトする場合は、国コード /us/ を削除し、残りの URL パスを変更しないようにする必要があります。

これを実現するには、 {variable:offset} (特定のオフセットの後にサーバー変数を含む) を変数の末尾まで使用します。 詳細については、「 サーバー変数の形式」を参照してください。

注

URL 書き換えアクションに対して同様の構成を行うには、次のポータルの例に示すように、リダイレクト アクションの/としてソース パターンを/“{url_path:3}として入力し、宛先を入力します。

ポータル

腕

{
    "type": "Microsoft.Cdn/profiles/rulesets/rules",
    "apiVersion": "2025-04-15",
    "name": "[concat(parameters('profiles_rulesengineblog_name'), '/RulesBlogScenarios/RedirectByRemovingFixedUrlLength')]",
    "dependsOn": [
        "[resourceId('Microsoft.Cdn/profiles/rulesets', parameters('profiles_rulesengineblog_name'), 'RulesBlogScenarios')]",
        "[resourceId('Microsoft.Cdn/profiles', parameters('profiles_rulesengineblog_name'))]"
    ],
    "properties": {
        "order": 107,
        "conditions": [
            {
                "name": "RequestUri",
                "parameters": {
                    "typeName": "DeliveryRuleRequestUriConditionParameters",
                    "operator": "RegEx",
                    "negateCondition": false,
                    "matchValues": [
                        "\\/[a-zA-Z0-9]{2}\\/"
                    ],
                    "transforms": []
                }
            }
        ],
        "actions": [
            {
                "name": "UrlRedirect",
                "parameters": {
                    "typeName": "DeliveryRuleUrlRedirectActionParameters",
                    "redirectType": "Found",
                    "destinationProtocol": "Https",
                    "customPath": "/{url_path:3}"
                    "customHostname": "example.com"
                }
            }
        ],
        "matchProcessingBehavior": "Continue"
    }
}

シナリオ 7: URL パスの 1 つ以上のセグメントを削除して URL を書き換える

URL パスの残りの部分を保持したまま、国コード (us) やロケール (en-us) などの 1 つ以上のセグメントを URL パスから削除できます。

たとえば、 https://domain.com/us/seg1/seg2/seg3/ を https://origin.com/seg2/seg3/に書き換える場合は、URL パスの残りの部分をそのままにしたまま、国コードと追加のセグメント /us/seg1/ の両方を削除する必要があります。

これを実現するには、 {url_path:seg#:length} サーバー変数形式を使用して、特定のセグメント番号から始まる特定の URL セグメントをキャプチャします。 この例では、 {url_path:seg2:2147483647} を使用して、 seg2 から最後までのすべてのセグメントをキャプチャします。 値 2147483647 (Int32.Max) により、残りのすべてのセグメントが確実に含まれます。 詳細については、「 サーバー変数の形式」を参照してください。

ポータル

腕

{
    "type": "Microsoft.Cdn/profiles/rulesets/rules",
    "apiVersion": "2025-04-15",
    "name": "[concat(parameters('profiles_rulesengineblog_name'), '/RulesBlogScenarios/URLRewriteRemovingOneorMoreSegments')]",
    "dependsOn": [
        "[resourceId('Microsoft.Cdn/profiles/rulesets', parameters('profiles_rulesengineblog_name'), 'RulesBlogScenarios')]",
        "[resourceId('Microsoft.Cdn/profiles', parameters('profiles_rulesengineblog_name'))]"
    ],
    "properties": {
        "order": 108,
        "conditions": [],
        "actions": [
            {
                "name": "UrlRewrite",
                "parameters": {
                    "typeName": "DeliveryRuleUrlRewriteActionParameters",
                    "sourcePattern": "/",
                    "destination": "/{url_path:seg2:2147483647}",
                    "preserveUnmatchedPath": false
                }
            }
        ],
        "matchProcessingBehavior": "Continue"
    }
}

注

{url_path}フィールドでなどのサーバー変数を使用する場合、サーバー変数はURLパスのどの部分を含めるかを明示的に制御できるため、一致しないパスを保持設定の関連性が低くなります。

シナリオ 8: 正規表現を使用してルール条件の数を減らし、制限に達しないようにする

ルール条件で正規表現を使用すると、必要なルールの数を大幅に減らすことができます。これにより、数百のクライアントに条件やアクションを必要とするお客様にとって、ルールの制限が阻害される可能性を回避できます。

たとえば、顧客が特定の ID パターンを持つクライアントを識別して、Azure Front Door の背後にあるリソースへのアクセスを許可する場合、クライアントは x-client-id: SN1234-ABCD56 などのヘッダーを送信します。 このヘッダーは、特定の形式 ( x-client-id: <SN + 4 digits + - + 4 uppercase letters + 2 digits>) に従います。

可能なクライアント ID ごとに個別のルールを作成する代わりに、1 つの正規表現パターン ^SN[0-9]{4}-[A-Z]{4}[0-9]{2}$ を使用して、 SN1234-ABCD56、 SN0001-ZYXW99、 SN2025-QWER12、 SN9876-MNOP34、 SN3141-TEST42など、1 つのルール内のすべての有効なクライアント ID を照合できます。この方法では、1 つのルール構成で数百の異なるクライアント ID を処理できます。

ポータル

腕

{
    "type": "Microsoft.Cdn/profiles/rulesets/rules",
    "apiVersion": "2025-04-15",
    "name": "[concat(parameters('profiles_rulesengineblog_name'), '/RulesBlogScenarios/UseRegexTogroupConditions')]",
    "dependsOn": [
        "[resourceId('Microsoft.Cdn/profiles/rulesets', parameters('profiles_rulesengineblog_name'), 'RulesBlogScenarios')]",
        "[resourceId('Microsoft.Cdn/profiles', parameters('profiles_rulesengineblog_name'))]",
        "[resourceId('Microsoft.Cdn/profiles/origingroups', parameters('profiles_rulesengineblog_name'), 'default-origin-group')]"
    ],
    "properties": {
        "order": 109,
        "conditions": [
            {
                "name": "RequestHeader",
                "parameters": {
                    "typeName": "DeliveryRuleRequestHeaderConditionParameters",
                    "operator": "RegEx",
                    "selector": "x-client-id",
                    "negateCondition": false,
                    "matchValues": [
                        "^SN[0-9]{4}-[A-Z]{4}[0-9]{2}$"
                    ],
                    "transforms": []
                }
            }
        ],
        "actions": [
            {
                "name": "RouteConfigurationOverride",
                "parameters": {
                    "typeName": "DeliveryRuleRouteConfigurationOverrideActionParameters",
                    "originGroupOverride": {
                        "originGroup": {
                            "id": "[resourceId('Microsoft.Cdn/profiles/origingroups', parameters('profiles_rulesengineblog_name'), 'default-origin-group')]"
                        },
                        "forwardingProtocol": "MatchRequest"
                    }
                }
            }
        ],
        "matchProcessingBehavior": "Continue"
    }
}

注

regex101 を使用して、Azure Front Door に実装する前に正規表現パターンをテストおよび検証できます。

シナリオ 9: 応答ヘッダー キャプチャを使用して配信元のリダイレクトを変更する

応答ヘッダー値をサーバー変数として使用することで、アクション フィールドを動的にすることができます。 これは、配信元サーバーが独自のドメイン名を参照するリダイレクトを発行する場合に便利です。

問題を： Azure App Service などの配信元サーバーでは、通常、独自のドメイン名 ( contoso.azurewebsites.net など) を参照するリダイレクト URL が発行されます。 これらの URL が変更されていないクライアントに到達すると、次の要求によって Azure Front Door がバイパスされ、ユーザーのナビゲーション エクスペリエンスが中断されます。

解決策: 配信元の Location ヘッダーをキャプチャし、ホスト部分だけを書き換えて、クライアントが最初に使用したホスト名が常に反映されるようにします。

たとえば、フロントエンド クライアントの Azure Front Door へのホスト ヘッダーが contoso.com され、配信元が contoso.azurewebsites.net場合、配信元が Location: https://contoso.azurewebsites.net/login/ などの絶対リダイレクト URL を発行すると、元のホスト名の場所を使用するように場所ヘッダーを変更できます。 https://contoso.com/login/

これは、サーバー変数の形式を使用して実現されます: https://{hostname}{http_resp_header_location:33}、ここで:

• {hostname} は、元のクライアント ホスト名 (contoso.com) を表します
• {http_resp_header_location:33} は、オフセット 33 ( /login/ 部分) から始まる Location ヘッダー コンテンツをキャプチャします。

詳細については、「リバース プロキシとそのバックエンド Web アプリケーションの間で、元の HTTP ホスト名を維持する」を参照してください。

ポータル

腕

{
    "type": "Microsoft.Cdn/profiles/rulesets/rules",
    "apiVersion": "2025-04-15",
    "name": "[concat(parameters('profiles_rulesengineblog_name'), '/RulesBlogScenarios/RewriteLocationHeaderToModifyRedirect')]",
    "dependsOn": [
        "[resourceId('Microsoft.Cdn/profiles/rulesets', parameters('profiles_rulesengineblog_name'), 'RulesBlogScenarios')]",
        "[resourceId('Microsoft.Cdn/profiles', parameters('profiles_rulesengineblog_name'))]"
    ],
    "properties": {
        "order": 110,
        "conditions": [
            {
                "name": "UrlPath",
                "parameters": {
                    "typeName": "DeliveryRuleUrlPathMatchConditionParameters",
                    "operator": "Contains",
                    "negateCondition": false,
                    "matchValues": [
                        "login",
                        "update"
                    ],
                    "transforms": []
                }
            }
        ],
        "actions": [
            {
                "name": "ModifyResponseHeader",
                "parameters": {
                    "typeName": "DeliveryRuleHeaderActionParameters",
                    "headerAction": "Overwrite",
                    "headerName": "Location",
                    "value": " https://{hostname}{http_resp_header_location:33}"
                }
            }
        ],
        "matchProcessingBehavior": "Continue"
    }
}

注

• このルールは、ルール条件が要求パラメーターに基づいている場合、または無条件で呼び出された場合に使用できます。

• 一貫性のあるオフセット計算を行う場合、配信元グループ内のすべての配信元サーバーには、同じ長さのドメイン名が必要です (たとえば、 https://contoso.azurewebsites.net などの 33 文字すべて)。 理想的には、配信元サーバーは 1 つだけ必要ですが、名前の長さが同じである場合は、複数の配信元を使用できます。

• 同じサーバー変数キャプチャ手法を適用して、要求クエリ文字列パラメーターを抽出して、異なるルール アクションで再利用できます。

シナリオ 10: If-elseif-else ルール

Azure Front Door ルール エンジンは、"if-elseif-else" 構造体を使用した従来の条件付きロジックをネイティブにサポートしていません。 既定では、すべてのルールは個別に "if condition1 then action1"、"if condition2 then action2" と評価されます。 複数の条件が同時に満たされると、対応する複数のアクションが実行されます。

ただし、"if-elseif-else" ロジックをエミュレートするには、 残りのルールの評価を停止 する機能を使用して、次のような条件分岐を作成します。

• 条件 1 が満たされている場合は、action1 を実行して停止します
• 条件 2 が満たされている (条件 1 が満たされていない) 場合は、action2 を実行して停止します
• 条件 3 が満たされている (条件 1 と条件 2 が満たされていない) 場合は、action3 を実行して停止します
• それ以外の場合は、既定のアクションを実行します

しくみ: 通常、複数の条件が同時に満たされる場合は、最初の照合後にルールの評価が停止するため、最初の照合ルールのみが実行されます。 これにより、従来の条件付き分岐が効果的にシミュレートされます。

ポータル

構成手順:

1. 新しいルール セットを作成します (例: "IfElseifElseRuleset")
2. 最も具体的な条件を最初に使用して、優先度順にルールを作成する
3. ルールごとに、[ 残りのルールの評価を停止 する] オプションをオンにします

Von Bedeutung

if-elseif-else パラダイムは、ルールセットがそのルートの 最後 のルールセットとしてアタッチされている場合にのみ機能します。

腕

なし

シナリオ 11: URL リダイレクトを使用して受信 URL からクエリ文字列を削除する

クエリ文字列を削除して Azure Front Door エンドポイントに戻す 3xx URL リダイレクトを実装することで、受信 URL からクエリ文字列を削除できます。

注

ユーザーは、この操作で要求 URL の変更に気付きます。

次の例では、受信 URL からクエリ文字列全体を削除する方法を示します。 その一部を取り除く必要がある場合は、必要に応じてオフセット/長さを調整できます。 詳細については、「 サーバー変数の形式」を参照してください。

ポータル

腕

{
    "type": "Microsoft.Cdn/profiles/rulesets/rules",
    "apiVersion": "2025-04-15",
    "name": "[concat(parameters('profiles_rulesengineblog_name'), '/RulesBlogScenarios/RemoveQueryStrings')]",
    "dependsOn": [
        "[resourceId('Microsoft.Cdn/profiles/rulesets', parameters('profiles_rulesengineblog_name'), 'RulesBlogScenarios')]",
        "[resourceId('Microsoft.Cdn/profiles', parameters('profiles_rulesengineblog_name'))]"
    ],
    "properties": {
        "order": 111,
        "conditions": [
            {
                "name": "QueryString",
                "parameters": {
                    "typeName": "DeliveryRuleQueryStringConditionParameters",
                    "operator": "GreaterThan",
                    "negateCondition": false,
                    "matchValues": [
                        "0"
                    ],
                    "transforms": []
                }
            }
        ],
        "actions": [
            {
                "name": "UrlRedirect",
                "parameters": {
                    "typeName": "DeliveryRuleUrlRedirectActionParameters",
                    "redirectType": "Moved",
                    "destinationProtocol": "MatchRequest",
                    "customQueryString": "{query_string:0:0}"
                }
            }
        ],
        "matchProcessingBehavior": "Continue"
    }
}

シナリオ 12: クエリ文字列に SAS トークンを追加して Azure Front Door を Azure Storage に認証する

ストレージ コンテナーへのアクセスをパブリックからプライベートに変更し、Shared Access Signature (SAS) を使用して、アカウント キーを公開せずに Azure Front Door から Azure Storage リソースへの制限付きアクセス権を付与することで、ストレージ アカウント内のファイルを保護できます。 マネージド ID を使用してこれを実現することもできます。 詳細については、「 マネージド ID を使用して配信元に対する認証を行う」を参照してください。

SAS トークンの挿入のしくみ: 受信 URL パスをキャプチャし、リダイレクトまたは書き換えルールを使用して SAS トークンをクエリ文字列に追加します。 URL 書き換えはパスでのみ機能するため、クエリ文字列を変更する必要がある場合はリダイレクト ルールを使用します。

たとえば、受信 URL https://www.contoso.com/dccp/grammars/0.1.0-59/en-US/grammars/IVR/ssn0100_CollectTIN_QA_dtmf.grxml?version=1.0_1719342835399に SAS トークンを追加する場合、書き換え URL は次のようになります。 https://www.contoso.com/grammars/0.1.0-59/en-US/grammars/IVR/ssn0100_CollectTIN_QA_dtmf.grxml?version=1.0_1719342835399&<SASTOKEN>

この例では、受信 URL にはクエリ パラメーターが既に含まれており、既存のクエリ文字列を保持しながら、 /{url_path:seg1:20}?{query_string}&<SASToken>を使用して URL リダイレクトを構成することで SAS トークンを追加します。

ルール構成では、SAS トークンがまだ含まれていないすべての HTTPS 要求がリダイレクトされます (クエリ文字列に sp=rl が存在しないことで識別されます)。

ポータル

腕

{
	"type": "Microsoft.Cdn/profiles/rulesets/rules",
	"apiVersion": "2025-04-15",
	"name": "[concat(parameters('profiles_rulesengineblog_name'), '/RulesBlogScenarios/RedirectForAppendSASToken')]",
	"dependsOn": [
	"[resourceId('Microsoft.Cdn/profiles/rulesets', parameters('profiles_rulesengineblog_name'), 'RulesBlogScenarios')]",
	"[resourceId('Microsoft.Cdn/profiles', parameters('profiles_rulesengineblog_name'))]"
	],
    "properties": {
        "order": 100,
        "conditions": [
            {
                "name": "RequestScheme",
                "parameters": {
                    "typeName": "DeliveryRuleRequestSchemeConditionParameters",
                    "matchValues": [
                        "HTTPS"
                    ],
                    "operator": "Equal",
                    "negateCondition": false,
                    "transforms": []
                }
            },
            {
                "name": "QueryString",
                "parameters": {
                    "typeName": "DeliveryRuleQueryStringConditionParameters",
                    "operator": "Contains",
                    "negateCondition": true,
                    "matchValues": [
                        "sp=rl"
                    ],
                    "transforms": []
                }
            }
        ],
        "actions": [
            {
                "name": "UrlRedirect",
                "parameters": {
                    "typeName": "DeliveryRuleUrlRedirectActionParameters",
                    "redirectType": "Found",
                    "destinationProtocol": "MatchRequest",
                    "customQueryString": "{ {query_string}&<replace with your SAS token>",
                    "customPath": "/{url_path:seg1:20}"
                }
            }
        ],
        "matchProcessingBehavior": "Continue"
	}
}

Von Bedeutung

• リダイレクト後に /grammars/* のルートが正しく構成されるようにルート構成を更新する

• SAS トークンを適切なトークンに置き換えます。 この例では、SAS トークンは sp=rl で始まり、sp=rl を含まないすべての要求をリダイレクトするために、この規則を適用する必要があります。

シナリオ 13: ルール エンジンを使用してセキュリティ ヘッダーを追加する

Azure Front Door ルール エンジンを使用して、HTTP Strict-Transport-Security (HSTS)、X-XSS-Protection、Content-Security-Policy、X-Frame-Options などのブラウザーベースの脆弱性を防ぐのに役立つセキュリティ ヘッダーを追加できます。

たとえば、ルール エンジンの構成に関連付けられているルートで定義されているパスと一致するすべての受信要求に Content-Security-Policy ヘッダーを追加できます。 この構成では、 script-src 'self' https://apiphany.portal.azure-api.net をヘッダー値として使用して、信頼されたサイトのスクリプトのみをアプリケーションで実行 https://apiphany.portal.azure-api.net できるようにします。 詳細については、「 ルール エンジンを使用してセキュリティ ヘッダーを追加する」を参照してください。

ポータル

腕

{
    "type": "Microsoft.Cdn/profiles/rulesets/rules",
    "apiVersion": "2025-04-15",
    "name": "[concat(parameters('profiles_rulesengineblog_name'), '/RulesBlogScenarios/ContentSecurityPolicyExample')]",
    "dependsOn": [
    "[resourceId('Microsoft.Cdn/profiles/rulesets', parameters('profiles_rulesengineblog_name'), 'RulesBlogScenarios')]",
    "[resourceId('Microsoft.Cdn/profiles', parameters('profiles_rulesengineblog_name'))]"
    ],
    "properties": {
        "order": 100,
        "conditions": [],
        "actions": [
            {
                "name": "ModifyResponseHeader",
                "parameters": {
                    "typeName": "DeliveryRuleHeaderActionParameters",
                    "headerAction": "Append",
                    "headerName": "Content-Security-Policy",
                    "value": "script-src 'self' https://apiphany.portal.azure-api.net"
                }
            }
        ],
        "matchProcessingBehavior": "Continue"
    }
}

関連コンテンツ

• Azure Front Door のルール セットとは
• ルール一式のアクション
• Azure Front Door でルール セットを構成する