为什么开 VPN 会变慢？降速多少才算正常

一打开 VPN，网页就变沉了，视频开始转圈缓冲，通话也断断续续。这正常吗，还是哪里出了问题？有一定程度的变慢是意料之中的，因为 VPN 确实改变了数据走的路径，也改变了数据包本身。但如果损失很大，通常是某个具体原因造成的——最常见的是服务器太远或负载过高——而不是"VPN 这种东西"本身的问题。下面讲清四大原因，并教你测出自己实际损失了多少。

核心要点

• 拖慢 VPN 连接的有四个因素： 经由 VPN 服务器绕行带来的更长路径、每个数据包多出来的头部开销、你的设备或路由器上的加密运算，以及服务器及其上游链路的负载。
• 不存在通用的"正常降速比例"。 任何一个适用于所有 VPN 的数字都是编出来的；你的损失取决于所用服务器、协议、设备和运营商。
• 延迟和吞吐量是两种不同的损失。 距离主要影响延迟；开销、CPU 和服务器负载主要影响吞吐量。
• 自己动手测： 同一个测速服务器，先关 VPN 再开 VPN，各跑多次，分别比较延迟和吞吐量。
• VPN 改变的是你的 IP，而不是浏览器指纹——而且有些网站会因此对你起疑。

1. 额外的距离：经 VPN 服务器绕一圈

不用 VPN 时，数据包按运营商选的路由从你的设备直达网站。用了 VPN，数据包要先到 VPN 服务器，再从服务器到网站，回程也原路返回。如果服务器在另一个国家，这段绕行就会增加往返时间，任何软件都消除不了：光纤中信号的传播速度有上限，所以距离给延迟设定了一个下限。

这一点的影响比多数人想象的更大，因为单条连接的吞吐量同样取决于延迟。TCP 连接在必须等待确认之前，能在途中保持的数据量是有限的，所以往返时间越长，同样的带宽能给单条连接带来的速度就越低。在同一套餐下，近处的服务器往往比远处的快得多。

2. 封装开销与 MTU 问题

隧道会把你的每个数据包再包进另一个数据包里。这层外壳——新的 IP 头、UDP 或 TCP 头，加上 VPN 协议自己的头部和认证数据——要占用空间，所以每个数据包能携带的实际数据就少了一点。在正常配置下，这对速度的影响通常不大。

更棘手的是 MTU（最大传输单元，即链路能承载的最大数据包）。普通以太网路径通常允许 1500 字节，但隧道的外壳也得装进这个范围内，因此隧道内可用的大小更小。数据包过大就必须分片，或者被丢弃。RFC 4459 描述了网络内隧道带来的这类 MTU 与分片问题。当路径上的某台设备悄悄丢弃超大数据包、发送方又得不到任何通知时，连接就可能卡死或慢如蜗牛：小请求正常，大文件传输却挂起，有些网站只加载一半。这就是经典的"黑洞"故障。

现代协议栈会尝试自动找出可用的大小。RFC 8899 定义了分组化层路径 MTU 发现（PLPMTUD），它通过探测找出真正能通过的最大尺寸，而不是依赖常被防火墙拦截的错误消息。想通俗了解路径 MTU 发现在实践中如何工作又如何失效，可以看 Cloudflare 的这篇解读。如果 VPN 只在访问某些网站或下载大文件时异常缓慢，MTU 设置过高就是典型的嫌疑对象，在客户端中调低隧道 MTU 是常见的解决办法。

隧道本身跑在哪种传输协议上也有影响。大多数现代 VPN 协议，比如 WireGuard 和默认 UDP 模式下的 OpenVPN，都通过 UDP 承载你的流量。有些客户端为了穿过严格的防火墙会退回 TCP 模式，这时你自己的 TCP 连接就跑在另一条 TCP 连接里面。一旦丢包，内外两层会同时重传、同时降速，少量丢包也可能被放大成明显的卡顿。如果客户端允许选择，UDP 通常更快。

3. 加密要消耗 CPU

每个数据包在发出前都要加密，到达后要解密。在现代笔记本或手机上，这点开销很小，许多 CPU 还对常见加密算法提供硬件加速。但在老旧手机、自己运行 VPN 客户端的低功耗路由器或繁忙的单核设备上，加密运算可能成为瓶颈，把吞吐量压在远低于线路速度的水平。一个典型迹象是：传输时 CPU 占用飙高，即使连的是近处的服务器，速度也始终达不到套餐标称的速率。

4. 服务器负载与服务商的上游链路

VPN 服务器是共享的。如果同时有很多人在用，或者它通往更广阔互联网的链路发生拥塞，你只能分到剩下的那一份。服务商自己到目标网站的路由也很关键：一台离你很近、但与你要访问的网站连接很差的服务器，照样会很慢。这就是为什么换一台服务器——哪怕在同一个城市——速度有时会天差地别。

降速多少才算正常？

对任何通用数字都要保持怀疑。对你来说什么算正常，几分钟就能测出来：

1. 选定一种测试方式并保持不变。 使用同一个测速服务器、同一台设备、同一个网络，这样唯一变化的就是 VPN。
2. 先关 VPN 再开 VPN 各测一遍。 使用 BrowserInsight 的网络测速，它能在浏览器中测出下载、上传、延迟和抖动。每种状态至少跑三次；单次结果只是快照，不是定论（参见为什么测速结果总在变）。
3. 分别比较延迟和吞吐量。 延迟升高而下载速度相近，指向距离问题；下载速度大幅下降而延迟变化不大，则指向开销、CPU 或服务器负载。M-Lab 开放的 NDT 测试是另一种独立交叉验证吞吐量的方式。
4. 一次只改变一个变量。 先换近一点的服务器，再换协议（或把 TCP 模式改成 UDP），再调低 MTU，每次改完都重新测。

如果你不确定这些数字意味着什么，网速指标详解讲解了带宽、延迟和抖动，上传与下载速度则解释了为什么两个方向的速度常常不一样，所以要分开比较。如果别人一占用网络，你的通话就变差，那多半根本不是 VPN 的问题，而是缓冲区膨胀；如果是时断时续、而不是整体变慢，请看抖动与丢包。

也要清楚测速能告诉你什么、不能告诉你什么。它测的是你的浏览器到本站边缘节点之间的路径，所以能反映开关 VPN 时你的连接有多快，但它不会检测 VPN，也不会测量你的 MTU。

VPN 能让网络变快吗？

偶尔可以。如果运营商对某些流量限速，或者它到某个目的地的默认路由很差，隧道可以绕开这个问题，速度反而会提升。这种情况有可能出现，但并不常见，只有在你自己的前后对比测试确实显示如此时才值得相信。

关于隐私的提示

VPN 改变的是网站看到的 IP 地址；它不会改变你的浏览器指纹，而且有些网站会对 VPN 地址心存戒备。想知道各种工具究竟隐藏了什么，请看隐私工具对比；想知道网站如何识别 VPN 流量，请看网站如何检测 VPN。要查看连接后网站眼中的你是什么样子，可以运行 VPN 检测。

常见问题

我的 VPN 怎么突然变得这么慢？

大多数突然的变化源于服务器：它变得拥挤，或者上游发生了拥塞。先换一台服务器，重新做一遍前后对比测试，再去动别的设置。

用 VPN 一定会降低速度吗？

通常会增加一些延迟，因为路径变长了。在近处、负载较轻的服务器上，吞吐量损失可以很小；在远处或过载的服务器上则可能很大。

为什么小网页能打开，大文件下载却卡住？

这种现象通常指向 MTU 问题：小数据包能通过，大数据包被丢弃。试试调低隧道的 MTU 设置。

用有线连接配 VPN 会更好吗？

有线连接能排除测试中 Wi-Fi 的波动，让你的 VPN 对比更干净，但它解决不了服务器太远的问题。

总结

VPN 拖慢网速有四个原因：距离、隧道开销、加密运算和服务器负载。具体慢多少取决于你的环境，所以请分别在关闭和开启 VPN 的状态下测量，并把延迟与吞吐量分开看。然后一次只改一个变量——通常先从换服务器开始。