规则模式、全局模式与直连模式怎么选:Clash 分流逻辑入门

三种模式：决定进入内核后的流量出口

日常使用优先选择规则模式；排查某个网站的分流问题时，短暂切换全局模式；需要比较本地网络是否能直接访问时，再使用直连模式。三者不是速度档位，而是 Clash 或 Clash Meta（mihomo）对已接管连接采取的不同路由方式。

先分清两个环节：系统代理、TUN 负责让流量进入内核，规则、全局、直连负责决定进入之后怎么出去。只切换全局模式，不会让原本忽略系统代理的游戏自动经过代理。开启 TUN，也不代表所有连接都会使用远端节点。

规则模式：首条命中，不是最精确规则优先

在规则模式下，内核会使用当前连接可获得的信息进行匹配，例如目标域名、目标 IP、端口，以及受平台支持情况影响的进程信息。找到一条符合条件的规则后，就采用该规则指定的策略，不再继续向下比较哪条“更精确”。

先看一组有顺序的规则

下面是用于说明顺序的配置片段，不是完整订阅。网页出口 策略组必须已经存在于配置中；example.com 是演示域名，实际应替换为需要分流的域名。

mode: rule

rules:
  - DOMAIN,account.example.com,DIRECT
  - 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,网页出口

• account.example.com 命中第 1 条，使用直连。
• docs.example.com 没有命中第 1 条，但命中第 2 条，交给“网页出口”。
• 目标地址为 192.168.1.20 的连接命中第 3 条，通常用于访问局域网设备。
• 此前规则都未命中的连接落到最后的 MATCH，交给“网页出口”。

如果把第 2 条放到第 1 条之前，账号域名也会被后缀规则覆盖，第 1 条将无法处理这个域名。因此，账号、办公系统等窄范围例外通常应放在宽范围域名规则之前，兜底 MATCH 则放在末尾。

规则目标可以是策略组，不一定是节点

DIRECT 是直接出站策略，REJECT 是拒绝连接策略；“网页出口”这类名称通常指策略组。策略组可能再指向另一个策略组，最终才落到具体节点或直连。看到日志显示命中了某个组，还需要检查组内当前选择，不能直接认定已经使用远端节点。

no-resolve 表示不为了这条 IP 规则主动触发域名解析。连接若已经有可用目标 IP，仍可以进行 IP 匹配；若只有域名且没有可用 IP，这条规则不能靠主动解析来获得匹配条件。它不是“关闭整个配置的 DNS”。

全局与直连：适合对照，不等于接管开关

全局模式要确认 GLOBAL 的实际选择

切换到全局模式后，需要打开客户端的代理或策略组页面，查看 GLOBAL 当前选中了什么。如果选择的是 DIRECT，流量仍会直连；如果选择的是另一个组，还要继续确认该组最终使用的节点。全局模式不会自动修复失效节点，也不会补齐节点不支持的 UDP 转发能力。

一个实用对照是：保持同一节点不变，把规则模式切为全局模式，然后为故障网站建立新连接。若全局可用、规则不可用，应优先检查命中规则和组内选择；若两者都不可用，再检查节点、DNS、接管路径和目标服务。这个结果只是缩小范围，不是单凭一次访问就能确定故障原因。

直连模式仍可能保留本地代理入口

直连模式下，浏览器可以继续把请求交给本地代理端口，随后由内核直接访问目标。它与“关闭系统代理”“关闭 TUN”“退出客户端”不是一回事：本地监听、DNS 设置及接管机制可能仍在运行。

如果目的是完全退出代理接管，应先在客户端关闭系统代理或 TUN，再退出程序。否则系统可能仍指向已经停止监听的本地端口，表现为客户端一退出，浏览器也无法联网。排查时应明确是在测试“内核直连”，还是在测试“不经过内核的系统网络”。

系统代理与 TUN：先确认流量有没有进入

系统代理主要供遵循操作系统代理设置的应用使用。浏览器通常能够遵循这类设置，但游戏、自带网络栈的程序和部分命令行工具未必使用它。TUN 通过虚拟网络接口接管符合路由条件的 IP 流量，可覆盖更多应用，但仍受路由排除、其他 VPN、权限和 DNS 配置影响。

1. 先检查接管方式：在客户端查看系统代理或 TUN 的启用状态。不同客户端菜单名称有差异，不要把“规则模式已选中”当成“系统代理已开启”。
2. 再建立新连接：打开测试网站或重新连接游戏服务器，同时查看客户端“连接”页面。能找到对应目标，是流量进入内核的重要证据。
3. 最后查看出站链：检查命中的规则、策略组和最终出口。节点列表中的延迟数字只代表那次测试，不能证明浏览器正在使用该节点。

日常浏览、游戏与办公的模式选择

游戏延迟不能只看节点测试

客户端的延迟测试通常请求配置指定的测试地址，并不等同于游戏服务器的往返时间。即使测试成功，游戏也可能因为 UDP 不受支持、服务器区域不匹配或流量根本没有进入内核而失败。应查看真实游戏连接和游戏内网络指标，不要把全局模式当成游戏加速按钮。

办公直连需要同时考虑域名和 DNS

内网服务可能使用组织内部才能解析的域名。只添加一条 DOMAIN-SUFFIX 直连规则，不保证公共 DNS 能解析该域名。此时要结合组织提供的 DNS 和 VPN 方案处理；如果域名解析已经失败，继续调整节点选择通常没有帮助。

用端口与连接记录验证模式是否生效

以下使用 127.0.0.1:7890 演示显式代理测试。7890 是示例端口，不是所有客户端的固定值。先在当前生效配置或客户端端口设置中确认 HTTP 代理端口或混合端口，再修改命令。若客户端只提供 SOCKS 端口，不能直接套用这里的 HTTP 代理写法。

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

macOS、Linux 可在终端使用上述命令；Windows PowerShell 可把命令开头改为 curl.exe，避免某些环境里的同名别名影响参数解释。这里连接超时上限为 10 秒，整个请求上限为 20 秒。这些是测试参数，不是节点性能承诺。

1. 选择规则模式，执行一次命令，查看 example.com 的连接记录，记下规则和最终出站链。
2. 切换全局模式，确认 GLOBAL 使用预期节点，再执行一次，比较出站链。
3. 切换直连模式，再执行一次，检查是否由 DIRECT 出站。
4. 完成对照后恢复规则模式，把发现的错误规则修正在持久配置中，而不是长期依靠全局模式绕过。

显式代理测试证明的是“这个请求通过指定本地端口进入了内核”，并不能证明系统代理或 TUN 已覆盖其他应用。收到目标服务器的 HTTP 响应，说明请求已到达能响应的一端，但出口仍应以连接记录为准；个别服务会拒绝 HEAD 请求，不能仅凭响应状态码认定节点故障。

常见误判与恢复步骤

切换模式后，网页似乎没有变化

模式调整通常主要影响后续新建连接。浏览器可能复用 HTTP/2、HTTP/3 或其他长连接，已有连接不一定立即换出口。先关闭相关页面，再重新发起请求；必要时在客户端连接页面关闭对应连接。不要在同一条复用连接上反复刷新，然后据此判断切换无效。

规则改了，订阅更新后又恢复原样

直接编辑订阅下载生成的配置，可能被下一次更新覆盖。优先使用客户端提供的覆写、合并或持久规则机制，并确认新增规则插入的位置。若被放在 MATCH 后面，即使配置能加载，也无法接管已经被兜底规则匹配的连接。

全局能用，规则模式却选到了直连

先查目标连接实际命中的规则，而不是立刻把所有规则删除。常见情况包括域名被宽泛后缀规则提前匹配、策略组当前选择为 DIRECT，或某项规则集覆盖范围与预期不同。将必要的窄范围例外放到对应宽规则之前，再用新连接复测。

日常配置完成后，保留规则模式通常更便于同时处理本地服务、局域网和远端代理需求。需要完整的导入与接管步骤，可继续阅读入门指南；需要核对配置结构和规则设置，可查看完整文档。