VPN 速度为什么达不到宽带标称值：先接受“有损耗”这件事
连上 VPN 之后，速度比直连低，是正常现象。数据包要先到达接入点、再转发到目标服务器，路径变长，每个包还要额外封装和加解密；再加上线路拥堵和本地网络状况，最终速度通常只是宽带标称值的一部分。真正需要关心的，不是“有没有损耗”，而是损耗落在哪一段、能不能降下来。这篇文章把常见的损耗来源拆成五类，用简单的算例说明原理，并给出由易到难的排查顺序。
五类常见的损耗来源
| 来源 | 机制 | 可以调整的地方 |
|---|---|---|
| 往返时延 | 距离越远，一次确认往返越久，单连接吞吐受窗口限制 | 选择更近的线路，使用多线程下载 |
| 封装开销 | 每个数据包额外增加头部，有效载荷变小 | 调整 MTU，避免分片 |
| 加密计算 | CPU 要对每个包加解密，没有硬件加速时容易成为瓶颈 | 换用更适合当前设备的协议 |
| 线路拥堵 | 高峰时段接入点或国际出口带宽被占满 | 换时段、换线路 |
| 本地网络 | Wi-Fi 信号弱、路由器性能不足 | 改用有线，靠近路由器 |
往返时延：为什么“距离”会直接限制单连接速度
TCP 连接的吞吐上限大致等于窗口大小除以往返时延。举一个纯算术的例子：假设窗口是 64 KB，往返时延是 200 毫秒，那么单连接吞吐上限约为 64×1024×8÷0.2，大约 2.6 Mbps，与宽带有多快没有关系。现代系统有窗口缩放机制，实际数字会高得多，但这个例子说明了一件事：同样的宽带，线路越远，单连接越难跑满，多线程下载往往比单线程更快。
封装开销：为什么 WireGuard 的默认 MTU 是 1420
以太网的常规 MTU 是 1500 字节。WireGuard 在 IPv4 上再套一层 UDP 时，额外增加约 60 字节头部；如果隧道跑在 IPv6 上，则是 80 字节。为了让两种情况都不触发分片，常见的默认值取了 1420。如果你的网络路径上有 PPPoE 拨号（常见于家庭宽带）或其他隧道，可用 MTU 还会更小，设置过大就会出现分片或丢包。
加密计算：设备能力不同，结果也不同
电脑和较新的手机 CPU 通常带有 AES 硬件加速，加解密几乎不占资源；性能较弱的旧手机、旧路由器则不然。这类设备上，不依赖 AES 硬件指令的 ChaCha20 算法往往更有优势，这也是 WireGuard 在这类设备上表现更好的原因之一。如果你在路由器上跑隧道，发现 CPU 占用接近满负荷而速度上不去，瓶颈多半在这里。
排查顺序：由易到难，一次只改一处
- 先在未连接 VPN 的状态下测一次本地速度，记录结果，作为对照。
- 手机或笔记本改用有线连接，或者靠近路由器，排除 Wi-Fi 因素。
- 连接 VPN 后，在不同时间段各测三次，取中位数，排除线路拥堵造成的偶然低值。
- 在客户端里更换线路或节点，优先选择离你更近的地区，再比较结果。
- 如果客户端允许切换协议，尝试在 WireGuard 与其他协议之间切换，对比差异。
- 怀疑 MTU 问题时，把值从 1420 逐步调小到 1380 再试，观察网页加载和下载是否改善。
网页半开、图片加载一半，为什么多半和 MTU 有关
MTU 设置过大，会让较大的数据包被中间设备丢弃，而较小的数据包正常通过。表现为简单的文字页面能打开，带大量图片的页面加载一半卡住，或者上传文件时突然失败。这类现象与带宽无关，调小 MTU 往往比换线路更有效。
测速软件显示很快，但视频还是会卡，为什么
测速软件通常用多线程短时间测出峰值，而视频播放对抖动和丢包更敏感，两者不是一回事。如果测速结果不错但播放依然卡顿，可以把注意力转到延迟的波动情况，这一点在下一篇讲延迟、抖动和丢包时会展开。
我会在晚高峰和凌晨各测一轮再决定用哪条线路。如果你想快速体验线路选择对速度的影响，可以试试 TonBoVPN，在客户端里切换几个节点，用上面的方法各测几次，数据以你自己的网络为准。
小结：先定位，再调整
速度下降通常不是单一原因造成的。先排除本地网络，再看线路和时段，最后才轮到协议与 MTU 这类细节设置。一次只改一处，并把每次的测速结果记下来，比凭感觉判断哪个设置更有效要可靠得多。