修复空闲时的 VPN 掉线：Wi-Fi 省电检查清单

笔记本闲置一段时间后隧道就断了，而一碰触控板它立刻恢复。这个规律指向无线链路进入了省电模式，而不是 VPN 网关拒绝了你的凭据。同一个配置文件在忙碌的早晨安然无恙就是证据：有流量时隧道活着，无线一安静就断。请按下面的顺序逐项检查，在第一个失败的检查处停下，然后才去改一个设置。

检查一：掉线是否跟随空闲？

先证明相关性，而不是假设它。记录你发出的最后一个数据包的墙上时间、客户端报告隧道断开的时间，以及这期间屏幕是否熄灭。如果间隔每次都一样，你面对的是空闲路径问题；如果掉线在活跃使用中随机出现，直接跳到检查五。

一个撤销起来毫无成本的廉价测试：用二十分钟向网关发送稳定的低速率 ping，然后别碰机器。如果整个过程中隧道都没断，说明持续的小流量只是在掩盖症状而非修复它，而这仍然是有用证据。我把那段 ping 输出留在草稿终端里，事后与客户端日志对照，因为两个时钟很少对得上。

检查二：只是 VPN 流量吗？

在归咎于隧道之前，先弄清链路本身是否还能用。趁隧道已死但屏幕仍暗时，试着用 IP 访问接入点地址和一个公网主机。如果普通 ping 也失败，那就是无线或接入点把你丢下了，VPN 客户端只是旁观者。

如果普通流量正常而隧道沉默，说明链路健康，问题出在隧道自身的定时器，或者客户端处理恢复的方式上。这是两种不同的修法，所以不要跳过这一步。在同时有 Wi-Fi 和以太网的笔记本上，拔掉网线重做空闲测试：有线以太网上消失的空闲掉线，就是无线层的有力证据。

检查三：读取省电状态

大多数桌面环境给你一个复选框，但复选框不等于驱动所处状态。先读驱动自己的报告，再做决定。在使用 mac80211 的 Linux 上，接口会直接回答：

iw dev wlan0 get power_save          # on or off, per interface
sudo iw dev wlan0 set power_save off # diagnostic only, lost on reconnect

第二条命令是测试而不是修复。它熬不过断连、睡眠或重启，这使它成为在验证假设的同时不留下永久改动的一种干净做法。

在 Windows 上，powercfg /q SCHEME_CURRENT会打印当前电源方案，而无线适配器的子树会显示该适配器是否可以被要求省电；同样的选项也在设备管理器中适配器的电源管理选项卡里。在 macOS 上，按接口的 802.11 省电并不向你公开，所以改看pmset -g来了解睡眠与待机行为。在那里，故障通常被证明是睡眠与唤醒路径的问题，而不是无线的空闲行为。

检查四：只改一个变量，然后复测

每次只改一个变量，并重复同样的负载。如果关掉省电后隧道能撑过一小时空闲，你学到了真东西。如果它仍然掉线，就在测试下一个想法之前先回退，否则你最后会面对三个互相重叠的设置，却不知道哪个才重要。

保活是另一个独立变量，而且它总和省电混为一谈。WireGuard 的PersistentKeepalive = 25让 NAT 映射保持温暖；OpenVPN在两端都keepalive和ping-restart都用。两者都会让本应安静的隧道产生流量，所以看似修好掉线的保活，可能只是掩盖了无线问题。请分别、逐个地测试它们：

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
PersistentKeepalive = 25

检查五：当无线是无辜的

如果在关闭省电、开启保活之后空闲掉线依旧，就往笔记本之外看。接入点和家用路由器会按自己的节奏让空闲的 NAT 或会话条目过期，VPN 服务器也可能丢弃没有流量的会话。在共享同一 SSID 的接入点之间漫游，也可能在客户端没说清的情况下重置链路。

然后与同一网络上的第二台设备做同样的空闲测试作对比。两台设备以相同间隔掉线，是路径或服务器的故事；只有一台掉线，是本机驱动或电源的故事。这个对比只花十分钟，却能让你不必重写错误的配置。

在把它变成永久设置之前

决定你愿意保留什么。只在出现掉线的那个网络上关闭省电的按配置文件脚本是站得住脚的。以每个网络上的电池续航为代价、全局关掉一切的调整通常站不住脚。

• 把原始的省电数值记在脚本旁边，以便日后恢复。
• 每次更新驱动或客户端之后都重跑空闲测试；默认值会变。
• 报告问题时，把 ping 日志和客户端日志放在一起。
• 如果第二步失败了，就别再改 VPN 设置，而要把它当作本地链路故障。

如果只做一件事，就做检查二。它决定这份清单的其余部分是否与你有关，也正是人们在已经认定答案是省电之后会跳过的那一步。