双栈分流必须分别验证 IPv4 与 IPv6。浏览器打开网页成功，只能说明至少有一条可用路径，不能证明两个地址族都按预期经过客户端。最有效的方法是把名称解析、连接地址族、命中规则与实际出口放在一起检查。
为什么正常访问会掩盖问题
同一个域名可能同时提供两种地址。应用为了减少等待，可能并行或交错尝试多个候选地址，最终选择先成功的连接。相关机制在 Happy Eyeballs 标准中有说明。用户看到的只是页面成功，不会自然知道另一路尝试是否超时或绕过了预期规则。
因此，“启用 IPv6 后网页依然能打开”是很弱的证据。某个应用可能成功回退到另一地址族，另一个应用却没有相同机制。设备换到移动网络后，候选地址与可用路径又可能变化，同一份配置不能只在家里的无线网络检查一次。
也不应把关闭 IPv6 当作默认修复。它可以在有限对照中帮助缩小问题，但长期处理应确认故障来自上游支持、接管范围、规则遗漏还是本地路由。否则关闭功能只是暂时隐藏了配置缺口，并没有说明原因。
建立四格检查表
将测试分成两种地址族与两种路由目标：预期直连和预期代理。每格挑一个确实支持相应地址族的目标，记录解析结果、实际连接地址及出口。目标不提供某种地址时应标记“不适用”，不能把没有地址写成客户端失败。
测试工具应明确支持地址族选择，使用前核对其帮助文档。浏览器的结果可作为真实使用观察，但不适合作为唯一的强制地址族测试。特别是缓存和连接复用，会使后续刷新继续使用第一次成功的路径。
示例中，一个站点的两种地址都存在。直连检查均成功，但代理检查只有其中一种进入客户端。此时优先看虚拟接口和路由是否覆盖另一地址族，再查规则，不必先怀疑站点服务器。若两种都进入客户端而只有一种失败，才进一步检查节点出站能力。
接管范围与代理能力是两层
系统是否把流量交给客户端，是第一层；客户端选择的代理是否能处理目标地址，是第二层。路由表存在相关默认路由，并不自动代表客户端的所有规则与出口都支持这一地址族。需要在连接日志里确认实际走到了哪一步。
还应区分代理服务器的连接地址和最终网站地址。连接代理使用 IPv4，不妨碍远端在其支持的情况下连接 IPv6 网站；反过来也不能根据代理节点名称推断目标流量地址族。日志记录时应分别写“节点连接”和“目标连接”，避免把两个地址混为一谈。
DNS 返回策略也会影响观察。若解析设置抑制了某类地址，应用根本没有机会尝试对应连接。测试前确认这是否是有意设置。改变返回策略会影响大量应用，应保留原值并在受控窗口验证，不要在会议或下载过程中突然调整。
看懂三个常见结果
第一种是某地址族直接超时，另一个正常。这支持路径存在差异，但不能仅凭结果确定是哪一跳阻断。检查本地网关、客户端接管和节点日志，可以逐步缩小范围。
第二种是两者都可访问，但出口归属不同。若需求是全部经过同一类策略，这意味着还需要核验分流；如果业务原本允许直连，则未必有问题。判定标准来自预先写下的需求，而不是看到不同就判定泄漏。
第三种是只有某个应用异常。可能该应用使用独立解析、固定地址或不同的连接尝试策略。将它与另一应用在同设备同网络对照，可以判断问题是否集中在应用路径。不要立即把整个家庭网络的地址族功能关闭。
修改后要复测业务动作
网络层检查通过以后，再执行登录、文件上传和持续播放等真实动作。某些业务会跨越多个域名，首页检查无法覆盖。记录实际完成情况与连接日志时间，避免将出口检测工具的成功当成所有业务都稳定。
还要检查局域网访问。双栈调整可能涉及本地地址、邻居发现或企业网络服务；本地打印和设备管理也应在回归清单内。若不熟悉路由设置，优先采用客户端正式支持的模式，并准备恢复配置，避免直接删除系统路由。
维护记录应包含设备、接入网络、客户端及内核版本、地址族、目标和结果。下一次切网后用同一张表复测，能够看出是配置变化还是环境变化。无须追求大量目标，少量覆盖完整的样本比随机访问更可靠。
解析侧可参考DNS 出口核验，业务分组可结合客户端分流工作清单，出现路径循环则看TUN 环路检查。双栈验收应明确写出两种地址族的测试范围，而不只留下“网络正常”四个字。
测试目标本身也应定期复核。如果它调整了地址记录或服务部署，旧检查表可能失去代表性。保留当次实际使用的目标地址与响应时间，并避免将某个第三方检测站的暂时不可用，直接解释成整个地址族在本地网络失效。
参考资料
- RFC 8305：Happy Eyeballs 第二版，核验日期：2026-10-15。
- mihomo TUN 配置，核验日期：2026-10-15。