IPv6 的异常有个特点：IPv4 用户完全感知不到。所以不能等用户报障，只能主动测。

拿到一份异常结果，先别急着改配置，按下面的顺序过一遍，基本不会跑偏。

第一步：全体失败还是局部失败

全体失败，问题在源头。域名没有 AAAA 记录、源站没有 IPv6 地址、CDN 没开 IPv6，这三种占绝大多数。

局部失败，问题在链路。某个地区、某个运营商的 IPv6 出口有问题，或者当地节点没有 IPv6 覆盖。这类异常往往下次再测就变了，属于网络侧波动。

把这两类分开，后面的排查方向才不会错。

第二步：只有 IPv6 挂，IPv4 正常

这是最典型的场景，也是最容易被忽略的。

先去服务器上确认三件事。Nginx 有没有写 listen [::]:443，只写 listen 443 的话 IPv6 请求进不来。ip6tables 和云厂商安全组有没有放行，这两套规则是分开的，很多人只配了 IPv4。机房有没有真的分配 IPv6 地址并开通出口，内网分了个地址不算。

三件事都确认过，再去看 CDN。CDN 开启了 IPv6 加速，但回源仍走 IPv4，这种半吊子配置很常见，用户侧看着是通的，一旦回源出问题，IPv6 用户先受影响。

第三步：握手失败

解析和连接都成功，卡在 TLS，问题在证书。

证书没覆盖这个域名、证书链不完整、SNI 配置只对 IPv4 生效，都会导致握手失败。用 IPv6 网站测速 复测一次，如果错误稳定出现在握手阶段，基本可以锁定是证书配置问题。

第四步：能通但慢

先看慢在哪一段。

首字节慢，和后端有关，和 IPv6 无关。数据库查询、接口超时、缓存没命中，都会让 TTFB 飙高，换回 IPv4 测一样慢。

连接慢但稳定，多半是路由绕行。IPv6 的互联质量在国内还在完善，跨运营商绕路并不少见。这种情况优化空间有限，能做的通常是调整 CDN 调度或换线路。

连接慢且波动大，才是链路质量问题，需要拿路由追踪去定位具体哪一跳。

一个容易误判的现象

所有节点都能通，但 IPv6 比 IPv4 慢二三十毫秒。

这不是异常。两种协议的出口、回程和互联关系本来就不同，有稳定差异是正常的。判断标准应该是“各自是否稳定”，而不是“两边数字是否接近”。

真正要处理的是方差：同一节点连续三次结果差出一倍以上，才说明链路有问题。