HTTP/3 请求需要一条支持 UDP 的代理路径
区分 HTTP/3 的 QUIC 传输、普通 HTTP CONNECT 的 TCP 隧道，以及 SOCKS5 服务可选的 UDP 支持。
客户端通过 TCP 代理成功访问 HTTPS，并不等于为 HTTP/3 建立了通路。HTTP/3 使用 QUIC，而 QUIC 使用 UDP。
普通的 HTTP CONNECT 隧道只提供到目标的 TCP 字节流。即使 URL 以 HTTPS 开头，或目标监听 443 端口，它也不会变成 UDP 中继。
SOCKS5 同样需要 UDP 路径
SOCKS5 定义了 UDP 关联，但客户端与服务端都必须实现它，而且中继端必须可达。一个只暴露 SOCKS TCP 拨号器的库，并不会因为类型名写着 SOCKS5 就能提供数据报传输。
同样，工具中名为 proxy 的组件可能只是开发用的丢包模拟器，而非通用的上游代理客户端。应检查它真实的接口与所支持的传输。
CONNECT-UDP 等标准定义了通过 HTTP 代理体系承载 UDP 的另一种方式。它们需要两端都支持，不应与传统 CONNECT 混为一谈。
如果 HTTP 客户端回退到基于 TCP 的 HTTP/2 或 HTTP/1.1，请求可以经普通代理成功，而全程并未使用 HTTP/3 连接。当这一区别重要时，请记录协商出的协议。
因此有用的兼容性问题很具体：这个客户端能否用这种受支持的机制，把它的 QUIC 数据报透过这个代理送出去？一个能打开的浏览器页面或一次 TCP 端口检查，回答的是更小的问题。