HTTP/3 已经普及到不能在全球代理测试中忽略的程度。Cloudflare Radar 近期全球协议视图显示，观测到的 HTTP 请求中约三分之一使用 HTTP/3。不同测量平台的样本和口径并不相同，这不是整个互联网的统一市场份额，但已经足以改变代理采购、质量测试和公开数据业务对“连接成功”的定义。
HTTP/3 为什么形成不同测试路径
HTTP/1.1 与 HTTP/2 通常运行在 TCP 上；HTTP/3 将 HTTP 语义映射到基于 UDP 的 QUIC，并集成 TLS 1.3。IETF RFC 9114 描述了独立 QUIC 流、较低延迟的连接建立，以及 UDP 无法连通时向 TCP 版本回退的行为。
在代理链路中，应用收到内容前，协议行为就可能不同。浏览器可能直接使用 HTTP/3，也可能回退到 HTTP/2；代理隧道还可能改变连接某一侧使用的协议。因此，单独查看 HTTP 状态码无法说明真实传输路径。
代理团队应新增的五类指标
1. 分别记录两侧协商协议
记录客户端到代理、代理到目标端的协议。浏览器支持 HTTP/3，不代表整条链路都在使用 HTTP/3。TCP CONNECT 隧道、网关策略或目标配置都可能改变结果。
2. 按地区测试 UDP 可达性
分别检查北美、欧洲和亚太的 UDP 连通性。企业防火墙、接入网络和本地路由策略对 QUIC 的处理可能不同。某个地区看似延迟较高，实际原因可能是 QUIC 多次尝试后才回退到 TCP。
3. 测量回退耗时，而非只看最终成功
请求最终成功仍可能因为回退增加数秒等待。应记录首次连接、回退、TLS 完成、首字节和整体完成时间，并使用 p50、p95 与 p99，而非只看平均值。
4. 检查连接复用与会话稳定
QUIC 连接可以承载多个独立流。需要检查网络变化时长连接是否稳定，以及重试时代理轮换是否意外改变身份。应用 Session、Cookie 与代理会话标识必须符合业务预期。
5. 按协议统计有效业务结果
将挑战率、预期地区内容、完整页面率、API 有效性、重试率和单位有效结果成本按协商协议拆分。握手更快并不代表结果更好，尤其当回退导致地域身份或会话发生变化时。
四格测试矩阵
- 直连加 TCP：建立传统基线。
- 直连加 HTTP/3：确认目标与本地网络支持 QUIC。
- 代理加 TCP：测量常规隧道或网关路径。
- 代理加支持 HTTP/3 的客户端：确认 HTTP/3 是被保留、终止还是替换，并衡量回退速度。
四种测试必须使用相同的获准目标、地区、请求集与时间窗口，否则差异可能来自目标负载、页面变化或地域，而不是协议。
常见故障模式
- HTTP/3 失败但 TCP 成功：检查 UDP、防火墙和网关支持。
- 两种协议都成功但 HTTP/3 更慢：检查路由、丢包、连接复用和回退。
- 不同地区协商结果不同：检查目标边缘配置和区域网络策略。
- 重试后会话身份变化：检查粘性会话参数和重试范围。
- 只有业务完成失败：检查依赖接口、授权和地区内容一致性。
选择代理时应该问什么
应确认代理入口协议代表什么、相关产品是否支持 UDP 或 QUIC、回退如何处理以及能够提供哪些指标。大范围区域测试可用上述矩阵评估 98IP 的动态住宅代理；需要更长期网络身份的任务可比较静态住宅代理。
本文由 98IP 团队发布并披露服务关系。代理基础设施只应用于有权访问的系统与数据，并应遵守适用条款和速率限制；协议测试不等于获得绕过访问控制的许可。
内部研究说明
本文内部参考了 Cloudflare Radar 全球 HTTP 版本观测数据（查阅于 2026 年 8 月 16 日）、IETF RFC 9114 HTTP/3（2022 年 6 月发布）以及 IETF RFC 9000 QUIC Version 1（2021 年 5 月发布）。根据 98IP 零外链规则，仅保留机构、资料名称和日期的纯文本。
结论：关键不是强制所有请求使用 HTTP/3，而是知道结果由什么协议交付、回退如何发生，以及最终业务结果是否正确。
