为什么你的 VPN 恢复得比断网还久

Wi-Fi 三十秒前就回来了，VPN 却还没恢复，于是客户端看起来像坏了。它往往只是在按自己的重试时间表走，而这张表并不知道网络刚刚恢复。这个落差就是全部故事：恢复时间等于断网时长，加上客户端早已承诺的那段等待。把每个计时器都调低是一种应对，弄清哪个计时器真正重要则是另一种。

三个条件决定调参是否有用：哪一阶段慢、失败到底能否重试，以及客户端如何得知网络已经恢复。

三种看起来像一种的等待

端点解析、IKE 或 TLS 协商、数据包重传，以及发起一次新的尝试都是各有独立计时器的独立事件。strongSwan 记录了 IKE 的重传退避机制，而OpenVPN有自己的重试控制，语义并不相同。把一个数值从一个抄到另一个，前提是机制一致，但事实并非如此。先读日志顺序，再判断你看的是哪一段时间。

日志里安静一分钟，未必是进程卡死。它可能是指数退避正在按配置行事。

到底是哪一阶段慢？

如果日志显示尝试因认证错误而失败，改任何计时器都没用，因为凭据是错的。如果根本没有发起尝试，客户端还在等待窗口内，那就该改时间表。如果尝试了却超时，问题在于可达性或缺少监听，重试更快只会把日志填满。这三种状态各有不同的负责人，只有一种是时间问题。

先给失败归类，再去动数字。

什么时候调低计时器有用，什么时候没用

当主要成本是短促而频繁的断网之后的等待时，降低重试上限，例如笔记本在接入点之间移动。断网时间长或很少发生时就不要动它，因为激进重试会在集中器最无力回应的时候增加负载。两种情况都只改一个参数，记录下来，并测量下一次恢复，而不是假定它变好了。

把极低的超时抄进每个配置文件，是缺乏测量的调参常见的结局。

在责怪客户端之前，先检查就绪状态

客户端往往要等到有东西尝试，才知道网络已经可用。强制门户、DHCP 续租或路由变化，都可能让它按此前设定的时间表干等。把操作系统的网络状态变化和客户端的下一次尝试放在同一时钟上观察，就能看出这是谁的等待。快捷做法是记下网络就绪事件的时间戳，以及之后第一次尝试的时间戳。

同时确认等待期间直连流量仍被阻断，因为更快重连却发生流量泄漏并不算改进。

该记录什么

写下改了哪个计时器、从什么值改到什么值，以及之后的恢复情况。也要记下客户端版本，因为默认值会随版本变化，而未记录的极低超时会让下一个读配置文件的人困惑。

这样的记录让下一次软件升级成为对比，而不是实验。