摘要：同一个网址，在公司网络可以打开，换到手机热点却一直等待，原因未必是网站故障，也不能直接归结为出口 IP 质量。本文从双栈网络的地址选择入手，说明域名解析、实际连接与页面资源之间的关系，并整理一套保留现场、逐项验证的排查方法。
建议标签：IPv4、IPv6、计算机网络、DNS、故障排查
一、同一个域名，不一定对应同一条访问路径
我们通常用网址描述一次访问，例如"这个网站打不开"。但域名只是入口名称，客户端还需要解析地址，再选择实际连接的目标。
一个域名可以配置 IPv4 地址，也可以配置 IPv6 地址。DNS 中常见的 A 记录对应 IPv4，AAAA 记录对应 IPv6。看到两类记录，只能说明域名提供了相应地址，不能证明当前设备到这两类地址的路径都可用。
RFC 8305 讨论的正是这类情况：同一主机名可能解析出多个地址，不同地址或地址族的连接表现可能不同。1 因此，比较两次访问时，除了网址，还需要确认实际使用了哪一类地址。
二、能上网，不代表两类连接都正常
判断网络是否正常时，常见做法是随便打开一个网站。如果能够加载，就认为整条网络没有问题。
这个验证范围其实很小：它只证明当时访问的目标和实际使用的路径可用。
假设一个测试环境中，IPv4 路径可用，IPv6 路径存在异常。如果某个应用选中了 IPv6 地址，连接表现就可能与另一个选用 IPv4 的应用不同。这里是原理示例，并非对任何网络的实测结论。
反过来也一样。不能因为某次 IPv6 访问失败，就认定 IPv6 天生更慢；也不能因为切换网络后恢复，就立即确定故障来自运营商。客户端、路由路径和目标服务都需要分别验证。
三、为什么浏览器正常，另一个程序却失败？
客户端如何处理多个候选地址，会影响用户看到的等待时间。
Happy Eyeballs 的设计思路，是安排多个候选连接尝试，减少某个地址族不可用时带来的等待。1 不同软件、版本及运行环境的具体实现可能不同，因此不能假设所有程序都与浏览器采用相同策略。
此外，"访问同一个网站"也可能只是口头上的相同。浏览器访问的是首页，程序访问的是接口；首页加载成功，接口所在的子域名却可能有另一组解析结果。
一张网页还可能分别请求脚本、图片和接口。MDN 对 HTTP 的介绍指出，完整页面通常由多个资源组成。2 所以，页面有文字但图片空白，应该先确认失败资源的域名，而不是笼统判断整个网站失联。
四、把一次对比测试记录完整
建议在自有或获准测试的环境中，用下面这张表整理证据。
| 核查项目 | 需要记录的内容 |
|---|---|
| 测试对象 | 具体页面或接口路径、失败资源所属域名 |
| 测试条件 | 时间、设备、网络类型、客户端版本 |
| 解析结果 | 是否存在 A、AAAA 记录 |
| 实际连接 | 可观察到的目标地址及地址族 |
| 故障表现 | 连接超时、证书报错，还是收到应用响应 |
| 对照结果 | 相同条件下是否重复出现 |
如果有应用维护权限，可以结合客户端诊断记录与服务端日志核对实际请求。存在中间转发时，客户端显示的对端可能只是中间设备，不能直接当成源站地址；服务端看到的来源，也不一定等于设备本地地址。
需要保留"未观察到"的状态。缺少连接记录时，不要把"没有看到 IPv6 请求"改写成"程序不支持 IPv6"。
五、先缩小范围，再调整设置
一次只改变一个条件，更容易判断因果关系。例如固定设备和客户端，只切换网络；随后固定网络，再比较两种客户端的同一请求。
若每次同时修改 DNS、更换网络并重启程序，即使恢复，也难以定位原因。直接把域名替换为 IP 地址也不是等价测试，因为 HTTPS 证书校验和站点选择可能依赖
域名。
同样，不建议把永久关闭某个地址族作为未经验证的通用修复。即便临时对照测试表明问题与某条路径相关，后续仍应由维护人员核对对应的解析、路由和服务配置，并记录恢复结果。
排查代理 IP 或其他网络环境问题时，可以把结论写得具体一些："同一客户端访问指定接口，在网络甲连接成功，在网络乙出现连接超时；两次实际目标地址族不同，尚需验证对应路径。"这样的记录，比"这个 IP 不稳定"更能帮助下一位排查者继续工作。