VPN 真能降低网游延迟吗

能，但只是有时候，原因也比大多数教程承认的无聊得多。隧道会把游戏流量送到出口，再从那里沿另一条路径回到同一批服务器，所以它可能替换掉一条拥塞或绕远的路径，也可能在原本就好的路径上多加一跳和一段排队。究竟属于哪种情况，只有在你自己的线路、你自己的地区做测量才知道；同一个服务商的两个玩家，从同一个出口也可能得到相反的结果。下面的检查顺序是为了让你最终拿来比较的数字站得住脚：同一个地区、同一个时段、同一台服务器。

先固定地区和服务器，再谈对比

你放任漂移的每一个变量，都会变成无法排除的解释。把游戏地区、设备、接入网络和时段都固定下来，再拿基线与单个出口比较。每轮只改一个因素，否则结果无法解读。

按路径选出口，而不是按国家标签。你所玩地区的首都机房，也可能对游戏基础设施的连通很差；而更远的一台反而可能挂在更好的对等互联上。国旗只是把对拓扑的猜测包装成了信息。

有训练场或人机对战就用它。实时对局会轮换玩家、在回合之间分配不同服务器，并让后台负载不断变化，这些都会把受控对比变成噪声。

平均 ping 掩盖了你真正感觉到的东西

玩家口中的卡顿，通常是波动而不是均值偏高。稳定的 60 ms 感觉可预期，而均值 40 ms 却夹着 120 ms 的尖峰，会让瞄准感觉像坏了一样。要记录分布，而不是游戏角落打印的那一个数。游戏自带网络覆盖层就用它，然后再从主机侧用抓包工具，针对会话实际使用的地址做印证。

ping -c 20 <game-server>
mtr -rwc 50 <game-server>

真正值得看的是丢包和抖动。单看 ICMP 不回包证明不了什么，因为很多主机一边降低 ping 的优先级，一边把游戏本身的流量转得很好。对丢包下结论之前，先用游戏内计数器印证。

本地拥塞比任何出口选择都优先

VPN 做什么都修不好你自己线路上被占满的上行。家里的备份、云同步或视频通话会把上行缓冲区填满，游戏的小包排在大流量后面，整条连接上所有人的延迟都会跳起来。

能的话就在固定位置用网线测一次，再在上行繁忙时测第二次。如果尖峰只在有负载时出现、负载一停就消失，那你找到的是排队，任何出口都修不好它。接入线路上的缓冲膨胀通常是元凶。

无线同样值得怀疑。边缘状态的 Wi-Fi 链路会随距离和干扰变差，而隧道出口却背了锅，只因为它是这条链上最新的一环。换有线跑一次，答案通常就很明显。如果有线稳定、无线不稳定，你调的是无线电，不是路由。

隧道里的 UDP 仍然是隧道里的 UDP

游戏发的是 UDP 数据报。VPN 会用它外层传输把它们包起来，如果外层是 TCP，它的重传与保序行为就夹在你和游戏之间。对局中途重连的隧道，会制造出和烂路由一样的卡顿，但原因完全不同。IETF 的 UDP 使用指南 解释了数据报行为为什么在本文关心的这些方面与 TCP 不同。

协议失败的方式也不一样。把 TCP 转发给一个只监听 UDP 的服务，得到的是沉默而不是报错；改个端口也变不出一个从未启动过的监听。要比较有效的服务器配置，否则对比毫无意义。

还有一个与网络无关的影响值得知道：新的出口会改变服务推断出的地区，这可能触发验证步骤或账号里的位置不一致。那是账号事件，不是延迟事件，换个更近的出口也修不好。

先用数字记录，再凭感觉判断

每次测试都保留同样的字段，包括那些感觉良好的场次，因为有用的对比是在两次记录之间，而不是在印象与记忆之间。这样记下来的一次短测试，胜过一晚上的主观感受，也能让你注意到服务商路由变差的时候。下面这张表是让事后对比保持诚实的最低要求。

在数字之上再凭感觉判断。真实对局里的响应性才是你在意的结果；如果测量变好而手感变差，说明你测错了东西。服务商或线路一变就重跑这张表，因为这个答案只对测过的那条路径成立。