规则模式、全局模式与直连模式怎么选:三种代理模式差异图解

先选规则模式，再确认流量是否进入内核

日常使用先选规则模式（Rule），确认订阅已启用、目标策略组已选好节点，再访问需要测试的网站。如果只有某个网站异常，可以临时切到全局模式比较；需要确认当前网络能否直接访问目标时，再切到直连模式。每次只改一个设置，结果才容易解释。

三种模式决定的是已经进入 Clash 或 Clash Meta（mihomo）内核的连接如何出站，不是决定哪些应用一定会被接管。系统代理、应用内代理和 TUN 负责把流量送进内核；规则、全局和直连负责处理送进来的流量。这两层设置要分开看。

三种流量走向：入口相同，出站决策不同

下面的图以同一个已经被接管的应用连接为例。图中的“代理选择”是示例策略组名称，不是每份订阅都具备的固定名称；实际配置可能使用“节点选择”“自动选择”或其他名称。

规则模式：从上往下，首次匹配生效

应用连接
  ↓ 系统代理 / 应用代理 / TUN
Clash 或 mihomo 内核
  ↓ 从上到下检查 rules
  ├─ 命中直连规则 → DIRECT → 目标服务
  ├─ 命中代理规则 → 代理选择 → 当前节点 → 目标服务
  ├─ 命中拒绝规则 → REJECT → 连接终止
  └─ 走到 MATCH 兜底 → 指定策略 → 目标服务

规则不是“越具体的自动优先”，而是通常由上至下检查，先匹配到的先执行。如果把一条覆盖范围很大的规则放在前面，后面更精细的域名规则可能根本没有机会生效。订阅中的规则集也要结合它在 rules 列表里的引用位置判断。

全局模式：绕过通常的规则分流

应用连接
  ↓ 已被接管
Clash 或 mihomo 内核
  ↓ Global 模式
GLOBAL 策略组
  ↓ 当前选中的节点或其他可选出站
目标服务

切到全局后，还要打开代理页面检查 GLOBAL。全局并不等于“自动选择最快节点”，也不保证出口一定是代理节点。如果 GLOBAL 当前选择的是 DIRECT，或者选中的另一层策略组最终指向直连，连接仍会直接出站。部分客户端会用本地化名称展示这个组。

直连模式：仍可经过内核，但不经过代理节点

应用连接
  ↓ 已被接管
Clash 或 mihomo 内核
  ↓ Direct 模式
DIRECT
  ↓ 当前设备可用的网络出口
目标服务

直连模式不是退出客户端，也不等于关闭 TUN。内核仍可能处理连接和 DNS 请求，只是出站改为直连。因此，直连成功只能说明这条连接在当前接管和解析环境下可以直接访问，不能单凭这一点认定系统代理、DNS 和路由都已恢复到未启动客户端时的状态。

规则与策略组怎么配合：看一段最小示例

下面是用于解释匹配顺序的 YAML 片段，不能替代完整订阅。其中的“代理选择”必须已经在 proxy-groups 中定义。example.com 和它的子域名用于展示写法，不代表某项服务必须使用代理。

mode: rule
mixed-port: 7890
rules:
  - DOMAIN-SUFFIX,example.com,代理选择
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,代理选择

• mode: rule：表示默认按规则处理。客户端界面的运行时切换可能覆盖这个值，重载配置后的行为取决于客户端是否保存了模式覆盖。
• mixed-port: 7890：在同一入口端口接收 HTTP 与 SOCKS5 代理连接。7890 是示例，不是所有客户端的固定端口。
• DOMAIN-SUFFIX：匹配指定域名及其子域名；命中后交给“代理选择”，再由该策略组决定实际节点。
• IP-CIDR：按目标 IP 网段匹配。这里仅示范两个常见内网段，并不是完整的局域网直连规则。
• no-resolve：避免仅为匹配这条 IP 规则而主动解析域名；并不表示整个连接无需 DNS。
• MATCH：作为最后的兜底。放在前面会让后续规则失去匹配机会。

切到全局或直连后，通常不再按这份普通 rules 列表逐条决定出站。因此，“规则里写了内网直连”不能直接推出“全局模式也会按同一条规则直连”。对本地打印机、路由器管理页和企业内网服务，日常保留规则模式更便于明确控制。

什么时候临时切全局，什么时候回到规则

单个网站打不开：用全局做一次对照

1. 在客户端的“代理模式”区域确认当前是“规则”；部分客户端把入口放在托盘菜单的“代理模式”中，名称以实际界面为准。
2. 打开“连接”页面，访问一次目标网站，记录目标域名、命中规则和最终策略链。
3. 切为“全局”，在 GLOBAL 中选择一个已确认可用的节点。尽量与规则模式下原本使用的节点一致，避免同时改变两个条件。
4. 关闭目标网站的旧连接后重新访问。必要时只断开该域名对应的连接，不必立即断开全部应用。
5. 若全局正常而规则异常，切回规则，重点检查域名是否误命中 DIRECT、规则集是否缺失、兜底是否指向了不同策略组。

这个对照不是绝对结论。同一节点下两种模式仍可能受到配置中的按模式 DNS 行为等因素影响。若切换前后解析结果不同，需要把 DNS 一并纳入排查，而不是直接把所有问题归结为规则。

统一出口测试：可以短时间使用全局

需要观察某个代理节点的出口位置、测试一个服务能否通过该节点访问时，全局更容易减少规则分流的干扰。但这段时间内，已被接管的其他应用也可能使用相同出口，包含系统更新和云盘同步。按流量计费的订阅尤其需要留意后台下载。

日常浏览与本地服务：回到规则模式

测试结束后切回规则，重新确认常用策略组。需要代理的域名走代理，本地可直接访问的服务走 DIRECT，才能减少不必要的绕路。全局不是比规则“更高级”的模式；它只是省略了常规规则选择，更适合做短期对照。

系统代理、TUN 与 DNS：模式切换解决不了的部分

应用没有进入内核，全局也接管不到

桌面客户端开启“系统代理”后，一部分应用会读取系统设置，另一部分仍使用自己的网络配置。命令行程序还可能依赖环境变量。可以在确认本地混合端口为 7890 后，用下面的命令显式指定代理入口，减少系统代理设置带来的不确定性：

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

在 Windows PowerShell 中，如需明确调用系统提供的 curl 程序，可将开头写成 curl.exe。执行时同时看客户端的连接记录：出现这次请求，说明它确实进入了该代理入口；仅有 HTTP 响应并不能证明用了远端节点，还要看最终策略链。命令中的 10 秒是连接超时，20 秒是总耗时上限，不是延迟测试成绩。

TUN 通过虚拟网络接口和路由接管更多 IP 流量，但范围仍受路由、排除项、权限及具体实现影响。开启 TUN 不会自动让节点支持 UDP，也不会修复节点本身不可达的问题。需要接管不遵循系统代理的应用时，再按客户端教程检查 TUN 权限和路由配置。

切换模式不等于清空 DNS 状态

使用 Fake-IP 时，内核可能向应用返回用于域名映射的虚拟地址，再借助映射识别实际域名。这不等于连接真的被发送给了一个公网目标。DNS 上游、Fake-IP 过滤项、应用自己的加密 DNS，以及本机缓存，都可能影响排查结果。

不要因为切全局后仍然打不开，就立刻同时修改 DNS、TUN 和订阅。先看连接有没有出现，再看域名与策略链，最后检查解析和节点连接错误。一次修改多个层级，容易把原本可复现的问题变成偶发问题。

切换后没有变化：按连接记录逐项核对

模式切换通常影响后续新建连接，不保证已有 TCP 长连接或 QUIC 会话立即改道。网页刷新也可能复用连接；若记录仍显示旧策略，应先关闭相应连接，再重新发起请求。进行中的下载、会议或远程会话可能因此中断，操作前先确认影响范围。

最后按三个问题收尾：连接进内核了吗？最终走了哪个出站？新连接是否使用了预期模式？这三点确认后，再决定是修正规则、调整接管方式，还是更换节点。日常保留规则模式，排查时短暂使用全局或直连，通常比反复重装客户端更容易定位原因。