启动第二个 VPN 会替换第一个 VPN 的状态

两个客户端、两个“已连接”图标，以及一种认为流量现在同时经过两者的想法。请把这个想法与各平台实际允许的行为对比。手机通常只有一个 VPN 服务席位；桌面系统却可以运行多个客户端，让它们争夺同一套路由和同一个解析器。这两种情况的差别，解释了大多数“启动另一个 VPN 后 VPN 掉线”的报告。

图标描述的是进程，而不是链条。

手机上只有一个席位，桌面上却有多个竞争者

在 Android 上，平台提供的是每个用户配置文件只有一个活动 VPN 的服务模型，因此启动第二个会停止第一个。这是系统在执行自己的规则，而不是任一客户端的缺陷。在桌面系统上，多个客户端可以同时运行，于是它们会争夺路由表、策略规则、解析器配置和虚拟接口。两种结果都是平台按设计正常工作。

两种结果本身都不会产生嵌套隧道。链条需要一条隧道承载另一条隧道加密后的数据包，这是架构，而不是启动顺序的巧合。

第二个客户端会覆盖什么

第二个客户端通常会安装默认路由、添加自己的规则并推送自己的解析器。第一个客户端可能作为一个没有流量的进程继续存在，或者保留一条不再生效的路由。特定域名的路由通常是牺牲品，这就是为什么有些目标仍然可用，而另一些则失败。可见的症状是断线，实际状态却是部分替换。

出口 IP 检查不会揭示这一点。它只报告某个目标对应的一个地址，不会说明哪些路由被覆盖，也不会说明现在由哪个解析器应答。要看到损害，请读取路由表和解析器状态。

嵌套是一种设计，而不是点击顺序

如果目的是嵌套，就要记录每个端点的外层路径、失败策略以及 MTU 后果。要决定当外层隧道断开、而内层仍认为自己已连接时会发生什么。靠幸运顺序启动客户端不算配置，因为下一次更新或重新连接就会改变顺序。嵌套组合需要像其他任何拓扑一样谨慎对待。

当一条连接用于工作、另一条用于个人时，应依赖平台支持的隔离或受管安排。拆掉企业管控并不是分离策略。

用应用来验证，而不是用图标

在实际打算使用的每一种场景中测试真正重要的应用，并把解析器行为和重新连接纳入测试。最终出口地址无法识别每一条被覆盖的路由，绿色图标也一条都识别不了。记录连接的所有者以及实际受支持的组合。

如果某产品明确不支持与另一产品共存，随意更改路由或权限不会带来可维护的部署。它带来的部署只能撑到下一次更新。

写下哪个客户端拥有默认路由、哪个解析器负责应答，以及各自停止时会发生什么。