VPN 上传比下载慢？判断你撞上了哪道限制

大多数接入线路是不对称的，所以隧道通常上传比下载慢，这是预期答案，不是故障。有意思的问题是：你的上传是被线路限制、被已经在用它的别的东西限制，还是被一条不走稳而停滞的流限制。这三种给出同样的抱怨，却需要不同的处理。

从进度条看毫无区别的三道限制

第一是容量，它是接入产品的属性，不是隧道的属性。几 Mbps 的上行在家庭光纤和许多移动套餐里都很正常，相比之下加密开销很小。封装还会给每个包增加字节，这会同时削减两个方向的有效吞吐，而不只是一个方向，所以它本身解释不了很大的不对称。

第二是争用。云同步、照片库和更新代理会在机器看似空闲时上传，同一线路上的第二台设备也一样。第三是排队：饱和的上行会把交互流量挤到批量数据后面，于是通话断续，而传输本身却报告健康的进度。

一次只测一个方向

使用同一台设备、同一个配置和同一个目标，除非你就是要观察争用，否则绝不要同时跑两个方向。第一次测试前先暂停你自己的可选传输。中间只改一个开关的两次测试就能定下大半。

iperf3 默认从客户端发送，所以普通测试测的是你的上行路径；-R 反转方向，测的是下载。两次测试隔几分钟跑，记录两个数字，而不是取平均：

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

如果上传数字只是下载数字的一小部分，并且在多次测试之间保持稳定，形态就符合不对称接入线路，隧道不是问题所在。如果上传在测试之间摇摆，或者十秒后崩塌，请继续往下看。

按上传在何处变化来判断

一次只改一个变量，观察哪个方向在动。换一个上传更好的 VPN 节点后变好，说明问题在那个节点或去它的路由。同一线路上第二台设备也是同样慢的上传，说明问题在线路。另一条线路上的另一台设备也慢，说明问题在目标端的入口策略，这你本地修不了。

记录同一工作负载下的每秒字节数和耗时，而不是一个速度分数。备份客户端和测速用的目标与并发都不同，比较它们的数字说明不了任何事。如果小请求正常、只有大传输在爬，限制很可能根本不是带宽。

日常使用中，给后台上传设上限，或把它排到会议时间之外，往往比任何隧道设置都更有用。评估这项改动要看合并后的工作负载：备份晚一点完成、但不再毁掉通话，通常是更划算的交换。

当停滞胜过缓慢

在可复现的位置冻住、随后又恢复的传输，表现更像路径 MTU 问题，而不是速率限制。隧道减少了每个包可用的载荷，而丢掉随之而来的 ICMP 消息的设备会让发送方只能猜。这种形态值得单独测试，因为修法不同于调速率。稳定偏低的数字指向容量，而一阵爆发之后归于沉默，指向路径承载不了的载荷。

用不允许分片的载荷测试路径，然后把隧道接口的 MTU 与能通过的值做比较：

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

如果大探测包消失而小探测包成功，就在隧道上钳制 TCP MSS，而不是为所有协议降低接口 MTU。那一点之后的持续停滞属于接收端应用的存储或节奏，不属于网络路径。

该改什么，该放过什么

改变你能控制的东西：后台传输的时间表、节点的选择，以及停滞路径的 MSS。让每项改动都可回退，并且只针对一个工作负载。测量说没问题的就别动，包括已经与线路相符的下载速率。

把改动前后的数字连同配置、节点和时段一起记下来，因为随节点变化的上传问题是路由问题，随设备变化的是本地问题。正是这份记录把含糊的抱怨变成决定，而它只花同一条命令的两次运行。