本文可帮助你选择正确的Azure服务，使应用程序可从 Internet 访问。 它比较公共 IP 地址、Azure 负载均衡器、应用程序网关、Azure Front Door和Azure 流量管理器。 选择适合工作负荷的协议、规模和安全要求的选项。
本文介绍的内容
为外部用户提供服务的每个Azure工作负荷都需要入口路径：Internet 流量以安全可靠地访问应用程序的方式。 选择错误的入口服务会导致过度预配、安全漏洞或不必要的复杂性。 本文可帮助你评估接受来自外部用户的入站连接的七个Azure服务，并将这些连接路由到虚拟网络中的后端资源。 您可以选择符合您的协议、规模、地理位置和安全态势的组合。
注释
本文重点介绍流量如何从 Internet 进入Azure网络。 有关如何在应用程序后端之间平衡和传送该流量（包括Azure 负载均衡器、应用程序网关和Azure Front Door的详细比较），请参阅应用程序传递和性能。
谁需要本文
如果满足以下一个或多个条件，请阅读本文：
- 应用程序必须接受来自 Internet 上的用户或系统的入站连接。
- 需要根据协议和范围在公共 IP、负载均衡器、应用程序网关、Front Door 或流量管理器之间进行选择。
- 需要为 Web、API 或 TCP/UDP 工作负载设计安全的公共入口点。
- 需要将 Internet 公开与 WAF、DDoS 保护、TLS 终止或区域和全球流量分发相结合。
Tip
按照场景路径操作？ 在页面顶部选择你的方案，以获取定制指南。 以下核心指南适用于所有读者。
直接转移焦点： 迁移的应用必须可从 Internet 访问。 评估是否需要应用程序网关、Front Door 或更简单的公共 IP 方法。 许多平移迁移的工作负载仅供内部使用，因此，如果迁移后的应用不面向外部用户，你完全可以跳过本文。
如果你符合以下情况，请阅读本文：
- 正在将本地 Web 应用程序迁移到Azure，并需要决定如何公开它。
- 需要评估迁移的工作负载是否需要 Internet 入口。
- 想了解适用于已迁移应用程序的最简单且可用于生产环境的 Ingress 方案。
现代化重点： 面向客户的流量模式决定了体系结构的外部形状。 Front Door 处理 Web 应用，流量管理器处理移动和 API 应用。 现代化 PaaS 工作负载（应用服务，AKS）需要一个定义完善的入口路径，该路径与中心辐射型安全模型集成。
如果你符合以下情况，请阅读本文：
- 部署外部用户通过 Internet 访问的面向公众的应用程序。
- 需要在面向 Web 应用程序的 Azure Front Door 和面向移动或 API 工作负载的 Traffic Manager 之间进行选择。
- 想要了解入口如何与中心防火墙集成作为 DNAT 目标。
- 需要使用 Web 应用程序防火墙（WAF）或 DDoS 防护来保护面向互联网的端点。
跨云焦点： 仅当迁移的应用面向公众时，才包括 Internet 入口。 许多跨云应用程序都是仅限内部的，在云之间通过专用传输路径进行通信。 如果工作负荷面向公众（例如，从另一个云迁移的面向客户的 Web 应用），则需要Azure中的入口路径。
如果你符合以下情况，请阅读本文：
- 将面向公众的应用程序从 AWS 或 Google Cloud 迁移到 Azure。
- 迁移后的工作负载需要在 spoke VNet 中部署启用 WAF 的应用程序网关。
- 想要避免在跨云迁移期间直接将公共 IP 分配到 VM。
Azure服务和功能
Azure为 Internet 入口提供多个服务。 每个服务在网络堆栈的不同层上运行，并提供不同的用例。
| Service | 层 | Scope | 它提供的内容 | 何时使用它 |
|---|---|---|---|---|
| 公共 IP 地址（标准 SKU） | 3 | 区域 | 直接分配的可路由 IPv4 或 IPv6 地址。 默认采用区域冗余。 | 简单、低流量的场景。 不建议在没有负载均衡器的情况下用于生产环境。 |
| Azure 负载均衡器（标准版、公共版） | 4 （TCP/UDP） | 区域 | 在各后端 VM 之间分配入站 TCP/UDP 流量。 区域冗余前端。 运行状况探测会删除不正常的实例。 | 需要高可用性的非 HTTP/S 工作负荷。 游戏服务器、IoT 终结点或其他 TCP/UDP 服务。 |
| Azure 负载均衡器 （标准版、内部版） | 4 （TCP/UDP） | 区域 | 虚拟网络中的第 4 层负载均衡。 无公共 IP。 在内部层级之间路由流量。 | 公共前端分发到后端 VM 的多层应用。 中心辐射型东西向流量。 不直接面向 Internet，但通常与公共入口服务配对。 |
| Azure 应用程序网关 | 7 （HTTP/S） | 区域 | HTTP/S 负载均衡与基于 URL 的路由、SSL/TLS 终止、会话相关性和自动缩放。 | 需要基于路径的路由、基于 Cookie 的相关性或 SSL 卸载的单区域 HTTP/S 应用。 |
| 应用程序网关 + WAF | 7 （HTTP/S） | 区域 | 带有 Web 应用程序防火墙的应用程序网关。 使用默认规则集 (DRS) 防护 OWASP Top 10 攻击，其中包括 Microsoft 威胁情报规则。 | 在单个区域中需要第 7 层负载均衡和 WAF 保护的面向公众的 Web 应用。 |
| Azure Front Door | 7 （HTTP/S） | 全球 | 具有集成 CDN、WAF 和流量路由的全局 HTTP/S 负载均衡器。 通过 Split TCP 加速，在靠近用户的边缘 PoP 处终止 TCP/TLS 连接。 | 具有全局用户群的多区域应用。 需要 CDN 缓存、全局 WAF 和自动故障转移的工作负载。 |
| Azure 流量管理器 | DNS | 全球 | 基于 DNS 的流量路由。 将 CNAME 返回到最接近或最健康的区域终结点。 客户端直接连接。 流量管理器永远不会看到应用程序流量。 | 多区域 DNS 级故障转移。 Front Door 不适用的非 HTTP/S 协议。 按地理位置、性能或优先级进行路由。 |
注释
基本 SKU 公共 IP 已停用（2025 年 9 月）。 现有基本 IP 仍可正常运行，但不支持任何 SLA。 对所有新部署使用标准 SKU。
每个服务的工作原理
了解每个服务的内部体系结构有助于预测性能、排查问题并规划子网大小调整。
公共 IP 地址
标准 SKU 公共 IP 是软件定义的资源，可将可路由的 IPv4 或 IPv6 地址直接映射到网络接口、负载均衡器前端或网关。 默认情况下，在受支持的区域内，该地址采用区域冗余，这意味着平台可在可用区之间处理故障转移，而无需你进行任何更改。 公共 IP 没有流量处理。 数据包直接流向所附加的资源，不经过任何运行状况检查或分配逻辑。
Azure 负载均衡器（标准版、公共版）
标准负载均衡器对 5 元组流（源 IP、源端口、目标 IP、目标端口、协议）使用基于哈希的分配算法。 它在第 4 层的数据路径中完全运行，因此它永远不会终止连接或检查有效负载。 运行状况探测（TCP、HTTP 或 HTTPS）会持续检查后端实例，并在几秒钟内将不健康的实例从轮换池中移除。 负载均衡器会自动扩展。 无需进行容量规划或实例规格规划。
Azure 负载均衡器 （标准版、内部版）
内部负载均衡器的工作方式与公共负载均衡器相同，但它使用来自虚拟网络子网的私有前端 IP。 它在内部层之间分配流量，例如将流量发送到中间层 API 群集的 Web 层。 因为它没有公共 IP，所以它对 Internet 不可见。 将其与负责处理外部边界流量的公网入口服务（如 Front Door、应用程序网关或公共负载均衡器）搭配使用。
Azure 应用程序网关
应用程序网关是部署到虚拟网络子网中的专用虚拟设备。 它会终止网关上的 TLS 连接，检查 HTTP 标头和 URL，并根据路径规则、主机标头或自定义运行状况探测将请求路由到后端池。 v2 SKU 支持自动缩放（0 到 125 个实例）和区域冗余。 由于它是 VNet 驻留的，因此它可以访问专用后端，而无需在这些后端上使用公共 IP。
使用 WAF 的应用程序网关
添加 WAF 层时，可以在应用程序网关处理管道中直接启用 OWASP 核心规则集并Microsoft威胁智能规则。 在到达路由规则之前，每个 HTTP 请求都会通过 WAF 引擎。 WAF 支持每个站点策略，因此可以在同一网关上为不同的侦听器或主机组合使用不同的规则配置。 WAF 以检测（仅记录日志）或防护（拦截并记录日志）模式运行。
Azure Front Door
Front Door 从Microsoft全球边缘网络（190 多个存在点）运行。 当用户建立连接时，借助 Split TCP，TCP 握手和 TLS 协商会在最近的接入点完成。 接入点会与源站保持持久的预热连接，从而消除用户直接连接时会经历的冷启动延迟。 Front Door 会在边缘执行第 7 层路由、WAF 检查、缓存和压缩，然后将请求转发到Microsoft主干网络上最近的健康源。
Azure 流量管理器
流量管理器是基于 DNS 的服务，不涉及数据路径。 当客户端解析你的流量管理器主机名时，将返回一条 CNAME 记录，该记录会根据你所选的路由方法（优先级、加权、性能、地理、多值或子网）指向运行状况最佳或最近的终结点。 流量管理器持续探测终结点运行状况并相应地更新 DNS 响应。 因为它永远不会看到应用程序流量，因此它适用于任何协议：HTTP、TCP、UDP 或专有协议。
成本模型比较
每个入口服务都遵循不同的计费模型。 使用此表估算预期流量的成本。
| Service | 计费模式 | 关键成本驱动因素 | 免费层级或内含功能 |
|---|---|---|---|
| 公共 IP 地址 | 每小时（附加）+ 每 GB 出站流量 | 附加的小时数;出口费用 | 每月前 100 GB 出站流量免费（全球） |
| 标准负载均衡器 | 每条规则每小时 + 每处理 1 GB | 负载均衡规则数;通过 LB 处理的数据 | None |
| 应用程序网关 | 每个实例每小时 + 消耗的容量单位 | 实例小时数;计算、连接和吞吐量容量单位 | None |
| 应用程序网关 + WAF | 按实例每小时（WAF 层级定价）+ 容量单位 | 与应用程序网关相同，但采用 WAF 层的每小时费率 | None |
| Azure Front Door | 按请求计费 + 按每 GB 传输量计费 + WAF 请求数 | 路由请求、从边缘到客户端的数据传输、WAF 规则评估 | 标准层包括一些基本路由 |
| Azure 流量管理器 | 每百万次 DNS 查询 + 每个运行状况检查终结点 | DNS 查询量;受监视的终结点数 | 前 10 亿个查询具有分层定价 |
Tip
对于低流量工作负载（每月请求量低于 100 万次），Front Door 的按请求计费模式可能比 Application Gateway 的按小时固定成本更经济。 随着流量的增长，每小时模型变得更加可预测。 运行Azure定价计算器，以预期吞吐量进行比较。
如何选择
使用以下决策表为您的工作负载选择合适的入口服务。 从高级决策表开始，然后使用详细比较来确认选择。
应用程序网关、Front Door 与流量管理器
此表可帮助你在三种最常见的 HTTP 和 HTTPS 入口服务之间进行选择。
| 你的需求 | 建议的服务 | 为什么 |
|---|---|---|
| HTTP/S 流量、单区域、WAF 保护 | 使用 WAF 的应用程序网关 | 具有基于路径的路由和 WAF 的区域第 7 层服务。 在虚拟网络中运行。 |
| HTTP/S 流量、多区域、全局用户、CDN + WAF | Azure Front Door | 在边缘 PoP 处终止的全局第 7 层服务。 内置 CDN、WAF 和自动故障转移。 |
| 非 HTTP/S 协议的多区域路由，或仅限 DNS 级别的路由 | Azure 流量管理器 | 适用于任何协议的基于 DNS 的路由。 没有连接终止。 |
| 具有区域 VNet 绑定处理要求的多区域 HTTP/S | 应用程序网关 + 流量管理器 | 适用于需要深度 VNet 集成，或需要区域数据主权和区域 WAF 检测的工作负载。 对于大多数多区域 HTTP/S 场景，应优先选择 Front Door。 |
Tip
对于大多数多区域 HTTP 和 HTTPS 工作负载，相比将 Application Gateway 与 Traffic Manager 结合使用的方案，Front Door 是更推荐的选择。 Front Door 提供内置的 WAF、CDN 和自动故障转移，无需管理多个区域应用程序网关实例。 应用程序网关 + 流量管理器的组合对于以下工作负载仍然适用：需要绑定到区域性 VNet 的处理、仅可在 VNet 内访问的 专用链接 源，或要求实施区域数据主权的监管要求。
入口服务比较
如果需要了解每个服务的功能，请使用此详细比较。
| Service | 层 | 全局或区域 | 连接终止 | WAF 可用 | 健康探测 | 最适用于 |
|---|---|---|---|---|---|---|
| 公共 IP 地址 | 3 | 区域 | 否（直接连接到 VM） | 否 | 否 | 无需 HA 的开发/测试单实例工作负荷 |
| 标准负载均衡器（公共） | 4 | 区域 | 否（透传） | 否 | 是（TCP、HTTP、HTTPS） | 非 HTTP 工作负载：游戏、IoT、自定义 TCP/UDP |
| 标准负载均衡器（内部） | 4 | 区域 | 否（透传） | 否 | 是（TCP、HTTP、HTTPS） | 公共入口服务后面的内部层 |
| 应用程序网关 | 7 | 区域 | 是（TLS 终止） | 否（添加 WAF 层） | 是（HTTP/S 自定义） | 具有路径路由的单区域 HTTP/S |
| 应用程序网关 + WAF | 7 | 区域 | 是（TLS 终止） | 是（DRS 规则集） | 是（HTTP/S 自定义） | 需要 WAF 的单区域 Web 应用 |
| Azure Front Door | 7 | 全球 | 是（在 PoP 处拆分 TCP 连接） | 是（内置） | 是（HTTP/S） | 支持全局加速的多区域 HTTP/S |
| Azure 流量管理器 | DNS | 全球 | 否（仅限 DNS） | 否 | 是（HTTP/S、TCP） | 多区域 DNS 级故障转移，支持任何协议 |
Internet 入口体系结构
下图显示了流向 Azure 工作负载的入站流量的常见服务链模式。 每个模式将第 7 层和第 4 层服务组合在一起，以匹配特定的协议、区域范围和安全状况。
常见的入口模式
以下模式将多个服务合并为一个完整的入口体系结构。 选择符合协议要求、区域范围和安全状况的模式。
模式 1：具有边缘安全性的全局 Web 应用程序
服务： Front Door →应用程序网关（使用 WAF）→ VM/容器
场景： 为北美、欧洲和亚洲的客户提供服务的 SaaS 应用程序需要全球加速、边缘的 DDoS 保护，以及到不同微服务的区域基于路径的路由。
Front Door 在最近的状态点（PoP）终止用户连接，应用全局 WAF 规则，并缓存静态内容。 流量通过Microsoft主干路由到区域应用程序网关，后者执行基于 URL 的路由（例如，/api/*到 API 池、/static/*存储后端）。 此模式提供两层 WAF 检测：一层位于边缘，一层位于区域。
模式 2：采用 DNS 故障转移的多区域非 HTTP 模式
服务：流量管理器 → 标准负载均衡器（每个区域） → 虚拟机
方案： 游戏公司跨三个区域在 UDP 端口 7777 上运行专用游戏服务器。 玩家会自动连接到最近的状态正常的区域。
流量管理器使用性能路由方法返回最低延迟区域的 DNS 记录。 每个区域都有一个标准负载均衡器，用于将 UDP 流量分发到虚拟机规模集中的各个实例。 如果运行状况探测检测到区域故障，流量管理器会更新 DNS 以将玩家路由到下一个最近的区域。
模式 3：使用 WAF 的简单区域 Web 应用
服务： 应用程序网关（使用 WAF）→ VM
场景： 向外部合作伙伴开放的内部业务应用程序。 单个区域，中等流量，需要 OWASP 保护和 TLS 终止。
应用程序网关提供基于路径的路由、用于会话管理的 Cookie 相关性和 WAF 保护，所有这些资源都是从虚拟网络中的单个区域资源提供的。 当流量分散在地理上时，此模式可避免全局服务的复杂性和成本。
模式 4：具有锁定的专用源的 Front Door
服务： Front Door Premium → 专用链接 → 内部负载均衡器 → 虚拟机
场景： 一个金融服务应用程序，严格要求源站不得暴露公网 IP。 所有流量都必须通过 Microsoft 主干网络传输，且不得经过任何公共互联网跃点。
Front Door Premium 通过 专用链接 终结点连接到源站。 源后端没有公共 IP 地址，也不会暴露在 Internet 上。 此模式提供完全专用源的安全性，并结合 Front Door 全球边缘网络的性能优势。
借助 Front Door 实现多区域入口
下图显示了 Azure Front Door 作为全局入口点，将用户路由到最近的运行正常的区域源站，并提供自动故障转移。
先决条件
在向 Internet 公开应用程序之前，请确保已准备好以下组件：
- 部署的虚拟网络：后端资源必须在具有适当大小的子网的Azure虚拟网络中运行。 有关子网规划指南，请参阅 “设计虚拟网络和子网 ”。
- 运行工作负荷： 至少需要一个后端资源（虚拟机、容器或平台服务），才能为流量提供服务。
- DNS 名称： 外部用户用来访问应用程序的公共 DNS 名称。 可以使用Azure DNS或第三方 DNS 提供程序。
- 入站服务的子网规划： 应用程序网关需要一个专用子网（建议生产环境至少使用 /24）。 标准负载均衡器后端实例可以与其他资源共享子网。
设计注意事项
评估提升的工作负载是否需要 Internet 入口。 许多本地应用程序都是内部应用程序，在迁移后保持这种状态。 如果需要入口，请保持体系结构简单：
- 具有 WAF 的应用程序网关提供具有 TLS 终止和 OWASP 保护的单区域第 7 层入口。 对于此前位于本地部署的反向代理之后的迁移上云的 Web 应用，这种方法最为常见。
- 对于低流量、非 HTTP 工作负荷（例如，合作伙伴连接到的 TCP 服务），可以使用具有 NSG 的公共 IP。 将 NSG 限制为已知的源 IP。
- 避免将公共 IP 直接分配给 VM。 将负载均衡器或应用程序网关放置在 Internet 和后端之间。
如果迁移过来的应用程序不为外部用户提供服务，请跳过本文并继续阅读出站 Internet 访问。
现代化工作负荷基于应用程序类型具有不同的入口模式：
- 用于面向客户的 Web 应用程序的 Azure Front Door（例如，ContosoBiz）。 Front Door 提供全局加速、内置 WAF、CDN 缓存和跨区域自动故障转移。 对主动-主动部署使用加权路由。
- Azure 流量管理器用于移动应用和 API 应用程序（例如 ContosoCare）。 流量管理器为非 HTTP 协议或客户端需要直接区域连接时提供基于 DNS 的路由。
- 中心防火墙作为 DNAT 目标：所有入站流量在到达应用层之前，都会先经过中心 Azure 防火墙。 防火墙执行目标网络地址转换（DNAT），将清洗后的流量转发到正确的分支。 该模式可确保任何未经清洗的互联网流量都不会绕过您的集中式安全控制。
将 Front Door 与每个区域中的应用程序网关相结合，进行两层 WAF 检查：一个位于全球边缘，一个位于区域边界。
对于从 AWS 或 Google Cloud 迁移过来的面向公众的应用程序，请在工作负载所在的辐射型 VNet 中部署启用了 WAF 的应用程序网关：
- 辐射 VNet 中的应用程序网关 + WAF： 在预防模式下部署启用了 WAF 的区域应用程序网关。 这种方法可使入口流量靠近工作负载，而无需让流量经由中心进行 HTTP 检查。
- VM 上没有直接的公共 IP： 切勿将公共 IP 直接分配给已迁移的 VM。 所有面向 Internet 的流量都通过应用程序网关进入。
- 锁定源站：如果应用程序此前位于 AWS 应用程序负载均衡器（ALB）或 Google Cloud Load Balancing 之后，请将该入口流量模式映射到适用于区域性工作负载的 Application Gateway，或适用于全球性工作负载的 Front Door。
如果您的跨云工作负载仅限内部使用（通过专用传输网络在云之间通信），请跳过本文，继续阅读 Azure 防火墙 和流量检查。
安全注意事项
互联网入口是应用程序的正门。 这是不受信任的 Internet 流量进入Azure环境的边界。 遵循这些做法来保护入口路径。
切勿通过公有 IP 地址将 VM 直接暴露到公网
不要将公共 IP 地址直接分配给虚拟机的网络接口，以便为端口 80 或 443 上的应用程序流量提供服务。 而是在 Internet 和 VM 之间放置负载均衡器或应用程序网关。 此方法提供：
- 用于从轮换中删除失败实例的运行状况探测
- 用于 SSL 或 TLS 终止的单一端点
- 用于应用 WAF 规则和速率限制的位置
- 对所有入站流量进行集中日志记录
注意
VM 上的公共 IP 直接向 Internet 公开每个开放端口。 如果 VM 的网络安全组有错误配置的规则，攻击者将直接访问操作系统。
在预防模式下启用 WAF
如果使用 WAF 部署应用程序网关或使用 WAF Azure Front Door，请将 WAF 设置为生产工作负荷的预防模式。 防护模式在到达应用程序之前会阻止恶意请求。 检测模式仅记录威胁而不阻止威胁。 仅在初始测试期间使用检测模式来优化规则并识别误报。
WAF 默认规则集（DRS）可防范 OWASP 前 10 个攻击，包括 SQL 注入、跨站点脚本和远程代码执行。 DRS 还包括Microsoft威胁情报规则，用于检测已知的恶意 IP 和有效负载。
启用 DDoS 防护
所有具有面向公众资源的虚拟网络都应启用 DDoS 保护。 Azure DDoS 网络保护为公共 IP 提供自适应优化、攻击遥测和成本保护。 如果没有 DDoS 防护，流量型攻击可能会使您的入站带宽饱和，并导致应用程序无法访问。
有关详细信息，请参阅 网络的 DDoS 保护。
使用 NSG 实现纵深防御
即使使用负载均衡器或应用程序网关，在后端子网上配置网络安全组规则，以限制哪些流量源可以访问 VM。 正确配置的 NSG：
- 仅允许来自负载均衡器子网或服务标签的流量
- 拒绝来自互联网到后端虚拟机的直接入站流量
- 记录被拒绝的流量以进行安全监控
有关 NSG 规划，请参阅 网络安全组和应用程序安全组。
强制实施 TLS 1.2 或更高版本
将所有入口服务配置为仅接受 TLS 1.2 或 TLS 1.3。 禁用具有已知漏洞的 TLS 1.0 和 1.1。 应用程序网关和 Front Door 都通过其 TLS 策略设置支持最低 TLS 版本配置。 除非有特定的符合性要求，否则请使用预定义策略，例如 AppGwSslPolicy20220101 应用程序网关，而不是自定义密码配置。
锁定 Front Door 的源站
使用Azure Front Door时，请限制源服务器仅接受来自 Front Door 的流量。 如果源站允许来自任意来源的流量，恶意行为者就可以通过直接连接到源站 IP 来绕过 Front Door 的 WAF，从而使你在 WAF 上的全部投入失去效果。
源锁定使用两个独立的验证机制。 将二者都用于纵深防御：
服务标记限制（网络层）
配置源站的 NSG 或 Azure 防火墙，使其仅允许来自 AzureFrontDoor.Backend 服务标记的入站 HTTP/HTTPS 流量。 此服务标记包含 Front Door 用于连接到源的所有 IP 范围。 在源所在的子网或 NIC 上应用此规则：
-
NSG 规则： 优先级 100，源 = 服务标记
AzureFrontDoor.Backend，目标 = 后端子网，端口 = 80,443，操作 = 允许。 - 默认拒绝： 确保没有其他规则允许来自 Internet 的端口 80/443 上的入站流量。 除非添加更广泛的允许规则，否则 NSG 的默认 DenyAllInbound 规则将处理此规则。
仅服务标记就不足，因为所有Azure客户的所有 Front Door 实例共享相同的服务标记 IP 范围。 不良参与者可以创建自己的 Front Door 配置文件，并将其路由到源 IP，绕过 WAF 规则。
X-Azure-FDID 标头验证（应用程序层）
Front Door 的每个请求都包含一个标头，其中包含发送请求的 Front Door 实例的唯一 X-Azure-FDID 标识符（GUID）。 在应用程序或反向代理中验证此标头，以确认该请求来自 你的 Front Door 配置文件，而不是恶意行为者。
- 在 Azure 门户中，前往 Front Door 配置文件的概述页面（“Front Door ID”字段）查找您的 Front Door ID。
- 在应用程序代码或 Web 服务器配置中，拒绝与预期 GUID 不匹配的任何请求
X-Azure-FDID。 - 对于缺少或不正确的标头值的请求，返回 HTTP 403。
将服务标记（在网络层阻止非 Front Door 流量）与标头验证（在应用层阻止来自其他客户的 Front Door 流量）结合使用，可确保只有你自己的 Front Door 实例才能访问源站。
专用链接 源站（最严格锁定）
对于需要最高级别源站隔离的工作负载，Front Door Premium 支持使用 专用链接 的源站。 您的源站不需要公网 IP 地址。 Front Door 通过 Microsoft 主干网络经由专用终结点进行连接。 此方法消除了服务标记规则或标头验证的需求，因为源完全无法从公共 Internet 访问。
相关文章
- 设计虚拟网络和子网：应用程序网关和负载均衡器后端的子网大小调整
- 网络安全组和应用程序安全组：NSG 规则，用于在入口后限制后端访问
- 应用程序交付和性能：建立入口路径后的性能优化
- 出站互联网访问：控制出站流量，与入站相对应
- 安全的管理访问：管理员访问模式，有别于应用程序用户的互联网入口访问
- Web 应用程序防火墙：详细的 WAF 配置和规则优化
- 适用于您的网络的 DDoS 防护：为所有面向公众的资源规划 DDoS 防护
Learn more
- 什么是Azure 负载均衡器？
- 什么是Azure 应用程序网关？
- 什么是 Azure Front Door？
- 什么是Azure 流量管理器？
- Azure 中的公共 IP 地址
- 应用程序网关上的 Azure Web 应用程序防火墙
- Azure DDoS 网络保护概述
后续步骤
Tip
自行探索？ 返回到 概述导航器 ，按功能查找下一篇文章。
现代化之旅的下一步：
应用程序交付和性能：优化面向客户的 PaaS 工作负载的全局交付和性能。