WireGuard 的 PersistentKeepalive 怎么设置

大多数人从来不碰 WireGuard 里的 PersistentKeepalive，很多时候也确实没有问题。可是总有那么一天：中午还好好的隧道，到了下午就没动静了，应用上仍显示“已连接”，网页却打不开，要关掉再重新打开 VPN 才恢复。如果你遇到过，那很可能就是 vpn persistent keepalive 这个设置要解决的问题。本文讲清楚它做什么、空闲隧道为什么会失联、怎么选数值，以及要付出什么代价。

文章写给打开配置文件或设置页、想弄明白其中一行的读者，不打算完整介绍协议。想看全貌，可以先读什么是 VPN 协议和WireGuard 与 OpenVPN 对比。这里只聚焦一个数字，以及它背后的原因。

PersistentKeepalive 到底是什么

WireGuard 是一个刻意保持安静的协议。隧道里没有数据要传时，它什么都不发，不像一些老协议那样一直发心跳。这对隐私和电量都有好处，但也有副作用：对路径中间的网络设备来说，一条空闲的 WireGuard 隧道看起来就像一段已经结束的对话。

PersistentKeepalive 是针对每个对端（peer）的可选设置，单位是秒。设成 25，意味着只要这个对端有 25 秒没发任何东西，就会向另一端发送一个空的、经过认证的数据包。这个包不带用户数据，唯一的作用，是让沿途所有设有计时器的设备看到“这条路径还有人在用”。

客户端一侧的最简示例如下：

[Peer]
PublicKey = （服务器的公钥）
Endpoint = vpn.example.net:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

0 表示关闭，也是默认值；1 到 65535 之间的数字表示按该间隔开启。几乎所有人都用 25，这也是 WireGuard 项目文档里针对位于 NAT 之后的对端给出的建议值。后面会解释为什么 25 是个不错的折中。

别把它和 WireGuard 自带的行为混淆。协议本身在收到数据、约 10 秒内又没有东西可回复时，会自动发一个简短的 keepalive，让发送方知道隧道状态正常。但这只发生在已经有流量之后。PersistentKeepalive 则是让对端主动先开口，并且即使长时间一片寂静也持续发送。

空闲隧道为什么会死：NAT 与防火墙的计时器

几乎所有家用路由器、移动网络和公司防火墙都做 NAT，也就是网络地址转换。你的手机往外发一个 UDP 包时，路由器会在表里临时记一条：“来自那台服务器、那个端口的回包，属于这台设备”。正是这条记录，让返回的包能找到回家的路。

表项占内存，所以路由器会在一段时间无人使用后删除它。UDP 没有礼貌的“关闭连接”过程，计时器通常很短。常见家用路由器对 UDP 映射的保留时间大约从 30 秒到几分钟不等，一些运营商网络更激进。比如 Linux 的连接跟踪，对只看到单向流量的 UDP 流用较短的超时，对双向都有流量的则用较长的。具体数字因设备而异，你对当前所用网络的真实数值通常并不知情。

记录消失之后，可能出现两种情况：

1. 你发出去的包仍然能走。 下次你发东西时，路由器会重新建立映射，外部端口可能已经不同。WireGuard 处理得很好，因为它会从已认证的包里学到对端的新地址。
2. 进来的包被丢弃。 如果是对方要先发，比如服务器要把数据推给你的笔记本，路由器里没有对应记录，就直接把包丢了。从你这边看，隧道像是死了，直到你自己发出点什么。

第二种才是麻烦所在：聊天消息迟迟不到，远程桌面唤不醒，手机收不到通过隧道的来电，而你一打开网页问题又消失了。这就是 NAT 映射过期的典型特征，keepalive 的做法是在计时器到期之前刷新这条记录。

运营商级 NAT（CGNAT）让这种情况更常见。当网络服务商把一个公网地址分给许多用户共用，使用 RFC 6598 规定的共享地址段时，你自家路由器之外还有一层转换，其计时器你无法修改。更多内容见在 CGNAT 后使用 VPN。

谁需要设置，谁不需要

规则很好记：在位于 NAT 之后、空闲时仍需要能被访问的那个对端上设置 PersistentKeepalive。

场景	要设 keepalive 吗	原因
手机或笔记本主动连到 VPN 服务器，主要用来上网	通常不需要	你自己的流量就在刷新映射
屏幕空闲时仍要接收推送或来电的笔记本	在笔记本上设置	映射过期后服务器无法联系到你
家里路由器后面的服务器或 NAS，要通过隧道从外部访问	在 NAT 后面的设备上设置	要让路径一直畅通
有固定公网地址的服务器	一般不用	它前面没有会忘记映射的设备
两个对端都在 NAT 后面，通过一个公网对端中转	两边都对公网对端设置	各自都要保持自己的映射
只在你手动开启的短时间内使用的隧道	通常不用	每次都会建立新映射

注意，keepalive 解决的是“能不能被访问”，不是速度。如果只是 VPN 慢，应该看为什么 VPN 这么慢。

数值怎么选：为什么是 25 秒

间隔必须比路径上最短的空闲计时器短，同时又不能短到浪费电量和空口资源。这正是建议值集中在 25 秒左右的原因。

• 太长。 设成 120 秒，也许能赢过保留 180 秒的路由器，却会输给 30 秒就忘记的那台。隧道在有些网络正常、有些网络失效，这是最让人头疼的排查模式。
• 太短。 设成 5 秒，隧道几乎在哪里都能保持，但你要每 5 秒多发一个包，全天 24 小时不停。手机的无线模块每小时要被无谓地唤醒几百次。
• 25 左右。 低于部分设备对无应答 UDP 使用的 30 秒计时器，又足够稀疏，成本很低。如果遇到仍然掉线的顽固网络，试试 15 或 20 是合理的，再往下通常不值得。

举个例子。咖啡馆里的笔记本位于一台 UDP 映射保留 60 秒的路由器之后。关闭 keepalive 的话，你打开一份文档，把电脑放下两分钟，这时同事想访问你通过隧道提供的服务；映射在第 60 秒就过期了，他什么也连不上。如果设置了 25 秒的 keepalive，映射会在第 25、50、75 秒不断被刷新，永远不会过期，同事立刻就能连上。

流量成本很容易估算。一个 keepalive 包很小，加上 IP 和 UDP 头也就几十字节。每 25 秒一个包，一天约 3,456 个包；按每个约 100 字节算，一天大约 350 KB，比打开一个网页还少。它不会吃掉你的手机流量套餐。

代价：电量、隐私与噪声

keepalive 很便宜，但并非免费，值得了解其中的取舍。

电量。 成本不在字节数，而在唤醒次数。深度休眠的手机要发出哪怕一个很小的包，也得先把无线模块唤起，而手机系统会尽量把后台任务合并处理。手机上频繁的 keepalive 可能让一天的耗电明显增加，信号弱的时候尤其如此。如果手机上的 VPN 只用来上网，就把 keepalive 关掉。更全面的内容见VPN 会耗电吗。

隐私。 每 25 秒一个包是一种肉眼可见的节奏。内容是加密的，但观察网络的人可能注意到你和某个地址之间存在类似 WireGuard 的流。VPN 本来就不会向网络运营方隐藏“存在一条隧道”这件事，隐藏的只是里面的内容；没有 keepalive 时也是如此，只是不那么明显。

窄链路上的噪声。 在带宽很紧的链路上，比如按量计费的卫星或机上网络，再小的周期性数据包也会在运营方眼里累积。遇到这样的链路，只在确实需要被访问时才开启 keepalive。

排障：keepalive 是正确的解法吗

动手改之前，先确认症状是否吻合。keepalive 在以下情况有帮助：

• 刚连上时隧道正常，空闲一段时间后就没动静了。
• 只要你自己发出流量，比如打开网页或 ping 一下，隧道立刻恢复。
• 同一套配置在家里正常，换到某家咖啡馆、酒店或某个移动网络就失效。
• 服务器上显示的该对端最近一次握手时间很久以前，而应用里却显示已连接。

建议按这个顺序试：

1. 先查基础。 设备真的在线吗？账号或通行证还有效吗？用户名密码正确吗？提升 VPN 连接稳定性这篇指南讲了这些。
2. 看最近一次握手。 WireGuard 的工具会显示距上次握手过去了多久。很久以前且没有流量，指向映射或过滤问题，而不是密钥错误。
3. 开启 PersistentKeepalive = 25，设在 NAT 后面的一端，然后重连。等待的时间要达到过去导致失效的空闲时长的两倍。
4. 换一个网络测试。 如果移动数据正常、某个 Wi-Fi 不行，原因就在那个 Wi-Fi 的防火墙或计时器。
5. 只有 25 仍然不行时才降到 15-20，并记下哪个网络需要这个值。
6. 如果毫无变化，检查其他原因：MTU 问题、会杀掉后台应用的省电模式，或屏蔽 UDP 的防火墙。关于密钥交换如何进行、卡住的握手是什么样子，见VPN 握手。

如果你用的是 VPN 应用而不是自己的配置文件，很可能根本看不到这个选项。应用通常会选择合理的默认值，或自行处理重连。使用 XPASS 通行证配套的免费 VPNclient 应用时，除非客服另有建议，请保持应用的默认设置；应用可在下载页获取。

常见误区

• 习惯性地两端都设。 公网服务器很少需要，只会让数据包翻倍。
• 为了省电设一个很大的值。 间隔超过网络计时器，效果等于关闭，只是更难预测。
• 设成 1 或 2 秒。 几乎没有网络需要，电量损耗却是实实在在的。
• 把速度慢归咎于 keepalive。 它几乎不带数据，速度是另一个话题，见为什么使用 VPN 后网速会变化。
• 忘了 NAT 可能既在你家也在运营商那里。 家里的路由器和运营商的 CGNAT 都可能丢弃映射，而你能控制的只有自己发出的流量。
• 把 keepalive 与 kill switch 或自动重连混为一谈。 keepalive 只是维持映射，并不会把密钥或会话已真正失效的隧道重新建立起来。

速查表

问题	简短回答
默认值	0，即关闭
常用值	25 秒
设在哪	位于 NAT 之后、需要保持可访问的对端
流量成本	每天最多几百 KB
电量成本	手机上很小但确实存在
能解决	NAT 或防火墙状态造成的空闲超时
不能解决	速度慢、Wi-Fi 差、MTU 错误、账号过期

总结

PersistentKeepalive 是 WireGuard 里一个小小的设置：让对端按固定间隔发送空的认证数据包，使 NAT 路由器和防火墙不会忘掉空闲的隧道。它默认关闭，位于 NAT 之后的对端通常设为 25 秒，几乎不耗流量，只在手机上略微增加耗电。当隧道在空闲后失联、又在你发出流量时立即恢复，就值得启用；如果原因是速度、MTU、账号状态或被封锁的网络，则应从别处找答案。

如果想用简单的预付方式在自己的设备上体验，可以随时看看价格页面。