外观
开着 Clash 后公司 VPN、视频会议连不上？理解“路由冲突”并按顺序排查
远程办公时，一个很常见又容易令人困惑的现象是：浏览网页、使用普通应用都正常，但一打开公司 VPN，内部门户、代码仓库、远程桌面或视频会议就无法连接；也有人反过来发现，只要公司 VPN 连上，Clash 里的节点便全部超时。
这通常不意味着某一方“坏了”。Clash、公司 VPN、终端安全软件都可能修改系统的流量路径、DNS 或路由表。当多个组件同时接管网络时，流量可能绕错出口，DNS 可能问错服务器，甚至出现两条默认路由互相竞争。正确处理方式不是随意关闭安全功能，而是先确认公司网络的使用要求，再以“最少改动、一次只改一项”为原则排查。
先建立一个正确的判断：到底是哪一类冲突
开始操作前，先区分下面三种情况。它们表面相似，解决方向却不同。
- 只有公司内网资源打不开：例如
intranet、内部 Git、文件服务器、私有 DNS 域名或远程桌面地址不可用，但公共网站正常。这往往是内网路由或 DNS 没有走进公司 VPN。 - 公司 VPN 根本连不上：客户端停在“连接中”、认证后立即断开，或提示网络不可达。这可能与 TUN/VPN 适配器竞争、UDP 受限、证书校验或网络策略有关。
- VPN 连上后所有网络都变慢或断开：这通常与公司 VPN 的“全隧道”策略有关，即它要求所有流量先进入公司网络；此时再叠加代理软件，容易形成双重转发或路由冲突。
尤其要注意：公司设备和公司 VPN 通常受组织安全策略约束。不要为了让某个网站可用而修改安全客户端、安装来源不明的证书、关闭终端防护，或绕开明确的网络访问规定。遇到策略限制时，应优先向企业 IT 支持确认可用的网络模式。
认识四个关键概念：系统代理、TUN、全隧道和分流
系统代理：多数浏览器流量会听它的
Clash 开启“系统代理”后，会将本机 HTTP/HTTPS 等请求交给本地代理端口处理。浏览器和不少桌面软件会遵循这个设置，但不是所有应用都会遵循。
它的特点是影响范围相对有限，通常不直接改写所有 IP 数据包的去向。因此，当公司 VPN 出现兼容性问题时，先使用系统代理而非 TUN，往往是较温和的起点。
TUN 模式：接管范围更广，也更容易与 VPN 相遇
TUN 模式通过虚拟网卡处理更多应用的网络流量，某些不遵守系统代理的软件也能被纳入分流。但公司 VPN 本身也常创建虚拟网卡。两者并存时，Windows 或 macOS 必须决定“同一个数据包该交给哪张网卡”，这正是冲突容易发生的位置。
如果问题只在开启 TUN 后出现，最有价值的验证动作通常是：暂时关闭 Clash 的 TUN，保留公司 VPN，再测试内网资源和会议软件。若立即恢复，就说明重点应放在 TUN 路由、DNS 或虚拟网卡优先级上，而不是反复更换节点。
全隧道 VPN：所有流量都交给公司网络
企业 VPN 常见两种工作方式：
- 分流隧道（Split Tunnel）：只有访问公司网段、内部域名等流量进入 VPN，其他流量仍走本地网络；
- 全隧道（Full Tunnel）：包括普通互联网访问在内的全部流量都先进入 VPN。
全隧道是否启用通常由服务端策略决定，客户端未必能改，也不应擅自改。若企业使用全隧道，Clash 的本地代理请求可能被 VPN 再次转发，导致延迟增加、连接失败，或触发企业安全系统的限制。此时最稳妥的做法常常是：工作期间以公司 VPN 为主，按公司规范使用网络；需要使用 Clash 的个人场景则放在断开工作 VPN 后进行。
DNS：能打开 IP，不代表能打开域名
不少内网服务仅能通过内部域名访问，例如 git.company.local。连接 VPN 后，系统应该使用公司下发的 DNS 来解析这些域名；但若 Clash 的 DNS 接管、浏览器安全 DNS 或其他网络工具抢先回答查询，就可能得到“找不到域名”或错误地址。
一个实用判断方法是：同样的内网地址，在 VPN 已连接的情况下，直接输入 IP 能访问、输入域名却不能访问，DNS 就是首要怀疑对象。
推荐排查顺序：先收集现象，再逐层减少变量
不要一开始就重装客户端或重置整个网络。按下面顺序操作，能保留足够线索，也更容易恢复原状。
第一步：记录最小复现条件
请写下或截图以下信息：
- 问题发生在“先开 Clash 再连 VPN”，还是“先连 VPN 再开 Clash”；
- Clash 当前是否打开 TUN、系统代理、IPv6 或 DNS 覆写；
- 受影响的是全部网络、仅内网域名，还是某一款会议/远程桌面应用；
- 断开 Clash 后是否恢复，关闭 TUN 后是否恢复；
- 公司 VPN 客户端给出的精确错误提示和发生时间。
这些信息比“网络不行”更能帮助定位，也方便后续提交给 IT 支持人员。
第二步：建立一个稳定基线
- 退出 Clash，确认系统代理已关闭；
- 连接公司 VPN；
- 测试一个公司内网网页、一个内部域名服务，以及日常会议或远程桌面工具；
- 若此时仍不正常，问题大概率不由 Clash 引起，应检查 VPN 账号状态、企业证书、当前网络认证、系统时间，或联系公司 IT；
- 若此时正常，再启动 Clash，但先不要开启 TUN。
这一步的核心是证明“VPN 自身在当前网络下能否正常工作”。如果基线都不稳定，后续叠加任何设置都没有判断价值。
第三步：只开启系统代理，避免立即启用 TUN
在公司 VPN 保持连接的前提下，启动 Clash 并仅开启系统代理。之后分别测试：公司内网、会议工具、普通网页。
- 若一切正常，说明当前组合大致兼容，日常可维持这种较简单的方式；
- 若内网域名失败，而 IP 地址可访问，优先检查 DNS；
- 若某个应用完全不受系统代理影响，这不一定是故障，它可能本来就不读取系统代理设置；
- 若一开启系统代理 VPN 就中断，先关闭系统代理并记录现象，避免持续反复重连导致账号被安全策略临时限制。
第四步：将 TUN 作为单独变量测试
只有在确实需要让不支持系统代理的软件走 Clash 时，才考虑 TUN。开启前先确认公司是否允许同设备运行其他网络代理工具。
测试方式应当简单：开启 TUN 后，不改变节点、不改规则，立刻复测 VPN、内网域名和目标软件。若出现问题，立刻关闭 TUN 并恢复到基线。不要同时修改 DNS、IPv6、规则集、虚拟网卡优先级，因为这样会失去因果关系。
对于多数办公需求，“公司 VPN + Clash 系统代理”已经比“公司 VPN + Clash TUN”更容易维护。TUN 的覆盖能力更强，但并不意味着在每种网络环境下都更合适。
DNS 冲突怎么处理：优先让内部域名回到公司 DNS
当症状集中在内部域名时，可以依次检查：
- 浏览器安全 DNS：浏览器独立启用加密 DNS 后，可能绕过系统和 VPN 下发的 DNS。可暂时关闭浏览器的安全 DNS 后复测内网域名；若恢复正常，说明办公时应使用组织建议的 DNS 策略。
- Clash 的 DNS 接管设置：若关闭 Clash 的 DNS 功能后内网恢复，说明需要在配置中为公司内网域名、私有地址范围保留直连和本地/VPN DNS 解析路径。具体写法会因内核和配置结构而不同，不宜直接套用来历不明的整段配置。
- 系统中残留的第三方 DNS 工具：加密 DNS 客户端、广告过滤软件、安全软件的网络过滤功能，都可能改变解析链路。排查时建议一次只暂停一个工具。
- 内部域名后缀：将公司提供的内部域名后缀、DNS 服务器地址和网段信息交给 IT 支持人员确认。不要凭猜测把宽泛域名加入直连或代理规则。
需要强调的是，DNS 的“快”不等于“正确”。访问公司内部资源时，能解析到正确的私有地址，比使用公共 DNS 更重要。
路由问题的常见信号，以及不要轻易做的事
如果 VPN 一连上，访问内网 IP 超时，但域名解析正常，很可能是内网网段没有被正确送入 VPN。企业 IT 往往需要检查 VPN 服务端下发的路由；普通用户可以提供目标地址、连接时间和客户端日志，但不建议随意添加永久静态路由。
手动改路由表看似能解决一时问题，却可能造成以下后果：重启后失效、与公司策略冲突、把本应在 VPN 内传输的流量错误送到本地网关，或者在公共 Wi‑Fi 下扩大风险。除非由企业 IT 明确提供网段、网关和操作步骤，否则不要把网络论坛中的命令直接复制到工作电脑执行。
同样不建议采取以下做法：
- 不明用途地关闭 IPv6、证书校验或系统防火墙；
- 删除公司 VPN 的虚拟网卡、驱动或配置文件；
- 为了“强制可用”把所有流量设为全局代理；
- 将公司内网域名、IP、登录页面截图或日志完整公开到社区；
- 在受管设备上安装未经组织批准的网络过滤、抓包或证书工具。
一份适合提交给 IT 支持的说明模板
当问题无法自行确认时，清晰描述能减少来回沟通。可以按下面格式整理：
操作系统：Windows/macOS 及版本；
VPN 客户端版本：由客户端“关于”页面获取；
网络环境：家庭宽带、手机热点或公共 Wi‑Fi；
问题时间：精确到分钟；
现象：VPN 已连接，但无法访问某个内部域名/远程桌面/会议服务；
对照结果：完全退出其他代理工具后是否恢复；仅关闭 TUN 后是否恢复；
错误信息：原样附上文字，不包含账号、验证码、访问令牌和完整订阅链接。
如果公司允许，也可询问以下问题：该 VPN 是否使用全隧道策略；是否支持 split tunnel；内部 DNS 域名应由哪些 DNS 服务器解析；是否存在与其他 VPN/TUN 驱动共存的已知限制。这样问比笼统询问“为什么 Clash 和 VPN 冲突”更容易得到有效答复。
结语：稳定的关键是明确谁负责哪一段流量
Clash 与公司 VPN 同时使用时，最容易犯的错误是把所有异常都归咎于节点，随后不停换节点、换协议、改全局模式。事实上，真正需要先厘清的是：哪些流量应进入公司 VPN，哪些流量应留在本地网络，内部域名由谁解析，以及 TUN 是否确有必要。
建议把“VPN 单独正常”作为基线，再逐一开启 Clash 的系统代理、DNS 功能和 TUN 模式。每一步只改一个变量，问题通常会从模糊的“上不了网”，变成可以解释、可以恢复、也便于向 IT 支持说明的具体故障。对于工作设备和企业网络，遵守组织的安全要求始终应优先于追求复杂的网络组合。