看起来你遇到了Windows 11上双VPN客户端共存的棘手问题，我结合这类场景的常见坑点，给你梳理几个排查方向：

1. 优先排查路由表冲突（核心原因） #

因为你提到两个VPN都没有启用拆分隧道，这意味着它们都会试图抢占系统的默认路由（0.0.0.0/0），这大概率是导致掉线和请求成功率低的根源。同事的系统能正常工作，很可能是他们的VPN客户端自动配置了针对目标网段的专属路由，而非都依赖默认路由。

• 操作步骤：
  1. 分别在「只连FortiClient」「只连NetExtender」「同时连两个VPN」三种状态下，打开管理员命令提示符，运行 route print 查看路由表。
  2. 重点对比默认网关（0.0.0.0/0）的跃点数（Metric）：跃点数越低，路由优先级越高。如果两个VPN的默认路由跃点数相同或接近，就会出现路由抢占、网络波动的情况。
  3. 手动调整路由优先级：找到其中一个VPN的网络适配器（Windows设置→网络和Internet→VPN→对应VPN的高级选项→更改适配器选项），右键选「属性」→「Internet协议版本4（TCP/IPv4）」→「高级」，取消勾选「自动跃点」，手动设置一个更高的数值（比如20），让另一个VPN的默认路由优先级更高。同时确保两个VPN各自目标网段（DB/API）的专属路由存在且正确。

2. 验证隐式拆分隧道配置 #

有时候VPN客户端会自动推送目标网段的路由，开启隐式拆分隧道，只是你没在客户端界面看到明确的开关。可以：

• 对比同事电脑的路由表，看他们同时连双VPN时，是否存在针对DB服务器网段、Web API网段的专属路由条目（而非全走默认路由）。
• 如果确实是这样，你可以手动添加静态路由：比如针对DB网段，运行 route add 192.168.xxx.0 mask 255.255.255.0 10.xxx.xxx.xxx（替换成实际的DB网段和对应VPN的网关地址），这样DB请求会自动走FortiClient，API请求走NetExtender，避免默认路由冲突。

3. 检查Windows VPN连接的基础设置 #

• 打开Windows设置→网络和Internet→VPN，分别查看两个VPN的「高级选项」：
  • 确保「允许其他网络用户通过此计算机的Internet连接来连接」没有被勾选，这个选项容易引发网络冲突。
  • 如果不需要IPv6支持，暂时禁用两个VPN的IPv6协议（适配器属性里取消勾选「Internet协议版本6（TCP/IPv6）」），避免IPv6路由冲突导致的掉线。

4. 排查客户端版本兼容性 #

你使用的FortiClient 7.2.4.0972和NetExtender 10.2.339可能存在版本兼容性问题，或者和Windows 11的系统更新不兼容：

• 尝试安装和同事完全相同版本的客户端，排除版本差异带来的问题。
• 或者卸载现有客户端，安装各自的最新稳定版（比如FortiClient更新到7.4.x系列，NetExtender更新到10.3.x系列），再测试双VPN连接。

5. 重置Windows网络堆栈 #

如果上述方法都无效，可能是系统网络缓存或配置异常导致的：

• 打开管理员命令提示符，依次运行以下命令：

  netsh winsock reset
  netsh int ip reset
  ipconfig /release
  ipconfig /renew
  

• 重启电脑后，重新配置VPN连接并测试。

先从路由表排查入手，这是双VPN冲突最常见的原因，对比同事的路由条目应该能快速定位差异。如果还有问题，可以补充两个VPN连接后的路由表详情或者目标网段信息，我再帮你细化分析。

备注：内容来源于stack exchange，提问作者Kevin Wells