工作应用要求连 VPN？先查这三层

提示说应用需要 VPN，但应用通常只是在报告症状，而不是说出是什么挡住了它。能产生这句话的有三个不同的主体：应用所访问的私有服务、应用自己的策略代码，以及控制工作资料的系统管理层。是哪一种在发问，决定了你该做什么，而三者之中只有一个能靠连接隧道解决。先找出真正的主体，就能省掉重装一个从来不是问题所在的客户端。

应用自己能查到什么

在假设存在隐藏的平台规则之前，请记住普通应用也能看出 VPN 传输是否处于活动状态。ConnectivityManager 会报告带有 TRANSPORT_VPN 的网络，而缺少 NET_CAPABILITY_NOT_VPN 就告诉任何调用方当前路径是走隧道的。想拒绝在隧道外运行的开发者，用公开 API 就能做到，完全不需要企业级工具。

用这种方式看不到的，是这个 VPN 属于谁。传输标志只说明存在隧道，并不说明它终止在你组织所期望的地方。

服务路径：私有名称与地址

这句话最常见的诚实版本，其实根本不是策略检查。应用要解析一个内部主机名，比如只存在于企业 DNS 视图里的 wiki 或 API 端点，而解析在策略代码运行之前就已经失败。隧道可能已经建立并在转发普通互联网流量，但分离 DNS 把这个名字发给了从未听说过它的解析器。

这里的症状很窄。只有一个主机失败，应用其余的网络调用都正常，而且失败出现在名称解析阶段而不是启动时。内部证书又添了第二种失败模式：固定了组织 CA 的应用，即使数据包正常流动，也会拒绝公共证书。

随便接一个商业 VPN 解决不了上述任何一个问题。它只改变你的出口地址，内部名称照样解析不了。

应用策略层

应用也可以自带一道门。受管配置允许组织下发应用声明的键值对，应用通过 RestrictionManager 读取它们。像必需的配置文件名或允许的网络列表这样的键，完全是开发者自己的设计，由应用代码强制执行，错误提示也由那段代码任意决定。

这一层就是措辞通常会露出马脚的地方。如果提示在启动时立刻出现、早于任何网络调用，并且提到策略、配置文件或管理员，那你看到的很可能是应用逻辑，而不是丢包。

在个人设备上读同样的限制是死路。未受管设备没有限制可读，应用就会回退到它构建时的默认值。

平台层：始终开启与锁定

设备管理会加上应用无法覆盖的强制措施。设备策略控制器可以为工作资料调用 setAlwaysOnVpnPackage，可选开启锁定；一旦锁定生效，平台就拒绝不经过该软件包的流量。这种阻断表现为系统状态而不是应用错误：同一资料里的其他应用也上不了网。

范围很重要。始终开启 VPN 是按用户配置的，所以工作资料的软件包覆盖不到你的个人资料，个人 VPN 也满足不了工作资料的软件包。两个资料、两套独立的网络策略、一台设备。

这也是唯一一个无关 VPN 帮不上忙的层，因为策略点名了某一个具体的软件包。

区分这三种情况

按顺序逐条对照，遇到第一个吻合的就停下。只有一个主机名失败、其余都正常解析，指向服务路径。启动时立刻被拒且带策略措辞，指向应用逻辑。只要获批客户端断开、整个资料就失去连接，指向锁定。而任何隧道都接受的应用，查的是传输标志，不是你组织的身份。

有用的证据：确切的文字和出现时机、同一资料里其他应用是否还有连接、私有名称在获批隧道内能否解析、设备是否为你打开的应用显示工作徽标。

支持请求里该写什么

点明层级的请求，第一次就能被正确分派。大致这样：工作资料应用能打开，获批 VPN 连上后资源列表失败，在允许的诊断中私有名称解析失败，资料里其他应用一直正常。这样读起来就是路由或解析器问题，可以跳过重置账号的循环。

如果获批 VPN 根本不存在，受支持的路径是通过管理员注册或重新配置。删掉管理配置文件、装一个无关客户端或伪造网络状态，是改变安全安排，而不是恢复它。

从层级入手，而不是从客户端入手。上面三个特征通常一次会话就能定案。