被 99% 的人忽视的 HTTP/3 真实 IP 裸奔陷阱

先说结论：HTTP/3 可能会导致真实 IP 泄露。

Notebook 自从更名为 Gemini Notebook 后，就出现了一个问题，访问 https://notebook.google.com/ 的时候会被重定向到 https://notebook.google/?location=unsupported，导致完全无法正常使用。

这个重定向的意思非常明确了，不支持区域。检查了网络，全部都是正常转发，没有任何问题。

再想想之前反复发生的谷歌账号所属地域重置，明明网络各方面都没有问题，还是被精准定位到了。

今天抽空详细梳理了一下，找到了根本原因 —— HTTP/3。

Web 发展了几十年，从 HTTP/1.0、HTTP/1.1 到 HTTP/2，底层全都是基于 TCP 建立连接。而 HTTP/3，底层彻底抛弃了 TCP，换成了基于 UDP 的 QUIC 协议。

目前绝大部分的上网方法都主要处理的 TCP 流量，特别是价格便宜的，根本不支持 UDP。部分支持 UDP 的，也会添加一个说明「支持基础的UDP转发，不保证使用效果」。

这时候问题就出现了，无论是浏览器还是软件，访问的服务端支持 HTTP/3，就会尝试先走 UDP。

如果本地没有限制，网络那边不做处理，UDP 数据包就会直连服务器，这时候真实 IP 直接就暴露了。

这种情况，即便本地开了 TUN 虚拟网卡，使用指纹浏览器，使用模拟环境，都是治标不治本，一整个坑基本就和 WebRTC 差不多。

了解到这个后，绕过的方法就很直接了，直接在本地拒绝 UDP，这样请求会自动降级为 HTTP/2。

浏览器，在地址栏输入 chrome://flags/#enable-quic，在打开的实验特性列表里找到 Experimental QUIC protocol，把它从 Default 改成 Disabled，然后重启浏览器。

关闭之后，浏览器对外发起的所有请求都会被限制在 HTTP/2 和 HTTP/1.1，完全走 TCP。对于普通日常使用来说，因为 TCP 握手只比 QUIC 多了几十毫秒，在实际体验中根本感觉不到任何速度差异。

本机网络，这是一劳永逸的办法，可以防止整机的 UDP 流量暴露真实 IP。

以使用 Mihomo 内核的客户端为例，在正在使用的订阅扩展规则最顶部添加一行拒绝规则：

prepend:
  - AND,((DST-PORT,443),(NETWORK,UDP)),REJECT

这行规则的意思是，只要检测到目标端口是 443 且网络协议是 UDP 的数据包，客户端内核直接在本地把连接掐断。

改完配置后，可以打开 Cloudflare 的官方测试网站 cloudflare-quic.com。

按 F12 打开开发者工具，切到网络面板，在表头右键勾选协议列。

如果拦截成功，你会发现即便服务端返回了包含 h3 的升级声明，页面主文档和所有静态资源的协议列依然会维持在 h2，这就表示拦截成功了。

以上内容，可以完全让 AI 代劳。

HTTP/3 只是我实际经历遇到的原因，并不代表解决了就不会被风控。