**发布时间:** 2025-11-14
**厂商:** AZURE
**类型:** TECH-BLOG
**原始链接:** https://techcommunity.microsoft.com/blog/azurenetworkingblog/delivering-web-applications-over-ipv6/4469638
---
<!-- AI_TASK_START: AI标题翻译 -->
[解决方案] 通过 IPv6 交付 Web 应用程序
<!-- AI_TASK_END: AI标题翻译 -->
<!-- AI_TASK_START: AI竞争分析 -->
# 解决方案分析
## 解决方案概述
该文档详细阐述了在 **Azure** 平台上为面向互联网的 Web 应用程序提供 **IPv6** 连接的多种解决方案。核心目标是应对 **IPv4 地址枯竭**、移动网络向 **IPv6-only** 的演进以及全球多国政府对公共服务提出的 **IPv6 合规性要求**。该方案解决的核心问题是如何在不彻底改造现有基于 IPv4 的后端应用架构的前提下，快速、高效地为应用启用 IPv6 访问能力。其技术原理主要基于 **双栈（Dual-Stack）部署**，即让 Azure 的网络入口服务（如负载均衡器、应用网关）同时具备 IPv4 和 IPv6 前端地址。这些服务作为流量网关，能够接收并处理来自任一协议族的客户端请求。其中，**Application Gateway** 和 **Azure Front Door** 等 L7 服务具备关键的 **协议转换能力**，可以将来自客户端的 IPv6 请求转换为对后端服务的 IPv4 请求，从而极大地简化了现有应用的 IPv6 适配过程。
## 实施步骤
1. **规划并启用Azure VNET的IPv6地址**：为应用程序所在的虚拟网络（VNET）添加 IPv6 地址空间（推荐 /56），并为相关子网分配 /64 的 IPv6 前缀，使其成为双栈网络。
2. **部署或更新支持IPv6的前端服务**：选择一个合适的 Azure 前端服务（如 Application Gateway v2, Standard Load Balancer, Azure Front Door），并为其配置一个公共 IPv6 地址，通常采用双栈模式以同时获得 IPv4 和 IPv6 地址。
3. **配置后端和路由规则**：将后端应用服务器（通常仍使用 IPv4 地址）添加到前端服务的后端池中。配置监听器、负载均衡规则和健康探测，确保流量能被正确路由到健康的后端实例。
4. **更新DNS记录**：为应用程序的域名添加一条 **AAAA 记录**，指向新分配的 IPv6 地址。同时保留指向 IPv4 地址的 A 记录，以确保双栈客户端均可访问。
5. **测试IPv6连接性**：从一个启用 IPv6 的网络或使用在线测试工具，验证应用程序是否可以通过其 IPv6 地址成功访问，并检查 SSL 证书、路由等功能是否正常。
## 方案客户价值
- **扩大客户覆盖范围**：通过支持 IPv6，企业可以触达日益增长的 **IPv6-only** 网络用户（如部分移动网络和物联网设备），并满足美国、欧盟、印度等国家和地区的 **政府合规性要求**。
- **简化架构并消除NAT依赖**：IPv6 提供了近乎无限的地址空间，使得每个服务都可以拥有独立的公共地址，从而避免了因 IPv4 地址短缺而引入的复杂 **网络地址转换（NAT）** 和 **运营商级NAT（CGNAT）** 架构，简化了故障排查和网络管理。
- **无缝双栈兼容性**：Azure 的解决方案支持平滑过渡。通过双栈部署，企业可以在不影响现有 IPv4 用户访问体验的同时，逐步引入 IPv6 支持，实现新旧协议的无缝兼容。
- **面向未来的架构**：采用 IPv6 不仅可能在某些网络中获得性能优势，更重要的是使应用架构能够适应未来的技术演进，为将来完全基于 IPv6 的新服务和功能做好准备。
## 涉及的相关产品
- **全局流量管理与应用交付**
- **Azure Front Door**: L7 全局应用交付网络，提供 **Anycast** IP（IPv4/IPv6）、CDN、WAF 和智能路由功能。支持 IPv4 和 IPv6 后端，并可通过 **Private Link** 实现与后端的安全私有连接。
- **Azure Traffic Manager**: 基于 DNS 的全局负载均衡器，可根据性能、地理位置或优先级等策略，将客户端流量导向不同区域的 Application Gateway 端点。
- **区域性负载均衡**
- **Application Gateway (v2 SKU)**: L7 区域性负载均衡器，提供 SSL 卸载、WAF 和基于路径的路由。其核心优势是支持 **IPv6 前端** 与 **IPv4 后端** 的组合，实现协议转换。
- **External Load Balancer (Standard SKU)**: L4 区域性负载均衡器，为 TCP/UDP 流量提供高性能分发。要求前端和后端虚拟机都具备 IPv6 地址。
- **Global Load Balancer**: L4 跨区域负载均衡器，使用单个静态 **Anycast IP** 在全球范围内路由流量，实现比 DNS 方案更快的故障转移和更低的延迟。
- **基础网络与IP服务**
- **Virtual Network (VNET)**: Azure 的核心网络构建块，原生支持 IPv4/IPv6 双栈配置。
- **Public IP addresses / Prefixes**: 用于分配静态或动态的公共 IPv4 和 IPv6 地址。
- **DNS与安全**
- **Azure DNS**: 支持为域名配置 AAAA 记录，以解析到 IPv6 地址。
- **Azure DDoS Protection**: 为包括 IPv6 在内的公网端点提供增强的 DDoS 攻击缓解服务。
- **应用平台**
- **App Service**: （公共预览版）支持入站 IPv6 连接。
## 技术评估
- **技术先进性**
- Azure 提供了从 L4 到 L7、从区域到全局的完整 IPv6 应用交付解决方案栈。特别是 **Application Gateway** 和 **Azure Front Door** 所具备的 **IPv6-to-IPv4 协议转换能力**，极大地降低了企业采纳 IPv6 的技术门槛和改造成本，是其关键的技术优势。
- **Global Load Balancer** 和 **Azure Front Door** 采用的 **Anycast** 网络技术，代表了现代全局负载均衡的先进方向。相比传统的 DNS 方案（如 Traffic Manager），它能提供近乎即时的故障转移和基于网络拓扑的最优路径选择，显著提升了应用的可用性和性能。
- **架构选型分析**
- **L4 vs. L7 负载均衡**:
- **External/Global Load Balancer (L4)**: 适用于需要高性能、低延迟和保留原始客户端 IP 的 TCP/UDP 应用。架构更简单，但要求后端也必须支持 IPv6，对现有架构有一定侵入性。
- **Application Gateway/Front Door (L7)**: 专为 Web 应用设计，提供 SSL 卸载、WAF、URL 路由等高级功能。其最大优势是后端无需改造即可支持 IPv6 访问，是平滑迁移的首选。
- **单区域 vs. 多区域部署**:
- **单区域**: 使用 **External Load Balancer** 或 **Application Gateway** 即可满足需求，部署简单，成本效益高。
- **多区域**:
- **Traffic Manager + Application Gateway**: 经典的 DNS 方案，成熟稳定，但故障转移受 DNS TTL 限制，存在分钟级延迟。
- **Global Load Balancer**: L4 多区域场景下的最优选，通过 Anycast IP 实现秒级故障转移和低延迟路由。
- **Azure Front Door**: L7 多区域场景下的最优选，集成了 CDN、WAF 和 Anycast 路由，功能全面，性能卓越，并通过 **Private Link** 提供了增强的后端安全性。
- **可行性与适用范围**
- 方案覆盖了从简单的单体 Web 应用到复杂的全球分布式微服务等多种场景，可行性极高。企业可根据应用类型、部署范围、性能、安全及成本要求，灵活组合产品，构建最合适的 IPv6 交付架构。
- **当前限制**
- 部分核心网络服务（如 **VPN Gateway**, **Azure Firewall**, **Virtual WAN**）尚不支持 IPv6，这可能对需要端到端 IPv6 连接的混合云或复杂网络拓扑构成挑战。
- **Application Gateway** 必须使用 **v2 SKU**，**External Load Balancer** 必须使用 **Standard SKU** 才支持 IPv6，存量用户可能需要升级。
- **Application Gateway** 不支持 IPv6 后端池，而 **External Load Balancer** 则要求后端必须是双栈。这一差异在架构设计时需重点关注。
<!-- AI_TASK_END: AI竞争分析 -->
<!-- AI_TASK_START: AI全文翻译 -->
# 通过 IPv6 交付 Web 应用程序
**原始链接:** [https://techcommunity.microsoft.com/blog/azurenetworkingblog/delivering-web-applications-over-ipv6/4469638](https://techcommunity.microsoft.com/blog/azurenetworkingblog/delivering-web-applications-over-ipv6/4469638)
**发布时间:** 2025-11-14
**厂商:** AZURE
**类型:** TECH-BLOG
---
Azure Networking Blog
# 通过 IPv6 交付 Web 应用程序
2025 年 11 月 14 日
IPv4 地址空间池早已耗尽，这意味着互联网注册管理机构 (Internet Registries) 已无新的公共地址空间可供分配。目前，互联网仍然通过网络地址转换 (NAT) 和 [运营商级 NAT (Carrier Grade NAT)](https://en.wikipedia.org/wiki/Carrier-grade_NAT) 等技术手段，以及通过 [IPv4 地址空间交易](https://iptrading.com/) 进行地址空间再分配来维持 IPv4 的运行。
[IPv6](https://en.wikipedia.org/wiki/IPv6) 最终将成为互联网上的主导网络协议，因为网络运营商、托管服务提供商和 ISP 使用的 IPv4 续命机制终将达到其可扩展性的极限。移动网络已经在转向纯 IPv6 的接入点名称 (APN)；从这些移动网络访问纯 IPv4 的目的地需要通过 6-4 NAT 网关，这有时会引发问题。
客户端对 IPv6 的采用率正在稳步增长。[Google](https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption) 报告称，全球有 49% 的客户端通过 IPv6 连接其服务，其中法国以 80% 的采用率领先。
Google 测量的 IPv6 客户端访问量：
与此同时，世界各国正要求公共 Web 服务必须支持 IPv6 访问。例如 [美国](http://\(https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-07.pdf)) 、包括 [荷兰](https://www.forumstandaardisatie.nl/ipv6) 和 [挪威](http://\(https://lovdata.no/dokument/SF/forskrift/2013-04-05-959#shareModal)) 在内的欧盟成员国，以及 [印度](https://dot.gov.in/ipv6-transition-across-stakeholders) 和日本。
Google 测量的各国 IPv6 采用率：
需要遵守这些强制要求的实体正在寻求 Azure 的网络能力来提供解决方案。Azure 支持私有和公有网络的 IPv6，其功能也随着时间的推移不断发展和扩展。
本文将探讨构建和部署支持 IPv6 的、面向互联网的公共应用程序的策略，使其能够被纯 IPv6 (IPv6-only) 客户端访问。
## Azure 网络 IPv6 能力
Azure 的私有网络能力以虚拟网络 (VNET) 及其内部署的组件为核心。Azure VNET 支持 [IPv4/IPv6 双栈 (dual stack)](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/ipv6-overview) ：一个 VNET **必须** 始终分配 IPv4 地址空间，并且 **可以** 同时拥有 IPv6 地址空间。双栈 VNET 中的虚拟机 (Virtual machines) 将同时拥有来自 VNET 范围的 IPv4 和 IPv6 地址，并且可以置于支持 IPv6 的外部负载均衡器 (External Load Balancers) 和内部负载均衡器 (Internal Load Balancers) 之后。VNET 之间可以通过 VNET 对等互连 (VNET peering) 进行连接，这实际上将对等的 VNET 变成了一个单一的路由域。现在，可以仅对 VNET 的 IPv6 地址空间进行对等互连，这样分配给 VNET 的 IPv4 空间就可以重叠，而跨对等互连的通信则通过 IPv6 进行。通过 ExpressRoute 连接到本地环境也是如此：私有对等互连 (Private Peering) 可以仅为 IPv6 启用，这样 Azure 中的 VNET 就不必分配唯一的 IPv4 地址空间，而这在企业中可能供应紧张。
并非所有内部网络组件都已支持 IPv6。最主要的例外是 VPN 网关 (VPN Gateway)、Azure 防火墙 (Azure Firewall) 和虚拟广域网 (Virtual WAN)；IPv6 兼容性已在这些服务的路线图上，但目标可用日期尚未公布。
现在，让我们专注于 Azure 面向外部的公共网络服务。Azure 已准备好让客户通过 IPv6 发布他们的 Web 应用程序。
支持 IPv6 的面向外部的网络服务包括：
- [Azure Front Door](https://learn.microsoft.com/en-us/azure/frontdoor/front-door-overview#global-delivery-scale-using-microsofts-network)
- [应用程序网关 (Application Gateway)](https://learn.microsoft.com/en-us/azure/application-gateway/ipv6-application-gateway-portal)
- [外部负载均衡器 (External Load Balancer)](https://learn.microsoft.com/en-us/azure/load-balancer/deploy-ipv4-ipv6-dual-stack-standard-load-balancer)
- [公共 IP 地址 (Public IP addresses)](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-addresses#ip-address-version) 和 [公共 IP 地址前缀 (Public IP address prefixes)](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-address-prefix)
- [Azure DNS](https://learn.microsoft.com/en-us/azure/dns/dns-faq#do-azure-dns-name-servers-resolve-over-ipv6-->)
- [Azure DDOS 防护 (Azure DDOS Protection)](https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-protection-sku-comparison#tiers)
- [流量管理器 (Traffic Manager)](https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-faqs#does-traffic-manager-support-ipv6-endpoints)
- [应用服务 (App Service)](https://azure.github.io/AppService/2024/11/08/Announcing-Inbound-IPv6-support.html) (IPv6 支持处于公共预览阶段)
## IPv6 应用程序交付
**IPv6 应用程序交付 (Application Delivery)** 指的是使您的 Web 应用程序能够通过 IPv6 访问的架构和服务。其目标是为客户端提供 IPv6 地址和连接，同时通常在内部继续在 IPv4 上运行您的应用程序。
在 Azure 中采用 IPv6 的主要优势包括：
✅ **扩大客户端覆盖范围：** 纯 IPv4 的网站可能会面临无法被纯 IPv6 网络访问的风险。通过启用 IPv6，您可以将业务扩展到默认使用 IPv6 的不断增长的移动和物联网市场。政府和企业也日益强制要求面向公众的服务支持 IPv6。
✅ **地址充裕且无需 NAT：** IPv6 提供了几乎无限的地址池，缓解了 IPv4 耗尽的问题。这种充裕性意味着每个服务都可以拥有自己的公共 IPv6 地址，通常无需复杂的 NAT 方案。端到端的寻址可以简化连接和故障排查。
✅ **双栈兼容性：** Azure 支持双栈部署，服务可以同时监听 IPv4 和 IPv6。这使得单个应用程序实例或端点能够无缝地为两种类型的客户端提供服务。双栈确保您在增加 IPv6 功能的同时，不会失去任何现有的 IPv4 用户。
✅ **性能和未来服务：** 某些网络和客户端可能会在 IPv6 上体验到更好的性能。此外，为 IPv6 做好准备，也为您的架构迎接未来 Azure 的新功能和服务做好了准备，因为 IPv6 的集成正在整个平台深化。
在 Azure 中为 Web 应用程序启用 IPv6 连接的常规步骤如下：
1. **规划并启用 Azure 中的 IPv6 寻址**：在您的 Azure 虚拟网络中定义一个 IPv6 地址空间。Azure 允许向现有 VNET 添加 IPv6 地址空间，使其成为双栈。建议为 VNET 使用 /56 的段，子网则需要 /64 的段 (Azure *要求* /64 子网)。如果您有现有基础设施，可能需要创建新的子网或迁移资源，特别是因为旧的 [Application Gateway v1 实例不能简单地“升级”为双栈](https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-faq#does-application-gateway-support-ipv6) 。
2. **使用 IPv6 部署或更新前端服务**：选择一个合适的 Azure 服务 (Application Gateway、External / Global Load Balancer 等)，并为其前端配置一个公共 IPv6 地址。这通常意味着选择*双栈*配置，以便服务同时获得一个 IPv4 和一个 IPv6 公共 IP。例如，在创建 Application Gateway v2 时，您需要指定 [IP 地址类型：双栈 (IPv4 & IPv6)](https://learn.microsoft.com/en-us/azure/application-gateway/ipv6-application-gateway-portal) 。Azure Front Door [默认](https://learn.microsoft.com/en-us/azure/frontdoor/front-door-overview) 通过其全局端点提供双栈功能。
3. **配置后端和路由**：通常您的后端服务器或服务将继续使用 IPv4。在 2025 年 10 月撰写本文时，Azure Application Gateway 不支持后端池地址使用 IPv6。这没有问题，因为前端会终止来自客户端的 IPv6 网络连接，而后端会向后端池或源发起一个 IPv4 连接。确保您的负载均衡规则、侦听器配置和健康探测都已设置为将流量路由到这些后端。IPv4 和 IPv6 前端侦听器可以共享同一个后端池。Azure Front Door 支持 IPv6 源。
4. **更新 DNS 记录**：为您的应用程序主机名发布一条 DNS **AAAA 记录 (AAAA record)**，指向新的 IPv6 地址。这一步至关重要，以便纯 IPv6 客户端能够发现您服务的 IPv6 地址。如果您的服务同时也有一个 IPv4 地址，您将为同一个主机名同时拥有 [A (IPv4) 和 AAAA (IPv6) 记录](https://learn.microsoft.com/en-us/azure/dns/dns-zones-records#record-types) 。这样，DNS 将允许任一 IP 协议族的客户端进行连接。(在使 Traffic Manager 或 Front Door 的多区域场景中，DNS 配置可能由这些服务处理，详见后文)。
5. **测试 IPv6 连接**：设置完成后，从一个支持 IPv6 的网络进行测试，或使用在线工具确保网站可以通过 IPv6 访问。Azure 的服务如 Application Gateway 和 Front Door 会处理双栈路由，但最好验证一下内容在纯 IPv6 连接上是否能加载，以及 SSL 证书等是否像在 IPv4 上一样在 IPv6 上正常工作。
接下来，我们将详细探讨用于 IPv6 Web 交付的特定 Azure 服务和架构。
## 外部负载均衡器 - 单区域
Azure [外部负载均衡器 (External Load Balancer)](https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-overview) (也称为公共负载均衡器 (Public Load Balancer)) 可以部署在单个区域，为运行在虚拟机或 VM 规模集 (VM scale sets) 上的应用程序提供 IPv6 访问。**外部负载均衡器作为 IPv6 流量的第 4 层 (Layer 4) 入口点**，将连接分发到后端实例。当您拥有无状态应用程序或不需要 SSL 终止或基于路径的路由等第 7 层 (Layer 7) 功能的服务时，此场景非常理想。
**外部负载均衡器的关键 IPv6 功能**：
- **双栈前端：** Standard Load Balancer 支持同时拥有 [IPv4 和 IPv6 前端](https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-ipv6-overview) 。当配置为双栈时，负载均衡器会获得两个公共 IP 地址——一个 IPv4 和一个 IPv6——并且可以将来自两种 IP 协议族的流量分发到同一个后端池。
- **默认区域冗余：** Standard Load Balancer 默认是区域冗余的，无需额外配置即可在一个区域内的 Azure 可用区 (Availability Zones) 之间提供高可用性。
- **IPv6 前端可用性：** Standard Load Balancer 中的 IPv6 支持在所有 Azure 区域都可用。Basic Load Balancer 不支持 IPv6，因此您必须使用 Standard SKU。
- **IPv6 后端池支持：** 虽然前端接受 IPv6 流量，但负载均衡器不会将 IPv6 转换为 IPv4。后端池成员 (VM) 必须拥有私有 IPv6 地址。您需要为您现有的纯 IPv4 VM 基础设施添加私有 IPv6 寻址。这与下面将讨论的 Application Gateway 不同，后者会终止入站的 IPv6 网络会话，并通过 IPv4 连接到后端。
- **协议支持：** 支持通过 IPv6 进行 TCP 和 UDP 负载均衡，使其适用于 Web 应用程序和 API，也适用于纯 IPv6 客户端访问的非 Web TCP 或 UDP 服务。
要在一个区域设置一个支持 IPv6 的外部负载均衡器，请执行以下步骤：
1. **在虚拟网络上启用 IPv6：** 确保后端 VM 所在的 VNET 拥有一个 IPv6 地址空间。为 VNET 添加一个双栈地址空间 (例如，在现有 IPv4 空间的基础上添加一个像 2001:db8:1234::/56 这样的 IPv6 空间)。配置双栈子网，包含 IPv4 和 IPv6 前缀 (IPv6 为 /64)。
2. **创建具有 IPv6 前端的 Standard Load Balancer：** 在 Azure 门户中，创建一个新的 Standard Load Balancer。在创建过程中，为前端 IP 配置 IPv4 和 IPv6 公共 IP 地址。创建或选择现有的 Standard SKU 公共 IP 资源——一个用于 IPv4，一个用于 IPv6。
3. **配置后端池：** 将您的虚拟机或 VM 规模集实例添加到后端池。请注意，您的后端实例需要拥有私有 IPv6 地址以及 IPv4 地址，才能通过负载均衡器接收 IPv6 入站流量。
4. **设置负载均衡规则：** 创建将前端端口映射到后端端口的负载均衡规则。对于 Web 应用程序，通常将 IPv4 和 IPv6 前端的 80 端口 (HTTP) 和 443 端口 (HTTPS) 映射到相应的后端端口。配置健康探测以确保只有健康的实例接收流量。
5. **配置网络安全组：** 确保后端 VM 的子网上存在一个网络安全组 (NSG)，允许来自互联网的流量进入 Web 应用程序的端口。入站流量默认是“安全”的，意味着除非有 NSG 明确允许，否则来自互联网的入站连接是被阻止的。
6. **DNS 配置：** 为您的应用程序创建 DNS 记录：一个指向负载均衡器前端 IPv4 地址的 A 记录，以及一个指向 IPv6 地址的 AAAA 记录。
**结果：** 在这个单区域场景中，纯 IPv6 客户端会将您的应用程序主机名解析为一个 IPv6 地址，并通过 IPv6 连接到外部负载均衡器。
**示例：** 假设一个 Web 应用程序运行在瑞典中部的一个 VM (或 VM 规模集) 后面，该 VM 由一个外部负载均衡器提供服务。VM 运行着一个暴露在 80 端口的 [Azure Region and Client IP Viewer](https://github.com/mddazure/azure-region-viewer) 容器化应用程序，该程序会显示 VM 部署的区域和调用客户端的 IP 地址。负载均衡器前端的 IPv6 地址有一个 DNS 名称为 `_ipv6webapp-elb-swedencentral.swedencentral.cloudapp.azure.com_`。当从一个具有 IPv6 地址的客户端调用时，应用程序会显示其区域和客户端的地址。
**限制与注意事项：**
- _需要 Standard SKU：_ Basic Load Balancer 不支持 IPv6。您必须使用 Standard Load Balancer。
- _仅限第 4 层_：与 Application Gateway 不同，外部负载均衡器在第 4 层 (传输层) 工作。它不能执行 SSL 终止、基于 Cookie 的会话亲和性或基于路径的路由。如果您需要这些功能，请考虑使用 Application Gateway。
- _需要双栈 IPv4/IPv6 后端：_ 后端池成员必须拥有私有 IPv6 地址才能通过负载均衡器接收 IPv6 入站流量。负载均衡器不会在 IPv6 前端和 IPv4 后端之间进行转换。
- _出站连接：_ 如果您的后端 VM 需要通过 IPv6 进行出站互联网访问，您需要配置一个 IPv6 出站规则。
## 全球负载均衡器 - 多区域
Azure [全球负载均衡器 (Global Load Balancer)](https://learn.microsoft.com/en-us/azure/load-balancer/cross-region-overview) (又称跨区域负载均衡器 (Cross-Region Load Balancer)) 提供了一个云原生的全球网络负载均衡解决方案，用于在多个 Azure 区域之间分发流量。与基于 DNS 的解决方案不同，全球负载均衡器使用任播 (anycast) IP 寻址，通过微软的全球网络自动将客户端路由到最近的健康区域部署。
**全球负载均衡器的主要特点：**
- **静态任播全局 IP：** 全球负载均衡器提供一个静态的公共 IP 地址 (支持 IPv4 和 IPv6)，该地址从全球所有微软广域网边缘节点进行宣告。这个任播地址确保客户端始终连接到最近的可用微软边缘节点，无需进行 DNS 解析。
- **地理邻近路由：** 地理邻近路由 (Geo-Proximity Routing) 算法通过将流量引导到后端部署所在的最近区域来最小化延迟。与基于 DNS 的路由不同，这里没有 DNS 查询延迟——客户端直接连接到任播 IP，并立即被路由到最佳区域。
- **第 4 层穿透：** 全球负载均衡器作为一个第 4 层穿透 (pass-through) 网络负载均衡器运行，保留原始客户端 IP 地址 (包括 IPv6 地址)，供后端应用程序在其逻辑中使用。
- **区域冗余：** 如果一个区域发生故障，流量会在几秒钟内自动路由到下一个最近的健康区域负载均衡器，提供即时的全局故障转移 (failover)，没有 DNS 传播延迟。
**架构概述：** 全球负载均衡器位于多个区域性 Standard Load Balancer 的前面，每个都部署在不同的 Azure 区域。每个区域性负载均衡器为其本地应用程序部署提供 IPv6 前端服务。全球负载均衡器提供一个单一的任播 IP 地址，全球客户端可以用它来访问您的应用程序，并自动路由到最近的健康区域。
**多区域部署步骤：**
1. **部署区域性负载均衡器：** 在多个 Azure 区域 (例如瑞典中部、美国东部 2 区) 创建 Standard External Load Balancer。为每个负载均衡器配置双栈前端 (IPv4 和 IPv6 公共 IP)，并将它们连接到运行您应用程序的区域性 VM 部署或 VM 规模集。
2. **配置全局前端 IP 地址：** 在一个支持的 [全球负载均衡器主区域](https://learn.microsoft.com/en-us/azure/load-balancer/cross-region-overview#home-regions-in-azure) 中，为前端创建一个全局层级的公共 IPv6 地址。这将成为您应用程序的全局任播地址。
3. **创建全球负载均衡器：** 在同一个主区域部署全球负载均衡器。主区域是全球负载均衡器资源部署的地方——它不影响流量路由。
4. **添加区域性后端：** 配置全球负载均衡器的后端池，以包含您的区域性 Standard Load Balancer。每个区域性负载均衡器都成为全局后端池中的一个端点。全球负载均衡器会自动监控每个区域性端点的健康状况。
5. **设置负载均衡规则：** 创建将前端端口映射到后端端口的负载均衡规则。对于 Web 应用程序，通常映射 80 端口 (HTTP) 和 443 端口 (HTTPS)。全球负载均衡器上的后端端口必须与区域性负载均衡器的前端端口匹配。
6. **配置健康探测：** 全球负载均衡器每 5 秒自动监控区域性负载均衡器的健康状况。如果一个区域性负载均衡器的可用性降至 0，它将自动从轮换中移除，流量将被重定向到其他健康区域。
7. **DNS 配置：** 创建指向全球负载均衡器任播 IP 地址的 DNS 记录。为您的应用程序主机名创建 A (IPv4) 和 AAAA (IPv6) 记录，指向全球负载均衡器的静态 IP。
**结果：** 连接到您应用程序主机名的 IPv6 客户端将解析到全球负载均衡器的任播 IPv6 地址。当他们连接到此地址时，微软全球网络基础设施会自动将其连接路由到最近的参与 Azure 区域。然后，区域性负载均衡器将流量分发到本地后端实例。如果该区域变得不可用，后续连接将自动路由到下一个最近的健康区域。
**示例：** 我们的 Web 应用程序现在运行在瑞典中部和美国东部 2 区的 VM 上，这些 VM 位于外部负载均衡器之后。这些外部负载均衡器的前端位于一个全球负载均衡器的后端池中，该全球负载均衡器拥有一个全局层级的前端 IPv6 地址。该前端的完全限定域名 (FQDN) 为 `ipv6webapp-glb.eastus2.cloudapp.azure.com` (FQDN 中的区域标识 `eastus2` 指的是全球负载均衡器的“主区域”，全局层级的公共 IP 必须部署在该区域)。
当从欧洲的客户端调用时，全球负载均衡器将请求导向部署在瑞典中部的实例。
当从美国的客户端调用时，全球负载均衡器将请求导向部署在美国东部 2 区的实例。
**特性：**
- **客户端 IP 保留：** 原始的 IPv6 客户端地址被保留并可供后端应用程序使用，从而支持基于 IP 的逻辑和合规性要求。
- **浮动 IP 支持：** 在全局级别配置浮动 IP，以支持需要直接服务器返回或高可用性集群的高级网络场景。
- **即时扩展：** 在不中断服务的情况下，在全局端点后添加或移除区域性部署，从而为流量事件实现动态扩展。
- **多协议支持：** 支持跨区域的 TCP 和 UDP 流量分发，适用于 Web 服务之外的各种应用程序类型。
**限制与注意事项：**
- _主区域要求：_ 全球负载均衡器只能部署在特定的 [主区域](https://learn.microsoft.com/en-us/azure/load-balancer/cross-region-overview#home-regions-in-azure) ，但这不影响流量路由性能。
- _仅限公共前端：_ 全球负载均衡器目前仅支持公共前端——内部/私有全局负载均衡尚不可用。
- _Standard Load Balancer 后端：_ 后端池只能包含 Standard Load Balancer，不能是 Basic Load Balancer 或其他资源类型。
- _IP 版本要求相同：_ 不支持 NAT64 转换——前端和后端必须使用相同的 IP 版本 (IPv4 或 IPv6)。
- _端口一致性：_ 全球负载均衡器上的后端端口必须与区域性负载均衡器的前端端口匹配，以确保流量正常流动。
- _健康探测依赖：_ 区域性负载均衡器必须配置正确的健康探测，全球负载均衡器才能准确评估区域健康状况。
**与基于 DNS 的解决方案比较：**
与 Traffic Manager 或其他基于 DNS 的全局负载均衡解决方案不同，全球负载均衡器提供：
- **即时故障转移：** 没有 DNS 生存时间 (TTL) 延迟——故障转移在网络层面于几秒钟内完成。
- **真正的任播：** 单一 IP 地址全球通用，无需客户端 DNS 解析。
- **一致的性能：** 通过微软骨干网的地理邻近路由确保最佳路径。
- **简化的管理：** 无需管理 DNS 记录或考虑 TTL。
该架构通过任播路由为 IPv6 应用程序提供**全球高可用性和最佳性能**，使其成为需要全球可访问性且具有近乎即时区域故障转移的延迟敏感型应用程序的理想解决方案。
## 应用程序网关 - 单区域
[Azure 应用程序网关 (Azure Application Gateway)](https://learn.microsoft.com/en-us/azure/application-gateway/overview) 可以部署在单个区域，为该区域的应用程序提供 IPv6 访问。Application Gateway 作为 IPv6 流量的入口点，终止来自 IPv6 客户端的 HTTP/S 连接，并通过 IPv4 将其转发到后端服务器。当您的 Web 应用程序从一个 Azure 区域提供服务，并且您希望为其启用 IPv6 连接时，此场景非常适用。
**Application Gateway (v2 SKU) 的关键 IPv6 功能：**
- **双栈前端：** Application Gateway v2 支持 [IPv4 和 IPv6 前端](https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-faq) 。当配置为双栈时，网关会获得两个 IP 地址——一个 IPv4 和一个 IPv6——并且可以在两者上进行监听。(不支持纯 IPv6；IPv4 总是配对存在)。IPv6 支持需要 Application Gateway v2，v1 不支持 IPv6。
- **后端不支持 IPv6：** 后端池必须使用 IPv4 地址。目前不支持后端服务器使用 IPv6 地址。这意味着您的 Web 服务器可以继续使用 IPv4 内部地址，这简化了采用过程，因为您只需在前端启用 IPv6。
- **WAF 支持：** Application Gateway Web 应用程序防火墙 (WAF) 将像检查 IPv4 流量一样检查 IPv6 客户端流量。
**单区域部署步骤：** 要在一个区域设置一个支持 IPv6 的 Application Gateway，请考虑以下步骤：
1. **在虚拟网络上启用 IPv6：** 确保 Application Gateway 将要驻留的区域 VNET 拥有一个 IPv6 地址空间。为 Application Gateway 配置一个双栈子网 (包含一个 IPv4 子网前缀和一个 IPv6 /64 前缀)。
2. **部署双栈前端的 Application Gateway (v2)：** 使用 **Standard_v2 或 WAF_v2 SKU** 创建一个新的 Application Gateway。
3. **填充后端池：** 确保您的后端池 (目标应用程序服务器或服务) 包含指向您实际 Web 服务器 IPv4 地址的 (DNS 名称)。后端不支持 IPv6 地址。
4. **配置侦听器和规则：** 在 Application Gateway 上为您的站点设置侦听器。创建 HTTP(S) 侦听器时，您可以选择使用哪个前端 IP——您将为 IPv4 地址创建一个侦听器，为 IPv6 创建另一个。两个侦听器可以使用相同的域名 (主机名) 和相同的底层路由规则指向您的后端池。
5. **测试和 DNS：** 网关部署和配置完成后，记下前端的 IPv6 地址 (您可以在网关的概述或关联的公共 IP 资源中找到它)。更新您应用程序的 DNS 记录：创建一个指向此 IPv6 地址的 **AAAA 记录** (如果 IPv4 地址有变动，也请更新 A 记录)。DNS 设置到位后，通过从支持 IPv6 的客户端或工具访问应用程序来进行测试。
**结果：** 在这个单区域场景中，纯 IPv6 客户端会将您网站的主机名解析为一个 IPv6 地址，并通过 IPv6 连接到 Application Gateway。然后，Application Gateway 处理流量，并通过 IPv4 在内部将其转发到您的应用程序。从用户角度看，该服务现在原生支持 IPv6。重要的是，这不需要对 Web 服务器进行任何更改，它们可以继续使用 IPv4。
Application Gateway 会在 X-Forwarded-For 标头 (X-Forwarded-For header) 中包含源 IPv6 地址，以便后端应用程序可以看到原始客户端的地址。
**示例：** 我们的 Web 应用程序现在运行在瑞典中部的一个 VM 后面，该 VM 由 Application Gateway 提供服务。前端的 FQDN 为 `ipv6webapp-appgw-swedencentral.swedencentral.cloudapp.azure.com`。
Application Gateway 终止来自客户端的 IPv6 连接，并通过 IPv4 将流量代理到应用程序。客户端的 IPv6 地址通过 X-Forwarded-For 标头传递，应用程序会读取并显示该地址。
调用应用程序位于 `/api/region` 的 API 端点会显示更多细节，包括发起与后端连接的 Application Gateway 实例的 IPv4 地址，以及保留在 X-Forwarded-For 标头中的原始客户端 IPv6 地址 (附加了源端口号)。
```
{
"region": "SwedenCentral",
"clientIp": "2001:1c04:3404:9500:fd9b:58f4:1fb2:db21:60769",
"xForwardedFor": "2001:1c04:3404:9500:fd9b:58f4:1fb2:db21:60769",
**"remoteAddress": "::ffff:10.1.0.4"** ,
"isPrivateIP": false,
"expressIp": "2001:1c04:3404:9500:fd9b:58f4:1fb2:db21:60769",
"connectionInfo": {
"remoteAddress": "::ffff:10.1.0.4",
"remoteFamily": "IPv6",
"localAddress": "::ffff:10.1.1.68",
"localPort": 80
},
"allHeaders": {
**"x-forwarded-for": "2001:1c04:3404:9500:fd9b:58f4:1fb2:db21:60769"**
},
"deploymentAdvice": "Public IP detected successfully"
}
```
**限制与注意事项：**
- _不支持 Application Gateway v1 SKU 的 IPv6。_ 如果您有基于 v1 的旧部署，需要迁移到 v2。
- _不允许纯 IPv6 的 Application Gateway。_ 您必须同时拥有 IPv4 和 IPv6 (服务必须是双栈)。这通常没问题，因为双栈可以确保所有客户端都被覆盖。
- _后端不支持 IPv6 地址：_ 后端池必须拥有 IPv4 地址。
- _管理和监控：_ Application Gateway 会将来自 IPv6 客户端的流量记录到 Log Analytics (客户端 IP 字段将显示 IPv6 地址)。
- _安全：_ Azure 的基础设施为 IPv6 端点提供与 IPv4 相同的基本 DDoS 防护。但是，强烈建议部署 Azure DDoS Protection Standard：这提供了针对您特定部署的增强缓解措施。考虑使用 Web 应用程序防火墙功能来防御应用层攻击。
## 应用程序网关 - 多区域
关键任务的 Web 应用程序应部署在多个 Azure 区域，以实现更高的可用性和为全球用户提供更低的延迟。在多区域场景中，您需要一种机制将 IPv6 客户端流量引导到“最近”或最健康的区域。Azure Application Gateway 本身是一个区域性服务，因此要在多个区域使用它，我们使用 **Azure Traffic Manager** 进行全局 DNS 负载均衡，或者使用 Azure Front Door (下一节将介绍) 作为替代方案。本节重点介绍 **Traffic Manager + Application Gateway** 的多区域 IPv6 交付方法。
[Azure Traffic Manager](https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-overview) 是一个基于 DNS 的负载均衡器，可以将流量分发到不同区域的端点。它通过根据配置的路由方法 (性能、优先级、地理位置) 响应 DNS 查询，返回适当的端点 FQDN 或 IP。Traffic Manager 对 IP 版本是中立的：它要么返回 CNAME，要么为 IPv6 端点返回 AAAA 记录，为 IPv4 端点返回 A 记录。这使其非常适合在全球范围内路由 IPv6 流量。
**架构概述：** 每个区域都有自己的双栈 Application Gateway。Traffic Manager 为每个区域的网关配置一个端点条目。应用程序的 FQDN 现在是 Traffic Manager 托管的域名，例如 ipv6webapp.traffimanager.net，或者是一个最终指向它的 CNAME。
DNS 解析将通过 Traffic Manager 进行，它会决定返回哪个区域网关的 FQDN。然后客户端直接连接到该 Application Gateway 的 IPv6 地址，过程如下：
1. **DNS 查询：** 客户端请求 `_ipv6webapp.trafficmanager.net_`，该域名托管在一个 Traffic Manager 配置文件中。
2. **Traffic Manager 决策：** Traffic Manager 收到一个 DNS 请求，并根据路由规则 (例如，地理邻近度或最低延迟) 选择最佳端点 (比如，瑞典中部)。
3. **Traffic Manager 响应：** Traffic Manager 将瑞典中部 Application Gateway 的 FQDN 返回给客户端。
4. **DNS 解析：** 客户端解析区域 FQDN 并收到一个包含 IPv6 地址的 AAAA 响应。
5. **客户端连接：** 客户端的浏览器直接连接到西欧 Application Gateway 的 IPv6 地址。HTTP/S 会话通过 IPv6 与该区域网关建立，然后由该网关处理请求。
6. **故障转移：** 如果该区域变得不可用，Traffic Manager 的健康检查会检测到它，后续的 DNS 查询将得到次要区域网关的 FQDN 作为响应。
**多区域 Traffic Manager 部署步骤：**
1. **在每个区域设置双栈 Application Gateway：** 与单区域情况类似，在每个所需区域 (例如，一个在北美，一个在欧洲) 部署一个 Azure Application Gateway v2。在每个区域配置 Web 应用程序，这些应该是提供相同内容的并行部署。
2. **配置 Traffic Manager 配置文件：** 在 Azure Traffic Manager 中，创建一个配置文件并选择一个 [路由方法](https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-routing-methods) (例如，用于最近区域路由的“性能”，或用于主/备故障转移的“优先级”)。为每个区域添加 [端点](https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-endpoint-types) 。由于我们的端点是带有 IP 的 Azure 服务，我们可以使用*Azure 端点* (如果 Application Gateway 有 Azure 提供的 DNS 名称) 或使用 IP 地址的*外部端点*。最简单的方法是使用每个 Application Gateway 的*公共 IP 资源*作为 Azure 端点——确保每个 Application Gateway 的公共 IP 都有一个 DNS 标签 (这样它就有一个 FQDN)。Traffic Manager 会检测到这些，并知道它们的 IP。或者，直接使用 IPv6 地址作为外部端点。Traffic Manager 允许 IPv6 地址，并会为它们返回 AAAA 记录。
3. **DNS 设置：** Traffic Manager 配置文件有一个 FQDN (例如 `_ipv6webapp.trafficmanager.net_`)。您可以将其用作服务的 CNAME，也可以将您的自定义域配置为 CNAME 到 Traffic Manager 配置文件。
4. **健康探测：** Traffic Manager 持续检查端点的健康状况。当端点是 Azure Application Gateway 时，它使用 HTTP/S 探测到指定的 URI 路径，对每个网关的地址进行探测。确保每个 Application Gateway 在探测端点上都有一个侦听器 (例如，一个健康检查页面)，并且健康探测已启用。
5. **测试故障转移和分发：** 通过从不同地理位置查询 DNS 来测试设置 (以查看是否获得最近区域的 IP)。同时模拟一个区域宕机 (停止 Application Gateway 或后端)，并观察 Traffic Manager 是否将流量引导到另一个区域。由于涉及 DNS TTL，故障转移不是即时的，但通常在几分钟内完成，具体取决于 TTL 和探测间隔。
**此架构中的注意事项：**
- _延迟与故障转移：_ Traffic Manager 作为一个 DNS 负载均衡器，在连接时引导用户，但一旦客户端获得答案 (IP 地址)，它会一直向该地址发送请求，直到 DNS 记录的 TTL 过期并重新解析。这对于大多数 Web 应用来说是可以接受的。确保 Traffic Manager 配置文件中的 TTL 不要太高 (默认为 30 秒)。
- _IPv6 DNS 和连接性：_ 确认每个区域的 IPv6 地址都已正确配置并且全球可达。Azure 的公共 IPv6 地址是全球可路由的。Traffic Manager 本身是一个全球服务，并在其决策中完全支持 IPv6。
- _成本：_ 使用多个 Application Gateway 和 Traffic Manager 会产生每个组件的成本 (Application Gateway 按小时+容量单位收费，Traffic Manager 按百万次 DNS 查询收费)。这是为了高可用性而做出的权衡。
- _替代方案：Azure Front Door：_ Azure Front Door 是 Traffic Manager + Application Gateway 组合的替代方案。Front Door 可以在第 7 层自动处理全局路由和故障转移，没有基于 DNS 的限制，可能提供更快的故障转移。Azure Front Door 将在下一节讨论。
总之，使用 Application Gateway 的多区域 IPv6 Web 交付方案利用 Traffic Manager 进行全局 DNS 负载均衡。Traffic Manager 会为 IPv6 客户端无缝返回 IPv6 地址，确保无论纯 IPv6 客户端在哪里，都能被指向最近的可用区域应用部署。这种设计实现了全球弹性 (能够承受区域性中断) 和低延迟访问，并利用了每个区域端点的 IPv6 连接。
**示例：** 我们的应用程序的全局 FQDN 现在是 `_ipv6webapp.trafficmanager.net_`，客户端将使用此 FQDN 访问应用程序，无论其地理位置如何。
Traffic Manager 将返回其中一个区域部署的 FQDN，即 `ipv6webapp-appgw-swedencentral.swedencentral.cloudapp.azure.com` 或 `ipv6webappr2-appgw-eastus2.eastus2.cloudapp.azure.com`，具体取决于配置的路由方法、区域端点的健康状态和客户端的位置。然后，客户端通过其本地 DNS 服务器解析区域 FQDN，并连接到应用程序的区域实例。
来自欧洲客户端的 DNS 解析：
```
Resolve-DnsName ipv6webapp.trafficmanager.net
Name Type TTL Section NameHost
---- ---- --- ------- --------
ipv6webapp.trafficmanager.net CNAME 59 Answer ipv6webapp-appgw-swedencentral.swedencentral.cloudapp.azure.com
Name : ipv6webapp-appgw-swedencentral.swedencentral.cloudapp.azure.com
QueryType : AAAA
TTL : 10
Section : Answer
IP6Address : 2603:1020:1001:25::168
```
以及来自美国客户端的 DNS 解析：
```
Resolve-DnsName ipv6webapp.trafficmanager.net
Name Type TTL Section NameHost
---- ---- --- ------- --------
ipv6webapp.trafficmanager.net CNAME 60 Answer ipv6webappr2-appgw-eastus2.eastus2.cloudapp.azure.com
Name : ipv6webappr2-appgw-eastus2.eastus2.cloudapp.azure.com
QueryType : AAAA
TTL : 10
Section : Answer
IP6Address : 2603:1030:403:17::5b0
```
## Azure Front Door
[Azure Front Door](https://learn.microsoft.com/en-us/azure/frontdoor/front-door-overview) 是一个应用程序交付网络，内置了内容分发网络 (CDN)、SSL 卸载 (SSL offload)、WAF 和路由功能。它提供了一个单一、统一的前端，分布在微软的边缘网络上。Azure Front Door 原生支持 IPv6 连接。
对于拥有全球用户的应用程序，Front Door 具有以下优势：
- **全局任播端点：** 提供任播 IPv4 和 IPv6 地址，从所有边缘位置宣告，并自动支持 A 和 AAAA DNS 记录。
- **支持 IPv4 和 IPv6 源：** Azure Front Door 支持 Azure 内部和外部 (即可通过互联网访问) 的 IPv4 和 IPv6 源 (即后端)。
- **简化的 DNS：** 可以使用 CNAME 记录映射自定义域。
- **第 7 层路由：** 支持基于路径的路由和自动后端健康检测。
- **边缘安全：** 包括 DDoS 防护和可选的 WAF 集成。
Front Door 支持“跨 IP 版本”的场景：客户端可以通过 IPv6 连接到 Front Door 的前端，然后 Front Door 可以连接到 IPv4 的源。反之，纯 IPv4 的客户端也可以通过 Front Door 从 IPv6 后端获取内容。
Front Door 在 X-Forwarded-For 标头中保留客户端的源 IP 地址。
**注意：** Front Door 提供的是托管的 IPv6 地址，并非客户拥有的资源。自定义域应使用指向 Front Door 主机名的 CNAME 记录，而不是直接引用 IP 地址。
**Private Link 集成**
Azure Front Door Premium 引入了 **Private Link 集成**，实现了 Front Door 与后端资源之间的安全、私有连接，而无需将它们暴露到公共互联网。
启用 Private Link 后，Azure Front Door 会在微软管理的虚拟网络内建立一个专用终结点 (private endpoint)。该终结点充当 Front Door 全球边缘网络与您的源资源 (如 Azure App Service、Azure Storage、Application Gateway 或内部负载均衡器后的工作负载) 之间的安全桥梁。
来自最终用户的流量仍然通过 Front Door 全球分布的入网点 (POP) 进入，受益于 SSL 卸载、缓存和 WAF 保护等功能。然而，Front Door 不再通过公共的、面向互联网的端点路由到您的源，而是使用私有的微软骨干网到达专用终结点。这确保了 Front Door 与您的源之间的所有流量都与外部网络隔离。
专用终结点连接需要源资源所有者的批准，增加了一层控制。一旦批准，源可以完全限制公共访问，强制所有流量都通过 Private Link 流动。
Private Link 集成带来了：
- _增强的安全性：_ 通过消除后端服务的公共暴露，Private Link 显著降低了 DDoS 攻击、数据泄露和未经授权访问的风险。
- _合规与治理：_ 许多监管框架要求对敏感工作负载使用私有连接。Private Link 有助于满足这些要求，而不会牺牲全球可用性。
- _性能与可靠性：_ Front Door 与您的源之间的流量通过微软的高速骨干网传输，与公共互联网路径相比，提供了低延迟和一致的性能。
- _深度防御：_ 结合 Web 应用程序防火墙 (WAF)、TLS 加密和 DDoS 防护，Private Link 在多个层面加强了您的安全态势。
- _隔离与控制：_ 资源所有者保持对连接批准的控制，确保只有授权的 Front Door 配置文件才能访问源。
- _与混合架构集成：_ 对于涉及 AKS 集群、自定义 API 或内部负载均衡器后的工作负载的场景，Private Link 实现了安全连接，无需公共 IP 或复杂的 VPN 设置。
Private Link 将 Azure Front Door 从一个全球入口点转变为一个完全私有的应用程序交付机制，符合现代安全原则和企业合规需求。
**示例：** 我们的应用程序现在置于 Azure Front Door 之后。我们结合了一个公共后端端点和 Private Link 集成，以便在一个示例中同时展示这两种方式。瑞典中部的源端点是区域性外部负载均衡器的公共 IPv6 端点，而美国东部 2 区的源则通过 Private Link 集成连接。
全局 FQDN 为 `ipv6webapp-d4f4euhnb8fge4ce.b01.azurefd.net`，客户端将使用此 FQDN 访问应用程序，无论其地理位置如何。该 FQDN 解析为 Front Door 的全局任播地址，互联网会将客户端请求路由到宣告此地址的最近的微软边缘。然后，Front Door 会透明地将请求路由到 Azure 中最近的源部署。虽然本例中使用了公共端点，但该流量将通过微软网络进行路由。
来自欧洲的客户端：
调用应用程序位于 `ipv6webapp-d4f4euhnb8fge4ce.b01.azurefd.net/api/region` 的 API 端点会显示更多细节。
```
{
"region": "SwedenCentral",
"clientIp": "2001:1c04:3404:9500:fd9b:58f4:1fb2:db21",
"xForwardedFor": "2001:1c04:3404:9500:fd9b:58f4:1fb2:db21",
**"remoteAddress": "2a01:111:2053:d801:0:afd:ad4:1b28",**
"isPrivateIP": false,
"expressIp": "2001:1c04:3404:9500:fd9b:58f4:1fb2:db21",
"connectionInfo": {
"remoteAddress": "2a01:111:2053:d801:0:afd:ad4:1b28",
"remoteFamily": "IPv6",
"localAddress": "2001:db8:1:1::4",
"localPort": 80
},
"allHeaders": {
**"x-forwarded-for": "2001:1c04:3404:9500:fd9b:58f4:1fb2:db21"** ,
"x-azure-clientip": "2001:1c04:3404:9500:fd9b:58f4:1fb2:db21"
},
"deploymentAdvice": "Public IP detected successfully"
}
```
"remoteAddress": "2a01:111:2053:d801:0:afd:ad4:1b28" 是 Front Door 向源发起请求时使用的地址。
来自美国的客户端：
详细视图显示，现在调用后端实例的 IP 地址是一个本地 VNET 地址。Private Link 从其所在的 VNET 中获取一个本地地址来发起流量。原始客户端 IP 地址再次被保留在 X-Forwarded-For 标头中。
```
{
"region": "eastus2",
"clientIp": "2603:1030:501:23::68:55658",
"xForwardedFor": "2603:1030:501:23::68:55658",
**"remoteAddress": "::ffff:10.2.1.5",**
"isPrivateIP": false,
"expressIp": "2603:1030:501:23::68:55658",
"connectionInfo": {
"remoteAddress": "::ffff:10.2.1.5",
"remoteFamily": "IPv6",
"localAddress": "::ffff:10.2.2.68",
"localPort": 80
},
"allHeaders": {
**"x-forwarded-for": "2603:1030:501:23::68:55658"**
},
"deploymentAdvice": "Public IP detected successfully"
}
```
## 结论
为 Web 应用程序采用 IPv6 已不再是可选项，而是必需项。随着公共 IPv4 地址空间的枯竭、移动网络越来越多地只使用 IPv6，以及政府强制要求公共服务必须支持 IPv6 访问，这一点变得至关重要。Azure 全面的双栈网络能力提供了一条清晰的前进道路，使组织能够在外部利用 IPv6，而无需牺牲 IPv4 的兼容性或要求进行彻底的基础设施改造。
Azure 的面向外部的服务——包括 Application Gateway、External Load Balancer、Global Load Balancer 和 Front Door——都支持 IPv6 前端，而 Application Gateway 和 Front Door 则保持了 IPv4 后端连接。这种架构允许应用程序保持不变，同时立即变得可以被纯 IPv6 客户端访问。
对于单区域部署，Application Gateway 提供了 SSL 终止和 WAF 保护等第 7 层功能。External Load Balancer 提供高性能的第 4 层分发。多区域场景则可以受益于 Traffic Manager 基于 DNS 的路由与区域性 Application Gateway 的结合，或者 Global Load Balancer 任播寻址所带来的卓越性能和故障转移能力。
Azure Front Door 通过微软的网络提供全球 IPv6 交付，具有边缘优化、内置安全和无缝故障转移功能。Private Link 集成允许在保持后端隔离的同时进行安全的全球 IPv6 分发。
在 Azure 上向 IPv6 应用程序交付的过渡过程非常直接：在虚拟网络上启用双栈寻址，在负载均衡服务上配置 IPv6 前端，并更新 DNS 记录。使用 Application Gateway 或 Front Door，后端应用程序无需任何修改。这些 Azure 服务无缝地处理 IPv4 到 IPv6 的转换。这种方法既确保了即时的 IPv6 可访问性，又为全球 IPv6 加速普及提供了长期的架构灵活性。
更新于 2025 年 11 月 14 日
版本 1.0
<!-- AI_TASK_END: AI全文翻译 -->