开代理后网页变慢？HTTP/3、QUIC 与 HTTP/2 回退怎么核对
开代理后网页变慢，先定位哪一个请求、在哪个阶段变慢，再看它使用 h2 还是 h3。**HTTP/3 使用 QUIC，但协议名称本身不能证明请求经过了指定节点，也不能保证加载更快；HTTP/2 成功也不意味着代理失效。**需要把浏览器请求、代理接入与节点传输分开核对。
作者：小仓｜资料核对日期：2026-10-12
浏览器里的协议和节点协议不是一回事
| 观察对象 | 要回答的问题 |
|---|---|
| 网页的 HTTP 请求 | 浏览器对这个资源实际使用了什么协议？ |
| 本机代理或 TUN 接入 | 请求是否进入客户端，匹配了哪条规则？ |
| 客户端到节点、节点到目标 | 每一段连接能否承载所需流量？ |
例如，节点使用基于 QUIC 的传输，并不要求网页也显示 h3；网页显示 h3，也不能说明节点使用 Hysteria 2。外层承载和应用请求属于不同层次，相关背景可参考本站 Hysteria 2 与 QUIC。
HTTP/2 标准 描述的是 TCP 连接上的 HTTP/2；QUIC 标准 则说明 QUIC 包由 UDP 数据报承载。实际排障因此要核对 TCP 与 UDP 的路径，不能只写“443 端口通了”。
第一步：在 Chrome 查看慢请求
打开出问题的页面及开发者工具，切到 Network，再重新加载。每一行对应一个资源，主文档、脚本、接口和视频文件可能来自不同域名。打开记录后才发起测试，避免只看到后来加载的一小部分；操作基础见 Chrome 网络检查教程。
- 右键请求表格的列标题，显示 Protocol、Domain 和 Remote address。
- 找到真正慢或失败的行，保留域名、状态、协议、耗时和错误信息。
- 点击该行，检查 Timing，把它与同一资源的对照结果比较。
Protocol 列中，h2 表示 HTTP/2，h3 表示 HTTP/3；官方字段说明见 Chrome Network 功能参考。这些列帮助描述浏览器看到的请求，不是整个代理链路的抓包结果。
只看首页第一行容易遗漏问题。首页用 h3，但登录 API 用 h2 且一直失败时，应先排查 API；图片加载慢，也不能拿另一域名上的小文件来替它证明网络正常。失败请求若没有完整协议信息，就保留原始错误，不给空白栏补上猜测。
第二步：把“没有 h3”和“发生回退”分开
HTTP/3 需要浏览器发现并成功连接相应端点。RFC 9114 第 3.1 节 说明：UDP 受阻等条件可能使 QUIC 建立失败，此时客户端应尝试基于 TCP 的 HTTP 版本。服务器还可以通过 Alt-Svc 公告替代端点及端口。
因此，不能假设所有 HTTP/3 都固定使用同一个 UDP 端口，也不能把最终显示 h2 当作“之前必定尝试了 QUIC”的证明。目标未提供可用 h3、浏览器的策略或已有连接，都可能影响最终协议选择。
要定位回退，应把同一时间段的浏览器错误与客户端连接日志对上。记录是否出现了对应目标的 UDP 尝试、是否有回复，以及后来的 TCP 请求是否成功。普通请求表格中的一条成功记录，往往不足以还原所有连接尝试。
第三步：核对代理有没有接入所需流量
传统 HTTP CONNECT 建立的是 TCP 隧道；UDP 代理还有专门的扩展，例如 RFC 9298 的 connect-udp。协议标准存在，不代表你的浏览器、客户端和服务端已经实现并启用了它。
所以，“系统 HTTP 代理已开启”不能单独证明 UDP 被接入。使用 TUN 时，也要确认实际路由、客户端的 UDP 处理和出站能力；TUN 开关不是一份所有流量都经过节点的保证。先根据所用实现的日志核对规则和出站，背景可参考 规则、全局与 TUN 的区别。
同时保留接入模式：系统代理、PAC、应用自设代理或 TUN。切换模式后协议变了，说明测试条件发生变化，还需要验证慢请求是否进了预期路径。仅凭 h3 就断言“UDP 泄漏”，或仅凭 h2 就认定“节点不支持 QUIC”，都缺少链路证据。
第四步：做一组能解释的加载对照
固定浏览器版本、页面 URL、节点和本地网络。先在当前模式记录一次，再只改变一个获准的接入条件，按相同方式重新测试；不适合直连比较的环境，可以只比较客户端中两种已配置的路径。
测试前检查 Network 的模拟网络限速，保持 No throttling。两轮应采用相同的缓存条件，可以在开发者工具中勾选 Disable cache；它控制浏览器缓存，不应被理解成所有连接状态都已清空。缓存和限速操作可查前述 Chrome 文档。
每种条件各记录首次加载与重复加载，而不是只挑最快的一次。还要标注远端地址、资源大小和状态是否改变：如果换路径同时选中了不同服务端，结果是整条路径的比较，不能只归因于 HTTP 版本。
Timing 中长在哪一段？
按 Chrome 的时间阶段说明，Waiting（TTFB）包含网络往返和服务器准备首字节的时间；Content Download 则是读取响应体的时间，还可能受浏览器其他工作影响。
这意味着 TTFB 高不必然是节点带宽不足，下载阶段长也不能直接排除浏览器因素。先保留阶段差异，再结合客户端日志调查；若只是少数大请求卡住，可继续查看 MTU 排查指南。
观察结果之后怎么处理
- h2 稳定、业务正常：可继续使用，不必只为显示 h3 而改动网络。
- 只有某条路径出现对应 UDP 失败：检查该路径的 UDP 接入、出口和目标端点，并保留 TCP 回退结果。
- h2、h3 下同一资源都慢：继续检查资源大小、服务器响应及整条路径，不围绕协议标签重复切换。
- 协议相同、速度差异明显：先比较实际出站与服务端地址，再核对本地负载和网络条件。
本文没有实测特定机场，也不提供固定回退秒数或性能排名。清楚的协议与路径记录，能帮助管理员判断该调查浏览器、客户端还是目标服务。
可填写的测试记录
时间与时区、浏览器及客户端版本：
页面与具体慢资源（删除令牌）：
接入模式、节点、规则与出站：
协议、远端地址、状态或错误：
缓存条件、是否启用模拟限速：
首次与重复加载的阶段耗时：
本次只改的条件、UDP 尝试与回复线索：
反馈时按需分享记录中的字段；URL 查询参数、Cookie 和完整日志里的凭据应先处理，再交给可信的维护者。
评论