Wi-Fi 让 VPN 变慢了？先检查本地链路

大多数人把无线电造成的卡顿算到服务器头上，而他们采取的补救办法，反而让下一次诊断更难。信号格满只说明接入点喊得响，并不说明信道安静，也不说明空口时间空闲。无线故障以时延、丢包和乱序的形式传到隧道里，客户端却把这三样一起报成含糊的“连接有问题”。

真正有用的问题是：同一条隧道换一条本地链路，表现是否不同。回答这个问题时，其他条件都保持不变。

信号格测的是功率，不是可用的空口时间

接收信号强度告诉你客户端把接入点听得有多响，这个数字可以在吞吐量崩塌时依旧很高。空口时间要和邻居网络、你自己网络里的其他客户端，以及管理帧一起分，后者必须用所有参与者都懂的最慢速率发送。墙体、金属和身体姿势会改变路径，笔记本内部的天线布局也一样。这些都不会出现在信号格里。

重传计数是最清楚的内部证据，因为一个试了三次才发出的帧，照样算作已送达。一条报告速率健康、却在疯狂重传的链路，会让实时隧道看起来像坏了。

选频段是取舍，不是解药，不管建议专栏怎么说。5 GHz 信道通常干扰更少、覆盖更近，2.4 GHz 则穿得更深、遇到的邻居更多。按你真正需要的距离选频段，并记下原来的设置，这样失败的试验还能撤回。

只改一个变量，然后再看一次

改本地链路时，VPN 配置、服务器端点、目标地址和时段都保持不变。把同一件事在接入点旁边、在远处的房间、以及同一台机器上的以太网各做一遍。如果有线那次干净、两次无线都不干净，那么无线这一段就坐实了第一嫌疑。

在接入点之间移动是另一个实验，而在 mesh 网络里，这恰恰是人们跳过的那一步。漫游可能让隧道暂停、强制重新协商密钥，或者让会话活着但数据包不再流动。记下每次中断的时刻，再和客户端日志里关联切换的那一条对照。和漫游对得上的停顿，不是服务器过载，哪怕它看起来非常像。

繁忙信道会冒充慢服务器

别的设备在抢同一段空口时间，你自己的大上传也在和你的通话抢。先暂停可选传输，再做一遍同样的事，然后才去判断运营商。负载下的排队产生的正是人们口中的 VPN 变慢：时延上升、送达一阵一阵、下载还在跑通话却断了。如果这个模式跟着你的传输走，而不是跟着你的位置走，那隧道是在报告一条拥塞的链路，而不是在制造拥塞。

大流量吞吐和实时质量是两种不同的测量，所以下载快并不能证明链路干净。对通话来说，抖动和丢包比平均速率更重要。

换服务器之前，先用时延测量验证

把本地链路和隧道路径分开测，两份输出都留着。下面的命令会读取关联信息、对路径采样几分钟，并显示丢包是出现在第一跳还是更远处。在接入点旁边跑一次，在出问题的地方再跑一次。

iw dev wlan0 link
ping -i 0.2 -c 200 203.0.113.5
mtr -r -c 50 203.0.113.5
ping -i 0.2 -c 200 198.51.100.9

比较 ping 的汇总而不是单行结果，因为丢包率和时延抖动能把无线问题和远端服务器区分开。如果丢包出现在到网关的第一跳，而隧道端点显示同样的丢包，那本地这一段就是共同因素。如果丢包只出现在端点之外，那无线就不是解释。

然后只改一件事，再把同样四条命令跑一遍。换服务器正好赶上换到更安静的信道，看起来会像修好了，其实什么也没教你。