[解决方案] Azure Front Door 规则引擎场景与配置

<!-- AI_TASK_START: AI标题翻译 --> [解决方案] Azure Front Door 规则引擎场景与配置 <!-- AI_TASK_END: AI标题翻译 --> <!-- AI_TASK_START: AI竞争分析 --> # Azure Front Door 规则引擎解决方案分析 ## 解决方案概述 Azure Front Door 规则引擎是一种强大的边缘逻辑工具，允许用户通过配置匹配条件和动作对请求进行自定义处理和路由。该解决方案针对 Web 应用交付和安全问题，提供动态缓存管理、请求转发、头部修改以及 URL 重写等功能。核心目标是为用户构建可扩展的边缘逻辑，实现更快速、智能且安全的 Web 体验，适用于 **SEO 优化**、用户体验提升和安全防护场景。技术原理基于 19 种支持的匹配条件（如查询字符串、URL 路径段和主机名），结合动作（如重定向或头部修改），在 Azure 边缘位置处理请求，避免直接访问后端服务。 ## 实施步骤 1. **定义规则集**：在 Azure 门户创建规则集，选择匹配条件（如 {http_req_arg_<key>} 捕获查询字符串），并配置动作（如重定向）。理由：匹配条件确保规则针对特定请求触发，实现精确控制。 - 子步骤：使用服务器变量格式（如 {url_path:seg#}）提取动态值，确保规则灵活性。 2. **配置匹配条件和动作**：基于场景组合条件，例如使用正则表达式匹配客户端 ID，或提取 URL 段进行重定向。理由：减少规则数量，避免限额问题；逻辑衔接：先评估条件，再执行动作，以优先级顺序处理。 - 子步骤：测试正则表达式（如 regex101 工具），并应用到规则中。 3. **部署和验证规则**：通过 Azure 门户或 ARM 模板部署规则集，使用日志或指标监控效果。理由：验证可确保实际流量行为符合预期，例如 A/B 测试的流量分割。 - 子步骤：如果涉及重定向，检查是否保留查询字符串或路径段。 ## 方案客户价值 - **提升用户体验和 SEO**：通过动态重定向（如基于查询字符串或 URL 路径），实现批量管理重定向，减少规则数量；与传统方案相比，避免手动配置每个规则，显著降低维护成本，实现 _更高效的 SEO 和导航_。 - **增强安全性和合规性**：修改响应头部添加安全属性（如 HSTS、X-XSS-Protection），防止浏览器漏洞；量化收益：通过精确头部控制，提升安全级别，避免数据泄露，与未使用规则引擎的传统方案相比，减少潜在攻击面。 - **优化性能和成本**：动态缓存管理和 A/B 测试（如基于客户端端口分割流量）实现约 50% 流量均衡，降低后端负载；与竞品差异：Azure Front Door 通过服务器变量和正则表达式，提供更灵活的边缘处理，相比简单路由方案，_实现更高可扩展性并减少规则限额问题_。 ## 涉及的相关产品 - **Azure Front Door**：作为核心产品，提供规则引擎功能，用于自定义请求处理和路由。 - **Azure Storage**：在某些场景中结合使用，如通过 SAS 令牌认证访问私有存储，确保安全访问。 - **Azure App Service**：作为后端源，支持响应头部修改和重定向，处理动态内容交付。 ## 技术评估 Azure Front Door 规则引擎在技术先进性上表现出色，支持正则表达式和服务器变量，实现高效的动态路由和头部管理，适用于大规模 Web 应用场景。优势包括：高可扩展性（减少规则数量）和灵活性（模拟 if-elseif-else 逻辑）。可行性强，通过 Azure 门户或 ARM 模板轻松部署，但限制在于规则评估顺序依赖“停止评估剩余规则”选项，可能在复杂环境中需要额外监控以验证行为。适用范围广，覆盖 SEO、安全和 A/B 测试，但需注意代理影响流量分割准确性。总体而言，该方案在边缘计算趋势中保持领先，但用户应评估特定环境下的性能开销。 <!-- AI_TASK_END: AI竞争分析 --> <!-- AI_TASK_START: AI全文翻译 --> # Azure Front Door 规则引擎场景和配置 **原始链接:** [https://techcommunity.microsoft.com/blog/azurenetworkingblog/azure-front-door-rules-engine-scenarios-and-configurations/4423183](https://techcommunity.microsoft.com/blog/azurenetworkingblog/azure-front-door-rules-engine-scenarios-and-configurations/4423183) **发布时间:** 2025-06-13 **厂商:** AZURE **类型:** TECH-BLOG ---  Azure Networking Blog # Azure Front Door 规则引擎场景和配置 2025 年 6 月 13 日 ## 了解如何利用 Azure Front Door 的规则引擎构建强大、可扩展的边缘逻辑，从而自定义请求处理和路由—实现更快、更智能且更安全的网络体验 *_此文章是 Azure Front Door 早期博客的延续。如果您尚未阅读，可在 [Revolutionizing hyperscale application delivery and security: The New Azure Front Door edge platform | Microsoft Community Hub](<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftechcommunity.microsoft.com%2Fblog%2Fazurenetworkingblog%2Frevolutionizing-hyperscale-application-delivery-and-security-the-new-azure-front%2F4132638&data=05%7C02%7Cv-kweatherma%40microsoft.com%7C423216ba84d74279402c08ddaa2f3f10%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638853842146190391%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW5zMzIiLCJBTiI6Ik1haWwiLCJXSSI6Mn1%7C0%7C%7C%7C&sdata=vT97vPBYU5fMwe6WOIZTF1FkqSpNDCzXHIm1YAl0lzw%3D&reserved=0>)_ 中找到它。* Azure Front Door 规则引擎 (rules engine) 允许用户通过配置匹配条件和动作对来轻松自定义 Front Door 边缘处的处理和路由逻辑。 您可以基于传入请求的 19 种支持的匹配条件 (match conditions) 组合来定义各种规则 [动作](<https://review.learn.microsoft.com/en-us/azure/frontdoor/front-door-rules-engine-actions>)。这些规则使您能够： - 动态管理缓存策略 (cache policy)。 - 将请求转发到不同的源 (origins) 或版本。 - 修改请求或响应头 (headers)，以隐藏敏感信息或通过头传递重要信息。例如，实现安全头 (security headers) 来防止基于浏览器的漏洞，如： - HTTP 严格传输安全 (HSTS) (HTTP strict-transport-security)。 - X-XSS-protection。 - Content-security-policy。 - X-frame-options。 - Access-Control-Allow-Origin 头，用于跨源资源共享 (CORS) 场景。安全属性也可以通过 cookies 定义。 - 重写 URL 路径 (URL paths) 或将请求重定向到新目标。 - 使用正则表达式 (regex) 和服务器变量 (server variables) 启用复杂场景：从传入请求或响应中捕获动态值，并将它们与静态字符串或其他变量组合。 本文介绍了规则引擎支持的常见用例，以及如何通过 Azure 门户 (Azure portal) 配置这些规则。您可以在 [Azure Front Door 规则引擎场景](<https://learn.microsoft.com/en-us/azure/frontdoor/rules-engine-scenarios>) 中找到 Azure 资源管理器 (ARM) 模板示例，以帮助自动化这些功能的部署。 # 场景 1: 使用查询字符串、URL 路径段或传入主机名捕获进行重定向 管理重定向对于搜索引擎优化 (SEO)、用户体验和网站正常运行至关重要。Azure Front Door 的规则引擎和服务器变量 (server variables) 允许您根据各种参数高效管理批量重定向。 ## 基于查询字符串参数进行重定向 您可以通过捕获传入 URL 的查询字段值，以格式 {http_req_arg_<key>} 来重定向请求。这种方法无需为每个值创建单独的规则，从而显著减少所需规则的数量。 例如，从传入 URL: https://example.mydomain.com/testcontainer/123.zip?sig=fffff&cdpb=teststorageaccount 中提取 cdpb 查询键的值，并将其用于配置“目标主机”到传出 URL: https://teststorageaccount.blob.core.windows.net/testcontainer/123.zip?sig=fffff&cdpb=teststorageaccount。  ## 基于固定长度 URL 路径段进行重定向 您可以通过使用 {variable:offset:length} 捕获 URL 段来根据固定长度 URL 路径段将请求重定向到不同的源。有关更多信息，请参阅 [服务器变量格式](<https://review.learn.microsoft.com/en-us/azure/frontdoor/rule-set-server-variables#server-variable-format>)。 例如，假设租户 ID (tenant ID) 嵌入在 URL 段中且始终为六字符长，如: https://api.contoso.com/{tenantId}/xyz。从 URL 中提取 {tenantId} 并决定正确的重定向格式为 tenantId.backend.com/xyz。 这种方法无需为每个租户 ID 创建单独的规则，从而使用较少的规则处理动态路由。  ## 基于动态长度 URL 路径段进行重定向 当 URL 路径段具有动态长度时，您可以使用 {url_path:seg#} 提取它。有关更多信息，请参阅 [服务器变量格式](<https://review.learn.microsoft.com/en-us/azure/frontdoor/rule-set-server-variables#server-variable-format>)。 例如，如果租户 ID 或位置嵌入在 URL 段中，如: https://api.contoso.com/{tenantId}/xyz，您可以使用服务器变量 {url_path:seg0} 从 URL 中提取 {tenantId}，并决定正确的重定向格式为 tenantId.backend.com/xyz。 此方法避免为每个租户 ID 创建单独的规则，从而实现更高效的配置。这可以通过命令行工具配置。了解如何通过 Azure 资源管理器 (ARM) 模板配置此规则，请参阅 [Azure Front Door 规则引擎场景](<https://learn.microsoft.com/en-us/azure/frontdoor/rules-engine-scenarios>)。 ## 基于传入主机名部分进行重定向 您可以通过提取传入主机名的部分来将请求重定向到不同的源。 例如，从 https://[tenantName].poc.contoso.com/GB 中捕获 tenantName，并使用偏移和长度在服务器变量格式 {hostname:0:-16} 中将请求重定向到 s1.example.com/Buyer/Main?realm=[tenantName]&examplename=example1。有关更多信息，请参阅 [服务器变量格式](<https://review.learn.microsoft.com/en-us/azure/frontdoor/rule-set-server-variables#server-variable-format>)。  # 场景 2: 根据请求头值填充或修改响应头 在某些场景中，您可能需要根据请求头值填充或修改响应头。 例如，您可以添加 CORS 头 (CORS headers)，以从同一内容分发网络 (CDN) 域服务多个源的脚本，并确保响应中的 Access-Control-Allow-Origin 头包含与请求源头相同的完全限定域名 (FQDN)，而非通配符 (*) 以增强安全性。通过使用 {http_req_header_Origin} 服务器变量来设置响应头即可实现。  # 场景 3: 将响应头重命名为品牌特定头 您可以通过添加新自定义响应头并删除原头来重命名云提供商生成的响应头。 例如，将响应头 X-Azure-Backend-ID 替换为品牌特定头 X-Contoso-Scale-ID。  # 场景 4: A/B 测试 (实验) 将传入流量分割到两个源组 (origin groups) 对于 A/B 测试、滚动部署或负载均衡非常有用，而无需复杂的后端逻辑。 例如，您可以基于客户端端口号分割流量。规则可以匹配以 1、3、5、7 或 9 结尾的客户端端口，并将这些请求转发到 _experiment-origin-group_。其他流量按路由设置继续到默认源组。上述正则表达式仅为示例。您可以使用工具如 [regex101](<https://regex101.com/>) 来探索和测试自己的表达式。  **注意** 由于客户端端口是随机的，此方法通常会产生约 50/50 的流量分割。但是，客户端和 Front Door 之间存在的任何代理或负载均衡器可能由于连接重用或源端口重写等因素而影响此假设。请使用日志或指标验证您环境中的实际行为。 # 场景 5: 带 URL 路径修改的重定向并保留功能 在某些场景中，您可能需要添加新段或移除某些段，同时保留 URL 路径的其余部分。 例如，将 https://domain.com/seg0/seg1/seg2/seg3 重定向到 https://example.com/seg0/insert/seg2/seg3。在此场景中，您将 URL 路径的 {seg1} 替换为 /insert/，同时保留其余路径。Azure Front Door 通过组合从服务器变量 (URL 段) 提取的值和静态字符串段 /insert/ 来实现所需重定向。您可以使用 Int32.Max (2147483647) 为 URL 段的长度字段保留从 _seg2_ 到 _segn_ 的所有段。有关更多信息，请参阅 [服务器变量格式](<https://review.learn.microsoft.com/en-us/azure/frontdoor/rule-set-server-variables#server-variable-format>)。 **注意** 类似配置可用于 URL 重写动作，通过输入源模式为 / 和目标为 /{url_path:seg0}/insert/{url_path:seg2:2147483647}，如重定向动作所示。  # 场景 6: 通过移除 URL 路径的固定部分进行重定向 您可以从 URL 路径中移除已知大小的固定段（如国家代码 (us) 或语言环境 (en-us)），同时保留其余路径。 例如，将 https://domain.com/us/seg1/seg2/seg3/ 重定向到 https://example.com/seg1/seg2/seg3/，需移除国家代码 /us/ 并保持其余路径不变。 为此，使用 {variable:offset}，它包括从特定偏移开始到变量末尾的服务器变量。有关更多信息，请参阅 [服务器变量格式](<https://review.learn.microsoft.com/en-us/azure/frontdoor/rule-set-server-variables#server-variable-format>)。 **注意** 类似配置可用于 URL 重写动作，通过输入源模式为 / 和目标为 /“{url_path:3}，如重定向动作所示。  # 场景 7: 通过移除 URL 路径的一个或多个段进行 URL 重写 您可以从 URL 路径中移除一个或多个段（如国家代码 (us) 或语言环境 (en-us)），同时保留其余路径。 例如，将 https://domain.com/us/seg1/seg2/seg3/ 重写为 https://origin.com/seg2/seg3/，需移除国家代码和额外段 /us/seg1/，同时保持其余路径完整。 为此，使用 {url_path:seg#:length} 服务器变量格式从特定段号开始捕获特定 URL 段。在此示例中，使用 {url_path:seg2:2147483647} 从 seg2 开始捕获所有段。值 2147483647 (Int32.Max) 确保包含所有剩余段。有关更多信息，请参阅 [服务器变量格式](<https://review.learn.microsoft.com/en-us/azure/frontdoor/rule-set-server-variables#server-variable-format>)。 **注意** 在使用 {url_path} 等服务器变量时，在 **Destination** 字段中，**Preserve unmatched path** 设置变得不那么相关，因为服务器变量让您可以明确控制要包含的 URL 路径部分。  # 场景 8: 使用正则表达式减少规则条件数量并避免达到限制 在规则条件中使用正则表达式 (regex) 可以显著减少所需的规则数量，从而帮助避免规则限制，这对需要为数百个客户端设置条件或动作的客户来说是一个障碍。 例如，如果客户希望识别具有特定 ID 模式的客户端以允许访问 Azure Front Door 后面的资源，客户端会发送像 x-client-id: SN1234-ABCD56 这样的头。 而非为每个可能的客户端 ID 创建单独的规则，您可以使用单个正则表达式模式 ^SN[0-9]{4}-[A-Z]{4}[0-9]{2}$ 来匹配所有有效客户端 ID，例如 SN1234-ABCD56、SN0001-ZYXW99、SN2025-QWER12、SN9876-MNOP34、SN3141-TEST42 等。这样，您可以用一个规则配置处理数百个不同的客户端 ID。  # 场景 9: 使用响应头捕获修改源重定向 您可以通过使用响应头值作为服务器变量使动作字段动态化。这在源服务器发出引用其自身域名的重定向时非常有用。 **问题:** 源服务器如 Azure App Service 通常会发出引用其自身域名的重定向 URL (例如，contoso.azurewebsites.net)。如果这些 URL 未修改就到达客户端，下一个请求会绕过 Azure Front Door，从而破坏用户导航体验。 **解决方案:** 捕获源的 Location 头并仅重写主机部分，使其始终反映客户端最初使用的主机名。 例如，如果前端客户端的主机头 (host header) 到 Azure Front Door 是 contoso.com，而源是 contoso.azurewebsites.net，当源发出绝对重定向 URL 如 Location: https://contoso.azurewebsites.net/login/ 时，您可以将 Location 头修改为 Location: https://contoso.com/login/。 这是通过服务器变量格式实现的: https://{hostname}{http_resp_header_location:33}，其中： - {hostname} 表示原始客户端主机名 (contoso.com)。 - {http_resp_header_location:33} 从偏移 33 开始捕获 Location 头内容 (/login/ 部分)。 有关更多信息，请参阅 [在反向代理和其后端 Web 应用程序之间保留原始 HTTP 主机名](<https://review.learn.microsoft.com/en-us/azure/architecture/best-practices/host-name-preservation>)。  **注意** - 此规则可用于基于请求参数的规则条件或无条件调用。 - 为确保偏移计算一致，源组中的所有源服务器应具有相同长度的域名，例如所有 33 字符如 https://contoso.azurewebsites.net。理想情况下，只有一个源服务器，但多个源是可以接受的，前提是它们的名称长度相同。 - 您可以对请求查询字符串参数应用相同的服务器变量捕获技术来提取和重用。 # 场景 10: If-elseif-else 规则 Azure Front Door 规则引擎 (rules engine) 不原生支持传统的“if-elseif-else”结构。默认情况下，所有规则都独立评估为“if condition1 then action1”、“if condition2 then action2” 等。当多个条件同时满足时，会执行多个相应动作。 但是，您可以通过 **Stop evaluating remaining rules** 功能模拟“if-elseif-else”逻辑，从而创建类似于以下的条件分支： - 如果 condition1 满足，则执行 action1 并停止。 - 否则如果 condition2 满足 (但 condition1 不满足)，则执行 action2 并停止。 - 否则如果 condition3 满足 (但 condition1 和 condition2 不满足)，则执行 action3 并停止。 - 否则，执行默认动作。 **工作原理:** 当多个条件通常同时满足时，只执行第一个匹配的规则，因为规则评估会在第一次匹配后停止。这有效地模拟了传统的条件分支。 **配置步骤:** 1. 创建一个新规则集 (例如，“IfElseifElseRuleset”)。 2. 按优先顺序创建规则，从最具体的条件开始。 3. 为每个规则选中 **Stop evaluating remaining rules** 选项。  **重要** 此 if-elseif-else 模式仅在规则集作为该路由的 **final** 规则集附加时有效。  # 场景 11: 使用 URL 重定向从传入 URL 中移除查询字符串 您可以通过实现 3xx URL 重定向来从传入 URL 中移除查询字符串，从而引导用户返回 Azure Front Door 端点，而查询字符串已被移除。 **注意** 用户会注意到请求 URL 的变化。  # 场景 12: 在查询字符串中追加 SAS 令牌以验证 Azure Front Door 到 Azure 存储的身份 您可以通过将存储容器访问从公共改为私有，并使用共享访问签名 (SAS) 令牌授予受限访问权限来保护存储账户中的文件，从而使 Azure Front Door 无需暴露账户密钥即可访问 Azure 存储资源。您也可以使用托管身份 (Managed Identity) 实现。有关更多信息，请参阅 [使用托管身份验证源](<https://review.learn.microsoft.com/en-us/azure/frontdoor/origin-authentication-with-managed-identities>)。 **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 已有查询参数，您希望保留现有查询字符串同时追加 SAS 令牌，通过配置 URL 重定向使用 /{url_path:seg1:20}?{query_string}&<SASToken>。 规则配置会重定向所有 HTTPS 请求，这些请求不包含 SAS 令牌 (通过查询字符串中缺少 sp=rl 来识别)。  **重要** - 更新您的路由配置以确保 /grammars/* 的路由在重定向后正确配置。 - 用正确的令牌替换 SAS 令牌。在示例中，SAS 令牌以 sp=rl 开头，您希望重定向所有不包含 sp=rl 的请求以应用此规则。 # 场景 13: 使用规则引擎添加安全头 您可以使用 Azure Front Door 规则引擎添加安全头 (security headers)，以帮助防止基于浏览器的漏洞，如 HTTP 严格传输安全 (HSTS)、X-XSS-Protection、Content-Security-Policy 和 X-Frame-Options。有关详细信息，请参阅 [教程: 使用 Rules Engine 添加安全头 - Azure Front Door | Microsoft Learn](<https://learn.microsoft.com/en-us/azure/frontdoor/front-door-security-headers?pivots=front-door-standard-premium>)。 更新于 2025 年 6 月 13 日 版本 1.0 <!-- AI_TASK_END: AI全文翻译 -->