VPN 会比直连更快吗

在办公网络上慢如爬行的传输，有时走隧道反而很快完成，而额外的封装让这件事看起来不可能。这个表面上的悖论来自比较错了对象。隧道确实增加了开销，但它同时也改变了流量走哪条网络路径、目的端看到哪个地址，有时甚至改变了由哪台服务器应答。要判断速度，必须先把这三重效应分开，再做结论。

隧道可能改变的三件事

第一是中转路径。互联网路由遵循运营商策略和商业关系，而不是实测时延，因此经由 VPN 服务商的路径可能穿越与直连不同的网络。它可能避开拥塞的交换点，落到互联更好的位置，也同样可能更差。

第二是目的端。出口地址改变往往会改变 DNS 应答，内容网络也可能给你另一台缓存或另一个区域。这时一部分改善属于新服务器，而不是隧道。同一个主机名可能落在更近或负载更低的服务器上，而客户端毫无变化。

第三是传输行为。封装改变了有效包大小，而绕开丢包中间段的隧道，可能让一条 TCP 流得以扩大窗口，而不必反复退让。这些都不是普适的加速机制，每一项都是需要观测的条件。把它们分开，才是把好奇变成事实的关键。

它改变不了什么

隧道里的任何东西都不会给设备与网络之间的链路增加容量。饱和的 Wi-Fi 信道、拥塞的最后一公里，或者有流量上限的移动套餐，对两条路径的限制完全相同，隧道里的测速也无法突破那个上限。同一条链路承载着封装后的数据包，所以封装可以消耗容量，却永远创造不出容量。真正改变的是数据包离开这条链路之后去哪里。这就是为什么隧道跑出好成绩时，原因总在第一跳的上游。

服务器侧的限制同样无动于衷。如果远端主机服务得慢，更好的路径只是把慢响应用更高效率送回来，用户仍在等待。共享源站在负载下，会在同一时刻让两条路径都显得很慢。

正确地比较路径

让应用、方向、时长和并发保持一致，只改变路径。每次测试跑不止一遍，并在一天中的同一时刻进行，把出口地址和解析器应答与吞吐量一起记录下来。单次运行只是样本，不是测量；一次快速下载可能只是缓存命中，对路由什么也说明不了。先写下条件再记录结果，因为事后很难解释这些数字。

mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.com

解析器应答是大多数比较会漏掉的那一项细节，它解释了在同一服务器被强制时消失的“改善”。如果各次运行的地址不同，那么测试比较的是两个目的端，而不是两条路径。把时延和丢包与吞吐量并列报告，因为一条总体上更快、却给每个交互请求增加延迟的路径，对提出抱怨的那种负载并不更好。凡是先问后等的场景，往返时间都比大流量速度更重要。

什么时候值得保留这个差异

如果经过批准的隧道能稳定改善某一特定负载，那就是正当的运维选择：记录下负载、测量方法和所用出口。可用的记录会写明一台主机、隧道产生的出口地址、解析器应答，以及同一天直连路径的同一组数字。这足以让下一位工程师复现比较，而不是重新争论。这仍然不能证明服务商在限制什么，也不能迁移到其他应用或其他时段。

把测量记录和配置放在一起。它回答的是“改善是否仍然存在”这个后续问题，也是判断路径或负载是否改变的唯一方式。没有日期的记录根本无法回答这个问题。