同时运行两个 iPhone VPN：哪一个承载你的流量？

两个 VPN 应用都显示“已连接”，人们便以为流量现在同时经过两者，一个套在另一个里面。通常并非如此。iOS 有特定的共存模型，而它不是一条链。一类配置只允许启用一个实例，另一类可以与其并存，路由优先级负责裁决冲突。两个亮着的开关并不意味着两跳。这个模型是有文档的，因此路径可以预测，而不是从图标上猜。

误区：两个已连接的 VPN 就是一条链

两跳链路需要明确的外层传输、明确的内层隧道、兼容的端点路由，以及任一环节失败时的预案。两个独立配置同时存在，并不会自动形成这种结构。路由优先级不等于封装；某个配置赢得路由查找，也说明不了另一个配置是否承载了最终的数据包。

如果你需要嵌套，就把它当作嵌套来设计。不要凭两个连接指示灯推断出嵌套。分清这一点能省下大量排查时间。

这个误区背后的文档模型

Apple 的 NETunnelProviderManager 描述了常规企业 VPN 配置，并指出同一时间只能启用一个该类型配置。同一份文档允许 Personal VPN 保持启用并与之并存，且在两者重叠时让企业路由优先。

这里的 Personal VPN 是通过 NEVPNManager 管理的内置 IPsec 或 IKEv2 实现的 API 术语。NETunnelProviderManager 则是隧道提供方模型。消费级应用也可以使用提供方模型，所以产品名里带 personal 并不能据此归类。

Apple 记录了一种被允许的组合，而“允许”并不等于两家厂商的配置兼容，所以要问清每家厂商支持哪一对组合。它们的配置类型、路由和策略仍然决定最终结果。

误区：个人 VPN 会拿到浏览流量

一个宣称接管所有目的地的办公配置，也会赢得公共浏览的路由查找，于是个人出口什么都承载不到。按文档规定的优先级，企业路由在冲突处胜出，因此公共浏览不会仅因为那个应用也报告已连接就自动走个人出口。更窄的办公配置可能改变路由格局，但组织方客户端仍可强加 DNS、拦截或设备要求。这些要求应向它的所有者索要受支持的安排，而不是在本地改动。

受管理的按应用配置有各自的范围。不要把设备级规则外推到每一个受管理部署。

测试前写下两条流量：办公服务的私有名称与网段，以及一次全新的公共浏览请求。两者都合理，但需要不同的检查。

分隧道办公配置下的路由优先级

分隧道办公配置会接管它列出的私有前缀和内部 DNS 后缀，这些路由会赢得与之匹配的任何查找。不匹配任何企业路由的公共目的地会落到物理链路，除非个人 VPN 先接管它们。优先级规则只裁决重叠的匹配，所以这两个配置必须当作路由表来读，而不是当作图标。

把这一对写成两行，并写明各自的预期胜出者：解析到 10.x 或 172.16.x 的办公主机名应走企业隧道，而没有匹配前缀的公共地址应走剩下的默认路由。如果两行写的是同一个出口，这种分离就没有做到文档描述的效果。

写下两条流量并逐条验证

对每条流量，记录哪个已批准的配置应当承载它，以及每类名称应由哪个解析器接收。然后用新请求验证，而不是用缓存的办公页面或旧的 IP 结果。

停用一个配置，再重复两条流量。失败时的行为是设计的一部分，也正是用户会注意到的部分。当两家提供方都无法支持这种组合时，选定一个已批准的配置并记录它承载哪条流量，或者转向受管理的单隧道设计。NETunnelProviderManager 文档是共存规则的来源。