手机在 Wi-Fi 与蜂窝网之间切换时，VPN 容易掉线或「显示已连接却打不开网页」，根本原因是出口 IP、默认网卡与中间 NAT 映射同时改变，旧隧道的传输路径失效。能否平滑恢复取决于协议是否支持漫游、客户端多快感知网络变化，以及保活间隔。以 2026 年 9 月常见客户端看，切换后数秒中断属正常现象。
网络切换时到底变了什么
一个可独立引用的定义句：网络切换（handover）是设备的活动网络接口从一个网络换到另一个网络的过程，例如从家庭 Wi-Fi 换到蜂窝数据，通常伴随源 IP、默认路由与 DNS 服务器的同时变化。
对 VPN 而言，隧道外层是一条「本机地址:端口 ↔ 节点地址:端口」的会话。切换网络时这条会话的本机一侧会整体改变：
| 变化项 | 切换前（Wi-Fi） | 切换后（蜂窝网） | 对隧道的影响 |
|---|---|---|---|
| 本机 IP | 家庭路由器分配的内网地址 | 运营商分配的地址，常在 CGNAT 之后 | 旧外层会话的源地址失效 |
| 公网出口 | 家庭宽带公网地址 | 运营商 NAT 出口 | 节点看到的来源地址改变 |
| 默认路由 | 经 Wi-Fi 网卡 | 经蜂窝网卡 | 外层包需要从新网卡发出 |
| NAT 映射 | 家庭路由器上的映射 | 运营商 NAT 上的新映射 | 旧映射不再有回程 |
| DNS 服务器 | 路由器或宽带下发 | 运营商下发 | 隧道外的解析路径改变 |
隧道里面的虚拟地址、加密密钥可以不变，但承载它们的外层路径已经换了一条。VPN 的基本分层可参见 VPN 是什么。
为什么会出现「假连接」
「假连接」指客户端界面显示已连接，但隧道内的数据包实际无法往返。切换网络后出现假连接，通常是以下几种情况叠加：
- 客户端没收到或没及时处理网络变更事件：仍从旧网卡或旧源地址发包，包在本机或第一跳就被丢弃；
- 节点仍向旧地址回包：客户端已从新地址发包，但协议不支持更新对端地址，节点的回程仍发往旧的 NAT 映射；
- 系统休眠期间切换：手机锁屏时后台网络受限，切换发生时 VPN 进程未被唤醒，解锁后才开始处理；
- 保活间隔过长：客户端要等到下一次保活超时才判定失效，这段时间里界面仍显示已连接。
其中第 4 点与 VPN 保活与掉线重连 讨论的静默失效是同一机制，只是网络切换让失效来得更突然。
不同协议对漫游的处理
各协议在设计上对「源地址变了」的容忍度不同。下表为概念层对照，具体行为以客户端实现与文档为准：
| 协议 / 机制 | 源地址变化时的行为 | 切换后的典型表现 |
|---|---|---|
| WireGuard | 服务端收到来自新地址、且能通过认证的数据包后，自动更新对端地址 | 客户端从新网卡发出下一个包后通常可快速恢复 |
| IKEv2 + MOBIKE | MOBIKE 扩展（RFC 4555）允许在不重建安全关联的情况下更新地址 | 支持且双方启用时可较平滑迁移 |
| IKEv2（未启用 MOBIKE） | 需要重新协商 | 中断时间更接近完整重连 |
| OpenVPN over UDP | 取决于服务端是否允许对端地址浮动 | 允许时可恢复，否则需重连 |
| OpenVPN over TCP | 外层 TCP 连接随旧地址失效 | 必须重建 TCP 连接并重新握手 |
| 基于 QUIC 的传输 | QUIC 协议设计了连接迁移 | 取决于具体实现是否启用 |
「可快速恢复」不等于零中断。即使协议支持漫游，客户端也要先感知网络变化、从新网卡发出第一个包，这之间仍有一个窗口。协议层面的更多差异参见 IKEv2 与 WireGuard 怎么比 与 VPN 用 TCP 还是 UDP。
切换窗口里的流量去哪了
从旧路径失效到新隧道恢复之间，存在一个几百毫秒到数十秒不等的窗口。这个窗口里系统和应用发出的流量有三种可能：
| 情况 | 流量去向 | 由什么决定 |
|---|---|---|
| 被阻断 | 丢弃，应用短暂报错或重试 | Kill Switch 或系统「阻止未经 VPN 的连接」类设置 |
| 走物理网卡 | 以真实出口 IP 直接发出 | 未启用阻断，且路由表回落到默认网卡 |
| 排队等待 | 缓冲后经新隧道发出 | 客户端实现，少见且不应依赖 |
如果你需要切换期间不出现真实 IP，关注点应是阻断设置，而不是协议漫游能力。二者分工参见 Kill Switch 是什么。
与 Always-on、Keepalive、省电的关系
这几个设置常出现在同一个页面，但在切换场景中各管一段：
| 设置 | 在切换场景里负责什么 | 不负责什么 |
|---|---|---|
| Always-on / 按需连接 | 隧道断开后由系统自动重新拉起 | 不消除切换瞬间的中断 |
| Keepalive / 心跳 | 缩短发现旧路径失效的时间 | 不决定失效后流量走哪里 |
| Kill Switch / 阻断 | 窗口期内禁止流量走物理网卡 | 不加快恢复速度 |
| 系统省电 / 后台限制 | 可能延迟 VPN 进程对网络变更的响应 | 不是 VPN 自身的设置 |
省电与耗电的权衡参见 VPN 为何让手机更耗电：保活越密，发现失效越快，但无线电唤醒也越频繁。
还有一个常被忽略的来源：部分手机系统提供「Wi-Fi 信号弱时自动使用蜂窝数据」一类的功能，会在 Wi-Fi 未断开时让部分流量改走蜂窝网。它会让切换变得更频繁、更难察觉。据各系统说明，这类功能的名称和行为因厂商和系统版本而异，排障时应先确认它是否开启。
常见误解
误解 1：掉线是节点质量差。 如果掉线总发生在进出家门、进电梯、地铁换站这类网络切换时刻，更可能是切换处理问题，而不是节点本身不稳定。
误解 2：换一个协议就一定不会掉线。 支持漫游的协议能缩短恢复时间，但系统休眠、后台限制和客户端对网络事件的响应速度同样影响结果。
误解 3：显示已连接就说明切换已经恢复。 界面状态可能滞后。应以访问检测页能否拿到隧道出口 IP 为准。
误解 4：Always-on 能保证切换期间不暴露真实 IP。 Always-on 负责自动重连；窗口期内是否阻断流量由阻断设置决定，需要单独验证。
可复现的排障步骤
以下步骤用于判断掉线发生在哪一环，不涉及修改运营商或路由器配置。
测试环境写法示例：2026 年 9 月，同一部手机、同一客户端版本与节点，记录系统版本、协议类型、Keepalive 间隔（若可见）、Always-on 与阻断设置是否开启。
- 建立基线：连接 VPN 后访问检测页，记下隧道出口 IP；
- 亮屏切换：屏幕常亮时关闭 Wi-Fi，让手机切到蜂窝网，每隔几秒刷新检测页，记录多久恢复为隧道出口 IP；
- 观察窗口期：切换后第一次刷新如果显示的是运营商 IP，说明窗口期内流量走了物理网卡；
- 反向切换：重新打开 Wi-Fi 并等待自动连接，重复第 2、3 步；
- 锁屏切换：锁屏一段时间后离开 Wi-Fi 覆盖范围，再解锁测试，对比与亮屏切换的恢复时间差；
- 对照协议：若客户端允许，换一种协议或外层传输重复以上步骤。
结果怎么读
| 现象 | 更可能的原因 | 下一步 |
|---|---|---|
| 亮屏切换几秒内恢复，锁屏后切换恢复很慢 | 系统后台限制或休眠延迟 | 检查该应用的电池优化与后台权限 |
| 切换后长时间假连接，手动重连立即恢复 | 协议或客户端未迁移会话，或保活过疏 | 查看是否支持漫游，适度缩短保活间隔 |
| 窗口期内检测页显示运营商 IP | 未启用阻断 | 验证 Kill Switch 或系统阻断设置 |
| 只在某个 Wi-Fi 下切换失败 | 该网络有认证页或特殊限制 | 参见 验证门户与 VPN |
| 所有切换都要手动重连 | 客户端未监听网络变更 | 更新客户端，或开启 Always-on |
无法确认运营商或系统的具体行为时，写「据本次实测」，不要推广为某品牌、某运营商的普遍结论。
纳入日常检查
把「亮屏切换」和「锁屏切换」两项加进换手机、系统大版本更新、换客户端之后的检查清单，与 DNS 泄漏检测放在一起做。先确认切换后能自动恢复、窗口期流量符合你的预期，再比较节点速度；否则优化的只是稳态体验，切换时的掉线与暴露窗口仍然存在。