WireGuard 速度测试：应该测哪些指标

有人说"WireGuard 很快"，另一个人贴出一张数字惊人的截图，而你自己试了一下，却得到完全不同的结果。关于协议速度的比较常常失败，原因很简单：在没人控制的条件下只测了一项。某天单次测试得到的一个数字，只是一个故事，而不是测试。

本文介绍测试 WireGuard 隧道时值得测量哪些内容、如何设计可重复的测试、怎样解读结果，以及哪些错误会让数字产生误导。它适用于任何你有权测试的隧道。文中不声称任何服务使用 WireGuard 或某种特定协议，也不承诺任何速度。如果想先了解协议是什么，请阅读 什么是 VPN 协议。

为什么一个数字不能算速度测试

下载数字告诉你的是数据在几秒钟内达到的峰值速率。它无法告诉你通话是否会保持流畅，网页是否会迅速打开，或者隧道在切换网络后能否继续存活。这就像只看最高时速来评价一辆车。日常使用中你感受到的其实是别的：

• 网页多快开始加载；
• 语音和视频是否稳定；
• 游戏的响应是否灵敏；
• 大文件下载能否保持节奏；
• 手机或笔记本是否发热、电量是否掉得很快。

每一项都对应不同的测量。好的测试要选出与你关心的内容相符的指标，用可重复的方式收集，并与基线比较。

值得测量的六项指标

1. 吞吐量：下载和上传

每秒移动的数据量，单位为兆比特每秒。两个方向都要测。上传通常更低，对通话和文件分享很重要。报告多次运行的中位数，而不是最好的一次。

2. 空闲延迟

在没有其他流量时，一个小封包往返所需的时间，用 ping 测量。它主要由距离和路径决定。Cloudflare 对延迟的说明解释了它为什么与吞吐量是两回事。想了解隧道如何影响延迟，请读 VPN 能降低 ping 吗。

3. 负载下的延迟

在同时进行大文件下载或上传时再测一次 ping。如果数字从 30 毫秒跳到 400 毫秒，说明连接存在排队延迟，有时称为缓冲膨胀（bufferbloat）。这往往正是在测速成绩很好的线路上通话仍然卡顿的原因，很多人忘了测这一项。

4. 抖动

延迟在相邻封包之间的变化幅度。两条连接平均都是 40 毫秒，但在 20 到 80 毫秒之间摆动的那条，对通话和游戏来说糟得多。多数 ping 工具会给出范围或标准差，可以用来作为抖动指标。

5. 丢包率

从未到达的封包所占的百分比。哪怕只有百分之一二，也会损害实时流量并降低普通下载的吞吐量。用较长的 ping 测试，比如一百个封包，来观察。

6. 处理器占用

隧道在搬运数据时占用设备处理器的比例。它能说明限制来自设备还是网络。若隧道在中等速度就触到处理器上限，那么网络再好也不会更快。高占用还会消耗电量。

可选：连接时间与长时间稳定性

如果你经常切换网络，建立会话所需的时间就很重要。持续一小时以上的稳定性表明隧道能否经受休眠、漫游和地址变化。WireGuard 的会话设计得很轻，白皮书中也说明了简短握手是设计的一部分，但你的具体环境表现如何，仍需自己验证。

构建可重复的测试

别人，或者下周的你，按相同步骤能得到可比较的数字，这样的测试才可重复。

1. **选定一台设备和一个网络。**第一轮最好用网线。
2. **记录背景。**日期、时间、设备、操作系统、应用版本、网络类型、服务器位置。
3. **先做不走隧道的基线。**三次测速、一次一百个封包的 ping，以及下载时的 ping。记录中位数。
4. **连接隧道，**等待十秒让它稳定。
5. 开启隧道后做同样一套测试。
6. 吞吐量测试期间观察处理器。
7. **在另一个时段重复，**最好一个高峰、一个平峰。
8. **后续每轮只改一个变量，**比如服务器位置、网络或设备。

用简单的表格记下笔记。花几分钟记录，胜过之后猜上一个小时。关于泄漏和断网保护这些与速度无关的测试，见 如何测试 VPN。

可用的工具

• 浏览器测速提供吞吐量和延迟。它通常会同时打开多个连接，偏向于高速线路，并掩盖单数据流的行为。
• ping 提供延迟、抖动和丢包信息。估算丢包时，次数至少一百。
• 负载下延迟测试有些测速网站提供。如果你用的没有，就在进行大文件下载时运行 ping。
• iperf3 测量你控制的两台机器之间的原始吞吐量，例如笔记本与家中服务器或租用的机器。它避免了公网对目的地的影响，也可以测单流或多流。
• 系统活动监视器显示处理器占用、内存和网络吞吐量。
• **秒表加真实任务：**计时下载 500 MB、加载网页或上传大文件。真实任务能告诉你实际的感受。

一个计算示例

下面是一个虚构的例子，仅用于演示如何阅读一组结果。用户在用网线连接的笔记本上，把近处的隧道与普通连接作对比。

指标	无隧道	隧道，近处服务器	隧道，远处服务器
下载（3 次中位数）	220 Mbps	190 Mbps	105 Mbps
上传（3 次中位数）	45 Mbps	41 Mbps	28 Mbps
空闲延迟	12 ms	19 ms	180 ms
负载下延迟	38 ms	52 ms	330 ms
抖动（ping 范围）	1 至 3 ms	2 至 5 ms	8 至 40 ms
丢包（100 次 ping）	0%	0%	2%
测试期间处理器占用	不适用	22%	18%

解读：

• **近处服务器。**约为普通下载速度的 86%，额外延迟 7 毫秒，无丢包，处理器占用轻。结果健康。用户浏览时不会察觉，通话也正常。
• **远处服务器。**下载约减半，延迟高出十五倍，还出现了抖动和丢包。处理器占用更低，说明设备不是问题，问题在路径。这是位置不对的好隧道，而不是坏隧道。
• **处理器占用。**两个隧道都离设备极限很远。如果某一个已经达到 95% 而速度不再上升，那么设备就是瓶颈。

随之而来的决定很实际：通话和浏览用近处服务器，不要根据远处服务器的结果对协议下结论。

不同配置之间的公平比较

如果你要把 WireGuard 与其他方式比较，其他条件都要保持一致。

• **同一设备、同一网络、同一小时。**交替运行：配置 A、配置 B、配置 A、配置 B。
• **同一服务器区域，**如果可能的话同一台机器，前提是比较的是协议而不是路径。
• **其他设置相同：**DNS、封包大小、电池模式。
• **样本数量相同。**每种至少三次。
• **不要只看吞吐量。**吞吐量略低但抖动更稳的协议，实际感受可能更好。

想了解这两种最知名的协议在设计上有何不同，见 WireGuard 与 OpenVPN 对比。请记住，任何协议的性能都取决于实现、硬件和服务器，因此一次测试得出的一般性结论很少能适用于另一套环境。

会产生误导结果的陷阱

• 基线和隧道在不同时段测试。
• 一种情况用 Wi-Fi，另一种用网线。
• 拿隧道最好的结果与基线最差的结果比。
• **忘记后台流量：**备份、游戏更新、同步客户端。
• **使用与隧道出口在同一机房的测速服务器，**这会让结果好看得不真实。
• **用期望多流的工具去测单流，**或反过来。
• **忽略 CPU，**然后纳闷为什么更快的网络得到同样的数字。
• **把第一次结果当作典型。**第一轮往往包含慢启动的影响。
• **与网上的截图比较。**硬件、网络和服务器不同，那个数字对你没有意义。

结果不理想时的排查

如果隧道的表现远不如基线，请按顺序检查：

1. 换到近处的位置重新测试。
2. 重新连接，十秒后再测。
3. 从 Wi-Fi 改为网线，或坐到路由器旁边。
4. 查看处理器占用。如果接近极限，换更强的设备测试或关闭其他应用。
5. 用更长的 ping 检查丢包。丢包超过 1% 就应该换网络或位置。
6. 检查负载下的延迟。大幅跳升指向线路上的排队，而不是隧道。
7. 更新应用和系统软件。
8. 阅读更全面的清单 为什么我的 VPN 很慢，以及一般性说明 为什么开 VPN 后网速会变。

不过度解读结果

一次测试只测量一个时刻的一条路径。因此公平的结论应当谦逊："在这台笔记本、这个网络、这台服务器上，晚上时隧道保留了普通下载速度的约 85%，并增加了 7 毫秒。"这句话有用。"WireGuard 的速度是不用 VPN 的 85%"则不然。

还要记住，数字最好不等于体验最好。如果两个选项吞吐量相同，就选抖动和丢包更低的。如果一个选项稍慢一点，但在休眠和切换网络后能保持连接，这种稳定性比少掉的那些兆比特更有价值。

总结

要测好一条 WireGuard 隧道，请测量双向吞吐量、空闲延迟、负载下延迟、抖动、丢包率和处理器占用。先记录不走隧道的基线，每项测试在多个时段各跑多次，一次只改一个变量，并读取中位数。用结果来决定要调整什么，通常是服务器位置或网络，并小心不要把单次运行变成对协议的定论。

如果想用短期通行证练习这些测试，可在 价格页面 查看选项，免费的 VPNclient 应用在 下载页面。