典型现象：握手失败、秒断与内网不可达
Cisco AnyConnect 一类 企业 VPN 往往同时依赖：对网关域名的正确解析、到达网关与后续内网网段的路由，以及不被中间人式代理打断的 TLS 握手。当你再开一层 Clash，若流量被错误地送进代理节点、或 DNS 被劫持到 fake-ip、或 TUN 路由抢在 VPN 拆分路由之前生效，就会出现：连接按钮转圈后失败、隧道刚建立就掉线、或显示已连接但 10.x / 172.16–31.x 等内网地址 ping 不通。这类问题与「机场节点质量」常常无关，而是分流白名单与系统栈优先级没对齐。
在动手改配置前，建议先建立心理模型：个人代理与公司远程接入争的是同一套路由表与 DNS 解析路径，而不是两个互不相干的 App。关于「通用 VPN」与基于规则的代理在架构上的差异，可先读 Clash 与 VPN 深度对比，再回到本文按步骤收敛冲突面。
第 0 步：先分清系统代理与 TUN 谁在前
系统代理主要影响「尊重系统代理」的应用（多数浏览器默认如此）；TUN 模式则可能在三层把几乎所有进程的流量导入 Clash 栈，包括 AnyConnect 的某些组件——因此与 SSL VPN 叠加时，TUN 更容易踩雷。若你刚启用 TUN 后立刻出现企业 VPN 异常，而仅开系统代理时问题较轻，这本身就是强信号。TUN 与 DNS 劫持如何协作、为何会影响「看不见域名」的纯 IP 流量，详见 Clash TUN 模式深度解析；若你使用 macOS 且涉及系统扩展授权或「代理与 VPN 抢同一接口」的困惑，可对照 macOS 上 TUN 与系统代理冲突排查。
实操上建议做两次对照实验：① 仅开 Clash「系统代理」、关 TUN，重连 AnyConnect；② 仅开 TUN、关系统代理（或按客户端文档的推荐组合），再测。记录哪一档必现故障，可少改十几版订阅。若公司策略要求 VPN 全程在线，部分环境会禁止本地「全局捕获」，此时应优先收窄 Clash 的接管面（规则更细、或改用进程级分流），而不是硬开全局 TUN。
第 1 步：规则与策略组里的 DIRECT 白名单
打开你正在使用的 Clash / Mihomo 图形客户端，找到当前生效配置里的 rules: 段。目标是：凡指向公司 VPN 网关、证书 OCSP/CRL、身份提供商（IdP）与 SSO、以及明确内网网段的请求，都应落在 DIRECT（或你专门定义的「直连」策略组）上，而不是默认的 PROXY 或「漏网之鱼」规则。常见写法包括：DOMAIN-SUFFIX,corp.example.com,DIRECT、DOMAIN-KEYWORD,anyconnect,DIRECT（示例，勿照抄虚构域名）、以及对 RFC1918 私网的 IP-CIDR,10.0.0.0/8,DIRECT 等。顺序上务必把最具体的白名单放在前面，避免被一条过宽的 GEOIP 或「全站 MATCH」提前抢走；规则集合并与优先级细节可参考 Clash 规则分流最佳实践。
若你使用策略组 + 规则集，注意「策略组里选中的节点」与「规则里写 DIRECT」并不矛盾：规则先命中，命中 DIRECT 时不会再去问用户选的是哪个机场节点。另一个常见误区是：以为把浏览器设为直连就够了——AnyConnect 的系统服务、守护进程与 DTLS 会话往往不走路径完全相同的 HTTP 代理链，因此仅靠浏览器插件关代理经常无效。若你希望「只有浏览器走 Clash」，更需要在 Clash 侧收窄 TUN 覆盖或改用按进程分流（Windows 可参考 Windows 上 Clash Meta 按进程分流），而不是只改浏览器。
第 2 步：DNS、fake-ip 与企业域名解析
当 Clash 打开 fake-ip 且配合 DNS 劫持 时，应用层看到的「解析结果」可能与系统 nslookup 不一致：某些客户端会拿到198.18.x.x 段的伪地址，再由内核把连接映射回域名。企业 VPN 若在这一层被「假地址」误导，就会表现为握手超时或连上后访问内网 IP 异常。处理思路通常是：为企业相关域名配置 nameserver-policy 走系统 DNS 或公司指定 DNS、在 fake-ip-filter 中列入 VPN 网关与 SSO 域名、或对该类域名关闭 fake-ip 路径。更完整的 DNS 回落、过滤与 fake-ip-filter 组合示例，见 Clash Meta DNS 与 fake-ip-filter 实测。
若你的网络是 IPv6 双栈，还要警惕「解析走了 AAAA、路由却走了代理侧」的割裂，可对照 IPv6 双栈下 DNS 与直连规则 做一次收敛。验证时建议同时看 Clash 连接日志里的「解析到的地址」与系统侧 nslookup vpn.example.com，两边若长期不一致，就应优先修 DNS 策略而不是换节点。
第 3 步：用路由表核对 VPN 与 Clash 的优先级
AnyConnect 连接成功后，操作系统会下发指向隧道接口的主机路由或网段路由；Clash 的 TUN 也可能插入更优先或更具体的默认路由。当两者度量（metric）或前缀长度打架时，就会出现「VPN 显示已连接，但流量没进隧道」或相反「所有流量被 Clash 截胡」。在 Windows 上，用管理员 PowerShell 执行 route print -4，关注目标为 0.0.0.0/0 的几条默认路由各自的接口索引与度量；在 macOS 上，用 netstat -rn -f inet 查看 default 与指向 utun 的条目。对比「仅开 VPN」「仅开 Clash」「两者同开」三份输出，通常一眼能看出是谁抢默认路由。
修正策略上，优先在 Clash 配置里用更细的路由绕过（例如仅代理需要翻墙的网段、其余直连），而不是在操作系统里手动 route delete 企业路由——后者容易误伤生产网络。若你曾遇到「关 Clash 后系统代理仍指本地空端口」这类残留型问题，也可顺带阅读 退出 Clash 后的系统代理与 TUN 清理，避免把 VPN 故障与历史残留混在一起误判。
GlobalProtect 与同类 SSL VPN 的顺带对照
Palo Alto GlobalProtect 与 AnyConnect 在「排障维度」上高度相似：同样依赖门户域名解析、证书链校验、UDP/4500 类端口与拆分隧道路由。因此本文的 DIRECT 白名单、DNS 过滤与路由表对照方法，大多可以原样迁移到 GlobalProtect——差别主要在具体域名与内网段，需要你在连接日志或 IT 文档中替换为自家清单。若握手阶段报 TLS 相关错误，可结合 连接日志与 TLS 排障 区分是「被代理打断」还是「公司网关侧拒绝」。
第 4 步：用连接日志自证命中哪条策略
改完规则后，务必打开客户端的连接日志 / 实时连接，在点击 AnyConnect「连接」的瞬间观察：目标域名或 IP、命中的 rule 名称、走到的 policy 是否为 DIRECT。若仍显示走了某个海外节点，说明白名单仍未命中——回去检查规则顺序、是否被 RULE-SET 合并覆盖、或是否存在大小写与后缀写错。选客户端时，带清晰日志面板的发行版会省大量时间，可对照 如何选择适合自己的 Clash 客户端 评估自己的使用习惯。
结语
Clash 与 Cisco AnyConnect 并非天生互斥；真正冲突的，是未收窄的全局接管与企业 VPN 对路由/DNS 的刚性假设。把问题拆成「模式 → 规则 DIRECT → DNS → 路由表 → 日志自证」五步，多数「秒断」「内网不可达」都能定位到具体一层。相比反复重装 VPN 客户端，先在 Clash 侧做可回滚的小步修改，通常成本更低、也更易于向 IT 说明。
若你希望长期稳定地在合规前提下使用图形化规则与日志，选择维护积极、对 TUN / DNS / 策略组 文档齐全的 Clash 发行版，会比手工折腾系统路由更省心。
→ 立即免费下载 Clash，开启流畅上网新体验，用清晰的分流与日志面板，把个人代理与企业远程接入尽量「各走各路」。