@Avn

>Wine 把 Windows API 转换成 macOS API
>Rosetta 把 x86 指令转换成 ARM 指令
>它两个是不同级别的转译，一个是操作系统级别、一个是硬件级别，不是包含关系

这个说的没错

但是人家楼主明确说，要学的是 x86-64 -> ARM 指令转译。 你建议看 wine ，能学到 x86-64 -> ARM 转译吗？

wine 在 macos 上运行 底层还是靠 Rosetta 2 转译 并不是自己实现了类似技术

@cnbatch 我也遇到过类似的情况：

(有时候)1. 本来 udp 连接很快，但是过了几天会非常慢。如果重连换个连接就会快起来。

(其他有的时候)2. udp 刚连就很慢。如果手动反复重连，多试几次可以挑出来一个快(或者说丢包低)的 session 。然后可以保持快的速度很久。 (就好像底层有什么负载均衡机制，会把 udp session 分到不同的设备，反复手动重连可以“挑”出来一个快的设备）

>fec 然后疯狂发包就是了

别教别人乱搞 超过一定限度发越多丢越多

>我咋感觉现在这些欧洲国家没那么好拿永居。

对码农来说，

德国永居只要 27 个月（蓝卡途径），德语好可以更快； 爱尔兰 stamp4 只要两年。

主要难度是找到那边工作。

是那个 linnuxx 吗？ 我聊了两句发现有问题， 翻了下他 github 记录，发现了他在你的 issue 里骂人，然我直接把他 block 了：

https://github.com/wangyu-/udp2raw/issues/519

@fan88 我觉得我前面好像已经说过了啊

这个帖子里这么多人怼你，你不觉得自己理解和沟通上有一些问题吗

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/代理用