Clash 规则模式、全局模式、直连模式有什么区别，日常该选哪个

日常选规则模式，排障再临时切换

已有可用订阅、希望本地服务直连而指定网站走代理，先选规则模式。全局模式适合短时间验证代理出口，直连模式适合检查本地网络。三种模式改变的是进入 Clash 内核后的流量处理方式，不是三种不同的节点，也不是三个速度档位。

Clash 系列客户端及采用 Clash Meta（现称 mihomo）内核的客户端，通常把这三个选项显示为「规则 / Rule」「全局 / Global」「直连 / Direct」。具体入口随客户端版本变化，但底层配置字段通常分别是 rule、global、direct。

三种模式的流量走向

规则模式：规则决定出口，不是自动猜测网站位置

应用请求
  → 系统代理或 TUN 接入
  → Clash / mihomo
  → 按顺序检查 rules
      → 命中 DIRECT：本地网络 → 目标
      → 命中代理策略组：选定节点 → 目标
      → 命中 REJECT：拒绝连接
      → 到达 MATCH：按兜底策略处理

规则从上往下匹配，通常由第一条命中的规则决定处理目标。这个目标可以是内置策略 DIRECT、REJECT，也可以是配置中已经定义的策略组。规则模式并不自带一份固定的「国内直连、国外代理」名单；订阅写了什么规则、规则集是否成功加载，才决定最终结果。

例如公司内网域名应当直连，却被兜底规则送进代理组，访问就可能失败。此时换节点未必有用，应先在连接详情里检查命中规则，再考虑添加更具体的直连规则。涉及公司 VPN 的环境，还要确认路由不会被其他接管方式覆盖。

全局模式：跳过常规分流，使用 GLOBAL 的选择

已进入内核的应用请求
  → GLOBAL 策略组
  → 当前选中的节点或策略
  → 目标

全局模式一般不按常规 rules 列表进行分流，而是使用内置 GLOBAL 策略组。它适合回答一个明确问题：同一目标在明确指定代理出口后，是否能够正常访问？切换后还要进入代理页面，展开 GLOBAL，确认选择的是预期节点或策略组。

全局不保证一定经过远端节点。如果 GLOBAL 选择了 DIRECT，或者选中的下级策略最终落到直连，连接仍会直接发出。它也不会把没有进入内核的其他应用流量自动接管进来。

直连模式：保留接入，但不使用远端代理节点

已进入内核的应用请求
  → DIRECT
  → 本地网络
  → 目标

直连模式让进入内核的连接使用本地网络出口。客户端仍可能继续运行本地代理端口、DNS 服务或 TUN 虚拟网卡，因此它不等于「网络恢复到启动客户端以前」。如果要比较完全不经过客户端的状态，应另外关闭系统代理、关闭 TUN，并检查应用自己的代理设置。

代理模式、系统代理与 TUN 的区别

系统代理和 TUN 解决「流量怎样进来」，规则、全局、直连解决「进来以后怎样出去」。这是最容易混淆的两层设置。启用 TUN 后仍然可以选择规则模式，不需要为了 TUN 把模式改成全局。

• 系统代理：让遵循系统代理设置的应用把请求交给本地代理端口。部分游戏、命令行工具或自带网络栈的应用不会采用它。
• TUN 模式：通过虚拟网络接口和相关路由接入流量，覆盖范围通常比系统代理更广，但仍受路由排除、权限、平台实现等条件影响。
• 代理模式：针对已进入内核的连接选择规则分流、GLOBAL 策略或直连。

举例来说，配置中的 mixed-port: 7890 表示本地混合代理监听端口为 7890，不表示全局模式已经开启。浏览器手动代理地址可以指向 127.0.0.1:7890；端口必须以客户端当前显示的值为准，不能把示例端口当成所有安装环境的默认值。

在客户端中切换，并确认实际生效

桌面客户端通常把模式放在首页卡片、代理页面或托盘菜单中。以 Clash Verge Rev 一类客户端为例，可先在主界面找到「代理模式」，再选择「规则」「全局」或「直连」；部分版本也能通过托盘图标菜单切换。名称和位置可能变化，判断依据是这三个模式选项，而不是某个外观相似的开关。

1. 记录原状态：记下当前模式、当前节点、系统代理和 TUN 是否启用。不要只记节点名称。
2. 切到全局：选择「全局 / Global」，进入「代理 / Proxies」页面，展开「GLOBAL」，选择一个已知可用的节点。
3. 建立新请求：重新打开目标页面，并到「连接 / Connections」查找对应域名。必要时只关闭该目标的已有连接，再刷新页面。
4. 检查出口链：连接详情中应能看到所选节点或策略链。不同界面可能显示 GLOBAL、节点名称或完整链路，不能只凭按钮高亮判断。
5. 恢复规则：测试结束后切回「规则 / Rule」，再次访问同一目标，比较命中规则和最终策略。

已建立的 TCP 连接、浏览器连接池或持续运行的下载任务，可能继续使用原来的连接。切换模式并不意味着所有旧会话会立即重建。为了减少误判，优先重新打开目标页面；不必一开始就清空全部连接，避免中断会议或文件传输。

配置文件里的 mode 字段

# 配置片段：日常使用规则模式
mode: rule

# 本地混合代理端口示例，以实际设置为准
mixed-port: 7890

需要全局或直连时，mode 的值分别改为 global 或 direct。同一份 YAML 不要重复写多个顶层 mode。图形客户端可能保存运行时选择，也可能用覆写设置覆盖订阅字段；重新加载配置后模式发生变化，应检查客户端的持久化设置，而不是反复修改订阅原文。

规则不通、全局能通：按这个顺序检查

这个现象常见，但不能直接得出「规则模式坏了」的结论。全局测试可能用了另一个节点，也可能避开了错误的直连规则。只有把测试条件保持一致，结果才有参考价值。

先让两种模式使用同一个节点

在规则模式中，找到目标命中的代理组，手动选定节点；在全局模式中，也让 GLOBAL 使用同一个节点。暂时避免自动选择组在测试中更换出口，否则比较的既是模式，也是线路。

再查命中规则和兜底策略

• 目标命中 DIRECT，但本地网络无法访问：检查是否存在过宽的直连域名规则或 IP 规则。
• 目标命中 REJECT：核对拦截规则是否误伤，尤其是登录、验证和静态资源域名。
• 目标落到 MATCH：检查兜底目标是否符合预期，以及相关规则集是否加载成功。
• 目标命中了正确代理组却仍失败：核对该组实际选择，不能只看组名是否含有「代理」二字。

自定义规则必须引用已经存在的策略组名称，名称要完全一致。更具体的规则通常需要放在会先命中的宽泛规则之前，并位于兜底 MATCH 之前。订阅可能在更新时覆盖手工修改，长期调整宜使用客户端提供的规则覆写或合并功能，先阅读对应功能说明再保存。

最后再检查 DNS

切换为全局通常不会自动换掉整套 DNS 配置。域名解析失败、DNS 上游不可达、fake-ip 与应用不兼容等问题，可能在多个模式中都出现。先看日志中是否出现解析超时，再检查 DNS 上游是否可达；不要把「全局」当成 DNS 修复按钮，也不要一次替换多个 DNS 字段。

用三个目标做一次可重复的对照测试

准备一个正常直连的网站、一个需要指定代理出口的目标，以及一个局域网服务，例如自己的路由器管理页。局域网地址以实际网关为准，不要假定所有设备都使用同一个地址。每种模式给自己约 30 秒观察，记录新连接，而不是把等待时长当成性能测试结果。

如果局域网请求被路由排除而没有进入内核，它在全局模式下仍可能直连，这是接入层行为，不是全局模式失效。反过来，若访问局域网服务进入了内核并被全局送到远端节点，服务可能无法访问；完成排障后应恢复规则模式，并检查局域网直连或路由排除设置。

节点延迟测试的数值只能说明某种探测方式下的响应表现，不能证明目标网站的登录、视频或文件下载一定可用。最终应以实际业务请求、连接链路和错误日志共同判断。

常见问题与日常设置建议

全局模式一定更快吗？

不一定。原本适合直连的服务经过远端节点，可能增加绕行和延迟，也可能增加订阅流量消耗。全局模式的价值是简化出口选择、方便验证，不是提高所有应用速度。规则模式的性能则取决于规则是否合理、DNS 是否正常，以及所选线路的实际质量。

直连模式能暂停订阅流量消耗吗？

进入内核的普通业务连接使用直连时，不会通过所选远端代理节点转发。但客户端仍可能执行节点健康检查、订阅更新或其他后台任务，因此不能据此承诺后台通信全部停止。需要暂停相关活动时，应分别检查自动测速、更新任务与客户端运行状态。

手机上的全局模式等于所有应用都走节点吗？

也不等于。移动端客户端使用系统提供的 VPN 或网络扩展能力接入流量，仍可能存在应用排除、路由排除和平台限制。先确认目标应用被接管，再检查全局策略的实际选择。不要仅凭状态栏的 VPN 标识推断每条连接的出口。

继续配置前，可查看快速上手教程确认订阅已启用，再到配置参考核对规则和策略组的引用关系。遇到所有模式都无法访问的问题，优先检查接入、节点可用性和 DNS，而不是反复切换模式。