Clash 自定义规则怎么写:规则类型、匹配顺序与手机端覆写技巧

先确认规则模式、目标策略与内核

Clash 自定义规则解决的是“这条连接应该交给哪个出站”，不是创建代理节点。规则命中后，可以交给内置的 DIRECT、REJECT，也可以交给配置中已经存在的节点或策略组。策略组再决定实际使用哪个出站，因此“规则命中了代理组”与“最终通过代理节点连接”并不总是一回事：该组也可能选中了直连。

修改前先检查以下三项。它们决定规则能否被加载、能否参与判断，以及判断后会走向哪里。

运行模式：切换到规则模式，界面常显示为“规则”或 Rule。全局模式与直连模式不会按下面这套普通规则列表逐条分流。
策略名称：在配置的 proxy-groups 中确认目标组名，大小写、空格与中文都要一致。名称写错通常会使配置加载失败。
内核类型：确认客户端使用原版 Clash、Clash Meta 或 mihomo。Meta 分支后来更名为 mihomo，新增规则与规则集格式不能据此推定旧内核也支持。

常用规则类型与基本语法

大多数规则采用“规则类型、匹配内容、目标策略”的形式，各字段以英文逗号分隔。MATCH 没有匹配内容，直接写目标策略。YAML 中每条规则是一个列表项，使用空格缩进，不要把 Tab 混入缩进。

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,出站选择
  - DOMAIN-KEYWORD,example,出站选择
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,出站选择

这段代码用于展示语法，不是一份可单独运行的完整订阅。将它合入现有配置时，只保留一个顶层 rules 字段，并检查每条规则是否符合实际需求。

类型	判断内容	使用要点
`DOMAIN`	完整域名	`example.com` 不包含 `www.example.com`。
`DOMAIN-SUFFIX`	域名及其子域名	填写 `example.com`，不必添加 `*.`。
`DOMAIN-KEYWORD`	域名中的关键词	范围比后缀匹配宽，容易把不相关域名一起纳入。
`IP-CIDR` / `IP-CIDR6`	目标 IPv4 / IPv6 网段	匹配目标地址，不是手机当前接入的 Wi-Fi 网段。
`GEOIP`	目标 IP 的地理数据库分类	结果取决于所用数据库中的 IP 归属记录，不代表运营公司的注册地。
`RULE-SET`	规则提供者中的条目	名称必须对应 `rule-providers` 中的定义。
`MATCH`	所有尚未命中的连接	通常放在列表末尾，作为兜底。

域名规则不填写完整网址

要匹配 https://www.example.com/account，应写域名 www.example.com，不要把 https://、路径或查询参数放进 DOMAIN。普通域名规则不是 URL 路径过滤器，也不能据此区分同一 HTTPS 域名下的不同页面。

DOMAIN-SUFFIX,example.com,DIRECT 可以覆盖根域名与子域名，但不会把 notexample.com 当作该域名的子域。若只处理一个登录接口，优先使用精确域名，避免为整个域名后缀设置过宽的直连或拒绝规则。

IP 规则与 no-resolve 的区别

当连接带有域名而没有可用于判断的真实目标 IP 时，IP 类规则可能触发 DNS 解析。末尾的 no-resolve 表示不要仅为这一条规则主动解析域名；若已有可用目标 IP，仍可进行匹配。它不是关闭 DNS 的总开关，也不是“这条规则始终生效”的标志。

因此，GEOIP,CN,DIRECT,no-resolve 与不带该参数的写法，可能对同一条域名连接产生不同结果。遇到国内域名没有命中 IP 规则时，应先检查日志中的域名、目标 IP 与 DNS 行为，而不是反复调整节点。

匹配顺序：第一条命中生效，具体规则放前面

对于本文列出的普通规则，Clash 按列表从上往下判断，第一条命中后就选择对应策略，不会继续向下寻找“更精确”的规则。规则类型本身没有自动优先级：写在后面的 DOMAIN 不会自动压过前面的 DOMAIN-SUFFIX。

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,出站选择
  - MATCH,出站选择

login.example.com 命中第 1 条，交给直连。
www.example.com 跳过第 1 条，命中第 2 条。
example.net 没有命中前两条，由第 3 条兜底。

如果把前两条交换，登录域名先命中后缀规则，后面的精确直连规则便无法生效。排查“Clash 自定义规则加了没用”时，先找上方是否有更宽的规则，不要只盯着新增条目。

MATCH 为什么只能放在最后一段

MATCH 会接住此前所有未命中的连接。放在它后面的普通规则没有执行机会。建议按“明确例外 → 服务或业务规则集 → 通用地域规则 → MATCH”的思路整理，再根据实际需求调整；这是一种便于维护的组织方式，不是内核强制的分类顺序。

RULE-SET：规则提供者与引用位置要一起检查

RULE-SET 将一组匹配条件放入独立文件，再在主规则列表中引用。它不会绕过列表顺序：引用写在第几行，这组规则就在那个位置参与判断。提供者的名称、行为类型、文件格式与文件内容必须相互对应。

下面是 mihomo 的本地文件示例。先在内核可访问的配置目录中准备 ./rules/local-direct.yaml，再加入提供者定义。手机端能否写入该目录取决于客户端，不能把文件留在系统“下载”目录就默认内核能够读取。

rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,出站选择

对应的规则文件内容如下。classical 条目保留规则类型，但不写目标策略；此处的目标策略由主配置里的 RULE-SET,local-direct,DIRECT 统一指定。

payload:
  - DOMAIN,example.com
  - DOMAIN-SUFFIX,example.org
  - IP-CIDR,192.168.0.0/16,no-resolve

behavior: domain：用于域名集合，条目写法遵循对应域名集合语法，不要原样塞入上面的 classical 内容。
behavior: ipcidr：用于 IP 网段集合，不用于混放域名规则。
behavior: classical：用于带规则类型的条目，适合本文这种域名与 IP 条件混合的示例。

远程提供者还需要配置下载地址、缓存路径与更新间隔。订阅更新与规则提供者更新是两件事：主订阅刷新成功，不代表每个外部规则文件都已刷新。只有两三条手机端例外时，直接写普通规则通常比新增提供者更容易排错。

手机端覆写订阅：保留远程来源，单独管理本地规则

远程订阅是配置来源，客户端覆写是在加载时对配置进行本地调整。直接编辑订阅生成的 YAML，可能在下次更新时被替换。更稳妥的做法是保留原订阅，在客户端提供的配置覆写、规则管理或扩展配置入口中保存本地规则。

安卓客户端的操作检查顺序

打开当前使用的配置详情，先确认正在运行的是哪一份订阅。不要修改了备用配置，却继续测试另一份配置。
查找该客户端的规则管理或覆写入口，确认它支持“前置规则”、列表合并，还是仅支持整段替换。不同安卓客户端菜单名称并不统一。
先添加一条精确规则，例如 DOMAIN,example.com,DIRECT。不要同时修改 DNS、TUN 与十几条规则。
保存并重新加载配置，检查是否出现未知策略、YAML 解析失败或规则提供者加载失败。
刷新一次原订阅，再检查这条本地规则是否仍位于最终规则列表前部。能保存一次不代表能跨订阅更新保留。

若入口要求填写“合并 YAML”，先看它对数组的处理说明。rules 是数组：有的合并工具会替换整个数组，有的支持前置或追加。直接贴入只含一条规则的 rules: 段，可能把订阅原来的整套规则覆盖掉。覆写格式属于客户端功能，不存在适用于所有手机端的通用前置字段。

iOS 客户端先看配置格式，再谈规则迁移

iOS 上不同代理客户端的配置语法、模块与本地规则机制存在差异，不能仅因为都支持订阅，就认定都能直接运行 Clash YAML。先确认客户端明确支持的格式；若使用的是其他规则语法，应在其原生规则入口添加对应条件，而不是把 rules: 整段粘贴进去。

系统 VPN 权限负责让客户端接管流量，不负责把 Clash 规则转换为另一种配置格式。需要选择安装方式时，可先查看手机客户端选型指南，再按所选客户端核对配置与覆写能力。

规则不生效的排查：看连接记录，不只看网页结果

网页能否打开会受到 DNS、节点可用性、服务器状态与既有连接的共同影响。验证规则时，应在客户端的连接或日志页面查看目标域名、命中规则、策略组与最终出站。只看到页面变快或变慢，不能证明某一条规则已经命中。

现象	先检查	处理动作
配置保存后无法加载	缩进、英文逗号、策略组名	撤回最后一次改动，从单条规则重新验证。
规则存在但一直不命中	运行模式、上方宽泛规则、MATCH 位置	切回规则模式，将测试规则放到合适的前置位置。
已命中代理组但仍直连	策略组当前选择与嵌套组	沿策略链检查最终是否选中了 DIRECT。
域名规则匹配不到	连接记录中是否存在域名	核对 DNS 与流量接管方式，不要仅依据浏览器地址栏判断。
订阅更新后规则消失	修改的是源文件还是独立覆写	迁移到客户端支持的持久覆写入口，再做更新测试。

TUN / VPN 接管与规则匹配是两个步骤

开启 TUN 或系统 VPN 只意味着具备接管流量的条件，并不保证所有应用流量都进入内核。安卓的分应用设置、绕过应用列表以及客户端路由设置，都可能让特定应用直接绕开。没有进入内核的连接，自然不会命中配置里的规则。

另一个常见问题是内核只看到 IP，看不到域名。应用自带加密 DNS、直接连接固定 IP，以及 DNS 接管配置差异，都可能影响域名信息。mihomo 的域名嗅探在适用协议下可以辅助识别，但不能保证识别所有加密连接；应先理解当前 DNS 配置，再决定是否启用相关能力。可结合DNS 技术参考核对概念。

每次只改一项，并建立新连接

修改规则后，旧连接可能继续沿用建立时的出站。保存并重载后，应关闭相关应用的旧连接或重新打开应用，再观察新建连接记录。建议按“新增一条精确规则 → 验证命中 → 刷新订阅 → 再次验证”的顺序测试；出现异常时恢复上一份可用配置，而不是直接清空应用数据。