进阶配置 预计阅读 13 分钟

Clash 自定义规则语法详解：匹配类型、顺序与优先级

梳理域名、IP、进程与兜底规则的写法，解释自上而下匹配机制和常见失效原因。

PROOF / 01

规则匹配模型：从上到下，首次命中即停止

Clash 的 rules 是一张按行排列的流量分发表。每条规则通常由“类型、匹配内容、目标策略”组成，部分类型还可以附加参数。内核处理连接时会从列表顶部开始检查，遇到第一条符合条件的规则后立即采用该行指定的策略，不再继续检查后续内容。

这里的“优先级”不是由规则类型自动决定的。DOMAIN 不会天然高于 DOMAIN-SUFFIX，IP-CIDR 也不会自动覆盖前面的域名规则。真正决定优先级的是所在行的位置。因此，一条范围较宽的规则如果放得过早，就可能遮住后面更精确的例外规则。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,节点选择
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

以上顺序先让 api.example.com 直连，再把该域名下的其他子域名交给“节点选择”。如果交换前两行，精确域名也会先被后缀规则捕获，第一行的直连例外便失去作用。最后的 MATCH 是兜底规则，用于接收此前没有命中的连接，通常只放一条并置于末尾。

PROOF / 02

域名规则：精确主机、后缀与关键字

域名规则适合处理目标主机名明确的请求，也是自定义分流中最常用的一组类型。连接保留域名信息时，内核可以直接进行匹配，不必先把目标解析成 IP。常见类型如下。

规则类型 匹配范围 典型用途
DOMAIN 仅匹配完整域名 为单个接口或主机设置例外
DOMAIN-SUFFIX 匹配指定域名及其子域名 按整个站点或服务域分流
DOMAIN-KEYWORD 匹配域名中出现的字符串 覆盖命名规律明确但后缀分散的域名
GEOSITE 匹配数据集中收录的域名分类 在支持相应数据集的 mihomo 配置中批量分流 
rules:
  - DOMAIN,login.example.net,DIRECT
  - DOMAIN-SUFFIX,example.net,工作服务
  - DOMAIN-KEYWORD,streaming,媒体节点
  - GEOSITE,cn,DIRECT
  - MATCH,节点选择

DOMAIN,login.example.net 只匹配这一完整主机，不会匹配 static.login.example.net。DOMAIN-SUFFIX,example.net 通常同时覆盖 example.net 与它的各级子域名，适合作为站点级规则。DOMAIN-KEYWORD 的范围最难控制，只要目标域名包含指定片段就可能命中，因此应使用足够明确的关键字，并放在精确规则之后。

GEOSITE 属于数据集驱动的匹配方式。它是否可用、分类名称如何书写，取决于所用内核、客户端和地理数据文件。迁移配置时，不应把某个客户端可识别的分类直接视为所有 Clash 衍生内核都支持；应先检查内核类型以及数据文件是否已正确加载。

PROOF / 03

IP、来源地址与网络协议规则

当服务只能通过地址段识别，或者需要按局域网来源、目标区域进行控制时，可以使用 IP 类规则。IPv4 地址段通常使用 IP-CIDR，IPv6 地址段使用 IP-CIDR6；GEOIP 则依据地理数据库判断目标 IP 所属分类。

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

no-resolve 的作用是阻止这条 IP 规则为了匹配而主动触发域名解析。连接本身已经提供目标 IP 时，规则仍可检查该地址；目标只有域名且内核尚未取得真实地址时，这条规则不会强制补做 DNS 查询。局域网保留地址规则常添加该参数，因为它们不需要为普通域名额外解析。

是否添加 no-resolve 要结合目标判断。若希望 GEOIP 根据解析结果决定直连或代理，阻止解析可能使该规则无法获得所需地址。反过来，如果域名规则已经覆盖主要服务，IP 规则只是处理直接访问地址的连接，加入该参数可以避免不必要的解析动作。

在 Fake-IP 模式下，应用可能先看到内核分配的保留地址，Clash 则维护域名与真实目标之间的映射。域名规则通常仍可依据原始主机名工作，但排查 IP 规则时需要区分“应用看到的 Fake-IP”“内核保存的域名映射”和“上游解析出的真实 IP”。只盯着浏览器或应用显示的目标地址，容易误判规则是否命中。

来源地址与网络类型

SRC-IP-CIDR 按发起连接的设备地址匹配，常用于路由器或局域网网关场景。例如，可以让某台测试设备使用独立策略。NETWORK 则按 TCP 或 UDP 区分连接，适合与更具体的端口条件组合；如果单独把所有 UDP 流量提前交给某一策略，影响范围通常过大。

rules:
  - SRC-IP-CIDR,192.168.50.25/32,测试策略
  - NETWORK,UDP,节点选择
  - MATCH,DIRECT

桌面客户端只代理本机流量时，来源地址信息可能没有路由器透明代理场景那么有区分度。使用前应先确认客户端工作模式、TUN 接管范围以及内核实际获得的连接元数据。

PROOF / 04

进程、路径与端口匹配

进程规则可以按发起连接的应用分流。PROCESS-NAME 通常匹配可执行文件名称，PROCESS-PATH 匹配完整路径。它们适合处理同一域名被多个应用共用、仅希望某个程序走特定策略的情况。

rules:
  - PROCESS-NAME,example-client.exe,工作服务
  - PROCESS-PATH,C:\Apps\Example\example-client.exe,工作服务
  - DST-PORT,22,开发节点
  - DST-PORT,123,DIRECT
  - MATCH,节点选择

进程识别能力受到操作系统权限、客户端实现、内核版本和接管模式影响。Windows、macOS 与 Linux 对进程名称和路径的表示方式不同，移动系统通常也不能照搬桌面端的可执行文件规则。若日志中只有目标地址而没有进程字段，继续调整进程名称通常不会解决问题，应先确认当前平台能否提供进程元数据。

DST-PORT 根据目标端口匹配，SRC-PORT 根据本地来源端口匹配。目标端口比来源端口更稳定，但也不能单独代表某项业务：例如 TCP 443 被大量 HTTPS 服务共用，将它提前设置为单一代理策略，会覆盖绝大多数网页连接。端口规则更适合处理用途明确的协议，或在 mihomo 的逻辑组合规则中与域名、网络类型共同限定。

PROOF / 05

规则顺序与优先级的实用编排

便于维护的规则表通常遵循“例外在前、常规在中、兜底在后”的结构。可先放必须直连或必须拒绝的精确主机，再放业务域名与进程规则，随后处理地址段和地理分类，最后用 MATCH 收口。具体顺序仍应按实际目标调整，而不是机械套用固定模板。

  1. 本地与管理地址：路由器后台、局域网网段和本机服务通常优先直连，避免被广泛代理规则截获。
  2. 精确例外：使用 DOMAIN、单地址 CIDR 或明确进程名处理特殊需求。
  3. 业务规则：按域名后缀、规则集合或应用进程分配到对应策略组。
  4. 宽范围分类：地理数据库、关键字和大型规则集合放在更精确规则之后。
  5. 最终兜底：以 MATCH 指向预期的默认策略。
rules:
  # 局域网
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

  # 精确例外
  - DOMAIN,update.example.org,DIRECT
  - DOMAIN,blocked.example.org,REJECT

  # 常规业务
  - DOMAIN-SUFFIX,example.org,工作服务
  - PROCESS-NAME,media-player.exe,媒体节点

  # 区域与兜底
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

注释不会改变规则行为，但能显著降低后续校样成本。建议为每组规则写明用途，而不是只标记来源。订阅更新或手动合并配置后，可以快速确认自定义段落是否仍位于预期位置。尤其要检查客户端的覆写功能：有的客户端会把自定义规则插入顶部，有的会追加到底部，还有的会在更新订阅时重新生成完整配置。

PROOF / 06

规则集合与 mihomo 逻辑规则

规则数量较多时，可以通过 rule-providers 把规则内容拆到独立文件，再在主规则表中使用 RULE-SET 引用。集合负责保存匹配项，主配置中的引用位置仍决定它的整体优先级。把一个集合定义在配置顶部，并不会让它自动先于其他规则执行。

rule-providers:
  service-domains:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/service-domains.yaml
    url: https://rules.example.net/service-domains.yaml
    interval: 86400

rules:
  - DOMAIN,internal.example.net,DIRECT
  - RULE-SET,service-domains,工作服务
  - MATCH,节点选择

behavior 与规则文件内容必须对应。域名类集合可使用 domain 行为，IP 段集合可使用 ipcidr，包含多种经典规则类型的集合通常使用 classical。不同内核版本对 format、支持的行为和数据文件格式可能存在差异，导入现成规则集前应核对客户端所用的实际内核，而不能只看客户端界面名称。

mihomo 还提供逻辑组合能力，可用 AND、OR、NOT 把多个条件组合成一条规则。例如，仅处理 UDP 443 的条件可以写成：

rules:
  - AND,((NETWORK,UDP),(DST-PORT,443)),REJECT
  - MATCH,节点选择

逻辑规则适合表达“同时满足”或“满足其一”的复杂条件，但括号、逗号和嵌套层级更容易写错。它们属于 mihomo 等兼容内核的扩展能力，迁移到较早的原版 Clash 内核时可能无法识别。为了保持配置可读，能用两三条清晰的普通规则解决时，不必强行改成深层嵌套表达式。

PROOF / 07

规则未生效的定位顺序

规则失效通常不是单一语法问题。更有效的检查方式是沿着“配置是否加载、连接是否进入内核、元数据是否符合预期、是否被前序规则截获”逐项确认。

  1. 确认正在使用的 Profile：编辑文件后重新加载配置，并核对客户端当前启用的配置名称。修改未激活的副本不会改变运行结果。
  2. 查看连接或日志中的命中规则：记录目标域名、目标 IP、进程、网络类型和最终策略。若显示命中了更靠前的规则，应调整顺序或缩小该规则范围。
  3. 检查 YAML 层级：rules 必须位于正确的顶层位置，列表项需要使用连字符。全角逗号、错误缩进和不可见字符都可能导致解析失败。
  4. 核对策略组名称：规则引用的名称必须真实存在。重命名代理组后，旧规则中的目标名称也要同步修改。
  5. 区分域名与 IP：应用直接访问 IP 时，域名规则没有可匹配的主机名；启用加密 DNS、TUN 或 Fake-IP 后，也应结合内核日志判断实际元数据。
  6. 检查客户端覆写：订阅更新、脚本合并和图形界面的规则覆写可能改变最终顺序，应以运行时配置为准。
  7. 确认内核支持：GEOSITE、逻辑规则、部分进程字段和规则集格式并非所有内核版本都一致支持。

用最小规则集复现

当原配置包含数千条规则时，可以临时建立一份仅含测试规则和 MATCH 的最小配置。先验证目标域名能否被精确规则命中，再逐步加入后缀、规则集合、GEOIP 与进程条件。每次只增加一组内容，便于定位是哪一行改变了结果。

rules:
  - DOMAIN,test.example.com,DIRECT
  - MATCH,节点选择

如果最小配置能够命中，而完整配置不能，问题通常在前序规则、覆写顺序或规则集范围；如果最小配置也不能命中，则应检查流量是否进入 Clash、目标是否确实带有该域名，以及客户端当前是否加载了测试配置。

提交前校样清单

  • 精确例外是否位于宽泛的后缀、关键字和规则集合之前。
  • 所有策略名称是否与代理组名称一致。
  • IPv4、IPv6 与局域网地址段是否分别使用合适的规则类型。
  • no-resolve 是否只用于不需要主动解析的 IP 规则。
  • 进程规则是否符合当前操作系统和内核的识别方式。
  • 规则集合的行为类型是否与内容格式一致。
  • 列表末尾是否保留且只保留预期的兜底逻辑。

一份稳定的 Clash 自定义规则并不依赖规则数量，而依赖边界清楚、顺序可解释和运行结果可复查。先用精确规则表达例外，再逐层扩大匹配范围，最后通过日志核对首次命中的规则，通常比不断追加关键字更可靠。

下载Clash