Clash 规则不生效怎么办？按命中、顺序与连接三步排查

更新于 2026-11-01 · ghproxy.cyou

简答：Clash 规则不生效，最常见的原因不是规则完全没加载，而是流量没有进入 Clash、前面的宽泛规则先命中，或规则命中后指向了错误的策略组。最快做法是：切到 Rule 模式，打开 Connections/日志确认目标域名的命中规则，再检查自定义规则是否位于 MATCH 之前。修改后重新加载配置并关闭旧连接，再用同一域名重复测试。

定义：Clash 规则不生效，是指请求没有按照预期的规则类型、规则顺序或策略组转发，表现为本应直连的请求走了代理，或本应代理的请求仍然直连。

先试这一步：一分钟判断到底是哪一层出问题

不同 Clash 客户端的菜单名称可能略有差异，以下字段以当前运行核心和客户端界面为准。先不要急着改 YAML，按“流量是否进入—规则是否命中—策略是否正确”的顺序判断。

看到的现象	优先检查	下一步
Connections 或日志里完全没有目标请求	系统代理、TUN、应用内代理、其他 VPN 或应用绕过设置	先确认目标应用的流量确实经过 Clash，再看规则
有请求，但命中 MATCH 或其他宽泛规则	自定义规则顺序、规则类型、规则集是否加载	把精确规则放到宽泛规则和 MATCH 之前
命中自定义规则，但仍走错方向	规则末尾的策略组名称是否存在、是否选错节点	核对策略组名称和当前节点选择
修改后界面显示成功，但行为没变化	旧连接、配置未重载、订阅更新覆盖、缓存	重新加载配置，关闭旧连接后再测

官方文档说明，Rule 模式会按规则匹配请求，Global 和 Direct 则分别使用全局代理或全局直连；规则还会从上到下匹配，排在前面的规则优先级更高。查看运行模式说明，查看规则匹配顺序说明。

第一层：确认请求真的进入 Clash

确认模式。在客户端的代理或模式页面选择 Rule，不要停留在 Global 或 Direct。如果配置文件中使用核心字段，常见写法是 mode: rule，但客户端可能通过界面覆盖该值，最终应以运行状态为准。
确认接管范围。浏览器能按规则分流，不代表其他应用也会进入 Clash。依次检查系统代理开关、TUN 或虚拟网卡状态、应用自己的代理设置，以及是否存在其他 VPN、网络过滤器或安全软件。
用 Connections 或日志验证。访问一个容易复现的目标域名，然后在 Connections、Logs 或类似页面中搜索该域名。能看到目标地址、命中规则或策略组，才说明请求已经进入核心；只看到节点可用、端口已监听或客户端显示“已启动”，不能单独证明目标应用的流量已被接管。
如果没有记录。先暂时关闭应用自带 DoH、其他 VPN 和浏览器扩展代理，再仅保留一种接管方式测试。若仍没有记录，应先排查系统代理权限、TUN 权限和应用是否绕过系统代理，而不是继续修改规则。

如果请求没有进入 Clash，任何 DOMAIN、RULE-SET 或 GEOIP 规则都不会产生预期效果。此时应先恢复到原来的代理方式，逐项重新开启，避免一次修改多个变量。

第二层：检查规则顺序、类型和配置格式

Clash 规则通常按从上到下的顺序匹配，命中前面的规则后，后面的同类规则不会再优先处理。因此，下面这种写法可能让自定义规则看起来“不生效”：宽泛规则或规则集排在前面，目标域名已经被它们处理，后面的自定义规则没有机会命中。

示例：把具体规则放在 MATCH 之前。

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,DIRECT
  - RULE-SET,my-domains,PROXY
  - MATCH,PROXY

DOMAIN 适合精确匹配完整域名；DOMAIN-SUFFIX 可匹配该后缀及其子域名；IP-CIDR 和 IP-CIDR6 面向 IP 网段；RULE-SET 用于引用规则提供者。不要把一个只包含域名的规则文件声明成 ipcidr，也不要把完整的经典规则行当成普通域名列表。

规则提供者需要同时核对名称、类型、URL、本地路径、behavior 和文件格式。官方文档列出的 behavior 包括 domain、ipcidr 和 classical；mrs 格式目前只适用于 domain 或 ipcidr。查看 rule-providers 字段说明。

常见核对方式如下：

域名规则未命中：先看 Connections 中实际请求的主机名，确认不是跳转后的另一个域名，也不是只匹配了裸域名却遗漏了子域名。
IP 规则未命中：确认请求是否已经解析到目标 IP，以及是否需要 DNS 解析；官方规则说明指出，部分目标 IP 规则可能触发域名解析，no-resolve 会跳过该解析。
RULE-SET 未命中：检查 provider 是否加载成功、名称是否完全一致、文件内容是否符合对应 behavior，并在规则列表中确认引用名称没有拼写差异。
配置加载失败：检查 YAML 缩进、英文逗号、英文冒号、规则参数数量和策略组名称。无法确认客户端是否支持某个额外字段时，不要直接照抄第三方模板。

第三层：确认命中后的策略组和连接状态

规则命中并不等于最终体验一定符合预期。Connections 页面通常可以看到匹配规则类型、规则内容、策略或代理链；官方 API 文档也列出了连接中的 rule、rulePayload 和代理链等字段。查看规则与连接信息字段。

打开目标请求的详细信息，记录实际命中的规则和策略组。
检查规则末尾的策略组名称是否与当前配置中的名称完全一致，大小写、空格和标点都不要自行假设。
进入策略组，确认当前选择的节点或策略符合预期；如果规则命中的是代理组，规则本身可能没有问题，问题在策略组内部选择。
重新加载配置或重启核心，然后在 Connections 页面关闭目标旧连接。官方 API 提供关闭全部连接或关闭单条连接的接口；普通用户可直接使用客户端提供的关闭连接、清理连接或重启核心功能。
用相同域名连续测试两次，并分别记录命中规则、策略组和最终连接结果。第一次成功不能证明所有后续连接都会使用同一条规则，尤其是在域名跳转、IPv6、应用复用连接或 DNS 缓存存在时。

如果“命中规则正确但目标仍打不开”，这已经不是单纯的规则匹配问题，应转向节点连通性、DNS 解析、IPv6、TUN 权限或上游连接排查。不要为了证明规则有效而不断改变规则顺序，否则会把匹配问题和连接问题混在一起。

订阅更新后规则又失效：检查覆盖与回滚

如果规则刚改好，更新订阅或重启后又恢复原状，优先怀疑自定义内容没有写入当前运行配置，或被订阅更新、覆写配置、预处理脚本或 Dashboard 修改覆盖。此时先保留一份原配置，再做最小改动。

复制当前配置文件或导出配置，记录修改前的规则顺序。
确认当前客户端实际选中的 Profile，而不是只编辑了一个未启用的本地文件。
检查订阅更新后，rules、rule-providers 和策略组是否仍存在；如果被覆盖，把自定义规则放到客户端明确支持的覆写或本地配置入口中。
只添加一条测试规则，例如 DOMAIN,example.com,DIRECT，重新加载并观察日志。单条规则能命中后，再逐步恢复规则集。
测试失败时回滚到备份配置，避免在无法验证的模板上继续叠加修改。

不同客户端对配置合并、覆写和编辑入口的实现可能不同。本文不把某个固定目录、固定按钮或某个版本号写成通用结论；如果当前界面没有对应入口，应以客户端自己的帮助页和当前运行配置为准。

Clash 规则不生效速查清单

模式：是否为 Rule，而不是 Global 或 Direct？
入口：Connections 或日志中是否能看到目标请求？
域名：实际请求域名是否与 DOMAIN 或 DOMAIN-SUFFIX 写法匹配？
顺序：自定义规则是否排在宽泛规则和 MATCH 之前？
规则集：provider 是否加载成功，behavior、format 和引用名称是否对应？
策略：规则命中的策略组是否存在，组内是否选择了正确方向？
配置：当前运行的 Profile 是否就是你修改的文件？
连接：修改后是否重新加载配置并关闭旧连接？
分流干扰：是否存在浏览器 DoH、应用内代理、IPv6、TUN 权限或其他 VPN 影响结果？

完成以上检查后，仍无法定位时，保留一份脱敏日志，至少记录目标域名、命中规则、策略组、是否进入 Connections，以及修改前后的配置差异。不要公开包含订阅令牌、密码或完整节点链接的配置文件。

说明：关于 2026 年 10 月底的 Apple TestFlight 更新线索

截至 2026 年 11 月 1 日，本文只把所给线索视为“规则不生效问题受到关注”的更新背景，不把无法直接读取的社交平台帖文当作版本号、修复范围或兼容性证明。具体 TestFlight 构建号、修复内容和升级入口仍需以 Apple TestFlight 页面、客户端发布说明或项目公开资料为准。无论是否升级，规则排查都应以当前运行配置、Connections 和日志中的实际结果为准。

常见问题

为什么 Clash 已经启动，规则还是不生效？

客户端显示启动只说明核心或界面已运行，不代表目标应用的流量已经进入 Clash。先在 Connections 或日志中搜索目标域名；如果完全没有记录，应优先检查 Rule 模式、系统代理、TUN、应用内代理以及其他 VPN。

自定义规则应该放在 MATCH 前面吗？

通常应该。官方规则说明按从上到下匹配，前面的规则优先级更高。自定义的精确规则如果放在宽泛规则或 MATCH 后面，可能已经没有机会命中。修改前先备份配置，并确认当前客户端实际使用的是这份配置。

DOMAIN 和 DOMAIN-SUFFIX 有什么区别？

DOMAIN 用于匹配完整域名；DOMAIN-SUFFIX 用于匹配域名后缀及其子域名。例如需要覆盖 example.com 和其子域名时，通常应检查是否需要 DOMAIN-SUFFIX。最终仍应以 Connections 中的实际请求主机名验证。

RULE-SET 写了却没有效果怎么办？

检查 rule-providers 是否加载成功、provider 名称是否与 rules 中的 RULE-SET 引用完全一致，并核对 behavior 与文件内容格式。域名列表、IP 网段和 classical 规则行不能混用；加载后还要确认目标请求实际命中了该规则集。

改完规则后为什么必须关闭旧连接？

旧连接可能仍在复用此前的匹配结果或连接状态。重新加载配置、重启核心并关闭目标旧连接，可以减少缓存、连接复用和跳转造成的误判，然后用同一目标重新测试。