路由器重启后 VPN 卡住：三件变了的事

路由器启动完成，笔记本重新连回同一个 SSID，VPN 却停在已连接状态、什么都不动。保存的配置文件完好无损。在它下面失效的是路径，而客户端还握着为旧路径建立的状态。

修复由三个条件决定。按顺序排查，因为如果第一条就解释了卡住，后面的都是白费力气。

条件一：本地地址变了吗

重启可能给这台机器分配了不同的地址。于是用固定本地端点配置的 VPN 仍在沿用一条已不存在的附着。把套接字绑定到旧地址的客户端也一样。隧道接口可以保持启用，而它产生的每个数据包都去了无用的地方。

把客户端正在使用的地址与接口当前的地址对比。指向同样变了的网关的默认路由，是同一类问题换了个名字。

ip -4 addr show
ip route show default
ip route get 203.0.113.10

条件二：转换映射还在吗

家用路由器会转换出站流，而这些映射保存在内存里。一次重启会把它们全部清掉。对新建连接这无妨，但对一条认为现有流仍然有效的隧道则是致命的。对端什么都看不到，于是客户端永远拿不到可据以处理的错误。

没有 keepalive 的隧道会在这里悄悄停住，而不是响亮地失败。已知限制文档描述的正是同一种失败形态。端点状态不对，产生的是被丢弃的数据包，而不是诊断信息。

25 秒的持久 keepalive 是常见缓解手段，因为它会在空闲超时到期前刷新映射。它修不好已经消失的映射。把 keepalive 与重连逻辑搭配使用，而不是当成修复。

条件三：公网地址变了吗

如果路由器自身的外部地址变了，对端任何按源地址过滤的东西现在看到的都是另一个对等体。隧道可能能起来，服务器却仍在丢弃流量，这看起来像客户端坏了，实际上是另一端的策略。

记录重启前后的外部地址。两者不同时，问题就从客户端转移到维护允许列表的人身上，在笔记本上重置凭据帮不上忙。

按正确顺序恢复

先完成必要的强制门户登录，再让客户端走它支持的重连流程，而不是直接杀掉进程。观察身份和数据流量是否都恢复，因为这是同一条连接的两个不同阶段。

缓存页面证明不了什么，自己重连上的聊天应用也一样。用一次全新的请求测试你真正在意的端点。中断期间保持直连流量策略生效，因为重连尝试不是封锁。

如果每次重启后都如此，记录比再试一次更重要。把本地地址、网关、外部地址和客户端状态在前后各记一遍，再对比两列。这会把模糊的抱怨变成别人能修的生命周期缺陷，也能止住因为映射超时而第三次更换证书的做法。