CDN域名IPv4正常、IPv6失败：AAAA之后还要检查哪些环节

办公室访问正常，移动网络却间歇失败，原因可能与地址族不同有关。域名同时存在IPv4和IPv6路径时，一条正常不代表另一条也正常。CDN接入验收应分别检查两条路径，而不是以一次浏览器成功访问结束测试。

浏览器成功可能掩盖一条失败路径

RFC 8305描述的Happy Eyeballs机制通过尝试多个连接改善用户等待体验。这意味着某些客户端可以在一条路径异常时使用另一条路径成功访问，表面成功并不能证明两种地址族都可用。

不同客户端实现及网络条件可能不同，不能据此保证所有用户都会及时回退。排查时应使用支持明确选择地址族的正常诊断方式，并保留原域名及TLS名称。

建立可比较的样本

同一次比较尽量使用相同时间窗口、URL、登录状态和客户端条件。否则缓存命中或业务变更可能被误当作IPv6差异。

按最早失败的位置继续定位

没有预期AAAA时，先核对平台是否已启用该能力以及DNS发布是否正确。能解析但无法连接时，检查用户网络、路由、边缘监听和必要的网络控制。连接成功但TLS失败，则比较证书及入口映射。

如果两种地址族都能完成TLS，只有业务结果不同，应检查是否进入相同的域名配置、缓存策略和源站路由。不要在尚未确定层级时同时修改DNS、证书和应用，避免丢失因果关系。

源站IPv6也要纳入入口审核

有些团队只限制源站IPv4访问，却保留可直接访问业务的IPv6地址。应检查源站所有公开地址族的监听与访问边界，确认必要的回源和管理路径按设计保留。

这里不要求为了诊断开放源站。可以由维护人员通过受控环境验证，记录允许和不允许路径的结果。若临时回退IPv6发布，应说明用户影响、恢复条件与遗留任务，不能把永久关闭当作已经查明原因。

恢复后从两个方向确认

复测受影响网络和独立监测点，分别记录IPv4、IPv6的连接与业务成功情况。对仍存在差异的地区保留样本，而不是只汇总一个全球平均值。

进行边缘安全加速接入时，把地址族能力和覆盖范围写进验收清单；源站边界可结合防绕过检查处理。最终报告应清楚区分解析已发布、网络可达、TLS正确和业务可用四个结论。

资料核对日期：2026年10月30日。本文由AI辅助整理，技术事实依据文内原始资料核对。示例与操作清单供实施参考；产品配置和软件维护状态以实施时的官方资料为准。