WireGuard 空闲后失败：先测方向

在改动任何设置之前，有四个问题：客户端活跃时同一资源是否可用、空闲期持续了多久、设备是否休眠或更换了网络、故障是否只出现在对端主动发起的流量中。答案能把过期的 NAT 映射、休眠的无线网卡和过期的应用区分开。它们也能说明 keepalive 是否相关。先从方向入手，因为它只需一条命令，就能排除一半可能原因。

哪个方向失败？

客户端新发起的出站请求与安静期后到达它的入站流量，对有状态设备的考验并不相同。出站数据包离开时会重建映射，入站数据包则依赖旧映射仍然存在。这种不对称正是全部测试。若客户端能出不能进，映射很可能已过期；若两个方向都不通，则是隧道或客户端的网络访问没了。

记下安静期持续了多久，以及设备是否休眠或在这期间换了网络。这两个事实会在任何设置之前改变判断。

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

在安静期前后各运行那三条命令，因为它们回答问题的不同部分。没有变化的 handshake 时间戳说明双方停止了通信，而 发生变化的端点说明映射是移动了而不是消失了。传输计数器显示是否有数据到达，这正是旧映射与沉默应用之间的区别。在两个时间点都记下数字，因为对比就是证据。

休眠、无线网卡与应用状态

在手机或笔记本上，休眠的设备可能已经完全失去网络访问，keepalive 既无法恢复已关闭的无线网卡，也无法完成尚未通过的强制门户。移动平台会按策略暂停后台工作，因此周期流量能否继续取决于平台以及应用与平台协商的结果。缓存连接是第三种情况，也最具误导性，因为隧道恢复并不等于应用重新连上它。

空闲期结束后重新打开应用，而不是相信一直开着的标签页。如果新请求在旧会话失败的地方成功，隧道就从来不是问题。

keepalive 究竟做什么

PersistentKeepalive 会定期向对端发送经过认证的空包，足以让对端之间的 NAT 映射保持存活，并让对方的端点保持最新，正如 WireGuard 快速入门 所述。它修不好休眠的无线网卡、丢失的路由或从不重试的应用。请通过受支持的客户端设置选择间隔，不要仅因状态显示安静就在所有地方启用激进的值。

大多数空闲期并不是故障。沉默五分钟后再连接的隧道行为正常，问题只出现在本该有数据从对端到来的情况。

等过曾经失败的那段时间

只做一项受支持的更改，然后让同样的空闲时间过去，再重新测试该资源。等待是测试的一部分，不是形式。重连后立即成功说明不了长时间空闲的问题，因为重连正是重置状态的事件。如果问题在活跃使用时也出现，应回到 handshake 和数据路径检查，而不是增加更多周期流量。

每次测试只保留一项更改，并记录所用的空闲时长。否则之后的每次对比都会漂移，没人能说清哪项更改起了作用。把四个事实一起记下：方向、时长、休眠状态和应用行为。