为什么开 VPN 后上传速度会下降

你打开 VPN，跑了一次测速，下载速度看起来还可以接受。可是当你要把视频发给同事、备份照片或加入视频会议时，上传却慢得像爬。不少人反映，开着 VPN 时上传比下载受的影响大得多。原因是几件事叠加在一起：家庭宽带线路的结构、VPN 给每个数据包增加的东西，以及 TCP 的一些行为特点。

本文回答一个问题：为什么 VPN 的上传速度会下降，怎样判断你属于哪种原因，以及你能改变什么。内容专讲上传。如果想了解速度为何会波动的整体情况，请先读为什么用 VPN 速度会变化。

先看你的连接是什么形状

大多数家庭宽带套餐是不对称的：下行远大于上行。有线电视宽带和较老的 DSL 是典型例子，套餐可能是下行 100 Mbps、上行 10 Mbps，甚至更少。光纤套餐往往更均衡，但很多仍然是上行较小。

这个比例通过两种方式影响 VPN。

1. 上限更低。 如果你的原始上传是 10 Mbps，即使隧道再完美也不会超过 10 Mbps。扣除开销后，你可能看到 8 或 9。
2. 同样的损失显得更大。 如果隧道吃掉 15% 的吞吐量，那么 100 Mbps 的下载损失 15 Mbps，10 Mbps 的上传损失 1.5 Mbps。百分比一样，但小数字往往会成为你手头任务的瓶颈，比如发送一个大文件。

因此，任何诊断的第一步，都是知道你不开 VPN 时的正常上传数值。没有这个基线，你就分不清那是下降还是本来的上限。

每个数据包都要背的开销

VPN 给每个数据包包上一层额外的封装。外壳增加了包头，以及用于加密和认证的若干字节。对一个典型的满尺寸包，这部分开销是百分之几；对小包，占比更大。这种开销对下载同样存在，但在上行较小时更容易被注意到。

由此得出两点。

• 原始吞吐量比你在隧道内测到的略高。 你的线路可能传送了 10 Mbps 的数据包，但其中 0.5 Mbps 是外壳。
• 包的大小很重要。 如果隧道的包大小与路径不匹配，包可能被分片或丢弃，这对上传代价很高。具体的测算方法见如何找到合适的 MTU，路径 MTU 的背景见 RFC 1191。

协议细节也会让数字略有变化，但它们不是大幅下降的主要原因。

确认包走的是另一个方向

有件事让很多人意外：通过 TCP 下载时，你的设备会不断向上行方向发送一连串小的确认包；而你上传时，确认包则从下行方向回来。这对上传有两个后果。

• 进行大下载时，你的上行一部分被用来发确认包。如果你同时在上传，两者就会争抢本来就窄的上行。
• 上传期间，发送方依靠确认包才能继续发送。如果确认包迟到，即使线路还有空余容量，上传也会变慢。

有了 VPN，确认包同样要经过隧道，因此会增加更长路线带来的往返时间。TCP 的发送速率取决于往返时间，粗略的规则是：单条 TCP 连接的最大速度约等于窗口大小除以往返时间。如果更长的路线使往返时间从 40 毫秒增加到 80 毫秒，单条连接的最高速度可能降到约一半，除非窗口大到足以补偿。

一个计算示例：为什么单条连接会爬行

看看下面这组数字。

项目	不开 VPN	开 VPN 连到较远位置
往返时间	30 ms	140 ms
上行线路	20 Mbps	20 Mbps
单连接典型窗口	256 KB	256 KB
单连接的大致上限	约 70 Mbps	约 15 Mbps

线路本身仍有 20 Mbps 的空闲，但窗口相同的单条 TCP 连接在更长的路线上只能发出约 15 Mbps，而长路径上的丢包还会把它进一步压低。真实的上传常常只用一条大的数据流，比如把单个文件传到云服务，所以它比同时打开许多并行连接的网页更能感受到这种影响。

这就是为什么向同一个服务上传同一个文件，通过远处的位置可能慢得多，而通过更近的位置则明显更好。这不是缺陷，而是 TCP 在远距离上的工作方式。

常见原因，按出现频率排列

1. Wi-Fi 上行

手机或笔记本的无线电在发送时最弱。小天线、墙体和拥挤的信道降低上传速率的幅度比下载更大。如果 VPN 测试是在 Wi-Fi 上做的，请先改用网线重复一遍，再怪别的。

2. 拥塞或遥远的路径

通往 VPN 服务器以及从服务器通往目的地的路径，在晚上可能很拥挤。上传受影响是因为丢包会让 TCP 大幅降速，而每次恢复都很慢。可以试一个更近的位置，并在不同时间测试。快速检查丢包的方法见 VPN 丢包的原因与排查方法。

3. 设备的 CPU

加密要消耗处理器时间。在现代笔记本或手机上这点很小，但处于省电模式的旧手机、低端平板或很忙的电脑可能余量耗尽，上传会受到影响，因为设备必须对每个发出的字节加密。如果上传期间 CPU 曲线冲到 100%，这就是一条线索。

4. 相互争抢的上传流量

云备份、照片同步、游戏更新和家里的其他设备都在悄悄占用上行容量。窄的上行很快被填满，路由器队列增长，延迟攀升。你会同时看到上传变慢和通话变卡。

5. 数据包大小问题

如果包对路径来说太大，可能被分片或悄悄丢弃，上传会因为发送方不断重试而停滞。迹象是上传时断时续，或在某个大小上失败，而小文件传输一切正常。

6. 运营商的流量管理

有些运营商在繁忙时段会对某些类型的流量进行管理，而 VPN 可能改变这类流量被归类的方式。这很难证明，也很难从你这边改变。如果你发现所有位置都只在高峰期上传慢，请与运营商沟通。

7. 目的地自身的限制

许多服务会按连接或按账户限制上传速度。不管你的 VPN 怎么样，限制可能就出在目的地。把同样的上传换到另一个服务测试一下。

一套可量化的测试流程

有计划的话，大约十五分钟就能找出原因。

第 1 步：不开 VPN 的基线，尽量使用网线。 跑一次测速，记下下载、上传和延迟。重复三次，取上传的平均值。

第 2 步：用同一根网线，开 VPN 做同样的测试。 连接，等十秒，重复三次。把下降幅度记成百分比。

第 3 步：开 VPN，用 Wi-Fi 做同样的测试。 这能显示损失中有多少来自无线链路。

第 4 步：换一个 VPN 位置。 先测较近的位置，再测较远的。如果较近的明显更好，问题就在距离和路径上。

第 5 步：真实上传。 向你常用的服务上传一个 100 MB 的文件并计时。测速可能使用多条并行连接，而真实上传常常只用一条，所以两者可能不一致。

第 6 步：观察设备。 上传期间打开任务管理器或活动监视器。CPU 很高说明存在处理能力上限。

第 7 步：停掉其他上传。 暂停备份和其他设备，然后重复测试。大幅改善说明是在争抢上行带宽。

如何解读数字：

观察到的现象	可能的原因
不开 VPN 上传就很差	你的线路或路由器，与 VPN 无关
网线正常，Wi-Fi 差	无线链路
近的位置正常，远的位置差	距离与 TCP 往返时间
只在夜里差	高峰期拥塞
CPU 达到 100%	设备上限
测速正常，真实上传差	单数据流限制、目的地限速或包大小
上传停滞又重启	丢包或 MTU

按顺序要改什么

1. 先修好本地链路。 用网线，或改善 Wi-Fi 的位置与频段。
2. 大文件上传选更近的 VPN 位置。 把远处的位置留给对上传要求不高的任务。
3. 暂停争抢带宽的上传，包括你自己设备上的手机照片同步。
4. 把繁重的上传安排在非高峰时段，比如清晨，那时路线更清闲。
5. 关闭设备上的重负载应用，长时间上传时保持充电和散热良好。
6. 保持 VPN 应用和系统为最新，因为修复和性能改进都随更新而来。官方应用可以在下载页面找到。
7. 不要动 VPN 的默认连接设置，除非支持人员建议，并且一次只改一项。
8. 如果上传在某个大小上停滞或失败，检查 MTU。
9. 对于较大且不敏感的上传，可考虑关闭 VPN，前提是在可信的网络上。根据你要发送的内容来决定。
10. 如果线路本身就是上限，咨询运营商上行速度的问题。有些套餐只需小小的调整就能提供高得多的上传带宽。

局限与合理预期

• 有些下降是正常的。 开销和更长的路线是有成本的，比基线低 5% 到 20% 并不罕见。
• VPN 不可能让上传超过你的线路。 如果套餐的上行是 10 Mbps，隧道的速度就会低于它。
• 测速和真实上传不同。 你上传到的服务及其自身的限制，与隧道同样重要。
• 结果随时间和路径而变化。 在下结论之前多测几次。
• 不要为了速度而放弃加密。 如果某次上传文件很大且不敏感，你可以决定不用 VPN 来发送，但要有意识地这样做，并且只在可信网络上。

关于变慢的更多建议，见为什么 VPN 会慢；关于如何做公平的对比，见如何测试 VPN 速度。

常见错误

• 拿 VPN 上传速度与套餐标称速度比较，而不是与实测的基线比较。
• 只测一次，还是在晚上、用 Wi-Fi。
• 因为下载看起来快，就为大文件上传选了很远的位置。
• 忽略手机和笔记本的后台同步。
• 同时更改多个设置。
• 以为上传必须等于下载。

总结

使用 VPN 时上传速度下降，是因为上行通常是线路中较窄的一段，因为隧道增加了开销并使路线变长，因为 TCP 上传对往返时间和丢包很敏感，还因为 Wi-Fi 信号弱、设备繁忙或其他上传争抢带宽会进一步拖累。请先在不开 VPN 时测量，再用网线开着 VPN 测，然后换一个位置，并留意 CPU 和后台流量。大部分改善来自修好本地链路、选择更近的位置和暂停争抢带宽的上传。

如果用一个短期预付套餐可以帮你测试其他位置，可以在价格页面了解套餐如何运作。