为 CDN 开启 IPv6，不等于只在 DNS 中增加一条 AAAA 记录。完整上线至少涉及两段独立链路：访问者到 CDN 边缘节点，以及 CDN 边缘节点到源站。还要检查双栈 DNS、源站监听、防火墙白名单、签名 URL、真实客户端 IP、日志解析和 IPv4 回退。任何一处仍假设“IP 地址一定是 IPv4”，都可能造成部分用户无法访问、风控误判或监控数据缺失。
以 Amazon CloudFront 为例，访问者侧可以同时接收 IPv4 和 IPv6 请求；自定义源站侧还可选择仅 IPv4、仅 IPv6或双栈连接。稳妥的迁移方法通常不是直接切成“仅 IPv6”，而是先启用访问者侧双栈，修复应用和日志兼容问题，再评估源站侧双栈。
本文功能与配置核查日期为 2026 年 8 月 7 日。云服务功能可能调整，实际选项应以当前控制台和官方文档为准。
先分清 CDN IPv6 的两段链路
| 链路 | 解决的问题 | 主要配置 | 常见误区 |
|---|---|---|---|
| 访问者 → CDN | 让 IPv6 网络中的用户通过 IPv6 访问边缘节点 | 分配启用 IPv6，DNS 发布 A 与 AAAA | 误以为源站也会自动改用 IPv6 |
| CDN → 源站 | 决定边缘节点回源时使用 IPv4、IPv6或自动选择 | 自定义源连接类型、源站 DNS、监听与防火墙 | 只配置 AAAA，却没有验证服务真正监听 IPv6 |
访问者使用 IPv6，并不要求源站必须使用 IPv6。用户可以通过 IPv6 到达 CloudFront，而 CloudFront 仍通过 IPv4 回源。反过来，源站具备 IPv6 地址也不代表访问者侧已经获得 IPv6；是否向用户发布 IPv6 能力，仍取决于分配设置和 DNS。
CloudFront 的 IPv6 连接模式怎么选？
访问者侧：启用 IPv6
启用后，CloudFront 可以处理来自 IPv4 和 IPv6 网络的访问者请求。AWS 文档还说明，为了可用性，如果系统判断 IPv4 能带来更好的用户体验，CloudFront 可能使用 IPv4 响应访问者请求。因此，开启 IPv6 后不应期待全部请求立刻变成 IPv6。
源站侧：IPv4 only、IPv6 only 或 Dual-stack
CloudFront 当前为自定义源提供三种连接选择，但不包括 Amazon S3 与 VPC origins：
仅 IPv4：默认方式，适合尚未完成 IPv6 改造的源站。
仅 IPv6：源站域名必须能够解析出 IPv6 地址，且服务、路由和防火墙必须完整支持 IPv6。
双栈：允许 CloudFront 在 IPv4 与 IPv6 之间选择，以兼顾性能和可用性。
如果业务目标只是让 IPv6 用户能够访问网站，先开启访问者侧 IPv6 即可，不必同步把源站切换为仅 IPv6。源站双栈应作为单独变更测试和上线。
DNS 应该如何配置 A 与 AAAA 记录？
使用 CloudFront 默认域名时，CloudFront 管理相应的地址解析。使用自己的域名时，DNS 配置取决于服务商和记录类型。
使用 Route 53 Alias
如果 CloudFront 已开启 IPv6，并且对象 URL 使用自定义域名，AWS 要求为同一个域名创建两条指向该分配的 Alias：
A Alias：为 IPv4 查询提供路由。
AAAA Alias：为 IPv6 查询提供路由。
根域名不能使用普通 CNAME 指向另一个域名，因此 Route 53 Alias 或 DNS 服务商提供的 ANAME/ALIAS、CNAME Flattening 一类能力更合适。具体名称和行为由 DNS 服务商决定。
使用普通 CNAME
AWS 文档说明，如果自定义域名通过 CNAME 指向 CloudFront 分配域名，通常不需要再为 IPv6单独修改 CNAME，因为目标域名的解析可返回相应地址。不过，上线前仍应从真实的 IPv4-only、IPv6-only 和双栈网络验证最终解析和访问结果。
# 检查 IPv4 解析 dig A cdn.example.com # 检查 IPv6 解析 dig AAAA cdn.example.com # 分别强制使用 IPv4 与 IPv6 请求 curl -4 -I https://cdn.example.com/test-object curl -6 -I https://cdn.example.com/test-object
如果本地网络没有可用 IPv6，curl -6 失败不能直接证明 CDN 配置错误。应改用具备原生 IPv6 的测试环境或外部探测节点复核。
源站开启 IPv6 前要检查什么？
1. DNS 不仅要有 AAAA，还必须指向正确目标
源站域名返回 AAAA 只是第一步。需要确认该地址属于预期负载均衡器或服务器，不是已停用地址，也不是绕过当前安全设备的旧入口。修改前后都应记录解析结果和 TTL。
2. 服务必须真正监听 IPv6
服务器拥有 IPv6 地址，不代表 Nginx、Apache、应用容器或负载均衡器已经监听 IPv6。应在源站检查监听地址，并通过 HTTPS 请求验证证书、SNI、虚拟主机和响应内容。
3. 路由、防火墙和安全组需要单独支持 IPv6
IPv4 与 IPv6 使用不同地址族。仅复制一条 IPv4 CIDR 白名单并不能自动放行 IPv6。AWS 为 CloudFront 面向源站的服务器分别提供 IPv4 与 IPv6托管前缀列表；如果源站安全组只允许 CloudFront 回源，应选择与源站连接模式匹配的列表。
4. TLS 与健康检查不能省略
IPv6 回源仍要满足正常的 HTTPS 要求：源站证书中的域名应与 CloudFront 配置的 Origin domain 匹配，证书链完整，端口开放，TLS 协议可协商。测试不应只看 TCP 能否建立连接，还应核对状态码、响应头和返回对象。
IP 白名单、WAF 与签名 URL 有哪些兼容风险？
开启 IPv6 后，最容易被遗漏的是所有基于 IP 地址的逻辑：
WAF IP Set 是否同时包含需要允许或阻止的 IPv6 CIDR。
应用数据库中的 IP 字段是否能存储完整 IPv6 字符串。
正则表达式是否错误地只允许数字和句点。
速率限制是否把 IPv6 地址按错误粒度聚合。
后台、下载链接或 API 的 IP 白名单是否支持 IPv6。
第三方风控、地理库和 SIEM 是否能解析 IPv6。
CloudFront 签名 URL/签名 Cookie 的特殊限制：AWS 文档明确指出，自定义策略中的 IpAddress 条件仅支持标准 IPv4 CIDR，不支持 IPv6。如果分配正在使用这种 IP 限制，不应直接启用 IPv6。需要同时提供受 IPv4 地址限制的内容和支持 IPv6 的其他内容时，可考虑拆分为两个分配。迁移时还要避免把一个 IPv6 用户使用的多个临时地址误判为大量不同用户。IPv6 隐私地址可能变化，限速和身份判断不应机械地把完整单个 IP 当作永久用户标识。
如何获取真实客户端 IPv6 地址？
CloudFront 标准日志和实时日志中的 c-ip 字段可能同时出现 IPv4 与 IPv6。自定义源请求中的 X-Forwarded-For 也可能包含两种格式，并可能形成由多个地址组成的列表。
应用不应简单取字符串的第一段或最后一段就认定是真实客户端。正确做法是：
只信任来自已知代理或 CDN 的转发头。
按照代理链规则解析地址列表。
使用成熟 IP 地址库完成解析和规范化。
数据库使用能够容纳 IPv6 的字段类型或二进制格式。
显示时接受压缩格式，不依赖固定长度。
例如，2001:db8::1 与展开后的完整写法可以代表同一地址。字符串直接比较、手写补零和按冒号分割都容易出错。
日志、监控和分析系统要怎样改造？
| 检查对象 | IPv6 常见问题 | 建议 |
|---|---|---|
| 日志采集器 | 字段长度不足或解析正则只支持 IPv4 | 使用标准 IP 解析器，并加入压缩与完整 IPv6 测试样本 |
| 数据库 | 使用 VARCHAR(15) | 改用支持 IPv6 的字段或足够长度的规范化存储 |
| 报表 | 按点号拆分网段 | 使用地址库进行前缀和网段计算 |
| 告警 | 把解析失败记录丢弃 | 对未知格式单独计数并告警 |
| 地理与风控 | IPv6 数据库过旧 | 更新地址库并验证覆盖率，不把未知位置直接判为恶意 |
可以从 CloudFront 日志中的 c-ip 统计 IPv6 请求占比，但不要只通过“字符串中是否包含冒号”完成所有生产分析。冒号检测可用于粗略报表，安全判断和网段聚合仍应使用专门的 IP 库。
IPv4 回退为什么不能只靠 DNS？
双栈域名通常同时提供 A 和 AAAA。现代客户端一般会并行或错开尝试 IPv6 与 IPv4，而不是等待一条路径完全超时后才尝试另一条；这类机制通常称为 Happy Eyeballs。它能降低单条地址族路径异常带来的等待时间，但不能替代正确配置。
以下问题仍可能造成访问缓慢或失败：
AAAA 指向了可路由但应用不工作的地址。
IPv6 防火墙静默丢包，导致握手长时间等待。
某些旧客户端、SDK 或企业代理没有良好回退能力。
DNS 缓存仍保留已撤销的 AAAA 记录。
应用中的第三方依赖只支持 IPv4。
因此，回退策略应包括客户端双栈、CDN 的连接选择、DNS 变更预案以及服务端监控，而不是简单地认为“有 A 记录就一定能自动回退”。
推荐的 IPv6 上线步骤
盘点依赖：列出 DNS、CDN、源站、WAF、白名单、签名 URL、日志、数据库和第三方服务。
先修兼容性：让所有 IP 字段、解析器和安全规则能够接受 IPv6。
在测试域名启用访问者侧 IPv6：同时检查 A、AAAA、HTTPS、缓存和错误响应。
从多种网络测试：至少覆盖 IPv4-only、IPv6-only 与双栈网络。
小范围上线：监控请求量、4xx/5xx、TLS 错误、DNS 失败和 IPv6 占比。
保持源站 IPv4：先确认访问者侧稳定，不把两段链路同时改动。
再测试源站双栈：验证 AAAA、监听、证书、防火墙、CloudFront 前缀列表和回源指标。
准备回滚：记录原始 CDN 设置与 DNS 配置，避免故障时临时猜测。
上线后应该监控哪些指标？
IPv4 与 IPv6 请求数量和比例。
按地址族区分的 4xx、5xx 与连接失败。
DNS A/AAAA 解析成功率和响应时间。
TLS 握手失败与证书错误。
不同网络和地区的首字节时间。
WAF 拦截、白名单拒绝和速率限制异常。
日志解析失败、未知 IP 格式和地理库未命中。
源站 IPv4 与 IPv6 回源比例及错误率。
最好在变更前保存一段 IPv4 基线数据。没有基线时，即使上线后错误率升高，也很难判断是 IPv6、新版本发布还是源站本身波动。
常见问题
开启 CloudFront IPv6 后，源站必须有 IPv6 吗？
不需要。访问者到 CloudFront 与 CloudFront 到源站是两段独立链路。可以让用户通过 IPv6 访问 CloudFront，同时继续使用 IPv4 回源。
有 AAAA 记录就代表网站支持 IPv6 吗？
不代表。AAAA 只提供地址映射，还要确认路由、监听端口、防火墙、TLS、虚拟主机和应用响应都正常。
CloudFront 开启 IPv6 后是否所有用户都走 IPv6？
不会。用户网络、操作系统、浏览器和路径质量都会影响地址族选择。CloudFront 也可能在判断 IPv4 体验更好时使用 IPv4。
只删除 AAAA 记录就能立即回滚吗？
不一定。递归解析器和客户端可能继续缓存旧记录直到 TTL 到期。回滚计划应提前考虑 TTL、CDN 设置传播时间和仍持有旧解析结果的用户。
IPv6 会让 CDN 更快吗？
不一定。IPv6 可能在部分网络中路径更直接，也可能在另一些网络中质量较差。是否更快应以真实地区和运营商的测量结果为准。
结论
CDN IPv6 上线的核心不是“添加 AAAA”，而是把访问者链路、回源链路、DNS、安全控制和可观测性作为一个整体。对多数现有网站，风险较低的顺序是：先让系统完整识别 IPv6，再开启访问者侧双栈，观察稳定后才测试源站双栈。
使用 CloudFront 时尤其要留意三个细节：Route 53 自定义域名需要同时配置 A 与 AAAA Alias；日志和 X-Forwarded-For 会出现 IPv6；带 IpAddress 条件的签名 URL 或签名 Cookie 自定义策略不支持 IPv6。把这些限制提前纳入设计，比故障后临时删除 AAAA 记录更可靠。
CloudFlew 提供基于 CloudFront 的 CDN 服务。规划 IPv6 上线时，可以先整理当前域名、源站类型、IP 白名单和日志链路，再按双栈测试结果逐步启用相关能力。
参考资料
AWS CloudFront 开发者指南：Enable IPv6 for CloudFront distributions，核查日期：2026-08-07
AWS Route 53 开发者指南：Routing traffic to a CloudFront distribution，核查日期：2026-08-07
AWS CloudFront 开发者指南：Create a signed URL using a custom policy，核查日期：2026-08-07
AWS CloudFront 开发者指南：Request and response behavior for custom origins，核查日期：2026-08-07
AWS CloudFront 开发者指南：Locations and IP address ranges of CloudFront edge servers，核查日期：2026-08-07
IETF RFC 8305：Happy Eyeballs Version 2，核查日期：2026-08-07
