发布日期：2026 年 9 月 22 日 · RootGS 技术编辑
同一个网站，有的人访问正常，有的人第一次打开很慢；手机网络能访问，办公室网络却偶尔卡住。双栈环境下，浏览器可能尝试不同地址族并进行回退，所以表面上的“能打开”也可能隐藏一条损坏的路径。本文从DNS记录、实际连接、服务监听和路径MTU逐段排查，不把禁用IPv6当作所有问题的默认答案。
一、确认客户端最终使用了哪条连接
先记录域名、客户端网络、失败时间和具体错误，再确认DNS同时返回了哪些A与AAAA记录。某些客户端会采用类似Happy Eyeballs的连接策略，减少一条路径不可用时的等待；不同客户端和网络的表现可能不同，不能凭一次浏览器成功认定两种地址族都正常。
检查浏览器请求详情或受控命令结果中的远端地址，把IPv4与IPv6分别测试。不要在比较时同时更换域名、网络和请求路径，否则难以知道差异来自哪一个变量。如果目标域名本来没有AAAA记录，单独IPv6测试无法解析并不等于服务器IPv6路由故障。
二、分别验证解析、TCP和TLS
下面的只读示例固定同一个HTTPS域名，分别要求使用IPv4和IPv6，并设置有限等待时间。请将example.com替换为自己的测试域名；命令用于请求响应头，不代表已经验证全部业务功能。
dig A example.com
dig AAAA example.com
curl -4 -I --connect-timeout 10 --max-time 20 https://example.com/
curl -6 -I --connect-timeout 10 --max-time 20 https://example.com/解析失败、连接超时、连接被拒绝与证书验证失败应分别记录。能够建立TCP连接不代表TLS正确，TLS成功也不代表目标页面正常。使用IP字面量直接测试HTTPS还涉及证书名称与虚拟主机，不能为了省事跳过证书验证后就宣布访问健康。
三、检查AAAA是否指向实际可用的服务
AAAA记录存在，只说明名称发布了IPv6地址，不保证该地址已配置在正确接口、拥有可用路由并被服务监听。若记录指向旧服务器或未完成配置的新节点，一部分用户可能持续走错入口。前方有CDN时，AAAA可能指向边缘地址，应按实际TLS和流量终止位置核对。
服务监听、主机防火墙、云平台访问规则和网络路由都要分别检查。IPv4已放行的端口，不一定在IPv6路径上采用相同规则；应用只监听IPv4地址时，也不能靠添加AAAA让它自动接受IPv6。不要为了排查把所有入站规则一次性放开。
四、Ping结果不能代替网站访问测试
ICMP回显与TCP 443流量可能受到不同策略处理，因此ping不通不能单独证明HTTPS不可达，ping能通也不能证明网站端口、证书和应用都正常。应围绕实际业务协议检查，并保留错误发生在哪一阶段的证据。
同样，路径探测中某一跳没有回应，也不自动意味着后续流量无法通过。中间设备可能限制诊断回应，而目的服务仍正常。比较不同网络时，应关注端到端业务结果和可重复的模式，而不是仅根据中间一跳的显示给网络定性。
五、小响应正常，大传输卡住时再检查MTU
若握手或小页面成功，较大响应、上传或长连接却在特定网络稳定卡住，路径MTU是值得检查的方向之一，但仍需排除应用超时和存储处理。IPv6路径MTU发现依赖包括ICMPv6 Packet Too Big在内的机制，粗暴阻断必要控制报文可能导致大包传输问题。
不要把所有ICMPv6都归为无用流量，也不要未经测量就全局降低接口MTU。应在受控环境记录失败方向、数据量、相关报文与重传，再结合隧道、虚拟网络和防火墙规则判断。若需要调整网络参数，应保留原值和恢复路径，避免远程修改后失去连接。
六、临时缓解与长期修复分开记录
在明确某条IPv6路径不可用且业务受影响时，可以按变更方案评估暂时撤回错误AAAA或调整入口，但DNS缓存会影响生效时间。这个动作只是减少用户命中故障路径，不能证明底层IPv6问题已经解决。依赖IPv6的用户和系统也需要单独评估影响。
长期修复应对应根因：错误记录、监听缺失、访问规则、路由或MTU分别处理。不要同时修改DNS、应用绑定和防火墙后只看最终能打开，否则之后很难解释究竟哪一项有效，回退时也容易恢复错误组合。
七、验收要覆盖双栈和真实业务
修复后分别使用IPv4和IPv6验证主要域名、HTTPS、登录、下载及适合业务的上传样本，并从目标客户的代表性网络复测。浏览器自动回退可能掩盖单侧故障，因此持续监控中应保留明确按地址族区分的探测。
记录解析结果、实际远端地址、请求阶段、证书与业务结果，以及变更前后的差异。双栈部署不是发布两条地址记录就结束，而是两条访问路径都具备可解释的连通性、性能与恢复方式。只有分开验证，才知道一次“访问正常”究竟覆盖了什么。
