摘要

  • Happy Eyeballs 通过及时尝试可用地址来保护用户，却也可能让总体成功率保持绿色，同时 IPv6 正在失败。
  • 运营者需要分协议族证据：DNS 返回、候选地址、实际尝试、胜出协议族、失败错误，以及代表性接入网络上的强制协议族结果。

设想一个明确的假想场景：主合成监控保持绿色，交易完成率稳定，客服也没有收到中断报告；但从某个接入网络强制使用 IPv6 的探针无法建立连接。这两组观察可以同时成立。普通客户端收到 A 与 AAAA 记录，先发起 IPv6 尝试，随后又足够快地通过 IPv4 建立连接，用户只感受到很小的延迟。

这不是对任何具名网络事故的描述，而是一个测量边界。一次事务成功，只能证明至少有一条可用路径完成工作，不能证明所有公布的地址族都处于健康状态。

RFC 8305 定义 Happy Eyeballs v2，目标是在某些地址或整个地址族被阻断、损坏或性能不佳时，减少用户可感知的等待。流程包括异步查询 A 与 AAAA、排列目标地址、按受控间隔启动连接，并保留成功连接；其他尝试随即取消。算法通常优先 IPv6，但它首先保护的是可用性。

RFC 8305 建议使用 50 毫秒的解析等待，并在没有历史往返时间时使用 250 毫秒的连接尝试间隔。这些数值是示例默认值，具体实现可以调整，也可能使用历史表现。更稳定的事实是竞争机制：如果客户端不导出失败尝试，最终成功的应用连接几乎不会说明落败候选发生了什么。

RFC 6724 又增加了地址选择层。它规定 IPv6 与 IPv4 的源地址和目标地址排序，并允许管理员覆盖默认策略。主机可能因为策略、地址范围、可用源地址或已知可达性而改变优先级。同一域名在不同客户端上可以产生不同顺序和不同路径。

汇总的 HTTP 成功率把这些决定压成一个比特。它没有回答 AAAA 是否及时到达、哪个 IPv6 地址被尝试、等待多久、失败发生在 DNS、邻居发现、路由、过滤、路径 MTU 还是目标服务，也不能说明 IPv4 是策略首选还是故障救援。故障还可能集中在一个移动网络、一代家庭路由器、某个系统版本或企业安全栈中。

最低限度的证据应在连接建立时保留：A 与 AAAA 答案及到达时间；排序后的候选地址；每次尝试的源和目标协议族、开始与结束时间、错误或超时；胜出协议族；解析路径；接入 ASN 或网络群组；目标边缘节点；应用结果；客户端实现与观察时间。不能只凭回退推断故障原因。

常规双栈检查应与强制 IPv6、强制 IPv4 探针配套。普通检查保护用户旅程，强制检查分别验证各自的受检环节。双栈成功而 IPv6 探针失败时，状态应是“服务可用但已降级”，不能升级为“全部健康”。

来源