Happy Eyeballs：IPv6 连不上，浏览器为什么不用干等？

一台手机同时有 Wi-Fi、蜂窝网络和多种地址协议，连接网站时可能先拿到 IPv6 地址，也可能只能经 IPv4 到达目标。若客户端先尝试一种地址并长时间等待失败，再尝试另一种，用户就会觉得网页“明明有网，却要卡一下”。Happy Eyeballs 是一组让连接尝试更灵敏的技术建议，目标是在多地址、多协议环境中尽快取得可用连接。

它通常不会让客户端完全放弃 IPv6 或盲目并发所有尝试，而是先解析可用地址，再错开启动不同候选连接的时间。客户端可以优先尝试某一地址族，同时在短暂等待后启动另一种选择；哪个连接先成功，就使用哪个，并取消或清理不再需要的尝试。用户看到的是连接更快恢复，系统则在速度与避免无谓竞争之间折中。

为什么不同时把所有候选地址一股脑发起？并行越激进，越可能浪费连接、端口和服务器资源，也可能让不同地址族的流量偏向不符合预期。RFC 建议对 DNS 查询、地址排序和连接尝试进行协调，避免因单一地址不可达而让整个页面加载被拖住，同时尽量保留对 IPv6 等路径的偏好。

Happy Eyeballs 并不能修复网络本身，也不保证每次都选中“理论上最近”的服务器。它只是让客户端有机会绕开某个慢或不可达的候选路径；DNS 延迟、代理设置、防火墙、服务器健康和网络切换仍会影响体验。连接在一个地址族成功后，中途网络环境改变，应用可能还需要自己的重连和会话迁移逻辑。

当你发现网站在某些 Wi-Fi 或 VPN 环境里首次打开特别慢，之后刷新却快很多，双栈连通性问题可能是排查方向之一，但缓存也会造成类似现象。浏览器、操作系统和应用的实现细节各异，应结合 DNS 与连接时间线分析，而不是仅凭“IPv6 开了”就认定原因。

这个名字听起来像魔法，其实是工程上的竞速与回退策略：尊重多种可用路径，让客户端在不可靠网络里尽早找到第一条真正走得通的路。

来源：RFC 8305：Happy Eyeballs Version 2