4G 移动网络下的 WireGuard 实测：延迟、吞吐与续航解析

• 在真实 4G 环境下测评 WireGuard：延迟、吞吐与续航的那些事
• 测试环境与方法概述
• 延迟：看似小的开销，放大在移动网络
• 吞吐：带宽本身不是瓶颈，拥塞与抖动才是问题
• 续航：VPN 会“吃”电，但关键在无线模块唤醒
• 实战中的常见问题与可行策略
• MTU 与分片
• Keepalive 策略
• 多路复用与并发
• 设备与实现差异
• 面向未来：5G 与 WireGuard 的关系

在真实 4G 环境下测评 WireGuard：延迟、吞吐与续航的那些事

把一套在光纤机房里表现良好的 VPN 配置搬到手机上的 4G 网络，结果常常出乎意料。移动网络的无线链路、调度延迟、基站的功耗策略以及运营商的中间件都会影响 WireGuard 性能。本文基于多次实测数据与网络原理分析，讨论在 4G 网络下 WireGuard 对延迟、吞吐和电池续航的实际表现和主要影响因素，并给出面向技术爱好者的实用洞见。

测试环境与方法概述

为了保证结论可复现，测试在以下场景下进行：

• 客户端：常见 Android 手机（中端 CPU）与 iPhone（对比测试），WireGuard 官方实现
• 网络环境：多地点 4G（不同小区、不同运营商），在室内弱覆盖与室外强覆盖两种典型场景取样
• 服务端：VPS（数据中心千兆上行），WireGuard 运行在 Linux，MTU 设为 1420 与 1500 两组对比
• 测试项目：往返时延（RTT）、TCP/UDP 吞吐（iPerf 类测试）、网页加载链路、以及手机端耗电曲线（放置运行 1 小时的功耗监控）
• 额外测项：不同 Keepalive 间隔对续航与连通性的影响；开启/关闭内核 offload 的对比

延迟：看似小的开销，放大在移动网络

WireGuard 的设计让握手和加解密开销非常轻量，但在 4G 环境，这些开销并非主导因素。实测结论：

• 基站调度与无线链路延迟是延迟的主因。常见 RTT 在 30–80ms 之间浮动，差异受基站负载和用户位置影响更大。
• 隧道封装带来的 MTU/分片问题会增加延迟抖动。当隧道 MTU 设置不合适导致分片时，单包重传代价高且抖动明显。
• 握手频率（Keepalive 与重新握手）若过高，会频繁唤醒基带，潜在引入额外延迟；但若过低，NAT 超时后首包可能抖动很大。

举例说明：相同位置与时间，直连 TCP SYN→ACK RTT 为约 40ms，开启 WireGuard 后增加 5–12ms（主要来自封装与内核加解密路径），但在弱覆盖区域，隧道导致的分片重传可使 RTT 突增至 200ms+。

吞吐：带宽本身不是瓶颈，拥塞与抖动才是问题

在 4G 网络中可获得的链路带宽通常能支持几十到数百 Mbps，但 WireGuard 在移动端的实际吞吐受多种因素影响：

• TCP 性能受链路抖动与丢包影响明显：移动链路的短时丢包会触发拥塞控制回退，导致总体吞吐低于链路速率。
• UDP 性能受分片限制：当内部数据包接近 MTU 上限时，封装后容易发生分片，分片丢失或重传导致吞吐大幅下降。
• 设备端 CPU 与加密开销在中低端手机上会成为限制因素，尤其在高带宽场景下 WireGuard 的加解密循环消耗不可忽视。

实测数据（典型案例）：在良好覆盖的 4G 下，WireGuard 的单流 TCP 实测吞吐约为直连的 60%–90%；UDP 在小包场景下常优于 TCP，但在有分片或丢包时下降更剧。多并发流可以部分掩盖单流拥塞回退带来的损失。

测试场景（示例）
- 直连 TCP 单流峰值：60 Mbps
- WireGuard TCP 单流峰值：42–55 Mbps
- 直连 UDP（大包）：80 Mbps
- WireGuard UDP（大包）：65–78 Mbps

续航：VPN 会“吃”电，但关键在无线模块唤醒

很多人认为 VPN 本身就是耗电大户。实际上，WireGuard 占用的 CPU 与加解密消耗是因素之一，但更关键的是它如何影响基带与射频模块的省电策略：

• 长期保持心跳/Keepalive 会频繁唤醒基带，尤其当间隔低于运营商的 DRX（Discontinuous Reception）周期时，基带将无法进入深度省电，耗电显著上升。
• 短时间的大流量传输虽然会增加瞬时功耗，但对整体续航的影响不如持续的小包频繁唤醒来得大。
• 实现优化方面，使用更合理的 Keepalive（例如 20–60 秒，根据 NAT 超时与应用需求折中）和合并上层心跳可以明显降低额外耗电。

实测结果表明：在保持活跃连接且有中等流量的日常使用场景中，开启 WireGuard 的手机电量消耗比直连增加约 8%–20%，差异取决于运营商、覆盖质量与 Keepalive 策略。在弱覆盖且需要频繁重传的情况下，差异可能更大。

实战中的常见问题与可行策略

MTU 与分片

避免分片是提升稳定性与降低延迟的重要手段。通过合理设置隧道 MTU（通常小于物理 MTU 减去封装开销）可以减少分片。移动网络上的 PMTUD 有时不可靠，保守设置能带来更稳定的体验。

Keepalive 策略

若主要用于浏览或短会话，适当延长 Keepalive 能显著节省电量；但用于实时应用（VoIP、远程桌面），需要更短的心跳避免 NAT 超时。结合应用层心跳（如应用本身有活跃流量时抑制 WireGuard 心跳）是较优的折中方案。

多路复用与并发

在 mobile→server 场景，使用多流可以减少单流拥塞退让带来的吞吐下降。对于需要高可靠性的场景，考虑在应用层实现多路并发请求来提高整体吞吐。

设备与实现差异

不同手机的加密性能、内核实现（如是否启用内核态 WireGuard）会影响结果。尽量使用内核实现以降低上下文切换和用户态开销。

面向未来：5G 与 WireGuard 的关系

5G 带来更低延迟和更高带宽，同时在网络切片与边缘计算上提供更多优化空间。对 WireGuard 来说，5G 可以显著减小无线链路带来的抖动与丢包，从而提升 TCP 吞吐与延迟表现。但续航方面，5G 在空口节能策略上仍需时间成熟，Keepalive 和唤醒问题依然值得关注。

总的来说，WireGuard 在 4G 环境下依然是优秀的轻量隧道选项，但要在移动场景获得最佳体验，需要针对 MTU、心跳策略和设备实现做出适配。理解移动网络的调度与省电机制，能让技术爱好者在保证性能的同时，把电量损耗控制在可接受范围内。