每次等网页转圈都在交的学费，今天被 Firefox 155 用四路赛马一口气全退了

阿监·前端工程化内容创作者 2026-09-04 12 阅读

每次点开一个页面，浏览器都要先做一连串”先试试这个、不行再试那个”的网络决策——这个过程你看不见，但每次你等的那一两秒里，有大把时间就耗在这里。

Firefox 155（2026 年 9 月 1 日发布）把这件事从根上修了。

Happy Eyeballs v3：并联试错，不排队等失败

传统浏览器加载页面的逻辑大概是这样的：

每一步都是串行的。任何一步慢，整条链就慢。

Firefox 155 引入的 Happy Eyeballs v3 把这个过程彻底并行化了：IPv4、IPv6、HTTP/2、HTTP/3 四条路径同时出发，谁先到用谁。DNS 记录会告诉浏览器服务器支持什么协议，Firefox 不再靠猜，不再靠等，直接开四路赛马。

实测效果：在 IPv6 部署不完整的网络环境下，页面加载时间能省下 1-2 秒的 DNS + 连接建立时间。这个改进不是优化，是架构级别的重做。

QUIC 是 HTTP/3 的底层传输协议，比 TCP + TLS 1.3 快在：建连只需要 1 个 RTT（TCP + TLS 1.3 需要 2-3 个）。

但 QUIC 本身也有版本演进。Firefox 155 支持 QUIC v2（RFC 9369），关键改进是”兼容版本协商”（RFC 9368）：如果浏览器和服务器起步时 QUIC 版本不同，现在不需要额外一次往返来确定用哪个版本——Firefox 直接选，不需要多等。

Chrome 已经在新版里支持了 QUIC v2。Firefox 155 补上了另一块拼图。两大浏览器现在都支持 QUIC v2，意味着这个优化不是实验性功能，是可以上生产的。

Happy Eyeballs v3 解决的是”选哪条路”的问题，QUIC v2 解决的是”版本协商”的问题。两者叠加的效果是：用户在地址栏敲下回车，到看到第一个字节（TTFB），中间的等待时间普遍缩短。

这不是前端优化的范畴，是 TCP/IP 协议栈和 TLS 握手的范畴——但效果直接体现在用户感知到的”打开网页快不快”上。

Firefox 155.0 在部分 UDP 被封的企业网络里可能出现问题：QUIC 依赖 UDP，UDP 被封时页面加载会回落到 HTTP/2 或 HTTP/1.1，Happy Eyeballs v3 的多路赛马反而会因为额外探测拖慢一点时间。

临时解法：在 about:config 里把 network.http.happy_eyeballs_enabled 设为 false，关闭多路赛马，强制单路径连接。Mozilla 计划在 9 月 8 日的 155.0.1 补丁里修复这个问题。

另外，Mozilla 把捕获门户检测域名从 detectportal.firefox.com 换成了 firefox-portal-detection.com——如果你的网络有域名白名单，记得把新域名加进去。

Firefox 155 是 Mozilla 切到两周一发的第一个版本。Chrome 153（9 月 8 日）也会从四周一发切到两周一发。这是 Chrome 和 Firefox 第一次在主要版本发布节奏上同步对齐。

对于运维团队来说，这意味着：浏览器新功能到达用户的速度翻倍，但同时也意味着你的测试矩阵要更新得更勤快了。

下一步：

打开 Firefox 155，对比加载几个主流网站看看 TTFB 变化
检查你的 CDN 或边缘节点是否已经支持 HTTP/3 + QUIC v2（主流 CDN 如 Cloudflare、Fastly、AWS CloudFront 均已支持）
如果你在企业网络里，验证 UDP 443 端口是否开放，避免 QUIC 回退到 HTTP/2 影响这个优化的收益

0 条评论

登录后可评论。