如何公平地测试 VPN 延迟

VPN 会让数据多绕一段路。你的数据包先到达 VPN 服务器，在那里解密，然后再继续前往真正的目的地。玩在线游戏、参加视频会议，或者只是想让浏览器反应快一点的人，都想知道这段绕路要花多少毫秒。诚实的回答是"看情况"，而唯一能得到你自己答案的办法就是实际测量。问题在于，大多数自己动手做的测试并不公平：只 ping 几次、只测一次、只在某个时间段，然后拿去和另一个网络上得到的数字比较。

本文提供一套可以重复使用的 VPN 延迟测试方法，学生、远程办公者或游戏玩家用电脑自带的工具，不到一小时就能完成。它只关注延迟。如果想了解延迟本身是什么，请阅读 VPN 延迟详解；如果想知道 VPN 能否降低 ping，请看 VPN 能降低 ping 吗。这里我们专注于方法。

先明确你到底在测什么

延迟是一个小数据包到达目的地并返回所需的时间，称为往返时间（RTT）。它不是速度。一条下载速率很高的连接，如果每个请求都要等 200 毫秒，用起来依然很迟钝。Cloudflare 的延迟学习页面对这个基本概念有清楚的说明。

开启 VPN 后，你可以测三种不同的数字，把它们混在一起是糟糕结果的第一个来源。

测量对象	含义	何时有用
关闭 VPN 时到目的地的 RTT	你的正常路径	作为一切比较的基线
开启 VPN 时到目的地的 RTT	经过 VPN 服务器的路径	你真正感受到的数字
只到 VPN 服务器地址的 RTT	绕路的第一段	判断哪一段慢

前两行之差就是 VPN 开销，这是值得报告的数字。第三行帮助你解释原因：如果第一段本身就有 150 毫秒，隧道里的任何设置都无法修复它。

开始前，用一句话写下你的目标。例如："我想知道在晚上用家里的有线宽带与同事视频通话时，VPN 增加了多少延迟。"这样的句子会替你决定目的地、网络和时间段。

搭建公平的测试环境

只有当两次测试之间唯一的变化就是被测对象时，基准测试才公平。请准备以下内容。

1. 同一台设备。 每次都使用同一台笔记本或手机。关闭云同步、系统更新、下载工具和视频标签页，因为它们会占满上行带宽并抬高延迟。
2. 同一个网络，最好是有线。 Wi-Fi 会因干扰和信号变化带来随机延迟，网线能排除这个变量。之后你可以在 Wi-Fi 上重复测试，但不要把不同网络的结果放在同一个比较里。
3. 每次测试只用一台 VPN 服务器。 选择你平时会用的那台，并记下它的位置标签。如果想比较两个位置，就分成两次独立的测试。
4. 保持设置不变。 使用 VPN 应用的默认设置，中途不要切换连接类型，除非切换本身就是你要测的对象，并且要记录下来。
5. 记录表。 一个简单的电子表格甚至文本文件就行，列出日期、时间、网络、VPN 状态、目标、样本数、最小值、中位数、平均值、第 95 百分位、最大值和丢包率。

还要确认机器上没有别的东西以不同方式使用 VPN。如果启用了分应用隧道，要确保你测试的应用或工具真的走了隧道；什么是分应用隧道解释了为什么绕过隧道的应用会让 VPN 看起来快得可疑。

选择有意义的测试目标

只对一个地址做测试很脆弱。那个地址可能离你很远、很繁忙，或者被配置为对 ICMP 响应很慢。请选三到五个代表你真实使用情况的目标：

• 附近的公共 DNS 或基础设施地址。 它在对端距离最小的情况下反映 VPN 的成本。
• 你每天都访问的网站。 新闻、邮箱或公司门户。使用域名而不是记下来的 IP，这样用浏览器测试时 DNS 也是真实体验的一部分。
• 你真正关心的服务。 游戏服务器、会议服务，或团队使用的云区域。许多游戏和工具会公布测试地址或延迟显示，可以当作第二意见。
• 另一个大洲的远端目的地。 它能告诉你，对于长距离路线，VPN 路径和正常路径是否出现分歧。

每次测试使用同样的目标。如果某个目标不再响应 ping，要在基线和 VPN 两种条件下同时更换，而不是只换一边。

还有一点：普通的 ping 使用 ICMP 回显，有些网络对它的处理与网页流量不同。需要更准确时，也要测量应用层的请求，例如用浏览器开发者工具或带计时输出的命令行工具，测一个小网页的首字节时间。许多现代服务使用基于 UDP 的 QUIC（见 RFC 9000），所以基于 TCP 的测量不一定是应用实际遇到的情况。把 ping 当作指示，把应用层测量当作确认。

测量步骤，一步一步来

每次都按同样的顺序操作。下面是针对电脑的简单流程。

1. 预热。 在浏览器里先打开一次目标，让 DNS 缓存和路由建立起来。冷启动的第一次结果没有代表性。
2. 关闭 VPN 测基线。 对每个目标至少运行 100 个样本的 ping。macOS 或 Linux 上的命令是 ping -c 100 TARGET，Windows 上是 ping -n 100 TARGET。保存汇总行。
3. 对每个目标运行一次 traceroute（macOS/Linux 用 traceroute，Windows 用 tracert）并保留输出。它显示经过的各跳，之后可以据此判断路径是否变化。
4. 连接 VPN。 等待 20 到 30 秒，让连接稳定下来，初始密钥交换或重连完成。
5. 对同样的目标重复 ping 和 traceroute，样本数相同。
6. 断开连接，再测一次基线。 第二次基线能告诉你测试期间网络本身是否发生了漂移。如果两次基线相差超过大约 10% 到 15%，测试就不可靠，应丢弃并稍后重试。
7. 在三个时段重复整个流程：例如早上、下午和晚上，或者三个不同的日子。

如果想自动化，一个把时间戳和 ping 输出写入文件的简短 shell 循环就够了，不需要付费软件。需要的是让其他一切保持不变的自律。

记录的不只是平均值

平均值会掩盖真相。每种条件下至少记录以下数值：

• 最小值：大致是路径的物理下限（距离和设备）。
• 中位数：一半数据包比它更快。这是最诚实的"典型"数字。
• 平均值：便于比较，但对异常值敏感。
• 第 95 百分位：最慢 5% 的分界线，反映你在通话中感觉到的卡顿。
• 最大值：一次极端尖峰。记下来，但不要据此下结论。
• 抖动：相邻回复之间延迟的变化幅度。许多 ping 工具会输出标准差（mdev），可以作为抖动的快速估计。实际含义见 VPN 抖动。
• 丢包率：没有回复的请求所占百分比。即使 1% 到 2% 的丢包，对通话的伤害也可能超过多出的 20 毫秒；VPN 丢包有更深入的说明。

用一个例子来具体说明。设想一位远程办公者在晚上用有线宽带测量某个会议服务。

条件	最小	中位数	平均	P95	最大	丢包
关闭 VPN，第 1 轮	18 ms	21 ms	23 ms	34 ms	71 ms	0%
开启 VPN，第 1 轮	41 ms	46 ms	49 ms	78 ms	140 ms	0%
关闭 VPN（第 2 次基线）	18 ms	22 ms	23 ms	33 ms	65 ms	0%

两次基线吻合，所以测试有效。VPN 开销是中位数之差，约 24 毫秒；第 95 百分位的差约为 44 毫秒。对视频通话来说，这很舒适。对节奏很快的在线射击游戏，第 95 百分位比平均值更重要，78 毫秒再加尖峰就值得再看一眼。这些数字是为展示方法而虚构的例子，你自己的结果会不同。

解读结果，不要自欺

原始数字需要解释。用下面这份简短的检查清单。

先比较中位数，再看第 95 百分位。 如果中位数只差几毫秒，而且尾部有重叠，就当作平手。小于你自己多次测试之间波动的差异就是噪声。

看每一轮，而不只是汇总数据。 如果第 1 轮开销是 24 毫秒，第 3 轮是 60 毫秒，原因多半是某个时段的拥塞，可能在你这边，也可能在服务器那边，而不是 VPN 的设计问题。

利用 traceroute。 如果开启 VPN 后的路径先绕到很远的地区再回来，开销就是地理问题，正如 VPN 服务器距离中解释的那样。如果额外延迟出现在隧道之后的第一跳，则可能是服务器繁忙，或者你和它之间的网络状况不好。

检查是什么变了。 有时开启 VPN 后到某个目标的延迟反而下降，因为 VPN 提供方到该目的地的路由比你的网络运营商更直接。这确实可能发生，也是合理的结果，但它只适用于那一对网络和那个时间。不要把它推广成"VPN 能降低 ping"。

留意 ICMP 的特殊性。 如果通过隧道的 ping 与浏览器层面的测量差异大得离谱，请相信应用层的测量。有些网络对 ICMP 和网页流量的处理方式不同。

毁掉延迟测试的常见错误

• ping 四次就下结论。 某些系统的默认值是四次，这不是基准测试。
• 在不同时段比较。 晚间拥塞是真实存在的。基线与 VPN 的测量应相隔几分钟内完成。
• 在另一个房间用 Wi-Fi 测试。 信号变化会压倒一切。
• 忘记 VPN 曾经重连。 确认应用全程显示稳定连接。一次悄悄的重连会产生一个巨大的异常值。
• 选的目的地与 VPN 服务器在同一栋楼。 这会显示出不真实的小开销。请测你真正访问的地方。
• 在测试之间切换服务器。 两台不同的服务器就是两个不同的实验。
• 把某个提供方的宣传数字当成你的结果。 延迟是各人网络的本地问题，别人的数字不能搬到你家里。
• 忽略 DNS。 如果 DNS 查询经过很慢的解析器，即使 ping 正常，网页也会显得慢。浏览感觉慢时，请单独比较 DNS 查询时间。

结果偏高时的排查

如果开销比预期大，请按顺序处理下面的清单，每改一项就重新测一次。

1. 改用网线或靠近路由器，然后重新测量。
2. 暂停后台下载和云同步。
3. 重新连接，选择离目标或离你更近的服务器。位于去往目的地途中的服务器，比位于相反方向的服务器多绕的路更少。
4. 如果路由器已经运行了很久，重启一下，尤其是基线里就出现丢包时。
5. 关闭可能过滤同一流量的其他 VPN 或安全软件，冲突会带来延迟。如果连接掉线或卡住，VPN 连接不上和为什么我的 VPN 很慢提供了实用的解决办法。
6. 换一个时段再试。如果问题只在高峰期出现，原因多半是拥塞而不是配置。

做完这些步骤后，把剩下的差异看作在你的情况下绕路的真实成本。

可重复使用的测试模板

复制这份计划并按需调整。

• 目标句：一行，写明目的地、网络和时间。
• 目标：三到五个，所有条件下相同。
• 样本：每个目标、每种条件 100 个。
• 轮次：三轮，在不同时间。
• 顺序：基线、VPN、基线。
• 指标：最小值、中位数、平均值、第 95 百分位、最大值、偏差、丢包。
• 有效性规则：两次基线相差在 10% 到 15% 以内。
• 输出：每个目标的中位数开销和第 95 百分位开销，再加一句解释。

保留这份表格。更换路由器、宽带套餐或 VPN 服务器时，再运行同样的计划，拿同类数据比较。一个半年后还能重复的测试，比一个完美但无法重复的测试更有价值。

总结

公平的 VPN 延迟测试，是在关闭和开启 VPN 两种状态下，对同一设备、同一网络和同样的目标做比较：至少 100 个样本，多轮重复，用两次基线夹住 VPN 测量，并报告中位数和第 95 百分位，同时给出抖动和丢包。得到的是你自己情况下的开销，而不是通用排名，细微的差别通常只是噪声。如果想用短期预付通行证试一试，可以看看价格页面，然后在自己的网络上套用上面的模板。