VPN 在开车时重新连接：换基站还是换 IP？
基站切换可能让 IP 路径保持完好。比较把隧道一起搬走的客户端与重建隧道的客户端，并读取网络事件，而不是驾驶过程。
开车驶过城镇边缘时通话断了，VPN 图标也在同一刻消失。把它记成“换基站杀死了隧道”很有诱惑力。其实发生了两件不同的事，只有一件与基站有关。无线切换可以让你 IP 地址、默认路由和会话完全保持原样，而真正的地址变化会打断任何无法随之迁移的隧道。比较客户端如何处理第二种情况才是有用的练习，因为它告诉你看到的是设计好的行为还是缺陷。
换基站不一定就是换地址
只要运营商的移动性锚点不变，移动网络就能在切换过程中保持分组会话存活。无线链路变了，隧道毫无察觉，任何日志里都不该出现重连。这是城市内移动的普通情形。
真正改变地址的是锚点之间的迁移、从 Wi-Fi 切到蜂窝网络，或长时间中断后运营商侧重建隧道。这些事件替换了你数据包携带的源地址，VPN 对端会看到一个已经移动的对端。
实际结论是：移动并不构成证据。开过四十公里的设备可能全程只用一个地址，而停在原地的设备可能因为网络自己的决定换了两次地址。记录事件才是区分两者的唯一办法。
两种设计：把隧道搬走，或者重建它
客户端对“外层源地址变了”的在意程度不同。有些把隧道绑定在建立时的地址上，要求完整重建。另一些独立验证每个数据包，只更新回复发往何处。
| Mechanism | Behaviour after the source changes | What the user notices |
|---|---|---|
| WireGuard | Endpoint updated on the next authenticated packet | Usually nothing; the tunnel continues |
| IKEv2 with MOBIKE | Security association moves to the new address | Short pause, no re-authentication |
| OpenVPN over UDP with float | Peer address may change without a restart | Might survive, depending on timing |
| Client bound to one address | Session dies and is rebuilt | A visible reconnect and a new authentication |
第一行解释了很多令人困惑的报告。WireGuard 没有可被破坏的会话：每个数据包都携带对端索引并通过认证，因此从新地址到达的合法数据包按定义就来自该对端，记录中的端点会随之更新。整段行程始终显示“已连接”的客户端说的是实话。
最后一行也不是缺陷。重建会话会针对当前地址重新执行认证，而这正是当地址可能已归属他人时你想要的结果。
观察事件，而不是移动
在 Android 上，连接子系统把网络变化报告为事件，这正是你应该与客户端行为关联的东西。转储很长，但相关部分是默认网络及其地址：
adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40服务器侧对漫游情形有直接测量。WireGuard 会按对端保存最后认证的端点，因此地址变化表现为数值改变，而不是重连：
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakes比较行程前后的端点。如果地址和端口没变，隧道根本无需动作，重连来自别处，通常是应用。如果端点变了，而握手时间戳仍接近正常的密钥更新间隔，说明隧道是迁移而非重启。
重启看起来不同：握手时间戳会重置为重连的那一刻，客户端记录的是初始化序列，而不是安静的延续。
什么时候重连才是正确行为
把每次重连都当故障，会导致配置去维持已经死掉的会话。因为网络重新分配而换了地址的对端，不应继续接收旧映射的流量；而默默继续的客户端可能在图标仍为绿色时把流量送进黑洞。
从用户角度比较两种失败。重连的代价是几秒钟和一次重新认证。陈旧隧道的代价是一个毫无报错却卡住的应用，这更难解释，也更可能被报告成“网络坏了”。
底下还藏着一个策略问题。在丢失一条路径与建立另一条路径之间的空档里，有些客户端会退回直接发送流量。阻止这一点是与自动恢复分开的另一个控制项，而客户端可能擅长其中一个、不擅长另一个。先决定你需要哪一个，再去调整它们。
把观察到的顺序写下来
有用的报告会点明事件来源：带新地址的默认网络变化、从 Wi-Fi 切到蜂窝网络，或完全没有地址变化的切换。然后它说明客户端做了什么，时间戳取自服务器侧而不是凭记忆。
如果隧道迁移了，就明说，并记录新的端点族。如果它被重建，就记录认证是否首次尝试即成功、空档持续了多久。这三点能区分健康的移动设计与在网络之间来回摇摆的客户端。
除非设备日志真的证实，否则避免使用“换基站”这个说法。Android 连接文档描述了区分可用性与默认网络变化的回调，而那正是你报告所需的区别。其余都只是关于开车的故事。