开代理后网页转圈？HTTP/3 与 QUIC 的检查方法
开代理后网页一直转圈，先找到卡住的具体请求，再看它使用的 HTTP 版本和失败阶段。HTTP/3 是排查线索之一，不能只凭“换个节点就好了”认定 QUIC 有问题，也不必先把相关功能全部关闭。
作者：小六｜资料核对日期：2026年11月3日
本文适合部分网页加载停顿、重试后恢复，或请求出现 QUIC 连接错误的情况。示例以桌面版 Chrome 的请求记录为主，不提供对所有浏览器通用的实验开关，也不把协议版本当成速度排名。
HTTP/3、QUIC、UDP 是什么关系？
HTTP/3 是建立在 QUIC 之上的 HTTP 版本，QUIC 则使用 UDP 传输。可以把它们理解为不同层次的分工，而不是三个互不相关的加速开关。Everything curl 的说明介绍了这种关系，也指出 QUIC 自身提供可靠传输。
因此，其他 TCP 网页请求能成功，不能直接证明到某个 HTTP/3 服务的 UDP 路径也正常。反过来，HTTP/3 没有被采用，也不代表整个代理节点无法工作。
第一步：在请求列表显示协议
打开 Chrome 开发者工具的 Network（网络）面板，再执行出现停顿的操作。在请求列表的表头上右键，勾选 Protocol（协议）列。按 Chrome 官方文档，h2 对应 HTTP/2，h3 对应 HTTP/3。
先选择真正出问题的那一条：可能是首页文档，也可能是之后加载的图片、脚本或接口。一个页面可以涉及多个域名，不能只看首页的一行就概括全部请求。
下面的判断针对实际联网的请求。若资源直接来自内存或磁盘缓存，应另观察需要联网的新请求，不能用缓存加载成功来判断当前线路是否连通。
| 观察到的结果 | 可以说明什么 | 下一步 |
|---|---|---|
| 对应请求使用 h3 并完成 | 这次请求采用 HTTP/3 成功返回 | 继续核对停顿是否发生在别的请求 |
| 对应请求使用 h2 并完成 | 这次请求采用 HTTP/2 | 不据此推断 HTTP/3 一定可用或不可用 |
| 请求报错，协议信息不完整 | 当前记录不足以确认完成方式 | 保留错误、目标和时间，查失败阶段 |
协议列描述的是对应请求，不是代理路径每一段的完整清单。判断流量是否进入客户端、使用哪个出口，还要结合客户端连接记录。
响应头写着 h3，为什么实际还是 h2？
网站可以用 Alt-Svc 告诉客户端另一个 HTTP/3 服务入口。根据 RFC 9114，客户端收到这类声明后，可以尝试建立相应 QUIC 连接。
这是一条“可以尝试”的信息，不是“已经用上”的凭证。应该把响应头中的服务声明，与 Protocol 列中的实际结果分开记录。
同样的规范指出，UDP 连接问题可能导致 QUIC 建连失败，客户端此时应尝试基于 TCP 的 HTTP 版本。具体是否成功、等待多久，还取决于客户端和当时条件，不能给所有浏览器套一个固定的回退时间。
所以，“等了一会儿页面最终打开”并不能单独证明 HTTP/3 正常；也不能只看最后的 h2 结果，就认定先前必然尝试过 QUIC。
第二步：固定条件，比较实际路径
1. 先记下目标和当前状态
记录最终请求的域名、端口、时间、协议结果与错误提示。同时注明系统代理或 TUN 状态、选中的策略组和节点，避免把直连请求误当成节点测试。
2. 保持缓存和操作一致
检查开发者工具没有处于离线或人为限速状态，记录缓存选项。连续刷新与首次访问的条件可能不同；不要拿节点 A 的首次加载，与节点 B 的缓存命中直接比较。
若需要分析排队、建连或首字节等待，可结合本站网页请求计时指南查看，协议名称本身不会指出等待发生在哪一步。
3. 一次只换一个条件
保持浏览器和目标不变，只换一个节点重新建立测试请求；再按需要固定节点，对照自己的另一种可用接入网络。每次记下实际协议，避免同时更换浏览器、DNS、节点和网络后无法解释结果。
4. 看到差异后，再查对应范围
只有某条路径反复出现 QUIC 建连问题，可以优先检查那条路径的 UDP 处理及目标可达性。仅某个网站异常，则也要考虑该站点的 HTTP/3 服务。一次恢复只是线索，不能直接判定某一方故障。
需要检查客户端是否接收并允许相关 UDP 流量时，可参考本站UDP 连通性检查方法。打开一个 UDP 选项，仍不能替代对接管、节点和目标路径的核对。
用 curl 测 HTTP/3，有什么容易看错？
另用命令行对照时，要先确认工具具备相应功能，且连接入口与浏览器的对照条件一致。工具能力、代理支持和真实路径没有核实前，命令失败不能直接算节点故障。
curl 官方的 HTTP/3 文档明确区分：--http3 允许在 HTTP/3 失败或较慢时尝试较早版本；--http3-only 不进行这种回退。因此，使用前者下载成功，也不能只凭成功结果认定传输一定用了 HTTP/3。
这里解释的是 curl 的选项行为，不能把它的尝试节奏直接当成 Chrome 的实现。浏览器侧仍以对应请求和错误记录为依据。
什么情况下才值得临时调整协议设置？
当相同条件下的问题能稳定复现，且所用软件提供有文档的协议控制入口时，可以记录原值后做一次对照，并核对实际协议是否改变。没有明确入口时，先保留诊断记录，不照搬旧版本实验开关或整套设置模板。
求助时提供浏览器与客户端版本、目标域名、协议列、错误和两次对照条件，遮住 Cookie、认证字段、含令牌的参数及订阅地址。只截必要请求，不必公开整份抓包。
想交流 HTTP/3、QUIC 或网页转圈的排查，可以带上这些脱敏记录：Telegram 联系我
评论