为什么QuickQ的WireGuard内网速度慢

本文目录导读：

1. CPU 瓶颈（最核心原因）
2. 虚拟化或驱动问题
3. MTU 值（最大传输单元）设置错误
4. 路由转发与防火墙大量记录
5. 客户端侧问题
6. QuickQ 固件或内核问题
7. 优先级排查方案

针对 QuickQ 的 WireGuard 内网速度慢的问题，通常不是协议本身的问题（WireGuard 本身效率很高），而是网络环境、设备性能、配置细节或软件实现上的原因。

以下是几个最可能的原因及排查方向：

CPU 瓶颈（最核心原因）

WireGuard 是纯软件加密，对 CPU 的单核性能要求极高，它不善于利用多核（多线程支持不如 OpenVPN 完善）。

• QuickQ 设备本身：QuickQ 通常是软路由或低功耗小主机，其 CPU（如 J4125、N5105 甚至更低）在软件加密时性能有限，如果内网带宽超过 500Mbps 或 1Gbps，CPU 可能 100% 满载成为瓶颈。
• 检查方法：在跑内网 iperf3 测试时，同时通过 top 或 Web 后台观察 CPU 使用率，如果某个核心 100%,那就是原因。

虚拟化或驱动问题

如果你是在 PVE、ESXi 或 Hyper-V 中运行的 QuickQ 虚拟机,问题更常见：

• 半虚拟化网卡（VirtIO）：如果未使用 VirtIO 驱动，而用了旧的 E1000 模拟网卡,性能会暴跌。
• CPU 穿透设置：虚拟机需要正确的 CPU 穿透设置才能支持硬件加速指令集（如 AES-NI）。
• 解决：确认虚拟机开启了 AES-NI 支持，并使用 VirtIO 网卡。

MTU 值（最大传输单元）设置错误

这是最常见的低级错误，WireGuard 的默认 MTU 是 1420 字节，但如果你的链路中存在额外的封装（如 PPPoE、IPv6 隧道、MSS 钳制）,会导致分片或重传。

• 内网环境：虽然是内网，但如果通过 QuickQ 访问其他内网段，经过路由器/交换机时如果存在 PPPoE，可能需要降低 MTU。
• 建议操作：在 QuickQ 和客户端（手机/电脑）的 WireGuard 配置中，将 MTU = 强制缩小到 1280 或 1450 测试，如果速度突增，MTU 问题。

路由转发与防火墙大量记录

• 反向路径过滤（rp_filter）：QuickQ 上的 Linux 系统开启了严格的反向路径过滤，非对称路由可能导致数据包被丢弃，表现为速度慢、丢包。
• connection tracking（连接追踪）：如果你在内网建立大量连接（BT 下载或 P2P），防火墙的连接追踪表可能会溢出,导致新连接创建缓慢。
• 解决：检查 QuickQ 的防火墙日志，临时关闭 rp_filter 或增大 conntrack 表格大小进行对比测试。

客户端侧问题

• 手机/电脑 CPU：老手机（如 4 年前的中低端机）或低功耗笔记本，单核性能无法解密高速 WireGuard 流量。
• 电源管理：电脑或手机开启了节能模式，限制了 CPU 频率。
• 干扰：不要在测试时同时开其他 VPN 或代理软件（如 Clash）。

QuickQ 固件或内核问题

• 内核版本：旧版 Linux 内核（低于 5.6）对 WireGuard 的支持可能不完整或性能较差。
• 快速转发：检查 QuickQ 后台是否开启了“快速转发”、“硬件 NAT”或“SFE（Shortcut Forwarding Engine）”，这些功能有时与 WireGuard 的加密路由冲突，造成数据在软件层和硬件层之间反复拷贝,反而变慢。

优先级排查方案

1. 立即测试：在 QuickQ 后台，直接将 WireGuard 配置的 MTU 改为 1280，重启服务,再测速。
2. CPU 检测：用 iperf3 打流（iperf3 -c 服务器IP -t 30 -b 0），观察 CPU 是否吃满。
3. 直连对比：不做 WireGuard 加密，直接用 iperf3 测 QuickQ 本身到客户端的转发性能（比如通过 LAN 口直接传文件），看速度是否一样慢，如果一样慢，那就是 QuickQ 本身硬件瓶颈或交换机网线问题；如果加密后速度慢,则是上述原因。

最后提醒：如果你发现 QuickQ 的 WireGuard 速度始终无法突破 几百 Mbps，而你的内网是 千兆或 2.5G，那基本可以断定是 CPU 算力不够 在跑满带宽的同时完成软件加密，解决方法是：换用支持硬件 VPN 加速的更高端软路由，或者在两端都使用支持硬件加密的设备（如苹果 M 系列芯片或高端路由器）。