windows 下用虚拟机，能桥接就桥接，最简单。

不能桥接就从 windows DNAT 到虚拟机里 (windows 能不能 dnat icmp ，我不确定)

这个功能跟心跳检测的区别是什么？

>在半个小时内测了差不多 10 次，测试结果实在很诡异，有时端口全通，有时仅有个位数端口阻断，有时几十个、几百个，最多的一次竟然有一千多个！

感觉你说的现象，像是中间负责 UDP NAT 的设备 allocate 新端口处理不过来，或者是负责审查的设备跟不上新 udp session 建立。不像是故意这么搞你。

> 文档中确实提到对 UDP 没有任何的加速效果。
> 所以我想表达的是，他不只是没有加速效果，甚至是副作用更大

很正常，主要还是你理解不到位。

正常情况下如果套了不对的东西，就是套得越多越慢。

> @fan88 文档表达意思其实很清楚：它不保证 UDP 流量被代理后的品质。

对

>代码估计都没有针对 UDP 做任何事情，甚至额外的逻辑可能产生负优化。 这不是很正常的情况么？

实际可能更差。 我没看过代码，但是我猜 hy2 的 udp 是用 quic datagram 实现的。quic datagram 也是走拥塞控制的，比直接走 udp 还差。

本来 wireguard 是 udp ，wireguard 里面跑着 tcp ；现在 wireguard 外面又跑了层 quic 。tcp 跑在 quic 里面，两层拥塞控制，再慢也不奇怪。

不是有 udp 模式吗，觉得有反作用可以用 udp

>2 、我想到了多年前的 UDPspeed ，虽然他的主要目的并不是伪装而是抗丢包，但他内置了加密功能。我想知道他的内置加密功能足以对抗审查吗？

你内层流量已经是 wireguard 了， 数据安全已经由 wireguard 保障了。 你只需要伪装不需要强加密。udpspeeder 的 xor 也是一种伪装。 至于够不够用，自己试一试，以结果为准。

如果想要更强的伪装可以用 udp2raw, tcp 模式是加密混淆(aes+hmac) + 伪装成 tcp, udp 模式是仅加密混淆。

@duffercn 用 bridge 或者 host-only 网卡，运行在虚拟机里。 然后把公网 ip 的一个端口 dnat 到虚拟机里。

称不上完美。套壳 wireguard 实在没多少选择，这个帖子里提到的软件，除了 faketcp 类和 fec 类的，其他东西本来就不是设计用来 tunnel wireguard 的。

用 wireguard+ faketcp +fec 看似一套方案解决 tcp 和 udp 。 但是就 tcp 来说，这套方案没有魔改的拥塞控制, tcp 速度很可能比不上有魔改拥塞控制的方案。 但是 tcp 延迟相比大部分其他方案有优点，对打游戏什么的有帮助。

如果倾向 tcp 速度的话，不如 udp 走 faketcp+fec ，tcp 走别的(BBR, kcptun ，hy2)。

大概就像这个的图里面的： https://github.com/wangyu-/UDPspeeder/wiki/UDPspeeder---kcptun-finalspeed---%24%24-%E5%90%8C%E6%97%B6%E5%8A%A0%E9%80%9Ftcp%E5%92%8Cudp%E6%B5%81%E9%87%8F

另外，如果你想要 VPN 一样的接口的话，可以在 ss 基础上加个 socks2tun （或者类似的东西）,把 socks5“转成” VPN. (不支持 icmp)

据我了解，hy2 是魔改 quic ，手动控制拥塞控制，不能多倍发包。检测到丢包了再重传的不算多倍发包。

有多倍发包的是 net-speeder 这种纯多倍发包，或者是 kcptun-go udpspeeder 这种支持 fec 的。

> 按照出口带宽的现象推测：普通 ip 标准出口的带宽资源是有限的，除了 vip 线路其他共享一个带宽池，在超售带宽的前提下选择性丢包。hy2 这类的拥塞协议应该是通过多倍发包策略获得更多机会也别再大流量下有更好的表现
> udp qos 或者掐断应该是面向墙内一些 isp 自己的策略，推测是防止 udp 反射之类的 ddos 流量

所以你是想说，只考虑简单丢包的情况，不考虑别的情况。 那 wireguard over hy2 可能有一些意想不到的效果，也可能没有, 我不确定。

udp 简单丢包：
1. 如果上层只代理 tcp 。 那不如只用 hy2 ，不用 wireguard 。没有 tcp over tcp 的问题，底层 udp 有丢包，重传一下也就解决了；因为有激进的拥塞策略，速度可以保证，就是延迟会高。
2. 上层只代理 tcp ，对延迟还有要求。 那就用打开了 fec 的 kcptun ，延迟有改善，其他同 1
3. 上层要代理 udp ，这种情况才需要上 wireguard 。 先尝试用 faketcp ，看转成 tcp 丢包能不能降低，如果能问题解决。 如果不能，那就用 udpspeeder 加 fec 。 如果真的只是“简单”丢包，一般 fec 都可以解决；解决不了的话，很可能你的线路就不是简单丢包（参考下面）。

udp 非简单丢包（比如流量大了被掐断；再比如发得越多丢得越多）：
1. 上层只代理 tcp 。 那不如你试试 bbr 锐速这种，直接不走 udp 。
2. 上层要代理 udp 。 你试试转成 faketcp, 看问题能不能解决。 如果不能，那基本上没什么好办法了。 可以试一些非常规方案，比如不停换端口，但是别抱太大希望。 如果再解决不了，建议放弃这个线路。

>选个不稳定线路通过 udp over quic 等自带拥协议的用激进流控策略获得低延迟+大流量稳定性。

在 wireguard 下面增加一个可靠传输层，只会增加延迟，不会降低。

不太理解在有 udp qos 的情况下，udp over quic 或者 udp over kcp 解决了啥问题。 quic 和 kcp 底层还是 udp ，不管加了什么激进的流控策略，底层还是 udp 。

如果你说的 udp qos 只是简单的丢包，说不定有一些意想不到的效果。 如果你说的 udp qos 是断流或者有速率限制，那么你在上层做什么激进的策略也解决不了。

>自带流控、丢包重传的壳，选择很多。比如楼上提到的 Hysteria ，适合大流量传输；还有经典的 v2ray 和 xray-core ，走 UDP over TCP ；也可以用 KCPTube ，只不过这主要是为了抗丢包+低延迟的，大流量未必合适。

Hysteria 是 udp over Quic; v2ray 和 xray-core 是 udp over tcp; KCPTube 看描述应该是 udp over kcp

如果在 wireguard 里跑了 TCP, 就分别是 tcp over quic; tcp over tcp; tcp over kcp 。

还是有双重拥塞控制、head of line blocking 的问题。 只不过 over quic 和 over kcp 比 over 原生 kcp 在双重拥塞控制上好一点。 head of line blocking 完全无法避免。

你都提到 tcp over tcp 了不知道为啥还会考虑 4 ，4 一样有 tcp over tcp 。

>走 tcp 的话 fake-tcp 类（ udp2raw ，phantun ）无法使用正常 ss 类 tcp tunnel

为什么 4 个选项里没有：不使用机场路线，自己 vps 跑 faketcp

> wireguard+udp2raw
+1

udp2raw+ vpn 或者 udp2raw+ kcptun+ss 都能解决你的问题。udp2raw 很少单独用，一般都是配合其他 vpn/代理用

滋瓷

来滋瓷一个, 用 tun 实现很不错。

滋瓷一个

>使用 sstap 加速游戏时候，TCP 测试通过，UDP 转发失败

用 kcptun 和 UDPspeeder 并联,再和$$串联，可以解决

洛杉矶机房 3.5 刀的无货

@sunspaul

用了近一年了仍然很安稳，这个锅 udp2raw 和 UDPspeeder 不背。你还是想想自己是不是做了啥坏事让 IP 被重点照顾了吧。

一般直接在本地(非 VPS)开启 BBR 即可：

开启前：
debian9:~# scp -P10022 jdk-8u131-linux-x64.tar.gz 45.77.88.99:~
[email protected]'s password:
jdk-8u131-linux-x64.tar.gz 2% 4368KB 288.2KB/s 10:13 ETA^C

开启后(20m 宽带满速)：
root@debian9:~# ysctl -w net.ipv4.tcp_congestion_control=bbr
net.ipv4.tcp_congestion_control = bbr
root@debian9:~# scp -P10022 jdk-8u131-linux-x64.tar.gz 45.77.88.99:~
[email protected]'s password:
jdk-8u131-linux-x64.tar.gz 14% 26MB 2.1MB/s 01:11 ETA^

一般类似问题是丢包+tcp 拥塞控制造成的，然而很多人就是喜欢一上来就往墙 /加密 /混淆方面扯。