Clash 三种代理模式

先区分：流量接入与代理模式

日常按规则分流，排查时短暂切全局，需要本机直接连接时选直连。这三种模式决定的是：连接进入 Clash 内核之后，由什么逻辑选择出口。它们并不直接决定哪些应用的流量能够进入客户端。

例如，浏览器通过系统代理接入客户端，或者应用手动使用本机的 127.0.0.1:7890 HTTP 代理，连接才会交给内核处理。开启 TUN 模式则是另一种接入方式，通常通过虚拟网络接口和路由接管更多流量。实际接管范围仍受操作系统、路由、排除项和权限影响。

下面的说明适用于常见 Clash 配置语义及 Clash Meta（mihomo）内核。客户端可能把入口命名为“代理模式”“运行模式”或“模式”，但规则、全局、直连三项通常对应同一组 mode 值。

mode 字段：三种模式对照

在配置文件的顶层，mode 与 mixed-port、rules 等字段同级，不应缩进到 dns 或某个策略组内部。常见写法如下；这里只展示模式与监听端口，不是一份可独立运行的订阅配置。

mixed-port: 7890
mode: rule
log-level: info

在界面中切换模式，客户端通常会通过内核控制接口改变当前运行状态；它未必直接改写订阅文件。重载配置、重启客户端或者更新订阅后是否保留选择，取决于客户端的持久化与覆写机制。需要固定默认值时，应检查客户端提供的覆写设置，不要只修改下一次更新就会被替换的订阅副本。

规则模式：从上到下，命中即停止

规则模式下，内核按 rules 列表的顺序检查连接，第一条匹配成功的规则决定目标。目标可以是 DIRECT、REJECT，也可以是一个策略组名称。因此，“规则模式”不是“全部代理”，而是允许不同连接采用不同处理方式。

一个可读的规则片段

以下片段假设配置里已经存在名为“代理选择”的策略组。该名称必须与实际 proxy-groups 中的 name 完全一致；只有这几行规则不能创建代理节点或策略组。

mode: rule

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
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,代理选择

• DOMAIN-SUFFIX,example.com 匹配该域名及其子域名，前提是内核能够取得连接对应的域名信息。
• 三条 IP-CIDR 规则覆盖常见 IPv4 私有地址段，适合将访问本地服务的连接交给直连出口。
• no-resolve 表示不为了检查这一条 IP 规则而额外触发域名解析，并不代表整条连接不需要 DNS。
• 最后的 MATCH 接住前面没有匹配到的连接，交给“代理选择”。

规则列表不是自动按“更精确优先”排序。若把 MATCH,DIRECT 放到第一行，后面的域名规则就不会获得匹配机会。同样，把较宽泛的规则放在精确规则之前，也可能导致后者一直不生效。

策略组选择仍然影响最终出口

规则命中“代理选择”只完成了第一步。若该组当前选择 DIRECT，连接最终仍然直连；若它选择另一个策略组，则还要沿引用继续确定出口。遇到“命中了代理规则却没有走预期节点”的情况，应同时检查命中规则、目标组和组内当前选择，不能只看模式按钮。

MATCH 兜底：决定未分类连接的去向

MATCH 不需要域名、IP 或端口条件，它会匹配所有走到这一行的连接。为使配置行为清晰，通常将它放在规则列表末尾。它不是失败重试机制，也不会在节点无法连接时自动改为直连。

如果希望“已知本地服务直连，其余连接交给代理组”，可以采用前面示例的结构；如果希望“只代理明确列出的域名，其余直连”，则可将末行改为 MATCH,DIRECT。两者的差别在于默认出口，而不在规则模式本身。

全局模式：适合做出口对照测试

将 mode 改为 global 后，进入内核并由其处理的连接会交给内置 GLOBAL 策略组，而不是按照普通 rules 列表逐条分流。需要在客户端的代理页中查看全局组当前选择；只切模式、不检查全局组，不能保证出口就是期望的节点。

全局组可选内容由内核与客户端展示方式决定。若当前选择为 DIRECT，即使界面显示“全局”，最终也可能直接连接。因此，全局描述的是统一选择出口的方式，不是“必定使用远端代理”的保证。

规则模式失败、全局模式成功时怎么查

1. 使用同一个目标地址，先在规则模式下建立一条新连接，记录连接页中的命中规则、策略链和出口。
2. 切换全局模式，在 GLOBAL 中明确选择刚才要测试的同一个节点，再建立新连接。
3. 如果只有全局成功，优先检查规则顺序、规则集是否加载，以及规则模式对应策略组的实际选择。
4. 如果两种模式都失败，再检查节点状态、本地接入方式、DNS 和目标服务，不要继续只调整规则。

全局模式也有使用边界。局域网访问原本可能由直连规则处理，切换后这些普通分流规则不再参与选择。打印机、NAS 或内部网站若出现异常，应先恢复规则模式并检查访问路径，而不是把全局长期当作通用修复方案。

直连模式：不是关闭客户端

mode: direct 让由内核处理的连接通过 DIRECT 出口访问目标。此时客户端仍可能监听本机端口、接收系统代理流量或运行 TUN；内核 DNS 模块也可能继续参与解析。它与退出客户端、关闭系统代理、关闭 TUN 是不同操作。

这一区别对故障排查很重要：直连模式可以用来比较“使用远端代理”和“由本机连接”的表现，但不能单独证明客户端接管完全没有影响。若需要测试操作系统原本的网络路径，还应分别关闭系统代理与 TUN，并确保应用没有手动指定代理地址。

适合使用直连的三个场景

• 本地服务测试：确认目标是否能由当前网络直接访问，再决定是否需要补充直连规则。
• 节点与线路对照：同一地址在直连和代理出口下分别新建连接，比较可达性，而不是仅比较界面上的测速结果。
• 临时恢复默认出口：保留客户端运行状态，同时暂时让进入内核的连接直接访问目标。

直连模式同样不按普通规则列表分流，因此不能依靠其中的 REJECT 规则继续执行规则式拦截。若某些访问限制依赖这些规则，切换前应先理解行为变化。

系统代理、TUN 与 DNS 的检查顺序

遇到“切了模式没有变化”，可按接入、模式、规则、出口的顺序排查。先确认连接出现在客户端连接页，再观察匹配信息，比反复重启更容易缩小范围。

1. 确认接入端口：若实际 mixed-port 为 7890，应用应使用对应的本机代理地址。端口已修改为 7891 时，应用仍指向 7890 就可能连接失败或接入另一个进程。
2. 确认当前模式：在客户端的模式入口检查实际选中项，不只阅读磁盘文件中的 mode。运行状态可能已由界面修改。
3. 确认策略链：规则模式看命中项与策略组；全局模式看 GLOBAL；直连模式确认是否使用 DIRECT。
4. 重新建立连接：模式切换通常影响新连接，已有下载、视频或长连接未必立即迁移。可关闭测试页面后重新打开，必要时只结束对应连接。
5. 单独检查解析：模式切换不会自动重写所有 DNS 设置。应用的加密 DNS、系统缓存、内核 DNS 和 TUN 的 DNS 接管，都可能影响最终取得的地址。

日常选择与恢复检查

对于已经配置好订阅、策略组和规则的客户端，规则模式通常更适合作为日常默认选项。它可以保留局域网直连、指定站点代理以及必要的拒绝规则；全局模式适合短时间验证出口；直连模式适合比较本地网络路径。

• 日常使用：选择规则模式，确认末尾 MATCH 指向符合需求的目标。
• 分流异常：短暂切到全局，并明确选择对照节点；确认差异后回到规则列表定位问题。
• 网络基线测试：先使用直连模式比较；若仍需排除接管影响，再关闭系统代理和 TUN 测试。
• 测试结束：恢复原模式与策略组选择，重新检查局域网服务和常用站点，避免把临时状态长期保留。

记住两个独立问题即可减少混淆：系统代理或 TUN 决定连接如何进入客户端，mode 决定进入后如何选择出口。在规则模式中，再补上一层“从上到下匹配、由 MATCH 收尾”的检查，就能解释大多数模式切换与分流结果。