VPN 客户端里的「Keepalive」「心跳」「Dead Peer Detection」要回答的不是「网站会不会卡」，而是：**隧道在空闲一段时间后，你怎么知道对端或中间路径是否还活着，以及判定失效后如何重连。**2026 年常见误判是把状态栏的「已连接」当成路径健康证明。读这类选项时，先分清：你在缩短发现静默断线的时间，还是在改变断线之后的流量闸门——后者属于 Kill Switch，不是保活本身。
Keepalive 到底在防什么
一个可独立引用的定义句：Keepalive（保活）是按间隔发出的探测或空闲流量，用来刷新中间状态、发现对端失效，并在超时后触发重协商或重连。
它主要针对这类静默失效：
- 家庭或运营商 NAT 对「长时间无流量」的 UDP/TCP 映射表项过期；
- 公司或酒店防火墙对空闲会话的空闲超时；
- 对端进程崩溃、节点重启，本端仍以为会话有效；
- 蜂窝网切换、休眠唤醒后，旧五元组已不可用，但界面未刷新。
这与 VPN 是什么 中的模型一致：加密隧道是端到端的逻辑通道；中间网络仍可能按自己的空闲策略丢掉映射，而不给你发一条「已断开」的友好通知。
三个常被混用的词
客户端文案往往混用英文缩写。按下表分开读更清楚：
| 说法 | 更精确的含义 | 典型后果 |
|---|---|---|
| Keepalive / 心跳 | 周期性探测或填充流量 | 刷新 NAT/防火墙状态，或提前发现失效 |
| Dead Peer Detection（DPD） | 超时未应答则判对端失效 | 拆除旧会话，进入重连或失败态 |
| Auto-reconnect | 判定失效后自动再握手 | 恢复隧道；窗口期内是否泄漏取决于 Kill Switch |
保活回答「怎么发现坏了」；自动重连回答「坏了之后要不要再连」；Kill Switch 回答「坏了之后流量还能不能走物理网卡」。三者常一起出现在同一设置页，但解决的是不同问题。
为什么空闲会「假连接」
许多路径对 UDP 尤其不友好于长空闲。WireGuard、部分 OpenVPN UDP 模式以及商业客户端的默认隧道，外层常是 UDP（参见 VPN 用 TCP 还是 UDP）。中间设备若在数分钟到数十分钟无包后回收映射，后续数据包会丢在半路，而本端加密状态机仍认为「密钥还在」。
表现为：
- 状态仍显示已连接；
- 新打开的网页长时间转圈或超时；
- 已有连接可能半死不活，直到应用层超时；
- 你手动断开再连，或发送任意隧道流量后「突然又好了」。
测试环境写法示例：2026 年 9 月，同一设备、同一节点，先建立隧道并确认可访问检测页；静置 10～30 分钟不产生业务流量，再刷新检测页。记录是否在蜂窝网、酒店 Wi-Fi 或家庭宽带，以及客户端 Keepalive 间隔（若可见）。
对照表：常见策略与取舍
| 策略 | 在做什么 | 更适合 | 代价 | | --- | --- | --- | | 较短间隔心跳 | 更频繁刷新中间状态 | 严格 NAT、易空闲超时的网络 | 耗电、信令与可能的流量计数 | | 较长间隔或仅业务驱动 | 有真实流量时才刷新 | 电量敏感、路径很少掐空闲会话 | 静默失效发现更晚 | | 显式 DPD 超时 | 无应答则判死并拆会话 | 需要快速失败好触发重连 | 偶发丢包可能误判，需配合重试 | | 仅依赖应用层超时 | 不做隧道级探测 | 实现极简的协议路径 | 「假连接」窗口更长 |
「更适合」不是排名。同一品牌在桌面与手机上的默认间隔、是否允许用户改、是否在省电模式暂停心跳，往往不同；以你设备上的实际行为与文档为准。
和延迟、MTU、DNS 不要混为一谈
读 VPN 延迟：RTT、抖动与丢包 时，RTT 升高说明路径变差；Keepalive 失败说明控制面或探测路径已经认为会话不可用。两者相关，但不是同一指标。
同样：
- MTU 不匹配 常表现为大包失败、小包仍通——不是「空闲后整条隧道假死」的典型画像；
- DNS 或双栈旁路会让「测速像通、站点不像通」——那是解析与路由问题，换 Keepalive 间隔通常无效；
- Kill Switch 过严时，重连窗口内你可能「完全上不了网」，看起来像保活失败，其实是闸门在工作。
排障时先问：是从未握手成功、空闲后假连接，还是断线后流量回落？再决定动哪一档选项。
怎么验证保活与重连是否按预期工作
不要只看设置页数字。用可复现步骤制造空闲与断线。
建议流程：
- 连通基线：开启 VPN，确认检测页显示隧道出口，记下客户端版本与 Keepalive/DPD 相关选项；
- 空闲静置：停止主动浏览与大下载，静置一段长于常见 NAT 超时的时间（许多家用场景可从 10～15 分钟起试；公司网可能更短或更长）；
- 空闲后探测：刷新未缓存的检测页或对隧道内地址发一次探测。期望是仍通，或在短暂重连后恢复，而不是长时间假连接；
- 制造明确断线：临时阻断到节点的路径（例如切换网络、飞行模式数秒再恢复），观察是否自动重连、耗时多久，以及窗口期内真实 IP 是否暴露；
- 对照省电与休眠：笔记本睡眠唤醒、手机切后台后再测一次。许多「早上起来还显示已连接却打不开网页」发生在唤醒后的旧会话上。
结果怎么读
| 现象 | 更可能的含义 | 下一步 |
|---|---|---|
| 空闲后仍通，无需手动重连 | 当前间隔与路径匹配尚可 | 换网络类型再测一次 |
| 空闲后假连接，手动重连才好 | 心跳过疏、被省电暂停，或中间超时严于间隔 | 按文档适度缩短间隔或关闭错误的省电限制 |
| 频繁无故重连 | 间隔过密、误判丢包，或节点不稳定 | 放宽 DPD、换节点、先看丢包基线 |
| 重连数秒内出现真实 IP | 自动重连窗口缺少出站闸门 | 验证 Kill Switch，而不是只调心跳 |
| 一开保活就耗电明显 | 间隔过短或实现轮询过勤 | 在「发现速度」与耗电之间折中 |
无法确认中间设备策略时，写「据本次网络实测」，不要断言具体运营商超时秒数。
配置时的务实取舍
更值得关注保活的情况：
- 你经常挂机很久再继续用同一条隧道（远程桌面、长会话下载、夜间挂机）；
- 主要网络是运营商 NAT、酒店 Wi-Fi 或对 UDP 空闲不友好的环境；
- 你依赖「显示已连接」做安全假设，需要把假连接窗口压短。
可以保持默认或偏长间隔的情况：
- 电量敏感、且业务本身持续有流量；
- 路径很少对空闲会话动手，过密心跳只增加噪声；
- 客户端在省电模式下会暂停心跳——此时应先读清行为，而不是盲目改数字。
据各客户端文档，选项可能叫「Keepalive」「Heartbeat」「DPD」「Persistent keepalive」「自动重连」等；WireGuard 语境下常见的是对端持久保活间隔，OpenVPN 等则可能分开配置 ping 与超时。以实际文档与抓到的周期性探测为准，不要只凭按钮文案推断。
建议怎么纳入日常检查
把「空闲后再访问一次检测页」和 Kill Switch、DNS 泄漏放在同一清单里：换客户端大版本、换主力网络、系统大更新之后各测一次。先确认空闲后隧道仍可用或能自动恢复，再比较节点快慢；否则你优化的是稳态延迟，假连接窗口仍在。
对断线后的出站闸门，继续读 Kill Switch 是什么；对外层传输层选择，参见 VPN 用 TCP 还是 UDP。保活是发现与维持会话的旋钮，不是加速开关，也不是隐私总闸。