Azure Front Door 常见问题解答 （FAQ）

Azure Front Door 是一项基于云的服务，可更快、更可靠地交付应用程序。 它使用第 7 层负载均衡在多个区域和终端节点之间分配流量。 它还提供动态站点加速 （DSA） 来优化 Web 性能，并提供近乎实时的故障转移来确保高可用性。 Azure Front Door 是一项完全托管的服务，因此你不必担心缩放或维护。

Azure Front Door 和 Azure 应用程序网关都是 HTTP/HTTPS 流量的负载均衡器，但它们的范围不同。 Front Door 是一项可以跨区域分发请求的全局服务，而应用程序网关是一种可以在区域内平衡请求的区域服务。 Azure Front Door 适用于缩放单元、群集或标记单元，而 Azure 应用程序网关适用于同一缩放单元中的 VM、容器或其他资源。

可以为 Azure Front Door 使用不同类型的源，例如：

• 存储（Azure Blob、Classic、静态网站）
• 云服务
• 应用服务
• 静态 Web 应用程序
• API 管理
• 应用程序网关
• 公共 IP 地址
• Azure Spring Apps
• 容器实例
• 容器应用
• 任何具有公共访问权限的自定义主机名。

源必须具有可公开解析的公有 IP 或 DNS 主机名。 您可以混合和匹配来自不同区域、区域甚至 Azure 外部的后端，只要它们是可公开访问的。

Azure Front Door 不限于任何 Azure 区域，而是在全球范围内运行。 创建 Front Door 时，唯一需要选择的位置是资源组的位置，它决定了资源组元数据的存储位置。 Front Door 配置文件是一种全局资源，其配置分发到全球所有边缘站点。

有关为 Azure Front Door 提供全局负载均衡和内容交付的接入点 （POP） 的完整列表，请参阅 Azure Front Door POP 位置。 此列表会随着新 POP 的添加或删除而定期更新。 还可以使用 Azure 资源管理器 API 以编程方式查询当前的 POP 列表。

Azure Front Door 是一项跨多个区域全局分发应用程序的服务。 它使用由所有客户共享的通用基础结构，但你可以自定义自己的 Front Door 配置文件来配置应用程序的特定要求。 其他客户的配置不会影响你的 Front Door 配置，该配置与他们的情况隔离。

Front Door 不会对 Web 应用程序的路由进行排序。 相反，它会选择最适合请求的路由。 若要了解 Front Door 如何将请求与路由匹配，请参阅 Front Door 如何将请求与路由规则匹配。

为了确保 Front Door 功能的最佳性能，应仅允许来自 Azure Front Door 的流量到达源。 因此，未经授权或恶意的请求会遇到 Front Door 的安全和路由策略，并被拒绝访问。 若要了解如何保护源，请参阅 保护发往 Azure Front Door 源的流量。

新 Front Door 配置的部署时间因更改类型而异。 通常，更改需要 3 到 20 分钟才能传播到我们全球的所有边缘站点。

对路由或源组/后端池的更新是无缝的，不会导致任何停机时间（假设新配置正确）。 证书更新也是以原子方式完成的，因此不存在中断的风险。

• Front Door 标准版/高级版和 Azure CDN 配置文件可以在资源组或订阅之间移动，而无需任何停机时间。 要执行移动，请按照以下 说明作。
• Front Door 经典版不支持在资源组或订阅之间移动。 相反，您可以将 Classic 配置文件 迁移到 Standard/Premium，然后执行移动。
• 如果客户将 WAF 关联到 Front Door Standard/Premium，则移动作将失败。 客户必须先取消关联 WAF 策略，然后移动，然后再关联。

Azure Front Door 是一项为 Web 应用程序提供许多好处的服务，例如动态站点加速 （DSA），可提高站点的性能和用户体验。 Azure Front Door 还处理 TLS/SSL 卸载和端到端 TLS，从而增强 Web 流量的安全性和加密。 此外，Azure Front Door 还提供 Web 应用程序防火墙、基于 Cookie 的会话相关性、基于 URL 路径的路由、免费证书和多个域管理等。 若要详细了解 Azure Front Door 的特性和功能，请参阅 层比较。

Azure Front Door 支持 HTTP、HTTPS 和 HTTP/2。

Azure Front Door 支持用于客户端连接的 HTTP/2 协议。 但是，后端池通信使用 HTTP/1.1 协议。 默认情况下，HTTP/2 支持处于打开状态。

否。 目前，Azure Front Door 仅支持从边缘到源的 HTTP/1.1。 要使 gRPC 正常工作，需要 HTTP/2。

可以使用 Azure Front Door 重定向 URL 的主机、路径和查询字符串组件。 要了解如何配置 URL 重定向，请参阅 URL 重定向。

是的。 请参阅 Access Logs 下的 MatchedRulesSetName 属性。

是的。 有关详细信息，请参阅 Microsoft 对针对 HTTP/2 的 DDoS 攻击的响应。

Azure Front Door 支持 X-Forwarded-For、X-Forwarded-Host 和 X-Forwarded-Proto 标头。 这些标头可帮助 Front Door 识别原始客户端 IP 和协议。 如果 X-Forwarded-For 已存在，则 Front Door 会将客户端套接字 IP 添加到列表末尾。 否则，它将创建以客户端套接字 IP 作为值的标头。 对于 X-Forwarded-Host 和 X-Forwarded-Proto，Front Door 会将现有值替换为自己的值。

有关详细信息，请参阅 Front Door 支持的 HTTP 标头。

若要使用 Azure Front Door 标准层或（经典）层，需要可公开解析的公共 IP 或 DNS 名称。 公共 IP 或可公开解析的 DNS 名称的这一要求允许 Azure Front Door 将流量路由到后端资源。 您可以使用 Azure 资源（如应用程序网关或 Azure 负载均衡器）将流量路由到虚拟网络中的资源。 如果使用 Front Door 高级层，则可以使用专用链接连接到具有专用终结点的内部负载均衡器后面的源。 有关更多信息，请参阅 使用 Private Link 保护源。

Front Door 后面的应用程序网关在以下情况下非常有用：

• 你不仅希望平衡全局流量，还希望平衡虚拟网络内的流量。 Front Door 只能在全局级别执行基于路径的负载均衡，但应用程序网关可以在虚拟网络中执行该作。
• 您需要 Front Door 不支持的连接排空。 应用程序网关可以为 VM 或容器启用连接耗尽。
• 您希望卸载所有 TLS/SSL 处理，并在虚拟网络中仅使用 HTTP 请求。 Front Door 后面的应用程序网关可以实现此设置。
• 您希望在区域和服务器级别都使用会话关联。 Front Door 可以将流量从用户会话发送到区域中的同一后端，但应用程序网关可以将其发送到后端中的同一服务器。

链接两个 CDN 通常不是一种推荐的方法，它会起作用，但有以下缺点

1. CDN 的最后一英里加速利用保持与源站的连接流，并找到到源站的最佳路径以获得最佳结果。 将两个 CDN 链接在一起通常会抵消最后一英里加速的一些好处。
2. 安全控制在第二个 CDN 中变得不那么有效。 任何基于客户端 IP 的 ACL 在第二个 CDN 上都不起作用，因为第二个 CDN 会将第一个 CDN 的出口节点视为客户端 IP。 仍将检查内容有效负载。
3. 许多组织无法处理对两个 CDN 被链接进行故障排除的复杂性，当出现问题时，很难确定哪个 CDN 有问题。

若要使用 Azure Front Door，必须具有可公开访问的公共 VIP 或 DNS 名称。 Azure Front Door 使用公共 IP 将流量路由到源。 一种常见方案是在 Front Door 后面部署 Azure 负载均衡器。 还可以将专用链接与 Azure Front Door Premium 结合使用，以连接到内部负载均衡器。 有关更多信息，请参阅 使用内部负载均衡器启用 Private Link。

Azure Front Door 和 Azure CDN 是两种服务，可为应用程序提供快速可靠的 Web 交付。 但是，它们彼此不兼容，因为它们共享相同的 Azure 边缘站点网络来向用户交付内容。 此共享网络会导致其路由策略和缓存策略之间发生冲突。 因此，必须为应用程序选择 Azure Front Door 或 Azure CDN，具体取决于你的性能和安全要求。

两个配置文件/终端节点将使用相同的 Azure 边缘 POP 来处理传入请求，这会导致一个限制，阻止您将一个 Azure Front Door 配置文件/终端节点嵌套在另一个配置文件/终端节点后面。 此设置将导致路由冲突和性能问题。 因此，如果需要为应用程序使用多个配置文件/终结点，则应确保 Azure Front Door 配置文件/终结点不会链接在一起。

Front Door 的前端任播的 IP 地址是固定的，只要您使用 Front Door，它就不会更改。 但是，不能保证 Front Door 前端任播的固定 IP 地址。 避免直接依赖 IP。 为了在 IP 地址发生任何更改时随时了解情况并采取适当的措施，请开发自动化功能，以使用 服务标签发现 API 或 JSON 文件定期获取最新的 IP 地址。

Azure Front Door 是一项动态服务，可将流量路由到最佳可用后端。 它目前不提供静态或专用前端任播 IP。

Azure Front Door 使用三个服务标记来管理客户端与源之间的流量：

• AzureFrontDoor.Backend 服务标记包含 Front Door 用于访问源的 IP 地址。 为源配置安全性时，可以应用此服务标记。
• AzureFrontDoor.Frontend 服务标记包含客户端用于访问 Front Door 的 IP 地址。 如果要控制可连接到 Azure Front Door 后面的服务的出站流量，可以应用 AzureFrontDoor.Frontend 服务标记。
• AzureFrontDoor.FirstParty 服务标记是为 Azure Front Door 上托管的一组精选 Microsoft 服务保留的。

有关 Azure Front Door 服务标记方案的详细信息，请参阅 可用的服务标记。 为了在 IP 地址发生任何更改时随时了解情况并采取适当的措施，请开发自动化功能，以使用 服务标签发现 API 或 JSON 文件定期获取最新的 IP 地址。

源组是可以处理类似类型请求的源的集合。 对于每个不同的应用程序或工作负载，您需要不同的源组。

在源组中，您可以为每个可以为请求提供服务的服务器或服务创建一个源。 如果源具有负载均衡器（如 Azure 应用程序网关），或者托管在具有负载均衡器的 PaaS 上，则源组只有一个源。 源负责 Front Door 看不到的源之间的故障转移和负载均衡。

例如，如果在 Azure 应用服务上托管应用程序，则 Front Door 的设置方式取决于你拥有的应用程序实例数：

• 单区域部署：创建一个源组。 在该源组中，为应用服务应用创建一个源。 应用服务应用可能会跨辅助角色横向扩展，但 Front Door 看到一个源。
• 多区域主动/被动部署：创建一个源组。 在该源组中，为每个应用服务应用创建一个源。 设置每个源的优先级，以便主应用程序的优先级高于备份应用程序。
• 多区域主动/主动部署：创建一个源组。 在该源组中，为每个应用服务应用创建一个源。 将每个源的优先级设置为相同。 设置每个源的权重以控制发送到该源的请求数。

若要了解详细信息，请参阅 Azure Front Door 中的源和源组。

Azure Front Door 是一项为应用程序提供快速可靠的 Web 交付的服务。 它提供缓存、负载平衡、安全性和路由等功能。 但是，需要了解适用于 Azure Front Door 的一些超时和限制。 这些超时和限制包括最大请求大小、最大响应大小、最大标头大小、最大标头数量、最大标头数量、最大规则数量和最大源组数量。 可以在 Azure Front Door 文档中找到有关这些超时和限制的详细信息。

大多数规则集的配置更新可在 20 分钟内完成。 更新完成后，将立即应用该规则。

Azure Front Door 有 5 秒的超时时间，用于从客户端接收标头。 如果客户端在建立 TCP/TLS 连接后 5 秒内未将标头发送到 Azure Front Door，则连接将终止。 无法配置此超时值。

Azure Front Door 具有 90 秒的 HTTP 保持活动超时。 如果客户端在 90 秒内未发送数据，则连接将终止，这是 Azure Front Door 的 HTTP 保持活动超时。 无法配置此超时值。

不能对多个 Front Door 终结点使用相同的域，因为 Front Door 需要区分每个请求的路由（协议 + 主机 + 路径组合）。 如果跨不同终结点的路由重复，Azure Front Door 将无法正确处理请求。

目前，我们不提供在不中断服务的情况下将域从一个终端节点移动到另一个终端节点的选项。 如果要将域迁移到其他终端节点，则需要计划一些停机时间。

Azure Front Door 专用链接功能与区域无关，即使你选择的区域与源所在的区域不同，该功能也将正常工作。 在这种情况下，为了确保更低的延迟，在选择启用 Azure Front Door 专用链接终结点时，应始终选择最靠近源的 Azure 区域。 我们正在为更多区域提供支持。 支持新区域后，您可以按照这些 说明 逐步将流量转移到新区域。

Azure Front Door 是一个在全球范围内分发流量的平台，可以纵向扩展以满足应用程序的需求。 它使用 Microsoft 的全球网络边缘来提供全球负载均衡功能，让您在发生故障时将整个应用程序或特定微服务切换到不同的区域或云。

为避免在传送大型文件时出错，请确保您的源服务器在响应中包含 Content-Range 标头，并且标头值与响应正文的实际大小匹配。

您可以在 交付大文件中找到有关如何配置源和 Front Door 以进行大文件交付的更多详细信息。

域前置是一种网络技术，它使攻击者能够通过在 TLS 握手和 HTTP 主机标头中使用不同的域名来隐藏恶意请求的实际目的地。

2022 年 11 月 8 日之后创建的 Azure Front Door（标准层、高级层和经典层）或 Azure CDN 标准版（来自 Microsoft 的经典）资源启用了域前置阻止。 如果两个域属于同一订阅并包含在路由/路由规则中，则我们允许差异，而不是阻止 SNI 和主机标头不匹配的请求。 域前沿阻止的实施将于 2024 年 1 月 22 日开始，适用于所有现有域。 强制措施可能需要长达两周的时间才能传播到所有区域。

当 Front Door 由于不匹配而阻止请求时：

• 客户端收到 HTTP 421 Misdirected Request 错误代码响应。
• Azure Front Door 在诊断日志中的“ 错误信息 ”属性下记录数据块，其值为 SSLMismatchedSNI。

有关域前置的详细信息，请参阅 在 Azure 中保护我们的域前置方法 和 禁止在 Azure Front Door 和 Microsoft 的 Azure CDN 标准版（经典版）上进行域前置。

Front Door 使用 TLS 1.2 作为 2019 年 9 月之后创建的所有配置文件的最低版本。

可以选择将 TLS 1.2 或 1.3 与 Azure Front Door 配合使用。 若要了解详细信息，请阅读 Azure Front Door 端到端 TLS 一文。

Azure Front Door 是一项提供快速安全的 Web 交付的服务。 它允许您定义如何跨多个区域和终端节点路由和优化 Web 流量。 Azure Front Door 资源（例如 Front Door 配置文件和路由规则）仅在启用时收费。 但是，无论 Web 应用程序防火墙 （WAF） 策略和规则的状态如何，都会收取费用。 即使您禁用了 WAF 策略或规则，它仍然会产生成本。

否。

否。

AFD 不支持对大于 8 MB 的内容进行动态压缩。 但是，如果源已压缩内容，则只要支持范围请求且未启用分块传输编码，Front Door 就支持提供超过 8 MB 的静态压缩内容。

否。

有关日志和其他诊断功能的信息，请参阅 监视 Front Door 的指标和日志。

可以将诊断日志存储在其自己的存储帐户中，并选择保留它们的时间长度。 或者，可以将诊断日志发送到事件中心或 Azure Monitor 日志。 有关详细信息，请参阅 Azure Front Door 诊断。

若要访问 Azure Front Door 的审核日志，需要访问门户。 从菜单页中选择 Front Door，然后选择“ 活动日志”。 活动日志提供 Azure Front Door作的记录。

可以根据 指标或日志为 Azure Front Door 设置警报。 通过这样做，您可以监控前端主机的性能和运行状况。

若要了解如何为 Azure Front Door Standard 和 Premium 创建警报，请参阅 配置警报。

相关内容

• 了解如何创建 Azure Front Door 配置文件。
• 了解 Azure Front Door 体系结构。