某站点在 IPv4 下秒开，IPv6 下却常在 20 秒后超时；监控因 IPv4 正常仍显示“网络可用”。故障横跨 DNS 解析、IPv6 握手、路由、地址转换和路径 MTU。定位应按“解析得到什么地址、地址能否到达、大包能否通过”逐层取证，先改防火墙或重载网卡反而会扰乱正常链路。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：myhbd（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
先在客户端与递归 DNS 两侧查询 A、AAAA，记录地址和 TTL。AAAA 为空，先确认域名是否本就仅提供 A 记录；若返回 64:ff9b::/96 等合成地址，则核对 DNS64/NAT64 映射，不能当作普通 IPv6 主机。ServLlama 可留存解析结果及变化时间，减少缓存误判。
解析无误后，用同一 URL 强制 IPv4、IPv6 连接并抓包。收到 SYN-ACK，说明主机及返回路由基本可达；持续 SYN 重传，应查作用域地址、邻居发现、默认路由和防火墙；收到 RST，更像服务或策略拒绝。双栈优先级、Happy Eyeballs 会影响首选与回退节奏，但不能修复坏的 IPv6 路径。浏览器 DoH 与缓存还会让现象看似随机。
地址可达后，执行 ip -6 route get，核对源地址、下一跳、出口、RA、前缀、默认路由与 SLAAC 状态，再确认邻居发现完成。NAT64 场景还要核对合成前缀与 IPv4 地址池映射。traceroute 某跳不回 ICMPv6 不等于转发失败，沿途设备常过滤探测，应结合双向抓包判断。
若 TCP 握手完成而 HTTPS 停顿，重点检查路径 MTU 发现：小包正常、接近接口 MTU 的探测无响应，可能是 ICMPv6“数据包太大”被丢弃。开启 DF 后递增测试长度，确认 1280 字节下限；先放行必要的 ICMPv6，再调整接口 MTU 或 TCP MSS。修复顺序为：DNS/DNS64、IPv6 地址与路由、防火墙与 NAT64 映射、PMTUD/MTU。每层保存解析结果和握手抓包，避免被“ping 得通却打不开网页”误导，不要全局关闭 IPv6。
排查连接请求时，先把双栈优先级固定：A/AAAA的排序、缓存和应用选择都会改变路径。若只取AAAA，IPv4便没有回退；若IPv6失败后迟迟不重试，Happy Eyeballs也救不了场。
按 RFC 8305，Happy Eyeballs 会在短暂延迟后尝试另一地址族。它只减少选错地址后的等待，不修复坏链路；重试间隔、缓存和代理策略还会改变结果，必须在同一客户端、同一出口复现。
在 IPv6-only 网络中，DNS64解析把 IPv4 地址嵌入 NAT64 前缀并合成 AAAA；客户端连接 IPv6，报文再经NAT64映射转为 IPv4。DNS64成功不等于NAT64可用，地址池、端口映射、状态表和后端可达性都要确认。
因此分开测 A、AAAA，并强制 IPv4、IPv6；核对合成 AAAA 的前缀是否属于该 NAT64 站点。不同缓存、解析器和出口也可能返回不同答案。
最易漏掉的是路径MTU发现。IPv6中间设备不替源主机分片，超出链路MTU时应返回ICMPv6 Packet Too Big；若防火墙丢弃它，TCP就会小包正常、大包卡住。IPv4也可能因依赖分片形成PMTU黑洞。
另一个坑是把DNS64当成NAT64：前者改写DNS答案，后者维护IPv6到IPv4的会话；地址池耗尽、端口冲突、状态超时或后端拒绝都会失败。防火墙、VPN、负载均衡健康检查及Happy Eyeballs延迟也会掩盖根因。
可执行检查清单：①保存 dig {A,AAAA} 域名，用 curl -{4,6} -v URL区分解析、连接和TLS故障。②用 ip -6 route get 目标查路由，tracepath -6 目标看PMTU，以递增ping -6 -M do -s 负载验证大包；在客户端、NAT64、服务端抓包，核对DNS答案、映射状态、TCP握手及ICMPv6 Packet Too Big。③检查NAT64地址池、端口和防火墙ICMPv6策略；验证MSS调整或PMTUD修复后恢复配置，再回归IPv4、IPv6、TCP、UDP业务。按顺序留证再改配置，避免重启服务掩盖根因。
