这几年浏览器和视频网站越来越流畅，背后是传输协议在换代：HTTP/3 正在普及，底层用的是 QUIC。有朋友担心，新协议不按老套路走，代理 IP 是不是要没用了？这篇把两者的关系讲明白。
先认识 QUIC：跑在 UDP 上的新一代协议
传统 HTTP 版本都建立在 TCP 之上，要先三次握手、再加密握手，来回好几趟。QUIC 选择基于 UDP 自己实现可靠传输，把连接建立和加密合成一步，还能在网络切换时保持连接不中断。代价是它和“面向 TCP 的老代理”天然不在一个频道上。
传统代理为什么“不熟” QUIC
常见的 HTTP 代理、SOCKS5 代理，大多按 TCP 流的逻辑转发。QUIC 的报文是 UDP 包，很多代理默认不处理，于是浏览器检测到代理不支持，就会悄悄退回 HTTP/2，QUIC 的优势也就用不上了。
现状是：走代理时 QUIC 大多“优雅降级”成 HTTP/2，功能不受影响，但拿不到 QUIC 的提速红利。
三种情况，分别怎么看
- 完全不需要走代理：保持 QUIC 开启，享受握手提速
- 必须走代理出口：先确认代理是否支持 UDP 转发，不支持就接受降级到 HTTP/2
- 业务强依赖 UDP：选支持 UDP/QUIC 隧道能力的代理服务，或用隧道方式承接
和 IP 代理的关系
QUIC 解决的是“连接建立更快、网络切换更平滑”，代理解决的是“出口地址与身份可控”，两条赛道并不冲突：协议换代让握手变快，代理让出口稳定。真正要做的，是根据业务对 UDP 的依赖程度选对代理类型，而不是担心协议升级会淘汰代理——出口身份这件事，在任何协议下都绕不开。
一句话：QUIC/HTTP/3 快在握手，代理的价值在出口；协议换代不会淘汰代理，只会淘汰“不支持新协议还不自知”的配置。