企业官网建设流程全解析

一、场景：本地能开就以为全网可达

很多站长在本地 curl 一下域名，v6 和 v4 都通，就觉得双栈没问题了。实际上浏览器在 v6 失败时会静默切换 v4，掩盖问题数月，直到一批教育网、政务云、手机 5G 用户报障才发现。

二、原理：双栈不是双保险

Happy Eyeballs 的工作方式是同时发起 v6 和 v4 连接，哪个先握手成功就用哪个。如果 v6 超时时间设得比较短，用户感知不到切换过程，但 v6 的失败被默默吞掉了。

问题在于，纯 v6 客户端没有 v4 可以回退。一旦 v6 链路有问题，这些用户直接无法访问。

三、三个高频排障场景

第一，AAAA 配了但 v6 超时。截图显示无法连接，指定解析直连 v6 地址仍然不通，说明服务器没监听 IPv6 的 443 端口，或者安全组没放行 v6 流量。

第二，v6 比 v4 慢一倍。同运营商下 v6 的 TTFB 明显高，说明路由绕路或者 CDN 的 v6 边缘节点覆盖不足，需要用路由追踪工具看 v6 路径。

第三，本地 curl 通但线上用户不通。本地是双栈有回退，纯 v6 客户端无 fallback，必须用纯 v6 节点验证。

四、实操建议

用拨测平台的网站测速功能，支持 IPv4 和 IPv6 双栈模式。同 URL、同运营商节点，分别跑 v4 和 v6，对比完全加载时间和截图。移动端 UA 一定要切一下，手机网络的纯 v6 场景比宽带普遍得多。

五、总结

只测 v4 等于盲测一半流量。双栈环境必须分别验证，用纯 v6 节点跑一遍才能确认 v6 链路真的可用。

附：双栈对比测速用支持 IPv4 和 IPv6 的拨测平台都能复现，我用的快快测 kkce.，多运营商节点覆盖还行，纯 v6 验证场景比较实用。