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 应用程序网关 则可与同一规模单元中的虚拟机、容器或其他资源配合使用。

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

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

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

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

Azure Front Door 是一项跨多个区域全局分发应用程序的服务。 它使用所有客户共享的通用基础设施，但你可以自定义自己的前门配置文件，以配置应用的具体需求。 其他客户的配置不会影响你的 Front Door 配置，该配置与他们的配置是完全独立的。

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

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

Azure Front Door 和 CDN 配置文件的单次创建、更新、删除或 WAF 操作的配置传播时间可能长达 15 分钟，以增加安全性。 一次缓存清理操作可在10分钟内完成。 连续进行的更改可能会使总部署时间延长至约 30 分钟。 每次配置更新，包括规则集调整、路由变更、起点或域更新以及WAF修改，都被视为全局操作。 如果你在第一个操作仍处于传播过程中时（在其约 15 分钟的时间窗口内）提交额外操作，系统会将这些操作加入队列，并在前一个操作完成后才开始处理。 在此方案中，第一个操作在初始 15 分钟内完成，后续更改将在以下窗口中进行处理。 正在进行的平台增强正在进行中，这将进一步减少这一时间。

提交多个清除请求

每个清除请求最多可以包含 100 个 URL（域和路径的组合）。 第一批处理并在大约 10 分钟内生效。

如果你有超过100个需要清除的URL，必须等待并确认第一批已完成，然后再提交下一批。 如果你在上一批完成之前提交新的清除请求，该请求将被拒绝。

示例：清除 256 个 URL

1. 提交初始清除请求中的前 100 个 URL。
2. 等待大约 10 分钟并验证第一批是否已成功完成。
3. 在第二个请求中提交下一个 101-200 个 URL。
4. 等待大约 10 分钟，等待第二批完成。
5. 在第三个请求中提交剩余的 201-256 个 URL。

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

Azure Front Door为您的网页应用带来了许多优势，例如动态站点加速（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 支持处于打开状态。

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

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

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

No. Azure Front Door 无法强制客户端流量发到特定的 POP。 请求将路由到最近的可用边缘位置，以便获得性能和可靠性。 如果需要按地理位置限制访问，请使用具有 GeoMatch 条件的 Azure Web 应用程序防火墙（WAF）自定义规则。 此方法允许或阻止基于客户端区域的请求，但它不会将这些客户端重新路由到另一区域中的另一个 POP。 例如，如果阻止国家/地区 A，则会阻止来自区域 A 中的客户端的请求，而不管哪些 POP 会为它们提供服务。 有关详细信息，请参阅 Azure WAF for Azure Front Door 中的异地筛选。

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 高级层，您可以使用 专用链接 连接到具有私有终结点的内部负载均衡器背后的源。 有关更多信息，请参阅 使用 专用链接 保护源。

No. 为了安全性，Azure Front Door 仅支持在 密钥保管库 中访问证书时基于托管标识的身份验证。 有关详细信息，请参阅 在 Azure Front Door 中使用托管标识。

No. Azure Front Door 目前不支持托管标识与 Azure 事件中心集成。

No. Azure Front Door 当前不支持自定义错误页。

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

• 你不仅希望平衡全局流量，还希望平衡虚拟网络内的流量。 Front Door 只能在全局级别执行基于路径的负载均衡，但应用程序网关可以在虚拟网络中执行该作。
• 您需要连接排空功能，但 Front Door 不支持此功能。 应用程序网关可以为虚拟机或容器启用连接排泄功能。
• 您希望卸载所有 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 和 Azure CDN 是两种服务，可为应用程序提供快速可靠的 Web 交付。 但是，它们彼此不兼容，因为它们共享相同的 Azure 边缘站点网络来向用户交付内容。 此共享网络会导致其路由策略和缓存策略之间发生冲突。 因此，必须为应用程序选择 Azure Front Door 或 Azure CDN，具体取决于你的性能和安全要求。

两个配置文件/端点都使用同一个 Azure Edge POP 节点来处理传入的请求，这会造成一种限制，使你无法将一个 Azure Front Door 配置文件/端点置于另一个之后进行嵌套。 此设置将导致路由冲突和性能问题。 因此，如果你需要为应用使用多个配置文件/端点，应确保 Azure Front Door 配置文件/端点不会被串联在一起。

Azure Front Door 正在从 Anycast 切换到单播路由，以便进行名称解析，并将请求路由到最佳 PoP 位置。 这一转换发生在2026年3月至4月之间。 切换完成后，在整个 Front Door 基础结构中，Unicast 将取代 Anycast。

Azure Front Door 后面的源的名称解析请求落在 Front Door 的流量管理器终结点上。 Front Door 的流量管理器的配置文件整合了来自全球各个存在点的众多运行状况和可用性信号。 根据这些信号，系统会返回最佳 Front Door PoP 的单播 IP 地址。 然后，将请求直接提交到返回的 IP 地址，该地址遵循 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 服务标记方案的详细信息，请参阅 可用的服务标记。 为了在 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 文档中找到有关这些超时和限制的详细信息。

大多数规则集在15分钟内就能更新配置。 该规则在更新完成后立即生效。

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 区域。 如果 Front Door 专用链接支持的区域列表中不支持源区域，请选择下一个最近的区域。 流量从客户端流向受支持区域中的 Azure Front Door 专用链接终结点，然后通过 Microsoft 主干网络传输到您的原点，保持专用连接。 请注意，由于区域之间的网络跃点增加，此配置引入了额外的延迟。 在出现新增支持区域后，你可以按照相应说明逐步将流量转移到这一新区域。

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

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

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

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

在 2022 年 11 月 8 日之后创建的 Azure Front Door（标准层、高级层）已启用域前端阻止。 相较于阻止 SNI 和主机标头不匹配的请求，如果两个域属于同一订阅并包含在路由/路由规则中，我们允许这些差异。 域前置阻断措施的执行将于 2024 年 1 月 22 日开始，适用于所有现有域名。 强制措施可能需要长达两周的时间才能传播到所有区域。

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

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

有关域伪装的详细信息，请参阅 我们在 Azure 中对域伪装的方法的安全性 和 [禁止在 Azure Front Door 上使用域伪装]。

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

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

你不能禁用 Azure Front Door 资源。 你只能删除它们。 出站数据传输、入站数据传输和请求等可变计费项在没有流量时不会产生费用，但即使没有流量，基础费用仍会收取。 基本费用会持续收取，直到资料被删除。

No.

No.

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

No.

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

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

若要访问 Azure Front Door 的审核日志，需要访问门户。 从菜单页面选择你的前门，然后选择 活动日志。 活动日志提供了您 Azure Front Door 操作的记录。

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

要了解如何为 Azure Front Door 标准版和高级版创建警报，请参阅配置警报。

相关内容

• Azure Front Door 路由体系结构