使用代理 IP 访问网站时，浏览器地址栏或开发者工具可能显示 HTTP/3。这个标记只能说明某一条连接使用了 HTTP/3，不能单独证明代理生效，也不能直接证明请求绕过了代理。原因在于 HTTP/3 运行在 QUIC 之上，而 QUIC 使用 UDP；常见 HTTP 代理主要处理 TCP 连接和 HTTPS 的 CONNECT，代理是否支持 UDP 转发取决于协议、客户端和服务端实现。
先把三件事分开：代理、协议和出口地址
- 代理路径：浏览器是否把请求交给 HTTP、SOCKS5、系统代理或隧道客户端。
- 应用协议：目标连接最终使用 HTTP/1.1、HTTP/2 还是 HTTP/3。
- 公网出口：目标站看到的源 IP、ASN 和地区，是否符合本次代理设计。
三者不是同一个指标。代理生效但回退到 HTTP/2，仍可能是正确结果；浏览器显示 HTTP/3，也可能是某个未纳入代理规则的直连连接。
第一步：确认浏览器是否真的使用代理
先用一个明确支持代理的请求做对照，记录出口地址、请求时间和代理配置。以 SOCKS5 为例：
curl --proxy socks5h://USER:PASS@PROXY_HOST:PROXY_PORT https://example.com/ -I -v
curl --noproxy '*' https://example.com/ -I -vsocks5h 让域名由代理端解析；第二条命令明确绕过代理。两次请求应在相同网络条件下进行，再比较目标站返回的出口 IP 或服务端日志。不要只看本机网卡地址，也不要把 DNS 解析地址当成 HTTP 出口。
第二步：观察 HTTP 版本和连接协议
命令行可以用 curl 明确指定或限制 HTTP 版本：
curl --proxy http://USER:PASS@PROXY_HOST:PROXY_PORT --http2 -I -v https://example.com/
curl --proxy http://USER:PASS@PROXY_HOST:PROXY_PORT --http1.1 -I -v https://example.com/如果本机 curl 构建时支持 HTTP/3，可再做单独测试；不支持时不要因为命令报错就推断代理失效。观察输出中的连接协议、CONNECT 响应、TLS SNI 和最终响应头，并将“HTTP 版本”与“出口 IP”分别记录。
为什么代理下常见 HTTP/2 回退
HTTP 代理通常通过 TCP 建立到代理服务器的连接，再由代理对目标站发起 TCP 或 TLS 连接。若客户端没有通过支持 UDP 的隧道传递 QUIC，浏览器通常会回退到 HTTP/2 或 HTTP/1.1。回退本身不是错误，关键是回退后的 TCP 连接是否仍沿着代理链路，以及目标站看到的地址是否正确。
如果配置的是全局隧道或明确支持 UDP 的代理协议，情况会不同；此时还要检查客户端的 UDP 开关、MTU、NAT 映射、IPv6 和服务端转发策略。不能把“支持 SOCKS5”直接写成“支持 HTTP/3”，两者属于不同层次。
第三步：用禁用 QUIC 做对照实验
在浏览器临时禁用 QUIC 或 UDP/443，再访问同一目标，记录四项结果：HTTP 版本、出口 IP、页面是否完整、连接耗时。恢复默认设置后再测一次。这个实验只能帮助判断协议变化，不是性能排名，也不能代替多地区和多时段测试。
| 对照项 | 需要记录 | 不能据此推出 |
|---|---|---|
| 代理开启、QUIC开启 | 协议、出口IP、连接错误 | 不能仅凭HTTP/3确认代理生效 |
| 代理开启、QUIC关闭 | 是否回退到HTTP/2/1.1、出口是否一致 | 不能据此证明UDP一定被阻断 |
| 代理关闭 | 直连协议和直连出口 | 不能把DNS地址当作公网出口 |
出现“网站能开但协议判断不一致”怎么排查
只部分请求走了代理
检查 PAC 规则、浏览器扩展、系统代理和应用自带网络栈。HTTP/3 可能由浏览器直接建立 UDP/443，而页面的部分资源经 HTTP 代理走 TCP。用开发者工具的远程地址、代理日志和外部出口接口交叉核对。
IPv4与IPv6走了不同路径
代理只提供 IPv4 时，浏览器可能对 IPv6 使用另一条路径。分别执行 curl -4、curl -6，并确认代理客户端是否接管 IPv6；不要因一个地址族正常就判定全局代理完整。
代理支持 CONNECT，但不支持 UDP
CONNECT 成功只表示 TCP 隧道建立，不代表 UDP 转发可用。需要 UDP 的应用应查看代理协议和客户端文档，或使用明确支持 UDP 的隧道方案，并在目标端记录实际源地址。
一份可复用的验收记录
- 代理类型、认证方式、是否启用远程 DNS。
- 目标域名、解析地址族、HTTP 版本和 TLS SNI。
- 代理开启/关闭、QUIC 开启/关闭四组对照结果。
- 目标站看到的出口 IP、ASN、地区数据库和时间。
- 失败时的 curl verbose 日志、浏览器网络日志和代理服务端日志。
如果只想验证代理 IP 是否改变，先做 TCP/HTTPS 出口验收；如果要研究 HTTP/3，再单独验证 UDP 路径。把两个问题合并成“HTTP/3 越快越好”容易得出错误结论。
常见问题
HTTP代理能不能直接代理HTTP/3？
常见 HTTP 代理主要处理 TCP 和 CONNECT，不能因此推断具备 UDP/QUIC 转发能力。需要查看具体协议和客户端实现。
代理开启后从HTTP/3变成HTTP/2，是不是代理失效？
不一定。可能是 QUIC 不在代理能力范围内而发生回退；应比较出口 IP、CONNECT 日志和直连对照。
看到HTTP/3就能证明没有走代理吗？
不能。支持 UDP 的隧道或特殊客户端可以承载 QUIC；应按实际代理日志、出口地址和连接路径判断。
为什么同一页面有的资源走HTTP/3，有的走HTTP/2？
不同域名、连接复用、PAC 规则、地址族和缓存都可能造成差异。应按域名和请求逐条核对，而不是只看页面总状态。
