先记住规则优先级：从上到下，首次命中即停止

Clash 自定义规则不是“写得越精确就自动越优先”，而是在规则模式下按列表顺序检查：第一条匹配成功的规则决定连接交给哪个出站策略，后面的规则不再参与选择。因此，精确域名例外放前面，域名后缀规则放后面，MATCH 放在整个列表末尾。调整顺序，通常比反复更换节点更能直接解决分流错误。

本文以 Clash 常见规则语法为基础，涉及规则集时说明 mihomo（Clash Meta）用法。不同客户端的配置编辑入口、覆写机制和内核版本不同，不能仅凭客户端名称判断所有扩展字段是否可用。基础分流先用 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 和 MATCH，确认命中结果后再扩展。

系统代理与 TUN 模式决定流量怎样进入内核，规则决定进入后如何选择出站。开启 TUN 不会自动提高某条规则的优先级；应用流量没有进入 Clash 时，规则写得正确也不会出现在连接记录里。

规则基本格式：类型、匹配内容、出站策略

规则通常位于 YAML 配置的 rules: 列表下。常见格式是 类型,匹配内容,出站策略，部分类型允许附加参数。列表项前使用短横线，缩进用空格，不用 Tab。下面是可并入现有配置的规则片段，不是包含节点、端口和 DNS 的完整配置：

rules:
  - DOMAIN,login.example.org,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

这里的 DIRECT 表示直连，REJECT 表示拒绝连接，均是内置出站策略。示例使用保留示例域名说明顺序：login.example.org 直连，其余属于 example.org 的域名被拒绝，没有命中前面规则的连接由最后一条直连。

使用策略组时，名字必须能在配置中找到

如果已有 proxy-groups 中存在名为“节点选择”的策略组，可以把某一条的出站策略改成该名称。例如 DOMAIN,api.example.org,节点选择。但这不是通用内置名称：配置里没有这个组时，直接照抄会导致配置校验或加载失败。

  • 一个配置只保留一个顶层 rules: 键，在已有列表内插入规则，不要在文件末尾重复添加同名键。
  • 复制规则时使用英文逗号，避免中文逗号让整行变成无法识别的内容。
  • 规则指向策略组后，最终节点还由该组的选择或测速机制决定；规则命中和节点可用是两个检查环节。

DOMAIN 与 DOMAIN-SUFFIX：先写例外，再写范围

类型规则示例匹配范围
DOMAINDOMAIN,api.example.org,DIRECT仅匹配这个完整域名
DOMAIN-SUFFIXDOMAIN-SUFFIX,example.org,DIRECT匹配根域名及其子域名
DOMAIN-KEYWORDDOMAIN-KEYWORD,example,REJECT匹配域名中包含该字符串的连接

后缀不是任意字符串结尾

DOMAIN-SUFFIX,example.org,DIRECT 能匹配 example.org、www.example.org 和 a.b.example.org，但不应把 notexample.org 当作其子域名。若要处理一个域名及其所有子域名，直接写根域名即可，不要加 https://、路径或 *.。

规则里的域名不是完整 URL。https://example.org/account 包含协议与路径，不能直接放进 DOMAIN。普通域名规则也无法区分同一站点的 /account 与 /images 路径；HTTPS 的路径属于加密应用层内容，不能把域名分流当成按网页路径过滤。

关键词规则要防止误伤

DOMAIN-KEYWORD 使用方便，但范围往往比预想更大。“example”可能出现在并不属于 example.org 的其他域名里。知道完整域名时优先使用 DOMAIN，需要覆盖整个站点域时使用 DOMAIN-SUFFIX，不要用很短的关键词替代明确范围。

rules:
  - DOMAIN,download.example.org,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - MATCH,DIRECT

这段顺序让下载子域名成为例外。如果将后缀规则移到第一行，下载域名也会先命中拒绝规则，下面更精确的 DOMAIN 不会获得第二次判定机会。Clash 不会自动把具体域名提到宽泛规则之前。

IP-CIDR 与 no-resolve：区分目标地址和解析行为

IP-CIDR 按目标 IPv4 地址所在网段匹配，写法如 IP-CIDR,192.168.1.0/24,DIRECT,no-resolve。其中 /24 是网络前缀长度，对应地址范围为 192.168.1.0 到 192.168.1.255；只匹配单个 IPv4 地址时使用 /32。IPv6 使用 IP-CIDR6，单个 IPv6 地址使用 /128。

rules:
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - MATCH,DIRECT

这些是常见私有地址范围示例，不是完整的特殊地址处理方案。企业网络、自建路由和 VPN 可能拥有额外网段；如果目标网段应通过公司隧道访问，不能仅因为它是私有地址就假设普通直连一定可达。

no-resolve 不等于关闭 DNS

当连接带有域名、尚无可用于匹配的真实目标 IP 时，IP 类规则可能触发解析，以便判断地址是否落在网段内。附加 no-resolve 的含义是：不为了这条规则额外发起域名解析。若已有可用目标 IP，或应用本来就连接一个 IP 地址，仍然可以匹配这条规则。

反过来，给已知内网 IP 流量安排直连时，no-resolve 可以避免为了这条网段规则触发额外解析。它不阻止应用自行查询 DNS，也不表示最终建立连接时永远不需要解析。Fake-IP、DNS 映射和嗅探配置会影响内核可获得的信息，排障时要看实际连接记录。

MATCH 与规则集：把兜底留到最后

MATCH 无条件匹配剩余连接，因此只有两个主要字段：MATCH,出站策略。一旦把它写在列表开头，后续域名规则、IP 规则和规则集都会失去作用。常见安排是“精确例外 → 分类规则 → 必要的地址规则 → MATCH”，但不同类别之间仍以实际列表顺序为准。

规则集没有独立的更高优先级

mihomo 支持通过 rule-providers 管理规则集，再用 RULE-SET 引用。引用在 rules 中出现的位置，就是它参与匹配的位置。规则集文件再大，也不会自动高于写在它前面的单条规则。

  • 需要让一个域名绕过某个规则集，就把该域名的精确规则放在对应 RULE-SET 引用之前。
  • 使用前确认 provider 名称已定义，并检查 behavior 与实际内容相符，例如域名集与 CIDR 集的内容格式并不相同。
  • 规则集更新失败与“没有任何条目命中”不是同一问题，先看加载日志，再判断规则顺序。

原版 Clash 的不同分支与 mihomo 在规则集格式、逻辑规则和其他扩展上存在差异。跨内核迁移时，不要只复制 RULE-SET 那一行；还需要连同 provider 定义一起检查，并使用当前内核的配置检查能力确认支持情况。

兜底直连还是代理，取决于目标策略

本文片段使用 MATCH,DIRECT 是为了让示例不依赖任何外部策略组，并不代表所有订阅都应直连兜底。日常需要让未分类连接走代理时，应把最后一条改为已存在的代理策略组名称。先保留订阅原本的兜底意图，再逐步加入局部例外，通常更容易定位变化。

订阅更新后规则丢失：检查覆写位置和合并顺序

直接修改客户端下载的订阅 YAML，可能在下一次更新时被远端内容覆盖。更适合长期维护的方法，是使用客户端提供的本地覆写、合并配置或脚本能力；不同客户端菜单和合并语义不统一，应先在当前订阅的操作菜单中确认其本地扩展入口，不能假设所有“编辑”按钮都保存为永久覆写。

  1. 先备份当前可用配置。记录已激活订阅、当前模式和原来的最后一条规则，避免测试后无法还原。
  2. 先插入一条可观察的精确规则。例如对自己用于测试的域名设置临时拒绝，不要一次加入数百条新规则。
  3. 检查最终生效配置。若合并后自定义规则被追加到原有 MATCH 后面，即使文件里存在这条规则也不会命中。
  4. 重新加载后再更新订阅一次。确认本地规则仍存在且位置正确，才算完成持久化验证。

覆写工具可能把列表替换、前置或后置，三种行为结果完全不同。全量替换 rules 会丢掉订阅原本的分流逻辑；简单后置又可能落到兜底后面。明确客户端的合并规则，比只确认“保存成功”更重要。

规则不生效的排查顺序：模式、连接、命中、出站

判断修改是否成功，不要只看网页能否打开。缓存、已有长连接和浏览器复用都会干扰观察。重载规则后，关闭目标站点的旧连接再发起新请求；必要时在客户端连接列表中结束对应连接，不必先断开所有正常应用。

现象优先检查处理方向
没有目标连接记录应用是否读取系统代理，TUN 是否实际接管先解决流量入口，不要继续改匹配规则
连接显示 Global 或直连模式策略当前代理模式切换规则模式后建立新连接
显示命中 MATCH域名是否一致、IP 是否可用、规则是否已加载核对连接详情与最终规则列表
命中较宽的后缀规则精确例外是否排在后面把例外移动到宽泛规则之前
命中预期策略但请求失败策略组当前节点及目标连通性区分分流成功与出站连接失败

用同一目标做前后对照

如果当前混合端口确实配置为 7890，可用下面的命令让一次请求明确经过本地 HTTP 代理；若实际端口不同，应使用客户端显示的值。Windows 可使用 curl.exe 避免 PowerShell 旧版本的同名别名歧义。命令只用于请求测试，不提供固定延迟或成功率承诺：

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

随后在连接详情中核对目标域名、命中规则、策略组和最终出站。这个测试验证的是显式 HTTP 代理链路，不等于验证 TUN 接管或 UDP 转发。若应用直接连接 IP，域名规则可能缺少匹配所需的域名；mihomo 的嗅探能力可以在支持的协议与配置下补充信息，但不能保证所有加密流量都能恢复域名。

稳定的维护顺序是：保留已知可用配置，每次只改一小组规则，确认新连接的命中记录，再验证订阅更新后的持久性。需要继续配置订阅、DNS 或 TUN 模式时，可查阅Clash 完整手册；常见连接问题可先对照常见问题，避免把所有网络故障都归因于规则语法。