解决 PVE (VirtIO) 虚拟化环境下的 UDP 阻断或限速问题

为了解决 PVE (VirtIO) 虚拟化环境下的 UDP 阻断或限速问题，如果你必须将 UDP 流量伪装或转换为真正的 TCP，目前业界有几种非常成熟、且完美兼容虚拟机的替代方案。

它们之所以能绕过 PVE 的死锁，是因为它们不使用内核层的 eBPF/TC 拦截机制，而是通过标准的网络栈或应用层进行代理与封装。

以下是主流的三个方案及其性能、延迟的深度对比：

方案一：Udp2raw（经典且强悍的物理层双向伪装）

这是最接近 Mimic 目的的方案。udp2raw 是一个运行在用户态、但通过 raw socket 直接在网卡层拦截和拼装报文的工具。

• 工作原理： 它在 WireGuard 的外层套一个壳。它会在公网上发起真正的 TCP 三次握手（用 raw socket 模拟），然后把 WireGuard 的 UDP 密文塞进这个合法 TCP 链接的 Payload（载荷）里发送。
• 为什么能兼容 PVE： 它不依赖 Linux 内核的 TC (Traffic Control) 钩子。它使用标准的 iptables/nftables 规则（加上 -j DROP 阻止本地内核干扰）直接抓取原始报文，因此 TSO/GSO 等 VirtIO 卸载完全不会穿透它。
• 性能与延迟影响：
• 延迟： 极低。由于是直接改写/拼装报文，只增加微秒级的封装延迟。
• 吞吐性能： 由于它运行在用户态，且需要对每个包进行双向的 TCP 状态机模拟，会消耗一定的 CPU 算力。在单核性能较强的机器上，跑满 200M~400Mbps 是它的极限，很难像你刚才那样裸跑飙到 1Gbps。

方案二：Phantun（基于 TUN 网卡的高性能 Rust 伪装）

这是一个较新的、用 Rust 编写的 UDP-over-TCP 伪装工具，专门为了解决 udp2raw 在高带宽下 CPU 瓶颈而生。

• 工作原理： 它在系统中创建两个虚拟的 TUN 网卡（客户端和服务端各一个）。WireGuard 的流量发往本地的 Phantun TUN 网卡，Phantun 在用户态用 Rust 将其转化为纯正的 TCP 流，发往公网。
• 为什么能兼容 PVE： TUN 网卡是标准的 Linux 网络设备，VirtIO 网络栈和 TCP/IP 栈会对 Phantun 伪装出的 TCP 流量进行标准的路由转发，Anycast 防护网关看到的是完美的、拥有真实拥塞控制的 TCP。
• 性能与延迟影响：
• 吞吐性能（极强）： 得益于 Rust 的异步运行时和极其优化的内存分发，Phantun 的吞吐量非常恐怖。在虚拟机环境下，它可以轻松压榨出 800Mbps~1Gbps 的极限带宽，甚至能喂饱你的 BBRv3。
• 延迟： 稍有增加。因为流量多经过了一层 TUN 网卡（内核态 $\rightarrow$ 用户态 $\rightarrow$ 内核态），会有微小的性能损耗，但在高质量 BGP 链路上基本无感。

方案三：WSTunnel / WebSockets (应用层标准封装)

将 UDP 流量彻底打包进标准的 WebSocket (TCP) 或者 HTTP/2 隧道中。

• 工作原理： 客户端将 WireGuard 的 UDP 包封装进标准的 WebSocket 帧中，通过 443 端口发送给服务端的 Caddy / Nginx 反向代理，再分发给服务端的 WSTunnel 解包。
• 为什么能兼容 PVE： 这是纯粹的应用层常规 TCP 流量，与任何虚拟化环境完美兼容。
• 性能与延迟影响：
• 吞吐性能： 中等（约 150M~300Mbps）。由于经过了多层用户态应用（WebSocket 封装 + TLS 加密 + 反代处理），CPU 密集型开销很大。
• 延迟： 明显增加。由于引入了标准的 TCP 窗口控制和 TLS 握手，延迟会叠加，不适合对实时性要求极高的 UDP 业务。

📊 方案对比一览表

💡 最终建议

如果你在未来某天发现原生 UDP 确实开始被 Anycast 防网关误杀，且你必须要走 TCP 伪装，请直接选择 Phantun。

它是目前在 PVE 环境下唯一既能保证 100% 兼容性，又能完美继承你 XanMod 内核 BBRv3 高带宽吞吐（逼近 1Gbps）的硬核方案。

附注（Ray）: 选这个了
https://github.com/dndx/phantun#server