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、静态网站）
• 云服务
• App Service
• 静态 Web 应用程序
• API Management
• 应用程序网关
• 公共 IP 地址
• Azure Spring Apps
• 容器实例
• 容器应用
• 任何具有公共访问权限的自定义主机名。

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

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

Azure Front Door 是一项跨多个区域全局分发应用程序的服务。 它使用由所有客户共享的通用基础结构，但你可以自定义自己的 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 和缓存清除操作的配置传播时间可能最长需要 20 分钟，以确保安全性。 连续更改可将总部署时间扩展到大约 40 分钟。 每个配置更新（包括规则集调整、路由更改、源或域更新以及 WAF 修改等）都被视为全局作。 如果在第一个操作仍在大约 20 分钟的传播时间内时提交其他操作，这些操作会排队，并且只有在前一个操作完成之后才开始。 在此方案中，第一次操作在初始 20 分钟内完成，后续更改将在接下来的时间窗口中被处理。 正在进行的平台增强正在进行中，这将进一步减少这一时间。

提交多个清除请求

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

如果 URL 超过 100 个要清除，则必须等待并验证第一批是否完成（大约 20 分钟），然后才能提交下一批。 如果在上一批完成之前提交新的清除请求，该请求将被拒绝。

示例：清除 256 个 URL

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

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

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 支持处于打开状态。

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

No. 为了安全性，Azure Front Door 仅支持在 Key Vault 中访问证书时基于托管标识的身份验证。 有关详细信息，请参阅 在 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 边缘 POP 来处理传入请求，这会导致一个限制，阻止您将一个 Azure Front Door 配置文件/终端节点嵌套在另一个配置文件/终端节点后面。 此设置将导致路由冲突和性能问题。 因此，如果您需要为应用程序使用多个 Azure Front Door 配置文件/终结点，则应确保这些配置文件/终结点之间不互相连接。

Azure Front Door 正在从 Anycast 切换到单播路由，以便进行名称解析，并将请求路由到最佳 PoP 位置。 此转换将在 2026 年 3 月至 4 月之间进行。 切换完成后，单播将用于替代整个 Front Door 基础结构中的 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 的一些超时和限制。 这些超时和限制包括最大请求大小、最大响应大小、最大标头大小、最大标头数量、最大规则数量和最大源组数。

大多数规则集的配置更新可在 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 区域。 如果 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.

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

No.

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

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

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

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

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

相关内容

• 了解 Azure Front Door 体系结构。