造了个试验品，利用频繁更换端口的方式来躲避运营商的 UDP 限速

[cnbatch]

为了解决 UDP 限速，目前比较常用的做法是将 UDP 流量伪装成 TCP 流量。

我就想，能否不伪装，继续用 UDP 规避限速？
或许可以，我记得有人提到过，UDP 被限速后只要重新连接，速度就会重新恢复。
这么看来，只要四元组的其中一项发生变化就能打破限速。

于是我造了个试验品，作用类似于 wangyu 的 udp2raw （以及还有 Phantun ），只不过这个试验品全程保持 UDP ，每隔一段时间就自动更换端口。而且是客户端主动更换，无须通知服务器。即使服务器那边使用固定端口，客户端也会建立新的连接连过去。
同时，服务器端也支持同时监听多个端口（可以指定一个范围），让客户端新建连接时可以随机选择目标端口。

试验品在这：
https://github.com/cnbatch/udphop

目前支持三大平台，并提供这三大平台的 x64 可执行文件：
FreeBSD
Windows
Linux

听说重灾区在中国移动，但因为我没开通中国移动的家宽，所以没法在中移动家宽网络内试验。
试过用广东移动的手机网来试验，iperf3 从广东电信家宽发送到广东移动手机（包括手机开启热点给笔记本电脑做测试），发现 UDP 直接被堵死了，收都收不到； UDP 从广东移动手机（及热点下的笔记本电脑）发往电信家宽倒是可以；至于 TCP ，双向畅通无阻。但这样就等于无法开展测试，因为 UDP 无法双向通信。

[unnamedhao]

纯好奇，udp 怎么伪装成 tcp ，ip 包的类型字段就不同

[wangyucn]

滋瓷

[cnbatch]

@unnamedhao 可以问问你楼下的这位资深 UDP 限速破解专家，他就是 udp2raw 的作者

@wangyucn 果然是资深 UDP 限速破解专家，平时几乎不出现，只要有人发帖的内容跟运营商的 UDP 限速相关就基本会出现😆

[XiaoxiaoPu]

跳端口频率较快时，可能会给光猫等设备的 NAT 造成较大压力，导致其他使用 UDP 的应用（例如即时语音、视频）出现网络问题

[XiaoxiaoPu]

把一个 UDP session 拆成多个是不是也可能有效果？

[swxk521]

hysteria 的端口跳跃，和你说的功能一样吧，用这好多了

[cnbatch]

@XiaoxiaoPu
@swxk521
其实我是受到 v2ray 的启发，v2ray 很早就支持了 UDP 动态端口的功能，比起 hysteria 和 kcptun 还要早得多。
它们甚至有并行 session 的设置，多条 UDP session 一起来。
只不过它们并非单纯的简单转发，而是另有传输协议（ v2ray 用的是 vmess + mkcp ，kcptun 顾名思义就是 kcp ，hysteria 用魔改版 QUIC ），效果自然不一样，它们都可以顺便对抗拥塞丢包。

当然了，多一个选择总没坏处，我就是打算单纯转发数据，因为部分场景不太需要对抗拥塞丢包（比如墙内跨运营商 VPN 回家）。
我个人的使用情况是，联通↔电信这样用的效果不错，这两家运营商互联基本上极少拥塞导致的丢包，倒是特别需要对付 UDP 限速。

一条 UDP Session 拆成多个，这也是个好办法，只要每一条 Session 的数据量不是太大的话，应该也不会被限速策略盯上

[brMu]

@wangyucn 来膜拜一下大佬

[jousca]

是个好办法。

我是中移动家宽，其实中移动还好（成都移动），成都电信家宽会这个操作。封 UDP

电信专线不会。

[Zy143L]

目前来看移动 UDP 同网没啥问题
异网流量才有 UDP 限制的毛病

[a9k1n9]

qos 不是以 IP 限制的吗？躲得过初一，躲不过十五～

[benwjrumd]

Hysteria 也支持咯

[yulon]

按我几年前实验的结果，需要多 IP ，端口只是数据包里面的一个数字，只要发往同一个 IP ，就没多大区别，有时候可能还会变慢，因为多个端口收到数据后要同步与合并

[lly8666]

请问支持动态域名自动解析重连么？

[bclerdx]

@jousca 成都电信会怎么封 UPD ，为何电线专线不会？

[smartisan2047]

@jousca 我成都电信没遇到过封 UDP ，电信-移动跨网 UDP 也没太大问题

[emma3]

V2ray 的 mkcp 插件，好像很早就已经支持动态端口了，一直不太知道有什么用。

[cnbatch]

@lly8666 支持，每次更换端口时会自动扫一次。

如果数据一直传输不间断的话，它可以自动跟踪新的 IP ，所以理论上不用动态域名只填 IP 地址也能跟踪新 IP 的变化。
之所以这样做，主要是用于 STUN 给 NAT 打洞的场景，毕竟 NAT 打洞获得的新端口并不固定，这就必须自动跟踪了。

[cnbatch]

@emma3 在 7 楼那里我就提到过是受到 v2ray 的启发，因为我就用这个功能用了很长时间。
好处是爬梯时减少端口被封的概率，也能减轻 UDP 限速的影响。
只不过 v2ray 的方案不太完美，必须指定固定的主端口，一旦主端口被 ban 那就无法通讯。主端口受到严重限速时也会影响更换端口时的稳定性。

影响最大的还是 NAT 打洞，墙内想要打洞互联的话，靠 v2ray 做底层传输就不适合了。

[aru]

最后相当于提供了一个 socks5 服务么？