WireGuard 中的 PersistentKeepalive 有什么作用？

WireGuard PersistentKeepalive 在某个 peer 达到出站空闲间隔后发送认证空包，用于维持 NAT 或状态防火墙映射，使其后的 peer 空闲时仍可达。它不检测互联网健康、不修复断路，也不保证应用会话连续。

VPN 完整指南介绍整条受保护路径。本文只解释这个可选的逐 peer 定时器，帮助你判断空闲连接是否需要它。

关键要点

• PersistentKeepalive 默认关闭，并且按 peer 单独配置。
• 只有出站方向达到空闲间隔时，它才发送不含应用载荷的认证包。
• 它用于刷新 NAT 或状态防火墙状态，不是隧道健康检查。
• 25 秒是官方常用示例，并非适合所有网络的固定值。
• 通常由需要在 NAT 后保持可达的 peer 发送；到处启用只会增加流量和唤醒。

WireGuard PersistentKeepalive 到底是什么

wg(8) 将 PersistentKeepalive 定义为 1 到 65,535 秒的可选间隔。若达到间隔仍未向该 peer 发出流量，WireGuard 就发送认证空包。零或 off 会禁用它，而且默认关闭。［1］

“认证”表示该包属于既有 peer 关系并通过正常密码学处理；“空”表示没有隧道应用载荷，外层仍是带协议开销的 UDP 数据报。因此应用未产生数据时，抓包仍会看到少量流量。

设置属于具体 peer，不是接口共用的全局心跳。同一设备可能只须对一个远端保活，对稳定公网 peer 则不需要。间隔由配置方决定，远端不能命令其采用某个周期。

这也符合VPN 协议对比里的分层：WireGuard 负责加密 UDP 隧道和 peer 状态，操作系统、接入网络及应用各自还有独立的计时器和故障行为。

为什么空闲的 NAT 与防火墙状态会过期？

许多客户端位于路由器后。路由器把私有源地址和端口转换为临时公网映射；状态防火墙也保存记录，以允许匹配的 UDP 返回包。设备无法永久保留不活动流，会按实现和策略在空闲后删除状态。

家庭 peer 先向服务器发包时，路由器建立映射，服务器便能回复。若双方在映射过期前没有足够流量，服务器后来主动发送的包可能无法匹配现存状态。它虽记得上次的外层地址，但该地址与端口已不是可用返回路径。

WireGuard 白皮书说明：当 NAT 或状态防火墙后的 peer 必须在空闲时保持可达，保活包就有用。白皮书同时强调，多数 peer 不应发送这类包，因为 WireGuard 原本会在没有数据时保持安静。［2］这种静默能节省带宽，也让电池设备更充分地休眠。

图例：1 是边缘设备后处于安静状态的 peer；2 是临时 NAT 或状态防火墙映射；3 是之后可能需要主动回传数据的远端 peer；4 是空闲间隔到期后用于刷新映射的认证 UDP 空包。箭头只表示数据报方向，不表示健康检查的响应。

为什么普通流量可能已经足够

每个有效的 WireGuard 出站包都能刷新相关网络状态。通话、文件传输或频繁请求可能无需专门保活便能维持映射。只有隧道静默后仍须接收远端流量时，定时器才有价值。

“隧道全天有流量”和“空闲 peer 全天可达”是两种需求。应测试空闲场景，不要因为周期包听起来像通用可靠性开关就启用它。

为什么常见值是 25 秒但不必固定？

手册和官方快速入门都把 25 秒列为维持许多 NAT、防火墙映射的合理示例。［1］［2］它短于常见 UDP 空闲超时，但并非协议常量。WireGuard 接受其他非零值，真实网络也可能更早或更晚删除状态。

间隔越短，数据报与设备唤醒越多；越长则可能让中间设备先删除映射。合理值应低于实际空闲超时并留有余量；不同网络设备的时限可能不同。

不要用 ping 延迟推算该值：它无法说明空闲 UDP 映射保留多久。把间隔设成一秒，也不会修复拦截或错误路由。

场景	通常如何设置	原因
公网可达的服务器	通常关闭	已能接收新的认证发起包
只主动发起流量的 NAT 后客户端	通常关闭	新出站流量会按需重建状态
空闲后仍须接收数据的 NAT 后客户端	通常有用	周期出站包可维持返回映射
持续双向传输的隧道	通常不需要	现有流量会刷新状态
路径封锁 UDP	无法补救	增加 UDP 包不会解除封锁

PersistentKeepalive 不会做什么

PersistentKeepalive 不是要求远端作答的回显请求。发送方不能因为发出了包就判断“连接健康”。最近握手时间和收发计数可提供观察线索，但保活包本身不是完整的存活协议，也不会验证 DNS、路由、互联网接入或应用可达性。

它也不负责选择远端地址。Endpoint 说明讨论外层 IP 或主机名及 UDP 端口。保活包同样不会决定某个内层目的地属于哪个 peer；那是 AllowedIPs 以及独立系统路由的工作。

设备从 Wi-Fi 切到移动网络后，新路径和源映射要通过认证流量被远端学习，这属于 WireGuard 漫游机制。保活可能更早触发有用流量，也能维持当前 NAT 条目，但它并不定义 peer 身份或漫游规则。

有效的 WireGuard 隧道也不等于每个应用都连续。TCP 会话、实时媒体、DNS 缓存、门户认证、操作系统休眠以及应用重试策略，都可能在外层路径变化时作出独立反应。

应由哪一侧发送

先确认可达性需求。如果 NAT 后的 peer 必须接收由远端发起的流量，就在 NAT 后这一侧配置保活。它发出的包会刷新远端数据返回所需的状态。只让公网服务器周期发送，不一定能重建私网一侧已经消失的映射。

如果双方都能随时主动发起认证流量，并且空闲时不需要接收未预期流量，就保留默认关闭。如果两侧都在独立 NAT 后，至少仍要有一侧知道另一侧可用的初始 Endpoint；当双方都无法寻址时，周期流量不能凭空创造路径。

wg-quick(8) 可以根据 AllowedIPs 推导操作系统路由，但该自动化与保活定时器无关。［3］路由可能存在而 NAT 映射已经陈旧，映射也可能有效但系统选错路由。排障时应逐层区分。

想了解托管客户端在闲置后的表现，可以在位于同一 NAT 后的手机上连接 AethoVPN，让它闲置到足以令你自己的 peer 断开的时长，然后加载一个页面，记录它是立即恢复、重新连接，还是需要手动重试。再换一个位置重复一次，避免单台繁忙服务器影响结论。该产品没有文档说明 keepalive 设置，也不承诺连接零中断，所以要记录客户端的实际表现，而不是假定存在 25 秒的间隔。可用邮箱开始免费试用来做闲置测试。

怎样判断是否真是保活问题

先比较活跃与空闲表现。如果持续传输一直正常，但安静到一个较稳定的时长后，远端便无法联系客户端，状态过期才是合理候选。记录该间隔，并观察客户端主动发送一个新包后通信是否立即恢复。

接着分开核对证据：

1. 确认 peer 能在当前路径完成认证握手。
2. 确认目标内层地址关联到正确的 peer 和路由。
3. 观察空闲后客户端出站数据能否恢复可达性。
4. 测试低于故障窗口的保守非零间隔。
5. 对比传输计数与抓包，不把“已发送”误当成“已回复”。

如果隧道在持续传输时也失败，根因通常不是空闲映射。此时应检查 Endpoint 可达性、UDP 策略、密钥、时间、路由、MTU 或应用行为。一个窄用途定时器不应掩盖更广泛的故障。

总结

• PersistentKeepalive 在出站方向空闲达到间隔后发送认证空包。
• 它用于保留 NAT 或状态防火墙状态，使特定 peer 继续可达。
• 默认关闭；持续活跃或只需主动发起的 peer 通常无需开启。
• 25 秒是官方示例，不是所有网络的最佳值。
• 它不检测健康、不选择路由、不学习身份，也不保证应用连续。

常见问题

PersistentKeepalive 会发送应用数据吗？

不会。它发送不含隧道应用载荷的认证 WireGuard 包，但仍消耗少量网络流量和处理资源。

PersistentKeepalive 默认开启吗？

不会。零或 off 表示关闭，而且这是默认值。只有明确需要空闲可达时才应设置非零的逐 peer 间隔。

为什么示例常写 25 秒？

这是为了低于许多 NAT 和状态防火墙的 UDP 空闲超时而采用的实用间隔，不是协议常量，也不能保证适合每个网络。

两个 WireGuard peer 都要开启吗？

通常不用。典型发送方是必须保持可达的 NAT 后 peer。只有双方分别存在已验证需求时，才考虑两个方向都设置。

保活包能证明 peer 在线吗？

不能。发包只证明本机尝试了发送。应结合握手时间、计数器、日志和受控流量判断实际可达性。

PersistentKeepalive 能修复 UDP 被封锁吗？

不能。若 UDP 被封锁、Endpoint 错误或路由损坏，周期发送更多 UDP 包不会修复底层条件。

PersistentKeepalive 能让漫游无缝吗？

不能。认证包可在地址变化后触发 Endpoint 学习；保活可以维持或触发路径，但应用会话和操作系统切换有独立的连续性规则。

来源：

1. WireGuard Tools, wg(8): https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
2. WireGuard, “WireGuard: Next Generation Kernel Network Tunnel”: https://www.wireguard.com/papers/wireguard.pdf
3. WireGuard Tools, wg-quick(8): https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8

Sources checked 2026 年 9 月 12 日。

---

延伸阅读：

• 理解完整 VPN 路径
• 比较主要 VPN 协议设计
• 排查 VPN 在设备唤醒后失效
• 区分 WireGuard Endpoint 与隧道路由