为什么QuickQ的WireGuard ARQ重传太多

加速器 quickq 2026-05-25 1

本文目录导读：

为什么QuickQ的WireGuard ARQ重传太多-第1张图片-QuickQ官网 | 高速稳定下载-官网下载

链路质量差（最常见）
MTU 不匹配导致 IP 分片丢失
内核或驱动层面的 Buffer 溢出
WireGuard 对端密钥交换或握手问题
上层应用（TCP）的拥塞控制
特定于 QuickQ 设备或固件的 bug

QuickQ 的 WireGuard 出现大量 ARQ（自动重传请求）通常表明链路质量较差或配置存在不匹配，WireGuard 本身是一个轻量、高效的协议，它不包含复杂的拥塞控制或 ARQ 机制（这通常由 TCP 或上层应用处理），但数据包在传输层或物理层的重传（TCP 的重传、IP 分片丢失、或底层网络的重传）会被误认为是“WireGuard 的 ARQ 重传”。

如果你在 QuickQ 的日志或监控中看到大量重传（尤其是 WireGuard 隧道内的流量）,常见原因及解决方案如下：

链路质量差（最常见）

问题：Wi-Fi 信号弱、4G/5G 信号不稳定、物理线路丢包率高（例如跨运营商、国际链路）。
表现：UDP 数据包在传输过程中丢失，WireGuard 作为 UDP 封装，其上层（TCP 或应用）会触发重传。
解决：
- 检查客户端与服务器之间的 RTT（往返时延）和丢包率（使用 ping -c 100 -i 0.01 <服务器IP> 或 mtr）。
- 如果丢包率 >1%，考虑更换网络环境（例如从 Wi-Fi 切到有线，或切换 4G 基站）。
- 对于国际链路，使用加速服务（如 CN2、Warp 等）或降低 MTU（见下文）。

MTU 不匹配导致 IP 分片丢失

问题：WireGuard 默认 MTU 为 1420 字节，如果物理链路的 MTU 小于这个值（PPPoE 拨号为 1492，某些 VPN 或中间设备为 1400），数据包会被分片，分片后的任何一个片段丢失,整个数据包都会触发重传。
解决：
- 在 WireGuard 配置文件中 降低 MTU（例如设为 1280 或 1300）。
```
[Interface]
MTU = 1280
```
- 测试方法：从客户端 ping 服务器，设置 -M do -s 1472（不启用分片），看是否会报错“Frag needed”，如果报错，逐步降低 MTU。

内核或驱动层面的 Buffer 溢出

问题：某些设备（如低端路由器、树莓派、旧手机）的网卡驱动或内核网络栈处理能力不足，导致 UDP 包被丢弃（而非物理丢包）。
表现：CPU 占用高，日志中出现大量“buffer overflow”或“softnet backlog”。

解决：

调整系统参数：

# 增大 UDP 接收缓冲区
sysctl -w net.core.rmem_max=26214400
sysctl -w net.core.rmem_default=26214400
# 调整软中断处理（针对多核 CPU）
sysctl -w net.core.netdev_budget=600
sysctl -w net.core.netdev_budget_usecs=4000

如果使用 OpenWrt 或 QuickQ 设备，检查 CPU 是否降频或温度过高。

WireGuard 对端密钥交换或握手问题

问题：如果客户端长时间没有活动，WireGuard 会进入休眠状态，当数据再次发送时，会先进行一次密钥握手（1-RTT），此时如果握手包丢失,会导致数据包排队并触发重传。
解决：
- 在配置文件中启用 KeepAlive（定期发送心跳包保持连接活跃）：
```
[Peer]
PersistentKeepalive = 25  # 每 25 秒发送一个保活包
```
- 注意：频繁的 KeepAlive 会增加功耗和带宽,但可以减少突发重传。

上层应用（TCP）的拥塞控制

问题：WireGuard 下跑的是 TCP（HTTP、FTP、SSH），TCP 的重传会被 WireGuard 封装后再次重传，导致你看到大量“UDP 重传”。
解决：
- 启用 TCP BBR 拥塞控制算法（在客户端和服务器的系统层面）：
```
sysctl -w net.ipv4.tcp_congestion_control=bbr
sysctl -w net.core.default_qdisc=fq
```
- BBR 能更好地适应丢包环境,减少无谓的重传。

特定于 QuickQ 设备或固件的 bug

问题：某些定制版固件（如基于 OpenWrt 的 QuickQ）可能存在 UDP 处理优化不足或驱动 bug。
解决：
- 升级到最新的 QuickQ 固件。
- 尝试关闭硬件加速（如 NAT 加速、流量整形）后再测试。
- 在 QuickQ 的“高级设置”中，尝试启用 “UDP 缓存优化” 或 “降低 CPU 中断”。

先用 ping 和 mtr 确认底层网络：如果底层丢包 >1%，先解决 ISP 或 Wi-Fi 问题。
降低 MTU 到 1200-1280：这是最立竿见影的措施（尤其是通过 4G 或隧道嵌套）。
检查 KeepAlive 设置：确保 PersistentKeepalive 不为 0。
查看日志：在 QuickQ 后台或终端执行 logread | grep wireguard，检查是否有明确的“handshake failed”或“packet too big”错误。
更换端口：如果运营商（如中国移动）对 UDP 限速或限流，尝试使用 TCP 伪装（如通过 udp2raw 或 socat 将 WireGuard 封装成 TCP 443 端口）。