启用 IPv6 不只是新增一条 DNS 记录。海外访客可能通过 IPv6 网络访问网站，也可能仍使用 IPv4；因此，海外业务网站的IPv6启用与兼容性验证应先确保两种协议都可用，再逐步扩大流量。以下按准备、上线、验证和回退说明操作。
先盘点访问链路，别急着发布 AAAA 记录
网站的 IPv6 请求可能经过权威 DNS、CDN 或负载均衡器，再到源站和应用。链路中任一环节不支持 IPv6，都可能导致部分访客无法连接。先确认域名解析由谁管理、流量是否经过代理，以及源站是否拥有可用的公网 IPv6 地址。
- 列出主域名、登录入口、静态资源域名和 API 域名，逐一标明它们使用的 CDN、负载均衡器或源站。
- 向主机或网络服务商确认服务器已配置 IPv6 地址、网关与路由；仅在控制台看到地址，并不能证明外部流量能够到达。
- 检查防火墙、安全组、WAF、访问控制名单和日志系统，确认它们允许并记录 IPv6 流量。若规则只写了 IPv4 网段，IPv6 请求可能被拦截。
- 盘点支付、身份验证、图片存储等外部依赖。若应用按客户端 IP 限制访问，应核实这些依赖能否处理 IPv6 地址。
分阶段启用双栈
先打通测试环境
在测试域名或不承担主要业务的子域名上验证 IPv6。服务器和入口设备都要监听 IPv6，并配置相应的转发、证书和安全策略。HTTPS 证书通常按域名校验，不因增加 IPv6 地址而改变；但仍应确认访问链路能正常完成 TLS 握手。
确认后发布 AAAA 记录
正式域名通常保留原有 A 记录，同时增加指向可用 IPv6 入口的 AAAA 记录，这种方式称为双栈部署。不要用 AAAA 记录替代 A 记录：仍依赖 IPv4 的用户和网络需要继续访问。若流量经 CDN，先确认其 IPv6 接入和回源配置；客户端能通过 IPv6 到达 CDN，不代表 CDN 到源站也使用 IPv6。
发布前核对记录值和目标入口，按 DNS 服务商的能力设置合理 TTL。变更后，递归解析器的缓存可能使不同地区、不同网络的结果暂时不一致；TTL 影响缓存时长，但不能保证所有解析器立即更新。
从解析、连接到业务逐层验证
- 检查解析：用 dig 查询域名的 A 和 AAAA 记录，确认 IPv4、IPv6 分别指向预期入口。也可使用 Google Admin Toolbox Dig 查看公开解析结果。
- 检查 IPv6 连通：从具备 IPv6 网络的环境，用 curl -6 -I 访问实际页面，观察是否能建立连接并收到合理的 HTTP 状态码。若本地网络没有 IPv6，可安排云端测试节点或请不同地区的运维人员协助。
- 检查页面功能：分别访问首页、登录、表单、搜索或 API 等关键路径，并检查图片、脚本、字体等资源是否加载。主页面成功不代表所有子域名和接口都支持 IPv6。
- 检查真实流量：在 Web 服务器、负载均衡器和应用日志中确认客户端地址被正确记录，观察错误率、超时和业务失败是否变化。日志中若有代理，应确认转发头只信任已配置的代理来源。
- 验证不同网络：覆盖 IPv4-only、IPv6-only 和双栈环境；IPv6-only 网络可能借助 NAT64/DNS64 访问 IPv4 服务，不能据此认定目标服务本身支持 IPv6。Happy Eyeballs 会帮助双栈客户端在 IPv4、IPv6 连接间选择，但不能修复错误的 AAAA 记录或防火墙规则。
用监控和回退控制风险
上线期间按地区和网络观察连接失败、页面响应、登录及关键交易等指标，并与变更前基线比较。具体观察时长取决于流量、DNS 缓存和业务周期；小流量站点可延长观察，避免只凭短时间正常就判断稳定。
发现 IPv6 入口不可达或错误显著增加时，先定位是 DNS、路由、过滤规则还是应用依赖问题。若需要止损，可移除或调整 AAAA 记录，同时保留 A 记录，并检查缓存尚未过期的访客是否仍会尝试旧地址。修复后重新验证各关键路径，再恢复发布。海外业务网站的IPv6启用与兼容性验证应以真实网络和业务功能均通过为准，而不是以“解析出 AAAA”作为完成标志。
常见问题
只有服务器支持 IPv6，是否已经启用？
还不算。DNS、外部入口、防火墙和应用链路都要支持 IPv6，访客才能实际连接。
增加 AAAA 记录后，为什么部分用户打不开网站？
常见原因包括 AAAA 指向错误地址、IPv6 路由未通，或入口设备的防火墙没有放行 IPv6。应从解析和连接两层分别检查。
开启 IPv6 后可以删除 A 记录吗？
通常不应直接删除。保留 A 记录可继续服务尚未具备 IPv6 的网络和客户端。
怎样判断验证已经完成？
确认多个网络环境下解析和连接正常，关键页面及依赖资源可用，日志能正确记录 IPv6 请求，且监控未出现无法解释的业务异常。
