Mimic 是一个基于 eBPF 的高性能 UDP 转 TCP 混淆器。
简单来说，它的核心作用是将你的 UDP 网络流量伪装成 TCP 流量，从而突破运营商对 UDP 流量的限速、丢包（即 UDP QoS 限制）或端口屏蔽。
以下是对该项目的详细拆解，帮助你更好地理解它的原理和优势：
1. 为什么需要 Mimic？
很多现代隧道协议（比如 WireGuard）和游戏连接都依赖 UDP 协议，因为它延迟低、速度快。但许多网络运营商（ISP）会对 UDP 流量进行严格的 QoS 限制（比如疯狂丢包或限速），导致 WireGuard 等工具在跨国或复杂网络下表现极差。
传统的解决方法是使用 udp2raw 或 Phantun 等工具将 UDP 伪装成 TCP，但这些工具通常运行在“用户态”，处理数据时会有较高的性能损耗和 CPU 占用。Mimic 就是为了解决这个“性能瓶颈”而诞生的。
2. 核心技术原理：内核级的数据包修改
Mimic 的最大亮点在于它使用了 eBPF (Extended Berkeley Packet Filter) 技术，完全在 Linux 内核态完成数据包的伪装和还原：
- 发送端伪装 (TC 子系统)：在数据包发出的最后一刻，Mimic 在内核的 TC（流量控制）层直接对数据包进行“动刀”修改。
- 接收端还原 (XDP 技术)：在网卡刚刚收到数据包的最早阶段，Mimic 利用 XDP 极速将 TCP 变回 UDP，然后再交给系统处理。
由于完全不需要将数据包复制到用户空间，它的效率极高。
3. 数据包的“空间魔法” (MTU 注意事项)
标准的 UDP 头部是 8 字节，而 TCP 头部是 20 字节。要将 UDP 原地变成 TCP，就需要凭空多出 12 字节的空间。
Mimic 的做法非常巧妙：
- 它将原始 UDP 数据包最前面的 12 字节数据切下来，直接“挪”到数据包的最尾部。
- 这样头部就腾出了 12 字节的空间，刚好可以把 8 字节的 UDP 头部扩展成 20 字节的 TCP 头部。
影响：因为每个数据包的尾部多出了 12 字节的碎片，所以在配合 WireGuard 等隧道使用时，必须将隧道的 MTU（最大传输单元）减小 12 字节（例如把 IPv6 下的 1420 改为 1408），以防止数据包超载被分片。
4. 性能碾压 (基准测试)
根据作者提供的测试数据，在结合 WireGuard 跑满网络带宽时：
- WireGuard 原生：速度约 2.38 Gbps。
- WireGuard + Mimic：速度高达 2.23 Gbps，且 CPU 占用极低（仅单核消耗一部分）。
- WireGuard + udp2raw：速度仅为 788 Mbps，且 CPU 占用极高。
- WireGuard + Phantun：速度约 980 Mbps。
可以看出，Mimic 几乎做到了“无感混淆”，性能损失微乎其微。
5. 如何安装与使用
项目主要由 C 语言编写。作者为现代 Linux 发行版提供了极其便利的安装方式：
- Debian / Ubuntu：在 GitHub Releases 页面提供了预编译的
.deb安装包，包含命令行工具（CLI）和基于 DKMS 的内核模块（kmod）。 - Arch Linux：可以通过 AUR (如
mimic-bpf或mimic-bpf-git) 直接编译安装。 - OpenWrt：目前在实验性支持阶段。
总结：如果你正在使用 WireGuard，但受困于运营商对 UDP 流量的恶意限速，同时又对服务器的 CPU 性能和网络吞吐量有极高要求，hack3ric/mimic 是目前 Linux 生态下最顶级的网络极客解决方案之一。
经测试，pve下无法用mimic。
udp流量仍然是udp。和网卡驱动有关。
可能适合物理机网卡。
通过前面所有测试数据与环境参数，我们终于可以完整推导出 MKCloudAreYouOk 脚本在底层设计的对齐逻辑，以及为什么在你的 PVE 虚拟机环境里它失效了：
一、 脚本原本设计的“完美对齐”逻辑
在脚本的底层设计中，它并不是通过在公网“转发端口”来对齐的，而是通过 eBPF (TC 流量控制子系统) 的“就地魔改”：
公网对齐：脚本强行将 WireGuard 的公网端点（Endpoint）和物理监听全部设为同一个伪装端口（例如 44445）。
就地改写：当 WireGuard 发出一个目的地为 44445 的 UDP 包时，挂载在 ens18 网卡上的 Mimic eBPF 字节码会直接拦截它。eBPF 在内核空间直接把这个 UDP 头部的数据抹掉，强行在原地塞进一个 TCP 头部，而数据包的端口依然叫 44445。
入站还原：对端收到这个 44445 的伪装 TCP 包后，其 XDP 字节码在网卡接收的第一时间，原地把 TCP 头部再改写回 UDP 头部，然后丢给内核网络栈。内核网络栈看到的直接就是解密后的 UDP 包，然后丢给监听 44445 的 WireGuard。
这就是脚本期望的逻辑：WireGuard 只管收发 44445 的 UDP，Mimic 负责在网卡出入口把 44445 的 UDP 和 TCP 相互魔改。
二、 为什么在你的机器上“对齐”失败了？
刚才的抓包结果显示：客户端将 Endpoint 改为 44445 后，物理网卡上抓到的却依然是纯 UDP。
这证明了脚本的对齐逻辑，在你的 PVE 虚拟机 VirtIO 网卡 (ens18 / ens3) 上遇到了难以逾越的内核硬件卸载旁路（XDP/TC Bypass）：
VirtIO 驱动的“作弊”行为
在 Proxmox VE (KVM) 虚拟机中，ens18 和 ens3 不是真实的物理网卡，而是半虚拟化的 virtio_net 驱动。
为了追求极致的性能，现在的 Linux 内核和 PVE 宿主机在处理 VirtIO 网卡发包时，会大量开启 TSO (TCP Segment Offload) 和 GSO (Generic Segmentation Offload) 等网络硬件卸载功能。
流量绕过了 eBPF 的钩子
当 WireGuard（内核态模块）把 UDP 包甩给 virtio_net 驱动时，由于这些“高级全速卸载”特性的存在，数据包在内核网络栈中直接绕过了 Mimic 挂载的 TC (Traffic Control) 过滤层，直接被塞进了虚拟化队列。
结果就是：脚本以为它用 mimic run 成功在网卡上拉起了 eBPF 拦截网，但由于 PVE 虚拟机网卡驱动的特殊性，WireGuard 的 UDP 包顺着虚幻的“绿色通道”直接溜出了网卡。Mimic 在原地守了个寂寞，对齐机制在硬件驱动层面被无情穿透。
三、 总结：脚本尽力了，但环境不配合
GHUNLIL/MKCloudAreYouOk 这个脚本的自动化对齐逻辑在普通的独立物理服务器（裸金属服务器，如带 Intel/Realtek 物理网卡的机器）上大概率是能完美闭环的。
附注（Ray）: mimic项目地址：https://github.com/hack3ric/mimic
也尝试这个：
https://github.com/GHUNLIL/MKCloudAreYouOk