双栈网络可能同时提供IPv4和IPv6，但应用不一定每次选择同一类地址。某类连接异常时，支持自动回退的应用仍可能成功，另一个应用却持续失败。因此，“网页能开”与“两类路径均正常”需要分开记录。
为什么两台设备的结果可能不同
域名可能返回多个地址，应用的连接策略、解析缓存和本地网络条件又可能不同。RFC 8305给出的Happy Eyeballs机制旨在减少某类路径异常带来的等待，但不是所有应用、代理模式都保证采用相同实现。不能依据一个浏览器的表现替整台设备作验收。
| 现象 | 有用的下一步 | 不能先认定 |
|---|---|---|
| 浏览器正常，应用超时 | 核对应用采用的地址族与模式 | 节点对该应用特殊限速 |
| 家宽正常，热点失败 | 另建网络样本组 | 全部IPv6都不可用 |
| 首次请求慢，随后正常 | 记录首次连接与后续请求 | DNS一定是唯一原因 |
| IPv4、IPv6出口不同 | 核对预期规则及覆盖范围 | 多地址必然属于泄漏 |
一次对照要固定哪些条件
先选一个自己有权访问、诊断方法明确的非敏感目标。保持同一设备、应用版本、接入网络、节点与时间窗口。若工具支持按地址族观察，应分别记录IPv4和IPv6结果；如果工具不能显示实际选择，只写“该应用请求成功”，不要补填推测。
不能把A目标的IPv4成功与B目标的IPv6失败拼成同一组对照。目标服务自身是否提供对应地址，以及请求是否被代理或隧道处理，都需要同时明确。
示例：自动回退把差异藏起来
假设一组自设观察中，浏览器先尝试某类地址失败，随后换另一类成功，总等待变长。用户可能只感觉偶发卡顿，而专用应用可能直接报告超时。这提示应调查地址族或连接尝试差异，却还没有证明故障位于本地、节点或目标中的哪一段。
保留各阶段的错误和时间，比只统计最终成功更有价值。如果没有阶段信息，至少记录首开耗时、后续耗时和准确错误，不把原因写死。
分组检查的顺序
- 查目标解析与服务支持，确认不是在测试不存在的地址族。
- 阅读系统与客户端当前模式说明，核对其实际覆盖范围。
- 使用受支持的诊断方式观察同类任务，不改动生产网络全局参数。
- 再换个人允许的接入网络，重新建立独立记录，避免混样。
- 若只有一种路径异常，保留差异并向对应支持提交脱敏信息。
不建议为让检测结果“好看”长期关闭IPv6。若确有临时调整需求，应有明确目的、原值和恢复条件，并验证原本正常的任务。网络中缺少可观测信息时，结论应停留在“某组请求存在差异”。接着看分层排查和节点地址族支持，决定下一步查支持还是查实际路由。
来源与核验范围
以下为参考原始资料。品牌价格和功能应以资料库对应字段为准；本文不包含品牌测速或使用体验。内容由站点维护者使用 AI 辅助整理，尚不构成独立实测。