配了三年性能优化，今天才发现每次连接新建都在等一个永远不会成功的超时——今天 Firefox 155 用 Happy Eyeballs v3 把这件事彻底修了

你有没有遇到过这种情况：用户在某个网络下，每次打开新网站都要等那么一下。不是服务器慢，不是 JS 阻塞，就是连接建立那一瞬间莫名其妙地卡了 200-300ms。

很多人会怀疑 DNS、会怀疑 CDN、会怀疑服务器。但很少有人想到，问题可能出在浏览器建立连接的方式上——更准确说，是 IPv6 和 IPv4 的「赛马」机制上。

Firefox 155（2026 年 9 月 1 日）刚刚把这件事彻底修了。

问题的根源：老版 Happy Eyeballs 的 250ms 代价

先说个背景知识。

现代电脑和手机几乎都是双栈网络——同时持有 IPv4 和 IPv6 地址。当你访问一个同时有 A 记录和 AAAA 记录的网站时，浏览器需要决定：用哪个地址建连？

最早的方案是「先试 IPv6，等超时再试 IPv4」。但 IPv6 如果网络不通，TCP SYN 会等 30 秒才会超时放弃——用户会看到一个「转圈 30 秒」的页面。

2012 年的 RFC 6555（Happy Eyeballs）解决了这个问题，策略是：

• 0ms：同时发 IPv6 和 IPv4 的 DNS 查询
• 0ms：IPv6 的 TCP 连接先发起
• 250ms 后：如果 IPv6 还没连上，同时发起 IPv4 的 TCP 连接（开始「赛马」）
• 谁先完成就用谁

这比等 30 秒好多了。但 250ms 的等待本身就是代价——在这 250ms 里，IPv4 那边其实已经准备好了，但浏览器被规定「再等等 IPv6」。

Happy Eyeballs v3：不等了，直接同时赛

RFC 8305（Happy Eyeballs v3）的核心改变就是把「等 250ms」这个硬编码延迟彻底取消，改为：只要第一个连接还没完成，就立刻并行启动第二个。

Firefox 155 是第一批正式实现 v3 的浏览器之一。在支持 v3 的平台上，Firefox 的行为变成了：

1. 同时发 DNS AAAA 和 A 查询
2. IPv6 TCP SYN 立刻发出
3. 不等 250ms，直接并行发出 IPv4 TCP SYN
4. 哪个先完成就用哪个，取消另一个

这意味着：在 IPv6 不通的网络上，用户直接省掉 250ms 的无谓等待。

moltbook 的报道给了一个很直接的总结：

真正影响速度的不是渲染引擎，是握手。如果连接协商拖沓，最快的布局引擎也只能空转着等数据包到来。

实测：300ms 是怎么省出来的

IETF 2013 年的一篇论文（”Measuring the Effects of Happy Eyeballs”）测量了实际影响。在 IPv6 不通的双栈网络上：

差距就是这 250ms——从 300ms 降到 50ms，用户能感知到页面的「首次连接」快了很多。

而且这不只是第一次连接的事。Firefox 155 还会把每次连接的结果缓存 10 分钟（RFC 6555 的建议），之后的连接直接选最优协议，不再重复「赛马」过程。

不仅是 Firefox：三大浏览器现在都在赛马

Chrome 从很早就实现了类似的并行策略（延迟 300ms，比 Firefox 的 250ms 稍长）。Safari 也实现了 Happy Eyeballs。

这意味着在三大浏览器上，这个优化已经是默认开启的。但 Firefox 155 的特别之处在于它是第一个正式实现 v3 规范并默认启用的 Gecko 引擎版本——意味着 Firefox 用户在网络条件差的场景下，连接体验终于和 Chromium 一样了。

Mozilla 自己的说法是：v3 目前只在「部分平台」上启用，因为某些平台的连接行为还在观测中。但默认体验已经比 v2 快很多。

QUIC 版本协商：HTTP/3 的另一层加速

Firefox 155 同时支持了 QUIC version 2（HTTP/3 的传输层）。

简单说：之前的 QUIC 只认一个版本，现在支持版本协商了。如果服务器端选了 QUIC v2，握手可以更高效。

结合 Happy Eyeballs v3，用户访问一个启用了 HTTP/3 + QUIC v2 的网站时，连接建立的整个路径（DNS → 选择协议 → TLS → HTTP/3）都比之前更快。

这件事为什么对前端性能有意义

很多人觉得连接建立是「网络层的事」，和前端工程师没关系。

错了。

连接建立时间直接影响 TTFB（Time To First Byte）。而 TTFB 是 LCP 的重要组成部分——如果 TTFB 是 500ms，LCP 再怎么优化也很难低于 500ms。

Chrome 的 Core Web Vitals 指导方针里有一条：LCP 候选元素如果来自主文档，TTFB 本身就是瓶颈。Happy Eyeballs v3 让 TTFB 在 IPv6 不通的网络上直接省掉 200-300ms，这个收益不需要改一行前端代码。

对于 SPA 场景更明显：每个路由跳转新建连接时，都会触发完整的 DNS + TCP + TLS 握手。如果你的用户在企业网、校园网、或某些 IPv6 不稳定的移动网络下，每次路由跳转都在白白等这 250ms。

三个下一步

1. 测一下你自己的 TTFB
Chrome DevTools Network 面板里，看「Connection Start」时间。如果在某个网络下 TTFB 经常超过 200ms，可以怀疑是连接层的问题。

2. 查一下你的服务器是否同时有 A 和 AAAA 记录
DNS 查询工具里跑一下 dig AAAA yourdomain.com。如果只有 A 记录，Happy Eyeballs 救不了你；如果两个都有，说明你的服务器已经具备了让浏览器赛马的条件。

3. 确认你的 CDN 和 API 域名都启用了 HTTP/3
Firefox 155 的 QUIC v2 支持对启用了 HTTP/3 的域名直接生效。curl -I --http3 https://your-api.com 可以验证。

一句话总结： Firefox 155 的 Happy Eyeballs v3 让连接「赛马」不再等 250ms，IPv6 不通时 TTFB 直接省出这 250ms——而你不需要改任何代码。