Azure Front Door 常见问题解答

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

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

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

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

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

通常不推荐将两个 CDN 链接在一起，这种方法能够奏效，但有以下缺点

1. CDN 最后的加速利用了以下方法：保持与源的连接流并找到到达源的最佳路径，以实现最佳结果。 将两个 CDN 链接在一起通常会抵消最后的加速所带来的一些好处。
2. 安全控制会在第二个 CDN 上变得不那么有效。 任何基于客户端 IP 的 ACLing 都无法在第二个 CDN 上奏效，因为第二个 CDN 会将第一个 CDN 的退出节点视为客户端 IP。 系统仍会检查内容有效负载。
3. 涉及链接两个 CDN 的故障排除工作非常复杂，很多组织都无法应对，当出现问题时，很难弄清楚是哪个 CDN 存在问题。

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

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

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

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

• 存储（Azure Blob、经典、静态网站）
• 云服务
• 应用服务
• 静态 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 配置，该配置独立于客户的配置。

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

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

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

Front Door 前端任播的 IP 地址是固定的，并且只要你使用 Front Door，它就可能不会更改。 但是，Front Door 前端任播的固定 IP 地址不能保证。 请避免直接依赖 IP。

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

是的。 请参阅访问日志下的 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 头。

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

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

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

• Front Door 标准版/高级版和 Azure CDN 配置文件可以在资源组或订阅之间移动，而不会造成任何停机。 若要执行移动，请按照这些说明操作。
• Front Door 经典版不支持在资源组或订阅之间移动。 你可以改为将经典版配置文件迁移到标准版/高级版配置文件，然后执行移动。
• 如果客户已将 WAF 关联到 Front Door 标准版/高级版，则移动操作将失败。 客户必须首先取消关联 WAF 策略，然后再移动和进行关联。

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

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

在源组中，为可为请求提供服务的每个服务器或服务创建源。 如果源具有 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 和 Azure CDN 是两项服务，可为应用程序提供快速、可靠的 Web 交付。 但是，它们彼此不兼容，因为它们共享 Azure 边缘站点的同一网络以向用户传送内容。 此共享网络会导致路由和缓存策略之间存在冲突。 因此，必须根据性能和安全要求为应用程序选择 Azure Front Door 或 Azure CDN。

事实上，这两个配置文件使用相同的 Azure 边缘站点处理传入请求，这会导致此限制阻止将一个 Azure Front Door 配置文件嵌套在另一个的后面。 此设置会导致路由冲突和性能问题。 因此，如果需要对应用程序使用多个配置文件，应确保 Azure Front Door 配置文件是独立的，不会链接在一起。

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 服务标记方案的详细信息，请参阅可用服务标记。

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

Azure Front Door 的 HTTP 保持连接超时为 90 秒。 如果客户端未在 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（标准、高级和经典层级）或 Microsoft Azure CDN 标准版资源已启用“阻止域前置”功能。 如果两个域属于同一订阅，并且包含在路由/路由规则中，则我们不会阻止具有不匹配的 SNI 和主机头的请求，而是允许该差异。 “阻止域前置”功能于 2024 年 1 月 22 日开始针对所有现有域实施。 此次实施可能需要长达两周才能传播到所有区域。

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

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

有关域前置的详细信息，请参阅在 Azure 中增强我们的域前置防御措施和在 Azure Front Door 和 Microsoft Azure CDN 标准版（经典）上禁止域前置。

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

可以选择将 TLS 1.0、1.1、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 标准版和高级版创建警报，请参阅配置警报。

后续步骤

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