1 典型痛点：谁在抢默认路由
企业 VPN 一旦采用全隧道（full tunnel）或等效策略，客户端往往会在 Windows 上新增一条或多条主机路由，并把默认路由（0.0.0.0/0）指向 VPN 虚拟接口侧的网关。这样做的安全意图很明确：所有公网流量先进入公司边界再出站，便于审计与过滤。但对本机同时运行 Clash 的用户来说，副作用是：除非你另有更具体的前缀路由或更低的跃点数覆盖某些目标，否则大量流量会优先被操作系统交给 VPN 栈，Clash 的 TUN 网卡或系统代理在「全局路径」上可能根本接不到包。
另一种常见情况是：Clash 先开了 TUN，默认路由已经指向 Clash 虚拟网卡；随后你连接企业 VPN，VPN 客户端又下发一条metric 更小的默认路由，于是默认路径瞬间倒向公司网关——外网站点突然全部走公司出口，Clash 规则形同虚设；而若你手动调高 VPN 路由的优先级，又可能触发内网网段不可达或分隧道被安全软件禁止。因此「同时连接」的本质不是装两个软件，而是在同一套路由决策里给不同前缀分配不同下一跳，并保证公司要求的流量仍按策略走公司侧。
若你尚未在 Windows 上完整跑通过 Clash 的 TUN，可先阅读《Clash Verge Rev TUN 模式完全指南》，建立对虚拟网卡、DNS 劫持与规则链的基本认识，再回到本文处理与 VPN 的叠加。
2 拆分隧道与 IT 策略边界
拆分隧道（split tunneling）指：只有访问公司内网网段、数据中心、SaaS 白名单等目标的流量进入 VPN 隧道，而访问互联网其他地址时仍走本地物理网卡与本地 ISP 出口（或再走你本机的 Clash）。是否允许拆分、允许哪些前缀拆分，通常由网关配置与组策略决定，而不是单靠你本机改路由就能「偷偷」长期稳定实现——部分环境会在重连或每隔数分钟强制统一下发路由，覆盖你手工添加的条目。
Palo Alto GlobalProtect 与 Cisco AnyConnect 等客户端在界面上有时会显示「当前是否为拆分模式」或路由列表，但具体名称因版本与企业门户而异。实际排障时，不要死记菜单路径，而是以连接后 route print -4 或 PowerShell 的 Get-NetRoute -AddressFamily IPv4 输出为准：看 0.0.0.0/0 绑在哪个 Interface、RouteMetric 是多少，以及是否有一条指向公司内网大段（如 10.0.0.0/8）经 VPN 接口的路由。
3 Windows 路由表与跃点数
Windows 为每个 IPv4 目标选择下一跳时，会综合最长前缀匹配、跃点数（metric）、接口状态等。对企业用户最实用的记忆法是：越具体的路由越优先。因此常见做法是：保留 VPN 下发的内网段精细路由（例如整个 10.0.0.0/8 或公司分配的 /16），而让默认路由在合规前提下回到物理网卡或交给 Clash TUN——但这只有在拆分隧道被允许或 IT 为你单独开了策略时才是「官方可持续」方案。
在管理员 PowerShell 中查看 IPv4 默认路由示例（输出因机器而异）：
Get-NetRoute -DestinationPrefix "0.0.0.0/0" -AddressFamily IPv4 |
Sort-Object RouteMetric |
Format-Table DestinationPrefix, NextHop, InterfaceAlias, RouteMetric -AutoSize
你会经常看到两条 0.0.0.0/0：一条经 Wi-Fi 或以太网，一条经 VPN 虚拟适配器。此时较小 RouteMetric 的一条获胜（在相同前缀长度下）。调整思路不是「删掉 VPN」（往往删不掉或会立刻重连恢复），而是理解IT 是否允许多默认路由共存，以及是否可以通过拆分隧道减小 VPN 对默认路由的劫持范围。
4 连接顺序与虚拟网卡优先级
「先连 VPN 还是先开 Clash」没有放之四海皆准的答案，取决于当前默认路由是谁写的以及Clash 使用系统代理还是 TUN。若你只用系统代理而不开 TUN，企业 VPN 通常不会阻止浏览器指向 127.0.0.1:端口 的 HTTP 代理，但不感知系统代理的应用（许多命令行工具、部分后台进程）仍会走 VPN 或物理网卡默认路径，表现会「忽好忽坏」。这与《UWP 与 Loopback 系统代理》里讨论的分层问题类似：先要分清流量走哪一层管道。
若使用 TUN，Clash 会在路由表中加入指向虚拟网卡的前缀；企业 VPN 连接事件往往会批量重写路由。实践上更稳妥的顺序通常是：先连接 VPN，待内网路由稳定下发后，再启动 Clash TUN，并在 Clash 配置中确保公司内网 IP 段、组播、链路本地等走 DIRECT，避免被误送入海外节点。若你发现每次 VPN 重连后 Clash 都「失效」，多半是路由被刷新后 metric 顺序变化，需要在理解表项的前提下重新评估，而不是反复重装客户端。
route add 的条目在重启或 VPN 重连后可能丢失。若企业环境允许，应推动 IT 在网关侧做拆分；本机脚本化改路由也须评估是否触发终端检测（EDR）告警。
5 例外路由：内网走 VPN、其余走本地
在已获准拆分或测试环境中，技术目标是：公司 RFC1918 内网段与 VPN 池继续匹配经 VPN 接口的路由；公网目标则由本地默认网关或 Clash TUN 处理。Windows 经典命令行仍可用（需管理员，且下一跳与接口索引请用你机器上 route print 的真实值替换；示例仅说明形态）：
REM Example only: send corporate RFC1918 aggregate via VPN next hop
route add 10.0.0.0 mask 255.0.0.0 <VPN_GATEWAY_IP> metric 5
REM Verify
route print -4
更现代的做法是在 PowerShell 中用 New-NetRoute、Set-NetRoute 管理，并结合 Get-NetIPInterface 查看各接口的接口跃点数。关键仍是：不要猜测网关地址，务必从 VPN 连接后的有效路由或 IT 文档中获取。若你希望「仅浏览器走 Clash、其他维持公司默认」，有时不必动系统路由，而是退回系统代理 + PAC/规则，由应用自身决定是否使用代理——代价是覆盖面不如 TUN 完整。
对于「同一台机器上要区分进程」的高级需求，可在掌握 TUN 与内网直连的前提下，继续阅读《Clash 进程名分流教程》，把特定 .exe 指到不同策略组；但这仍不能违背公司禁止安装第二网络栈的规定。
6 Clash 侧：直连公司域名与 TUN
无论系统路由如何切，Clash 规则层都应显式保护内网与办公域名：IP-CIDR 或 GEOIP private 一类规则将公司段落在前部标记为 DIRECT，再放国内外域名分流。否则一旦目标 IP 被误判为境外，可能出现访问内网仓库却走了代理节点，既慢又容易留下审计疑点。若使用 FakeIP，还要保证企业域名的 DNS 解析路径不被完全劫持到 Clash 虚拟 DNS，细节可参考《彻底防止 DNS 泄漏》中的「解析链与规则一致」思路。
Clash Verge Rev 等图形客户端通常提供「绕过中国大陆」或自定义规则集，但企业内网段往往不在公共规则集里。建议向同事索要一份「必须直连的域名 / IP 列表」，用 DOMAIN-SUFFIX、IP-CIDR 写在订阅合并后的前部，并定期随基础设施变更更新。与 WSL2 或虚拟机联用时，还要注意宿主机 VPN 与 WSL 虚拟网卡的交互，可交叉阅读《WSL2 下 Ubuntu 走 Windows Clash》，避免「Windows 已走公司内网、WSL 却仍走错误默认路由」的割裂。
7 DNS：企业解析与 FakeIP 的协调
全隧道 VPN 常把系统 DNS 服务器改成仅可达公司内网的解析器，用于解析内部主机名。此时若 Clash 强行把所有查询劫持到公共 DoH，可能导致内网域名解析失败。较稳妥的做法是：在 Mihomo / Clash 配置里为公司域后缀指定 nameserver-policy 或等效机制，让这些查询仍走企业 DNS，其余再走加密 DNS 或 FakeIP 栈。具体键名随内核版本略有差异，以你所用发行版文档为准。
排障时可在连接 VPN 后，分别用 nslookup intranet.example.corp 与浏览器访问对比：若不经 Clash 能解析、经 Clash 失败，则优先怀疑 DNS 链而非路由表。把 DNS 与路由两层日志对齐时间戳，比单纯「换节点」更能定位问题。
8 合规提醒
许多公司对「个人代理软件」「修改系统路由」「第二隧道」有明确禁令，终端上的 EDR 也可能记录 route、netsh、TUN 驱动加载等行为。即使技术上可行，也不代表业务上允许。若你的目标是合法远程办公，应优先申请：官方拆分隧道、受控的 PAC 代理、或经批准的零信任访问，而不是在受限设备上长期对抗策略。
9 验收清单
- 连接 VPN 后，内网关键系统（OA、Git、堡垒机）在不启动 Clash 时已全部可用。
- 启动 Clash（系统代理或 TUN）后，内网仍可用；若不可用，先检查规则是否误代理再查路由 metric。
Get-NetRoute中默认路由指向与你的预期一致，且 VPN 重连后行为可接受或可脚本恢复。- 外网测试站点走预期出口（公司或 Clash），可通过 IP 查询站对照来源 ASN。
- 企业域名解析在 Clash 开/关两种状态下均正常。
- 已阅读并遵守公司 IT 政策；敏感设备不做未授权实验。
10 总结
Windows 企业 VPN 与 Clash 同时连接的核心矛盾，集中在默认路由与 DNS 由谁下发。拆分隧道从网关侧解决「哪些前缀进隧道」；本机例外路由与跃点数只是在策略允许的前提下微调路径；Clash 则通过内网直连规则与 DNS 策略避免把办公流量误送代理。三者缺一会表现为「连了 VPN 就不能翻墙」或「开了 Clash 内网全挂」。
与单纯折腾订阅节点相比，先把 route print 与 Clash 日志里的目标 IP、策略命中对齐，能少走大量弯路。若你使用的客户端基于 Mihomo 内核、支持清晰的连接日志与 TUN 栈，在复杂网络环境下往往比零散脚本更易维护——相比其他同类工具，Clash 系在规则可读性、社区文档与图形客户端成熟度上的综合体验仍然更省心。
安装与更新请选择可信来源；从本站下载页获取 Windows 安装包，可避免捆绑与来路不明的构建。
