Summary

  • Patrick Sattler 在 RIPE 92 报告的实验中，受测 Chrome 和 Firefox 会等 A、AAAA 两种 DNS 应答。A 记录迟到时，已有可用 IPv6 地址也可能拖慢页面；Firefox 在部分测试条件下直接失败。
  • 受测浏览器里，Safari 是唯一完整实现 Happy Eyeballs v2 行为并使用 DNS 解析等待期限的。对其他受测客户端，解析器的超时时间会变成用户眼里的网页等待时间。

网站的 IPv6 地址已经在手里，浏览器却还盯着另一张票。Patrick Sattler在 RIPE 92 讲的不是 IPv6 线路故障，而是一个更尴尬的等待：IPv4 的 A 记录迟迟不来，正常的 AAAA 答案也被拖着不能开工。

Happy Eyeballs 原本给 IPv6 一个短暂的先发机会，连接不顺再让 IPv4 追上。但连接竞赛之前，浏览器要先向 DNS 取地址。Sattler 的团队设置可控的 DNS 与服务器延迟，把浏览器当黑箱测量。问题在这里露了头：如果客户端坚持等齐两份 DNS 回答，另一条路准备好也不能出发。官方演讲页概述了这组浏览器差异。

在 2026 年 5 月使用的版本和配置里，Chrome、Firefox 都发起 A 与 AAAA 查询，并等待两者返回。受测版本没有采用 v2 的解析等待期限。A 的回应被推迟时，页面跟着等待；Firefox 有些案例在 AAAA 已返回的情况下仍失败。Safari 的行为不同：AAAA 很快返回、A 延迟时，它先走 IPv6；若 AAAA 延迟，展示的测试中约等 50 毫秒便可改走 IPv4。

连接阶段另有时钟。测试里的 Chrome 在约 300 毫秒时切换地址族，Firefox 约 250 毫秒；Safari 动态调整。Sattler 还提醒，操作系统、代理和网络条件会改变结果，当时公开测试点只设在慕尼黑。这些数字是受测环境的观察，不能拿来代替新版客户端的测量。

因此，用户抱怨“IPv6 网页慢”，不一定该先找网站。浏览器决定是否等待 A，解析器决定这个等待多久才超时。Sattler 建议 DNS 运营者检查超时配置；浏览器工程师掌握另一把开关，让可用的 AAAA 答案先进入连接阶段。

一份能解决问题的故障记录，应分别写下 A 与 AAAA 的应答时间、浏览器版本、解析器、代理路径和实际尝试的第一个连接。只给出“IPv6 ping 成功”的绿灯，解释不了那张不动的网页。Sattler 把丢失的时间找到了 DNS 与客户端之间。

来源：RIPE 92 原始速记 · 官方演讲页 · RACI 人物页。