curl 8.22 为 Happy Eyeballs v3 加入 25 毫秒解析延迟：代理团队应如何验证
curl 8.22.0 于 2026 年 9 月 2 日发布，其中一项网络变更被描述为“Happy Eyeballing v3：25 毫秒解析延迟”。对于使用代理执行合规数据采集、广告验证和市场研究的团队，这项变化值得单独测试，因为双栈连接调度会影响客户端连到哪个代理网关、何时启动另一地址族，以及哪些耗时会被归因于代理。
官方变更记录很简短。它并不意味着每个请求都会快 25 毫秒，也不是把连接超时或重试间隔统一改为 25 毫秒。解析延迟用于协调异步到达的地址族结果；连接尝试之间的节奏、完整连接超时和端到端请求耗时是不同指标。升级应被视为连接调度变化，而不是无条件的性能提升。
为什么需要解析延迟
双栈主机名可能同时返回 IPv6 与 IPv4 地址，但 A 与 AAAA 结果未必同时到达。企业 DNS、VPN、本地缓存、移动网络或云解析链路都可能让某一类结果更晚。如果客户端立刻使用第一批结果，可以快速启动连接，却也可能让另一地址族失去参与竞速的机会。
短暂的解析延迟会给另一类结果一个有界窗口，然后再安排连接。curl 8.22 记录的 25 毫秒属于这个解析阶段，不应与 CURLOPT_HAPPY_EYEBALLS_TIMEOUT_MS 混为一谈；后者控制地址可用后连接尝试之间的节奏。
为什么代理链路必须单独验证
使用代理时，客户端首先连接的通常是代理网关，而不是最终目标。传统 HTTP 代理和 CONNECT 隧道中，代理网关可能是双栈；目标域名则可能由客户端或代理解析，取决于协议与配置。不同 SOCKS 模式也会改变 DNS 责任方。
因此必须分别回答：
- 客户端是否同时解析代理网关的 IPv4 和 IPv6？
- 哪个网关地址最终胜出，升级前后是否一致？
- 目标域名由代理解析，还是由客户端先转换为地址？
- 首次连接之后，连接复用是否掩盖了新的调度逻辑？
- IPv4 与 IPv6 网关是否对应不同区域、出口池或策略？
仅看到页面返回成功，无法证明这些边界都正确。
建立授权范围内的回归矩阵
仅使用获准的代理账号和测试目标。在自有 DNS 测试环境中准备 IPv4-only、IPv6-only 与双栈名称，并加入一个可控制 A 或 AAAA 响应延迟的双栈场景。
至少覆盖以下用例：
- 不使用代理的双栈目标，作为对照；
- 双栈代理网关，目标由代理解析；
- 双栈代理网关，目标由客户端解析；
- 仅 IPv4 与仅 IPv6 的代理网关对照；
- 每条路径分别测试冷连接和复用连接；
- 正常 DNS、延迟 A 响应、延迟 AAAA 响应。
保持客户端构建、解析器配置、网关区域、认证方式、请求内容和超时预算一致，在同一环境比较当前批准版本与 curl 8.22.0。
记录能够解释结果的数据
如果测试工具允许，记录 A 与 AAAA 查询开始和完成时间，并记录第一次连接尝试、后续地址族尝试、胜出的网关地址、连接完成、代理认证、CONNECT 完成、目标 TLS、首字节与总耗时。
每个样本还应包含：
- curl 与运行时 libcurl 版本；
- 代理协议及 DNS 责任方；
- 网关主机名、区域与胜出地址族；
- 冷连接或复用连接状态；
- DNS 结果顺序和到达时间差；
- 连接结果与 curl 错误码；
- 响应验证、重试次数与字节数；
- 按路径类型统计的 p50、p90 与 p95。
不要在日志中保留代理密码、Cookie、令牌或完整个人数据。使用合成标识，并在共享诊断文件前完成脱敏。
不要用猜测解释升级差异
如果 8.22 在某一 DNS 结果较晚时更早启动连接，应继续确认网关区域与策略仍然正确。中位数变快并不代表上线成功；若尾部失败、路径漂移或重试放大增加，业务结果仍可能变差。
如果 IPv4/IPv6 胜出比例变化，应分别比较两类路径的丢包、握手耗时与有效响应率。不要因为某个办公室或云区域里 IPv4 更常胜出，就直接关闭 IPv6。问题可能来自解析器、路由发布、防火墙或网关部署。
如果热连接看不到差异，可能只是连接复用避免了新的解析与建连。在受控样本中强制新连接再做判断，但不要为了展示基准差异而让生产请求频繁断开。
可以结合代理延迟归因测试把 DNS 与网关连接变化从目标处理耗时中分离，并使用IPv6 代理连接指南完成更全面的双栈排查。
设定上线门槛
测试前定义明确阈值，例如：
- 有效请求失败率不得上升；
- 强制代理场景不得出现直连；
- 网关区域与出口策略保持稳定；
- IPv4/IPv6 胜出比例变化可解释且有界；
- p95 建连耗时改善或至少不恶化；
- 每个有效结果的重试数不增加；
- 单个有效业务动作的成本不明显上升。
如果客户端绕过代理、选择未授权路径、持续增加尾延迟或出现无法解释的地址族失败，应立即回滚。旧版本应保留到所有生产网络类型完成灰度。
升级检查清单
- [ ] 已确认 curl 8.22.0 与实际加载的 libcurl 版本。
- [ ] 已记录代理网关和目标域名的 DNS 责任方。
- [ ] 已准备 IPv4-only、IPv6-only 与双栈对照。
- [ ] 可在受控环境测量 A 与 AAAA 返回时间。
- [ ] 冷连接与复用连接分开报告。
- [ ] 已验证网关地址族、区域与出口策略。
- [ ] 代理认证与 CONNECT 耗时单独统计。
- [ ] p50、p90、p95 仅使用验证成功的响应计算。
- [ ] 重试放大和有效结果成本保持在预算内。
- [ ] 灰度回滚条件已提前批准。
常见问题
新的 25 毫秒就是 IPv4 回退超时吗？
不是。官方条目描述的是 Happy Eyeballs v3 的解析延迟。连接尝试节奏是另一个控制项，应分别测量 DNS 结果到达与套接字启动时间。
每个代理请求都会受到影响吗？
不一定。它主要影响正在连接的主机名为双栈、且地址族结果异步到达的场景。已经复用的代理连接可能不会重新解析和建连。
为了稳定是否应该强制 IPv4？
除非明确的网络要求如此，否则应先确定故障属于 DNS、路由、防火墙、网关部署还是客户端。强制单一地址族会掩盖 IPv6 缺陷并降低弹性。
更快的建连会不会选到不同代理出口？
部分部署中，不同地址族可能进入不同网关基础设施，因此必须记录网关地址、区域和实际出口策略。
内部来源说明：curl 项目《Changes in 8.22.0》，2026 年 9 月 2 日发布；条目“Happy Eyeballing v3: resolution delay of 25ms”。外部资料地址只保留在内部运营记录中。
代理基础设施只能用于合法且获得授权的活动。遵守目标站点条款、速率限制、隐私义务与数据保留要求，不得通过连接调优绕过访问控制或掩盖违规行为。
