企业 VPN 与普通网页代理职责不同

企业 VPN 可能负责内部网段、内部 DNS、设备合规和访问权限。个人代理的 TUN 又会修改路由或解析，两者同时运行时可能互相接管。公司 VPN 使用全隧道还是分流由组织配置决定，不能仅凭“都显示已连接”判断两者已经正确共存。

第一步：建立企业 VPN 单独工作的基线

  1. 保存正在进行的工作，记录两款客户端的名称、版本和连接顺序。如果当前远程桌面依赖隧道，先准备备用连接或在本地测试。
  2. 在允许的设备上正常关闭个人代理的系统代理和 TUN，仅连接企业 VPN。测试一个内部域名和一个实际工作操作。
  3. 再在获准的环境中分别测试个人代理单独工作、两者同时工作的情况。每次只改一项，记录失败时间和原始报错。
对照结果判断范围
企业 VPN 单独也打不开内网优先查组织账号、设备状态和企业网络
仅叠加个人 TUN 后内网失败优先查路由或 DNS 竞争
内网域名失败，已知内部地址可达可能是内部 DNS 路径；不是确定结论
只有浏览器失败，工作客户端正常检查浏览器、PAC 和系统代理
Android 开第二个 VPN 后第一个断开检查同一用户或工作资料的 VPN 实例限制

第二步：读取路由和解析信息，不直接删除路由

只读命令；各平台只运行对应部分
# Windows PowerShell
Get-NetRoute -AddressFamily IPv4
Get-DnsClientServerAddress
# macOS
netstat -rn
scutil --dns
# Linux
ip route
resolvectl status

Linux 最后一条适用于使用 systemd-resolved 的环境。输出可能包含内部网段和域名，应只留在本地或组织批准的支持渠道。比较连接前后默认路由、内部目标的更具体路由和 DNS 归属；单独看一条默认路由不能说明全部流量去向。

如果内部域名被公共 DNS 解析，返回失败不一定是企业服务宕机。另一方面，将所有域名强制交给企业 DNS 也可能违背网络设计。不要用公共解析器替换组织 DNS，更不要把内部域名和地址上传公共在线检测站。

第三步：确定职责边界，避免叠加后再靠猜测补洞

最容易维护的方式通常是工作时使用组织支持的网络方案；确需并用，由管理员明确允许的流量范围，再选择应用级显式代理或有清晰排除项的配置。应用显式代理并不自动覆盖 UDP，也不保证绕过企业网关，仍要验证实际路线。

不要通过移除组织根证书、卸载安全代理、关闭设备合规或改掉全隧道策略来“修复”。个人客户端里的 DIRECT 只意味着该内核不使用远端代理，后续仍按系统路由走，可能继续进入企业 VPN；它不是“强制走物理网卡”的保证。

验收与回退

  1. 由支持方确认方案后，复测内部域名、代码仓库、会议或远程桌面等真实工作，而非仅 ping 网关。
  2. 重新连接企业 VPN，再检查睡眠唤醒和网络切换后的路径，防止连接顺序一变就失败。
  3. 若未改善，撤销个人客户端本次新增的规则或接管，恢复企业 VPN 单独可用的基线。提供脱敏的两轮对照结果及时间给 IT，而不是公开整个配置包。