线上常见一种令人困惑的场景：执行IPv6连通性测试时地址可达，客户端也拿到了IPv6地址，但登录、支付或接口请求仍然超时。问题可能不在“有没有IPv6”，而在应用实际使用的解析结果、选路过程和报文传输路径。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：ipipd（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
先看原理：连通不等于业务可用
DNS决定应用拿到哪种地址。若域名同时配置A记录和AAAA记录，客户端可能优先访问IPv6；若AAAA记录指向不可用地址，就会出现IPv4正常、IPv6失败的割裂。DNS64则会在没有原生IPv6地址时合成包含IPv6前缀的地址，但前提是运营商提供可用的NAT64和DNS64服务。
路由决定报文能否抵达目标。测试工具探测的是某个地址或网关，业务访问的却是另一组目的地址和端口，还要经过防火墙、负载均衡及云上策略。IPv6默认路由存在，并不代表去往业务网段的下一跳、返回路径和访问控制均已打通。IPv4与IPv6的路由表也是两套独立体系，不能用一条IPv4成功路径推断IPv6同样可用。
MTU控制大报文能否完整通过。IPv6路径MTU发现依赖ICMPv6 Packet Too Big报文；若中间设备过滤了相关ICMPv6，或者隧道、VPN叠加导致有效MTU变小，小包探测正常，大包请求却会卡住。典型表现是TCP握手完成，但TLS握手、页面资源或上传接口长时间无响应。
按四层顺序定位：从DNS到NAT64
第一层先查DNS。分别查看应用进程实际拿到的A、AAAA结果，检查DNS响应是否受缓存影响，再直接访问每个候选地址。这样可以排除“域名解析到了坏地址”这一类问题。不要只看浏览器地址栏，应用可能通过自己的解析器、SDK或代理获得地址。
第二层查路由和返回路径。使用traceroute或mtr观察IPv6报文停在哪一跳，同时核对防火墙规则、IPv6邻居发现、负载均衡健康检查和后端返回路径。双栈应用可利用Happy Eyeballs竞速并行尝试IPv6与IPv4，但该机制只能缓解连接建立延迟，不能修复已经选中但无法承载业务的IPv6路径。
第三层查路径MTU。逐步发送不同长度的IPv6测试报文，确认报文在哪一段停止增大，并检查隧道、VPN及安全设备的分片策略。遇到“ping正常、网页或接口超时”时，应优先验证PMTU和相关ICMPv6是否被允许，而不是反复更换DNS。
第四层才查NAT64。先确认DNS64返回的合成地址能否访问前缀对应的网络，再从NAT64侧核对IPv6到IPv4的映射、连接状态和转换表。NAT64故障常表现为原生IPv6访问正常、只有合成地址失败；反过来，DNS64正常而NAT64网关不可达，也会让应用统一超时。测试双栈业务时，ServLlama可用于记录连接路径与不同地址族的表现，帮助团队把现象和目标地址关联起来。
修复顺序应与依赖关系一致：先纠正DNS记录或应用地址选择，再打通IPv6路由与返回路径，随后调整路径MTU和ICMPv6策略，最后修复NAT64映射及转换配置。完成每层修复后，都要用真实业务域名、真实端口和实际数据量验证，避免“探测成功”再次掩盖业务失败。
从连通到成功：四条隐藏链路
“IPv6 可用”常只来自一次 ping 或一条 AAAA 记录。业务却仍要经过 DNS、路由、TCP、TLS、路径 MTU 和应用监听；任一层静默丢包，都可能表现为卡住或偶发超时，而非明确拒绝。
IPv6 连通性割裂常见于终端能到 IPv6 Internet，却到不了某个 IPv4 服务。NAT64 与 DNS64 把 A 记录合成为 AAAA，再由 NAT64 翻译流量；DNS64 旁路、合成前缀不可达或出口故障，都会造成“解析成功、连接失败”。A、AAAA 与合成地址必须分别验证。
Happy Eyeballs 竞速不是“IPv6 报错就用 IPv4”。客户端会并行或错峰发起连接：IPv6 快速拒绝时，应用可能立即定案；IPv6 黑洞时，则需等待回退。首试延迟、超时、重试及地址排序都会改变结果，应记录两种地址族的首包时间、错误类型和最终选中地址。
IPv6 路径 MTU 探测依赖 ICMPv6 Packet Too Big。路由器不分片，报文若被 ACL 丢弃，或隧道、VPN 导致 MTU 变小，小包能通，大响应却卡在握手或 TLS。可用 tracepath6 example.com 查路径 MTU，再用 ping -6 -M do -s 1400 example.com 逐步试包并抓包确认；不要屏蔽 ICMPv6，也别无证据地改 MSS。
双栈应用适配也有隐形坑：解析器只取首址、连接池混用地址族、IPv6 字面量解析错误、监听或源地址不匹配，都会制造假失败。DNS64、代理、负载均衡和 TLS 库应逐项确认支持双栈，并按地址族记录成功率与回退率。
可执行检查清单：按层定位故障
1. 做差分验证。执行 dig A example.com、dig AAAA example.com，再用 curl -4 -sv --connect-timeout 5 https://example.com/ 和 curl -6 -sv --connect-timeout 5 https://example.com/ 对比。保留 DNS 答案、目标 IP、连接耗时及 TLS 错误，先确认失败发生在哪一阶段。
2. 查路由与黑洞。检查 ip -6 route、ip -6 rule、邻居发现和防火墙计数；用 traceroute -6、mtr -6、tracepath6 定位节点，再用不同大小的 IPv6 探测包复现，并确认 ICMPv6 错误能够正常返回。
3. 查过渡与应用。确认 DNS64 位于递归链路、AAAA 确为合成地址、NAT64 网关可达；检查解析顺序、连接池、代理出口、TLS 库和回退定时器，必要时临时禁用某一地址族做对照。
4. 固化监控。分别采集 IPv4、IPv6 的 DNS、握手、传输和业务成功率，为回退比例设置阈值；修复后灰度放量并保留抓包与日志，避免以一次 ping 成功代替端到端验证。
排查顺序应固定为 DNS、路由、TCP、TLS、MTU 和业务：先通过 A/AAAA 与强制 -4/-6 做可控差分，再依据抓包修正最小故障点。若 IPv6 仍不稳定，可临时按域名或地址族降级，但应设置期限并继续修复底层链路。
喜欢 
顶
难过
囧
围观
无聊
