VPN 下载为何可能快过你的直接连接

连上隧道，开始一次大文件下载，你会发现它的速度大约是同一文件不用隧道时的两倍。这听起来像广告，但在家庭宽带上完全可能是真实测量。常见原因是绑在某个端口上的限速：隧道把你的传输带到整形器不看的位置，线路的真实容量第一次显现出来。

也就是说，真正值得关心的数字不是 VPN 有多快。而是你一直没拿到的那部分带宽有多少，以及为什么。

跟随端口而非路径的限速

接入服务商可以按协议或目的端口限制每位用户的吞吐量，而 80 端口是热门目标，因为太多普通浏览都用它。限速往往不是从第一个数据包就开始：传输先接近线路速度，耗尽一段突发额度，然后落到被限制的数值上。最初几秒看着正常，其余部分不正常。

把同样的字节改从另一个端口发出，80 端口上的整形器就再也看不到它们。隧道似乎战胜了直连，尽管它多了一跳、一层加密以及自身的开销。变好的不是路径，而是少了一条规则。

这也解释了为什么该现象在不同文件和目标之间如此一致。如果限制落在端口上，走这个端口的任何内容表现都相同，不论文件多大、主机是谁。吸引另一条规则的目标会给出另一条曲线，而这个差别本身就足以诊断。

峰值是传输中信息量最少的部分，因为缓冲正在填充时每条连接都显得很好。记下速率在哪里稳定下来，以及能维持多久。

curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/

在同一台机器上、同一时段内、对可比网络中的主机，把两种方式接连各跑一遍。一次采样说明不了什么；各自两次运行的曲线形状，才是区分突发额度与稳定限速的关键。写下速率在哪里变平，而不是第一秒显示了多少，因为突发恰恰是整形器在开始限速之前给你的那部分。能持续到传输结束的平稳平台，才是要比较的数字。

让文件本身就是压缩格式，这样传输压缩就无法被拿来说明问题。PDF 或归档文件排除了这个变量，也让人无法辩称隧道压缩了载荷。如果两次传输用的是同一个文件，剩下的唯一差别就是路径和端口。把工具和端口记在每个数字旁边，否则第二次运行与第一次不可比。

按顺序做，一旦规律清楚就停下，因为每一组都排除一种不同的解释。

用普通网页路径和另一端口上的传输工具，从容量相当的主机各重复一次同样的下载。
用不可压缩的文件把两者各重复一次，让压缩不再是候选解释。
如果你自己运行隧道服务器，把它重新绑定到 80 端口，调整客户端配置让两端一致，再传输一次。若隧道此时落在被限制的网页速率上，说明限制跟着端口走，而不是跟着 VPN 走。

第三步是决定性的，也正是人们常跳过的一步，因为它需要改配置。不做这一步，你只证明了两种方式不同，没证明端口是原因。

它不证明隧道普遍更快，不证明它压缩了什么，也不证明线路上其他端口没有限制。它描述的是这次传输、这条线路、这个时段。限速可以按会话、按用户或按时段实施，也可能随时变化而不通知。

它同样不能证明直连路径坏了。被限速的路径仍然能用；它是被有意限制的，而刻意的策略并不是等待修复的故障。

更完全不能成为把所有流量都塞进隧道的理由。80 端口上的每个应用仍被限速，而你改道的一切现在都多了一跳，也多了一种故障方式。

把观察写成测量而不是判决：在 80 端口上的大文件传输，稳定在约一半于同一文件在另一端口上达到的速率；时间为这些时段，线路为这条，样本随附。这样才是一份别人能去查的支持请求。

「VPN 更快」不是。它只会招来一段关于加密开销的回复，那段回复技术上正确，却对谁都没有帮助。附上样本数、时段和端口，读者才能复现这个规律。

如果你决定继续用别的端口做大流量传输，把自己的记录写清楚：把监听搬到 80 端口会与任何已经绑定在那里的网页服务器冲突，随之而来的故障看起来像隧道坏了，而不像端口冲突。