IPv6 最气人的问题往往不是“完全不能用”，而是半好半坏：测速页面说支持，某些网站秒开，另一些网站转圈十几秒；关掉 IPv6 以后又突然正常。
这时候直接得出“IPv6 就是不行”有点早。关闭后变快只能说明故障大概率在 IPv6 路径，它没有告诉你坏在 DNS、路由、代理还是链路本身。
有地址，不等于能上公网
看到 fe80:: 开头的地址，通常只是链路本地地址，只在当前网络链路内有意义。设备拥有全局 IPv6 地址，也仍可能缺少正确的默认路由、DNS 解析或上游连通。
可以把完整访问拆成几层：
- 设备有没有合适的 IPv6 地址。
- DNS 能不能返回目标域名的 AAAA 记录。
- 系统有没有可用的 IPv6 默认路由。
- 网络能不能真正到达目标地址。
- TLS 和 HTTP 是否正常。
- 浏览器或应用失败后能不能及时回退 IPv4。
先确认是不是 DNS 问题
同一个域名的 A 记录对应 IPv4，AAAA 对应 IPv6。DNS 没返回 AAAA 时，浏览器通常不会凭空尝试 IPv6；返回了错误或不可达的 AAAA，应用则可能先撞上一条坏路。
可以用系统自带查询工具或可信 DNS 查询页对照 A、AAAA。记录类型看不懂时，先看DNS 查询到底在查什么。
先恢复自动 DNS 做基准，再测试自定义 DNS。路由器、私人 DNS、代理客户端和浏览器安全 DNS可能同时参与解析，一次全改会让结果完全不可解释。
解析正确，再测纯 IPv6 连通
在支持相应命令的平台，可以分别尝试：
ping -6 example.com
curl -6 -I https://example.com
curl -4 -I https://example.com命令名称会因系统不同而变化，而且有些服务器会禁用 ping，所以单次 ping 失败不能直接判死刑。真正有价值的是 IPv4 与 IPv6 对同一目标的对照。
为什么浏览器会先卡一下再打开
现代浏览器通常会并行或错开尝试 IPv6 与 IPv4，类似 Happy Eyeballs 的思路。如果 IPv6 不是明确失败，而是一直丢包超时，IPv4 回退就可能显得很慢。
因此“最终能打开”也不代表 IPv6 健康。首屏长时间空白、刷新后秒开、某些应用比另一些应用慢，都可能是不同回退策略造成的。
VPN 和代理是高频变量
有的代理只接管 IPv4，IPv6 仍直连；有的 VPN 会阻断 IPv6；有的分应用规则把浏览器和测试工具放在不同路径。结果就是同一台手机上，两个应用查到完全不同的出口。
如果你同时担心 WebRTC 暴露直连地址，可以结合WebRTC 泄漏测试的正确读法。重点不是盲目关 IPv6，而是明确哪些流量进入隧道、哪些没有。
DNS 和路由都正常，还可能是 MTU
部分链路的小数据包能通过，大页面、图片或 TLS 握手却卡住，可能与 MTU、分片或路径 MTU 发现异常有关。家庭宽带、隧道和某些校园网组合更容易出现。
普通用户不必一上来手改 MTU。先换另一个网络测试：同一设备在手机热点正常、家庭 Wi-Fi 异常，范围就已经缩小到路由器或运营商路径；所有网络都异常，再查设备和代理设置。
一个尽量不走弯路的顺序
- 关闭代理和私人 DNS，记录直连基准。
- 确认地址类型、默认路由和 A/AAAA 解析。
- 对同一目标分别测试 IPv4 与 IPv6。
- 换一个网络复测，区分设备问题和网络问题。
- 恢复代理，检查是否覆盖 IPv6。
- 只有证据指向链路时，再研究路由器固件、防火墙和 MTU。
最容易犯的几个错
- 把链路本地地址当成公网 IPv6。
- 换 DNS、重启路由器、改代理同时进行。
- 一个测试网站失败就认定运营商完全不支持。
- 关闭 IPv6 后正常，就永久关闭而不记录原因。
- 忽略路由器重启后前缀和旧静态规则已经变化。
什么时候暂时关闭 IPv6 是合理的
如果眼下需要稳定上课、会议或提交文件，暂时关闭 IPv6 可以作为应急绕行。但最好记录原设置和故障证据，之后再恢复验证。
诊断开关和最终修复不是一回事。真正的目标不是让某个测试页全绿，而是让设备在双栈网络里稳定、快速地选择可用路径。