VLESS Vision 拒掉 UDP 443 后真实 IP 泄露了怎么办
本文依据 Xray-core GitHub issue #7335（2026 年 11 月 5 日提交，复现版本 v26.10.31）整理，未在本地实测复现。issue 作者在开头猜测“很多 Claude 用户被封可能和这个 issue 有关”，那只是作者的推测，没有证据支撑，本文不采纳为结论。下面只写 issue 里有完整复现和对照的部分。
先说结论：先看你的客户端 flow 是不是普通 Vision
如果你用的是 VLESS + xtls-rprx-vision，同时路由里有一条默认 direct 兜底规则，那么 UDP 443 的流量（比如 QUIC / HTTP/3）在被 Vision 拒掉之后，后续包可能不再走代理，而是从你本机直连出去——对端看到的就是你的真实 IP。
issue 作者给出的临时规避办法是：只改客户端出站的 flow，改成 xtls-rprx-vision-udp443，服务端不用动。下面先讲清楚现象和复现，再讲怎么改。
现象长什么样
issue 作者的生产环境是这样：VLESS Encryption + XHTTP + Vision 的节点走 Cloudflare ECH（ALPN h3），客户端是 Linux 上的 v2rayN，用 Xray TUN 加域名分流。访问 openai.com 时被提示 Country, region, or territory not supported，而且页面上显示的是真实 IP。切到同一台服务器的另一条直连节点（VLESS + XHTTP + TLS，不带 Vision）后访问恢复，于是作者开始排查，最后定位到是 UDP 在 Vision 拒绝后走了客户端的 direct 出站。
为了排除 Cloudflare、ECH、v2rayN、TUN、IPv6 这些变量，作者又做了一套完全本机复现：服务端和客户端都只监听回环地址，curl 用 --http3-only 发两次相同的 HTTP/3 请求，目标是本机上的一个 UDP 接收器（127.0.0.2:443）。结果是：同一个客户端源端口先命中 proxy，被 Vision 拒绝后，又命中 direct；接收器收到了两个 1200 字节的 UDP 包，客户端日志里同时有对应的 direct 记录。
复现对照：只有普通 Vision 会漏
下面是 issue 里的受控对照表，各组用相同的密钥、UUID、XHTTP 路径、域名分流和默认 direct 规则，只改外层传输的 ALPN（h2/h3）和客户端 flow：
| 外层 ALPN | 客户端 flow | Vision 拒绝次数 | proxy 记录 | direct 记录 | 接收器收到包数 | 结论 |
|---|---|---|---|---|---|---|
| h2 | xtls-rprx-vision |
4 | 4 | 2 | 2 | 拒绝后由客户端直连 |
| h3 | xtls-rprx-vision |
4 | 4 | 2 | 2 | 拒绝后由客户端直连 |
| h2 | 空（服务端同步不启用 Vision） | 0 | 2 | 0 | 10 | 保持 proxy，服务端转发 |
| h3 | 空（服务端同步不启用 Vision） | 0 | 2 | 0 | 10 | 保持 proxy，服务端转发 |
| h2 | xtls-rprx-vision-udp443 |
0 | 2 | 0 | 10 | 保持 proxy，服务端转发 |
| h3 | xtls-rprx-vision-udp443 |
0 | 2 | 0 | 10 | 保持 proxy，服务端转发 |
对照还排除了几个干扰项，值得单独列出来：
- 普通 VLESS（
encryption=none）+ TLS + Vision 也复现，所以 VLESS Encryption 不是必要条件； - 完全移除 Cloudflare / ECH 后仍复现，所以不能把问题限定为 CDN 或 ECH 故障；
- 与 IPv6 无关；
- h2 和 h3 外层传输下都复现，不是 h3 特有的问题。
根因：拒绝之后，状态没了，包又重新分流了
issue 作者给出的分析是这样的（附了供维护者核对的代码路径，本文转述，不做独立判断）：
- 普通 Vision 遇到 UDP/443 会直接返回错误——Vision 本来就不处理 UDP/443，这一步是符合设计的；
- 但 UDP dispatcher 的状态关闭后，同一源端口的后续包会重新进入分流；
- 重新分流时嗅探不到域名，就按普通规则路由，最后落到默认 direct 规则上，于是包从本机直发。
所以问题的关键不在“Vision 拒了 UDP”，而在“被拒之后，本来已经判定要走代理的流量又被重新判定了一次，第二次判定丢了域名信息，就按默认规则直连了”。issue 里还提到了相关的旧 issue #6052（QUIC 阻断问题）和 #6057（Blackhole 修复），问维护者是否需要对 Vision 的拒绝分支做类似的丢弃或状态保留处理。
谁会中招
同时满足下面三条的，就在影响范围内：
- 客户端 VLESS 出站的 flow 是
xtls-rprx-vision（普通 Vision，不是-udp443后缀版）； - 有 UDP/443 的流量要走代理，最典型的是 QUIC / HTTP/3（比如访问 openai.com、Google 系服务时）；
- 客户端路由里存在默认 direct 规则（最后一条兜底是 direct），被拒的包才有地方可漏。
复现用的客户端和服务端都是 Xray-core v26.10.31。只看这份 issue，还不能确定更早的版本是否同样受影响，别急着给旧版本下结论。
临时规避办法：客户端 flow 改成 xtls-rprx-vision-udp443
issue 作者的对照结论是：客户端出站的 flow 改成 xtls-rprx-vision-udp443 后，h2 和 h3 两组都没有再出现泄漏路径。改法只有客户端一侧，服务端 clients 里的 flow 继续保持 xtls-rprx-vision 不变：
1 | "settings": { |
只改客户端 outbounds 里对应 VLESS 出站的 flow 这一项，其他配置（密钥、UUID、XHTTP 路径、TLS 设置）都不用动。
作者在 issue 里明确划了范围：这只是针对当前复现的对照结论，不声称该选项能消除所有域名嗅探失败或默认直连的风险。另一条路是完全去掉 Vision（对照组里空 flow 同样没有泄漏），但那等于放弃 Vision 的防护，改之前先想清楚自己要什么。
截至本文核查时（2026 年 11 月 6 日上午），issue 还没有官方确认，Xray-core 也没有发布包含修复的新版本，最新正式版仍是 v26.10.31。不要因为这一个 issue 就降级 Xray——v26.10.31 身上还有 MPTCP 的安全修复在，降级会把已修好的洞再打开。之前那篇讲升级后别降级的文章见升级 Xray 后 sing-box 连不上先别降级。
怎么自查自己有没有漏
- 看客户端的 access 日志：同一个源端口是不是先出现 proxy 记录、随后又出现 direct 记录。issue 的复现里就是这样确认的；
- 如果某个平时走代理的网站突然提示地区不支持、或者显示的 IP 变成了你 VPS 以外的地址，先别急着换节点，按上面三条对一下自己的配置。
另外注意：这个 issue 讲的是客户端一侧的路由泄漏，不是服务端配置问题。服务端日志里看不到直连的那几包，因为包根本没到服务端。
同一天的另一条 Vision 问题
同一天 Xray-core 还冒出另一个 Vision 相关 issue #7336：VLESS + xtls-rprx-vision + REALITY 服务端上，客户端开 Mux/XUDP（concurrency: -1，xudpConcurrency: 8）时，多个 UDP 会话同时发起会损坏下行，客户端日志报 common/mux: unknown status: <随机数>，之后该 mux 连接上的 XUDP 会话全部收不到回复。issue 里有完整复现和根因分析，修复 PR #7337 同日已提交，但发稿时还没有包含修复的新版本发布。这是另一个独立问题，本文不展开，只提醒一句：如果你正好是 Vision + Mux + XUDP 的组合，又遇到 UDP 会话批量丢回复，可以去看 #7336。
来源：