公网 IP 变了，VPN 就不再转发流量

运营商重新拨号，或上游发生地址转换变更，都会改变 VPN 会话的公网源地址，而客户端本地的私有地址通常原样不动。于是隧道看起来是连着的，却没有任何有用的流量通过。两种观察同时成立，这正是这类报告让人困惑的原因。

按顺序做完四项检查，遇到第一项不通过就停下。

究竟是哪个地址变了

在你获得授权的位置，把本地接口状态与远端设备所看到的源地址作对比。新的公网地址并不意味着出现新的本地网关，本地接口变化也不保证公网源地址发生了移动。中间存在地址转换，说明这是两件相互独立的事实。记录准确的路径和你观察到的时间，因为从旧报告里复制来的地理位置标签回答的是另一个问题。

要具体追问：变的是外层源地址、内层隧道地址，还是两者都变了。只有第一种情况才能解释一个仍在向已不存在的路径发送数据的对端。

让协议自己处理位置移动

不同协议得知对端已移动的方式并不相同，而这个差异决定了你是否应当介入。WireGuard 在收到用该对端密钥认证通过的数据包时，会更新该对端的端点，因此地址变化无需任何配置就能被吸收。IKEv2 在两端都支持的地方用 MOBIKE 达到同样目的。较早的设计则通过重建隧道来恢复。

不该做的是把一条未经认证的消息当作对端身份已经移动的证据。伪造一条声称来自新地址的数据报很容易，客户端却会相信它被引导到了攻击者的端点。真正的机制是经过认证的协议，而不是一条通知。

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

清除过期的外层绑定

当协议确实支持漫游、流量却仍然不通时，障碍往往是中途的状态型设备，也可能是远端的策略。跟踪过旧连接状态的防火墙可能保留着过期表项，而绑定旧源地址的服务器端访问规则会悄悄丢弃新条目。清理映射并重新核对规则，比更换凭据更快。

排查期间要保持必要的阻断。为了测试隧道能否恢复就把策略整个放开，既不能说明原因，也会让部署比你接手时更糟。

用全新的请求重新测试

变更之前建立的应用程序会话撑不过这次变更，因为它所依赖的四元组已经不存在了。恢复之后请生成一个新请求并确认它能够完成，而不是盯着一个停在零的旧下载、断定隧道仍然损坏。正是这一区分解决了这类报告中的很大一部分。

然后把诊断的两半都记下来：上游究竟变了什么，以及哪一个受支持的恢复步骤恢复了流量。下次会更快，而让下次更快的正是这份记录。

如果新请求成功、旧请求再也没恢复，说明隧道已经修好，应用程序只需要重新连接。