XUDP：VLESS & VMess & Mux UDP FullCone NAT

[RPRX]

#237 已阐明 V 系协议的 UoT 结构无法实现 FullCone，然而 Xray-core v1.3.0+ 却神奇地做到了本被认为是不可能的事情：

昨天的灵感，通过非常巧妙的机制实现了 V 系协议全部 FullCone，同时与旧版保持一定的兼容性。

这篇文章主要是说明原理及行为，以便其它软件的开发者实现这个 FullCone 方案。

前期探索

最初的思路是只能 breaking：设计新的 UoT 协议结构并通过某种方式启用，"encryption": "cone"、ID 非 UUID 等，但不优雅。

后来想到可以先用现有的 Mux 传递多地址端口信息：Xray-core 服务端可以识别出来特殊请求并按 FullCone 处理，Xray-core 客户端也可以判断出来请求是否被特殊处理了，因为返回的数据会采用新的 UoT 结构。这样完全不存在 breaking，但协议结构和处理逻辑上相对复杂、客户端还要维护目标二元组与子连接 ID 的双向映射关系、Mux 自身想 FullCone 却不好分配子连接 ID，还是不太优雅。

接着在我实现它的过程中，发现 Mux.Cool 协议 帧格式的 元数据长度 L 非常灵活，所以就有了最简单且优雅的解决方案：

扩展 Mux.Cool 协议 Keep 的元数据，使其像 New 一样带上 UDP 端口和地址信息，为方便交流，扩展后的协议命名为 XUDP。

因为它为 Mux 实现了 FullCone，顺便实现了 XUDP 原本的目标：UDP 聚合隧道，一箭双雕。

具体实现

1. 扩展 Xray-core 中的 Mux.Cool 协议，使其 frame/session、writer/reader、client/server 支持 XUDP，是真的简单改改即可。
2. 为 VLESS、VMess 出站准备了一份单独实现：https://github.com/XTLS/Xray-core/blob/main/common/xudp/xudp.go
3. Xray-core 的 VLESS、VMess 出站承载 UDP 时，会将指令和地址改为 Mux、端口改为 666，并使用上面单独实现的代码。

特性分析

1. Mux 本就是 VLESS、VMess 协议的 0x03 指令（TCP、UDP、Mux），Xray-core 和 v2fly-core 的服务端都支持它。
2. 客户端、服务端均为 Xray-core v1.3.0+ 时，VLESS、VMess、Mux 默认均为 FullCone。
3. 客户端为 Xray-core v1.3.0+、服务端为旧版 Xray-core 或 v2fly-core 时，它们的 UDP 行为类似于 Clash 的 VMess。

对于最后一种情况，简单来说查询 DNS、承载 QUIC、打中心服务器游戏等普通 UDP 应用是不受影响的，但不能用来打 P2P 游戏。
当然，本来也没人对 V 系协议的 P2P 抱有期待。若要完美 P2P，你应当都使用 Xray-core v1.3.0+。

至此，Xray-core 实现了全协议、全出入站、全传输方式完美支持 FullCone 🎉

[teddysun]

🎉🎉🎉前排撒花🎉🎉🎉
在此需要说明一点的是，当使用 Docker Image 时，需要使用 host 的网络（不能用端口映射）才能使用 UDP 的该特性。
Docker 容器的启动命令示例：
docker run -d --net host --name xray --restart=always -v /etc/xray:/etc/xray teddysun/xray

[lewisseng]

@teddysun 大哥能解释一下为何一定要host吗？如果改成host，路由/防火墙需要把这container全端口开放吗？

[CXwudi]

同求解释

[lbbboy]

🎉🎉🎉前排撒花🎉🎉🎉 在此需要说明一点的是，当使用 Docker Image 时，需要使用 host 的网络（不能用端口映射）才能使用 UDP 的该特性。 Docker 容器的启动命令示例： docker run -d --net host --name xray --restart=always -v /etc/xray:/etc/xray teddysun/xray

封的太快了咋办呀，都不能愉快的打游戏，fuckGFW

[lxsq]

同求解释

因为Docker使用Bridge网络时，会自动在iptables/nftables处添加一条MASQUERADE。相当于多了一层NAT。

[John-Smiths]

辛亏搜到你这句提示了，我这几天为了玩一个游戏各种socks5服务端都试了，无论如何都是完全锥形NAT，按你的提示改为host后终于玩上了

我使用Netch Socks5协议显示NoUDP 就是tcp可以但是udp不成功是socks5的问题吗?一般进入到大厅用tcp没问题,但是游戏内使用UDP就有问题了

[enihcam]

[AkinoKaede]

入站，测试可使用 NATTypeTester 等工具

[xiaoyaoyuxin]

入站，测试可使用 NATTypeTester 等工具

这个地方我没有搞明白，是要把这些端口全部放行，还是放行设定的端口（是不是VLESS协议监听的那个端口）？

经过测试，貌似要打开全部这些端口才有效。那么，会不会存在安全风险啊。

[DongfeiSay]

入站，测试可使用 NATTypeTester 等工具

不开放的话NATTypeTester第一次结果是PortRestrictedCone或者RestrictedCone，第二次及之后都是FullCone，这样在实际使用中会有什么影响吗？

[WuYouOwO]

如果你的服务器上没有部署重要业务，建议放行全部端口以避免各种奇奇怪怪的问题
如果你的服务器上有重要业务，建议放行高位端口(通常是60000-10000)

[TXIuTnVsbA]

我想问一下就是，我是用nginx转发vless的，而且还是https的，这个东西可以支持FullCone吗？我一个小白真的不懂

[AkinoKaede]

完全没有影响

[kxjhcmc]

使用了CDN有影响么

[RPRX]

无影响，但注意延迟

[Comah]

使用了CDN有影响么
延迟会更高

[kalagxw]

落地机开放UDP 高位端口（1024-65535），但路由中间经过iptables中转后（仅中转config里的port）， 有影响吗？

[dawnh]

服务端在用docker跑，想玩一下Full cone。想问一下docker方式必须使用host network，且开放所有UDP高端口这样的方式跑是不是因为必须以服务器本身IP接受UDP数据的原因？假如我要以Full cone方式跑的游戏是使用固定UDP端口的，我是不是可以docker容器加一个UDP同端口的-p映射即可？这样避免开放所有高端口，同时还无需host network？

[kyly1982]

我的服务端和客户端均是v1.4.2，需要怎么配置才能启用udp？

[iopq]

Found the sequel! Seems I need to fordward all of the high UDP ports to my machine

[oh-wind]

yep

[izeroo]

请问Vmess入站，Trojan出站，出站报错proxy/trojan: connection ends > read tcp 10.0.12.15:42656->2.58..:33251: read: connection reset by peer是因为nat的问题导致连接发起方无法接受到ack报文导致连接被rst了么

[izeroo]

已解决，outbound部分没有绕过出站节点导致被代理回环了

[iopq]

If the UDP packets have to be forwarded to the destination, does this stop working? v2raya does this automatically and I don't know if the issue is from this