我的 VPN 为什么这么慢？分四段逐一排查

通话卡顿、下载龟速、上传中途中止，这三种情况被贴上同一个标签，其实是三类不同的问题。先判断自己在追查哪一种，剩下的调查就能省下来。然后再一次只更换路径上的一段，并重复同一项任务。

下面的顺序从任务向外推进，因为隧道无法补足它底层缺失的带宽。

先定义什么叫慢，再动手测量

持续偏低的速率、带尖峰的高延迟、到固定大小就完全停住的传输，并不是同一种故障的不同表现。它们分别指向不同的段：吞吐量、路径本身，或者数据包大小上限。挑一个真正困扰你的任务作为基准，因为测速测的是大流量传输，行为可能和视频通话完全不同。记下端点、协议、时段，以及对你真正重要的那个数字。

没有这份记录，之后每次比较都会变成对各人印象的争论。

先查接入网络

先暂停你自己的大流量传输，然后在隧道介入之前测量本地链路。用一项无害的任务作对照，并按客户端的中止开关流程操作，而不是一次性关掉好几层保护，两次测试要使用同一目的地。测速服务商在你可见位置变化后可能分配另一台测量服务器，比较就变成了两台服务器的对比。

ping -c 20 192.168.50.1
ping -c 20 198.51.100.7
curl -o /dev/null -w "%{time_starttransfer} %{speed_download}\n" https://speed.example.net/10mb.bin

如果基线本来就差，问题属于 Wi-Fi、路由器负载或接入服务。有线测试，或者在接入点附近固定位置，可以把弱无线链路和拥塞的上行链路区分开。隧道做什么都不会凭空增加接入线路没有交付的容量。

先换出口，再换传输

保持设备、网络和协议不变，测试第二个端点。从位置列表里挑一个合理城市，但别以为最近的标签就是最优路由。如果某个出口慢而其他出口正常，它所在的主机或路径值得查；如果某台设备上所有出口都慢，而另一台设备正常，客户端嫌疑更大。

如果服务同时提供两种配置，就比较 UDP 上的 OpenVPN 和 TCP 上的 OpenVPN。交互式工作通常从 UDP 起步，而在完全不放行 UDP 流量的接入网络上，TCP 可能有帮助。TCP 隧道在流内重传来恢复丢包，所以在丢包链路上会显得更慢，OpenVPN 性能故障排查说明也讲到同样的取舍，值得在调整其他设置之前先读。把配置里的“udp”改成“tcp”，并不能凭空造出服务器从未打开的监听端口。

在尝试下一项改动之前，先把有效的配置存下来。否则之后出现退步，你只能猜是哪次编辑带来的改善。

把设备和症状放在一起看

要在传输过程中看处理器负载，而不是传输结束后，因为加密开销随流量增长，而一台服务全家的小路由器，和自己跑客户端的笔记本是两种机器。另一个 VPN、虚拟机或网络过滤器也可能坐在同一条路径上分走一部分流量。保持软件更新，但不要为了跑分好看而移除身份验证检查或中止开关。如果小请求能成功、大上传总在固定大小处卡住，下一步就是检查 MTU。

ping -M do -s 1400 -c 3 198.51.100.7
ip link show dev tun0 | grep -o "mtu [0-9]*"

如果隧道反复重连，先解决断线问题，再去解释任何吞吐数字，因为不断重连的隧道测到的是握手而不是路径。每次改动之后重复最初的任务，并保留结果。测速变快了但通话仍然断，并没有解决你一开始的抱怨。