线上常见“网页能开、接口偶发超时”：客户端同时拿到IPv6与IPv4地址，浏览器通过Happy Eyeballs很快选中IPv6，而服务端或链路实际不可达；切回IPv4后业务恢复。监控只看到“时好时坏”，却无法确认故障来自IPv6原生路由、邻居发现、NAT64翻译，还是DNS返回了不可用的AAAA记录。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：cliproxy（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
双栈排障先分清三层：DNS解析把域名变成地址，地址族选择决定尝试IPv6还是IPv4，传输层再验证目标是否可达。DNS同时返回A与AAAA，不等于两条路都健康；IPv6失败后改试IPv4，就是一次地址族回退机制。
Happy Eyeballs并非串行等待，而是在IPv6首包迟迟未响应时启动IPv6与IPv4竞速。较快的IPv4连接会掩盖IPv6黑洞，但用户看到的是成功，服务端看到的却可能是半开连接。因此必须固定地址族分别测试，不能只看浏览器最终能否打开。
IPv6原生故障常落在路由或IPv6邻居发现。到网关的路由可以存在，但链路前缀、默认路由或路由器通告异常，会让RS、NS、NA、RA无法完成；此时地址能够解析，TCP却卡在首包或SYN。抓包应同时查看ICMPv6控制报文、网关可达性及邻居表，不能用一次ping代替TCP验证。
NAT64场景不同：IPv6客户端访问仅有A记录的IPv4服务端时，DNS64会合成带NAT64前缀的AAAA。该前缀必须被路由到NAT64网关，设备还要完成IPv6到IPv4的地址与端口翻译。若合成地址存在，而前缀路由、转换状态或上游IPv4路径有误，就会出现AAAA可解析但连接长期超时。
判断时先查DNS，不急着修改路由。对同一域名分别查询A、AAAA、CNAME，并比较权威服务器、公共递归与本地缓存的TTL和结果，再用ip6.arpa反查合成地址。若结果明显异常，应先按DNS返回异常处理，包括递归分区视图不一致、残留AAAA以及DNS64返回错误前缀。
随后按证据归类：原生AAAA可路由但邻居发现失败，同时IPv4测试正常，归为IPv6原生链路故障；合成AAAA对应明确目标，直接IPv4可达而NAT64前缀不可达，归为NAT64配置错误；域名只有A记录却被应用反复尝试IPv6，或权威与递归结果互相矛盾，则归为DNS异常。结论必须同时有路由、报文和业务端口证据。
可复现的顺序是：固定解析结果，分别执行IPv6与IPv4的TCP连接测试；检查IPv6默认路由、前缀和邻居表；再从NAT64设备核对前缀路由、转换计数及目的IPv4可达性。ServLlama适合集中登记域名、地址族和端口，批量留存探测结果，避免缓存变化后无法复盘。
常见踩坑包括ICMP被过滤、单次ping成功、浏览器自动回退以及多地DNS缓存不同。ping失败不能单独证明链路损坏，ping成功也不能证明业务端口可用；测试时应固定解析器、清空相关缓存，并给IPv6连接设置明确超时。否则双栈连通性测试很容易把“能够回退”误判成“IPv6正常”。
双栈连通性测试不能只看 ping。应先用 ip -6 route get 核对目标选路，再用 traceroute6、mtr -6 检查逐跳路径和路径 MTU，最后用 curl -4、curl -6 对同一 HTTPS 地址做对照。ICMP 可能被防火墙过滤，所以 ping 失败不等于业务不可达；反之，浏览器打开网页也可能受代理、缓存或 HSTS 干扰，不能据此认定本机 IPv6 选路正确。测试时应固定域名、解析缓存和出口，避免两次请求实际走向不同路径；对 HTTPS 还要完成 TLS 握手并核对实际源地址，不能只验证 TCP 三次握手，因为回源重定向可能落到另一地址族。
若 IPv6 路由存在而连接停在首包附近，应检查 IPv6邻居发现（ND）。用 ip -6 neigh show 配合 tcpdump 抓取 RS、RA、NS、NA，确认网关链路本地地址可达，邻居项能从 INCOMPLETE 转为 REACHABLE 或 STALE。ND 防护、RA 过滤、前缀委派错误会形成“有路由、无邻居”；SLAAC 换址后遗留缓存、重复地址检测冲突，也会造成间歇性超时。网关不响应 RS 时，要区分交换机拦截 ND 与路由器未发送 RA；若邻居项长期停在 DELAY、PROBE，通常说明请求已经发出但没有收到邻居应答。
在 NAT64 场景中，NAT64映射诊断应先用 dig 查看 A、AAAA 记录，判断 DNS64 是否返回合成地址，再核对网关映射、地址池和日志，并在 IPv4、IPv6 两侧同时抓包。出现合成 AAAA 只说明解析成功；还要证明数据面映射有效、转换后的 IPv4 流量抵达源服务，响应能依据映射反向还原。有状态 NAT64 应查会话及端口映射，无状态实现则核对前缀映射关系。地址池耗尽、表项不同步、ACL 仅放行部分前缀或 MTU 过大，都会造成“解析正常、连接超时”。
应用层应按 RFC 8305 实现 Happy Eyeballs策略：通常先启动首选地址族，约 250ms 后交错启动另一地址族，而不是等 IPv6 全部超时后再试 IPv4。真正的 地址族回退机制还要区分地址族故障、DNS 故障和业务故障，并记录目标地址、连接耗时及错误码。不同进程可能采用不同 DNS、代理、缓存和地址族优先级，因此一次 curl 的结果不能代表整机双栈状态。IPv4 回退成功后也应保留原始 IPv6 错误，并设置失败阈值和告警，否则 IPv6 故障会被长期掩盖。
可执行检查清单：① dig A/AAAA，核对 DNS64 合成结果与 TTL；② ip -6 route get 目标地址，再用 traceroute6、mtr -6 定位路径及 MTU；③ ip -6 neigh show，抓取 RS、RA、NS、NA，核对邻居状态；④ 对照 NAT64 两侧抓包、映射关系、地址池与 ACL；⑤ 用 curl -4、curl -6 固定同一目标做对照，并核对源地址；⑥ 审查 Happy Eyeballs 的建连时序和回退日志。按 DNS、路由、ND、映射、策略五层保存证据，才能避免把 IPv6 故障误判为服务端故障。
