为什么通过 VPN 下载比直连更快

你开始下一个大文件，最初的几秒一切正常，随后速率稳定在线路本应提供的大约一半。你连上隧道，重复同一个下载，整个文件都保持着更高的速率。这既是真实的测量，也是误导人的结论，因为隧道并没有让路径变快。它只是把你的流量从沿途某处被限制的端口上移开了。

曲线的形状会暴露答案

看传输过程，而不是最终数字。受限路径通常始于接近线路速率的峰值，用尽突发额度后停在限值上，所以平均值取决于你观察了多久。真正改善了路径的隧道会从第一秒起就表现出更好的速率，并一直保持。平台期就是指纹，如果只记录峰值，很容易错过它。

同一个文件跑两遍，一遍直连、一遍走隧道，就足以看出是否存在平台期。

记下平台期何时开始、持续多久、保持在哪个速率。这三个值能把整形器和拥塞路径区分开：拥塞让速率来回漂移，整形器则把它钉在一个数字上。如果直连那一遍逐渐变差，而走隧道那一遍保持稳定，你看到的是策略，不是物理。

三组对比，每次只动一个变量

每次只改一件事，否则什么也学不到。先用普通 Web 路径取同一个文件，再换成一个使用不同端口的传输工具，从容量相当的主机、在同一时段取回。客户端机器要保持不变，因为笔记本在不同网络间移动，会引入你无法控制的变量。

curl -o /dev/null -w '%{speed_download}' https://files.example/big.iso
scp [email protected]:/exports/big.iso /dev/null

用一个已经压缩过的文件，比如磁盘镜像，这样传输压缩就无法解释差异。然后，如果你能控制服务器，把它的监听端口换成你怀疑被限制的那个，更新客户端配置，再重复一遍。如果隧道这时掉到被限制的速率，说明限制跟着端口走而不是跟着隧道走，问题就定论了。每组对比都要跑两遍，记录平台期的数值，而不是峰值。

时段也要记下来，因为整形器可能按时段生效，晚上的测试和早上的测试可能不一致。同一时段的两遍，比分散在一天里的十遍更有价值。

这个测量支撑不了什么

它不能说明隧道普遍更快，不能说明隧道压缩了什么，也不能说明其他端口没有被限制。它描述的是一条线路上、一小时内的一次传输。限制可以是按会话、按订阅或按时段的，运营商可以不作通知就改掉。

它同样不能说明直连路径有故障。受限路径完全按设计工作，只是被策略限制住了。

写报告时这个区分很重要。故障对应一张维修工单，而策略对应一个关于合同的问题，或者一个绕开它的决定。把限速叫故障，会让支持对话从错误的前提开始。把它叫策略，你才能提出一个有明确答案的具体问题。

把发现变成一份支持请求

用数字，丢掉结论。请求里写明：在这些时段，经 80 端口的大文件传输稳定在预期速率的大约一半，并附上平台期数据，这样的请求是可执行的。说 VPN 更快的请求不可执行，因为它读起来是对隧道的断言，而不是对线路的观察。附上两遍传输及其时间戳，然后让运营商去描述策略。

不要只为了追那个数字就把每个应用都塞进隧道。

隧道仍然要你多付一跳、加密和一套新的故障模式，而被限制的端口对其他使用它的东西依旧是限制的。当大文件必须可靠完成时，自己记下是哪个端口背着这个限制。把监听搬到 80 端口还会和任何已经占用它的 Web 服务器冲突，那带来的不是修复，而是一次新的中断。