keepalive 不是重连：按你遇到的故障来选

keepalive 和重连常常被一并配置，却解决不同的问题，所以调整其中一个很少能修好另一个。keepalive 发送少量流量，让状态条目保持存活，或者察觉对端已停止应答。重连则会拆掉坏掉的部分，重新建立关系，包括密钥、地址和路由。要选与故障相匹配的机制，而不是你已经熟悉旋钮的那个。两个问题决定它：路径是死了，还是对端之间有东西把它忘了？

当映射才是问题

只在静默几分钟后才断掉的隧道，通常丢失的是转换条目，而不是对端。WireGuard 的PersistentKeepalive正是为 NAT 和防火墙状态而存在，项目自己的说明也是这样描述它，而不是把它当作健康检查。几十秒的间隔能让条目保持温热，而每秒一个包则是电池决策，不是可靠性决策。OpenVPN也通过ping和ping-restart到达同一处，它们先察觉静默，再据此行动。

这些设置在不同协议之间也不能互换。IKEv2 的死对端策略、OpenVPN 的 ping 计时器和 WireGuard 的 keepalive 用三种语法和三种默认值回答同一个问题，因此在它们之间照搬数字，是披着调优外衣的猜测。

当关系已经消失

如果对端更换地址、凭据过期或远端重启，小数据包并不是修复手段。重连必须重建状态：取得地址、重新安装路由、重新协商密钥，在部分部署中还要重新认证用户。

无人值守重连的客户端持有证书或已保存的密钥。会去询问人的客户端，恰好在没人时失败，而那正是重连真正重要的场景。这是几个月前做出的设计选择，不是故障期间能改的设置。

两者都不能证明什么

隧道可以已重连、有密钥、有路由，而它背后的服务已经停了；keepalive 也可以为服务器几小时前就消失的会话维持映射打开。当你真正在意的东西不可用时，两种机制都可能报告成功。

所以测试要落在真实请求上。在你关心的间隔之后，通过隧道发点东西，然后单独触发你设计过的故障：映射场景用空闲时段，重连场景用重启或地址变更。

阻止直连流量是另一个决定

重连循环可以完全健康，而应用却在悄悄走普通路由，那是泄漏而不是故障。如果要求是任何东西都不许离开隧道，就在客户端配置里明确写出来，并通过断开隧道、观察还有什么在连接来证明。两种机制都不蕴含这种行为，再多重试纪律也建立不了它。

记录哪种机制运行过，以及之后新请求是否成功。下一个工程师需要的正是这两件事，而它们在状态图标里都看不到。一行写着客户端已重连的日志，不等于一个成功通过的请求。

写清策略，而不只是数字

把这一对写进一句话：空闲间隔、存活阈值、什么触发重建，以及客户端在重试期间做什么。没有这句话，将来每次故障都会重开同一场争论：是 keepalive 太短，还是重连太慢。

WireGuard 关于限制的说明是有益的提醒：keepalive 是针对中间盒的绕行办法，而不是通用的存活设计。在因为它解决不了某个问题而提高频率之前，先读一读那条限制。