规则分流 预计阅读 14 分钟

自定义规则怎么写:DOMAIN、IP-CIDR 等语法与匹配优先级详解

逐条解释常用规则类型的语法与适用场景,重点讲规则自上而下的匹配顺序、no-resolve 参数的作用,以及规则写了不生效时的定位方法。

先看懂一条 Clash 规则的组成

Clash 与 mihomo 的基础规则通常由逗号分隔，最常见的结构是“规则类型、匹配内容、目标策略”。例如 DOMAIN-SUFFIX,github.com,PROXY 表示目标域名以 github.com 结尾时，把连接交给名为 PROXY 的策略组处理。策略名称区分字符，必须与 proxy-groups 中的名称完全一致。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,github.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,FINAL

这里的 DIRECT、REJECT 是内置动作，PROXY 和 FINAL 则可以是用户定义的策略组。规则不会直接指定某一台服务器才算有效；更常见的做法是让规则指向策略组，再由策略组通过手动选择、延迟测试或故障转移决定实际节点。

YAML 缩进和规则位置

rules 是配置文件的顶层字段，列表项前通常使用两个空格缩进。不要使用 Tab 字符，也不要把规则写进 proxy-groups 或 rule-providers 内部。修改后需要让客户端重新加载配置；只保存文件而不重载，运行中的内核仍可能使用旧内容。

以常见桌面客户端为例，先在配置页面打开当前启用的配置，完成编辑后执行“保存”或“重新加载”。然后进入“连接”页面访问目标域名，查看该连接显示的规则类型和策略链。不同客户端菜单名称略有差异，但验证重点相同：确认当前配置文件、内核运行状态和连接日志三者一致。

DOMAIN、DOMAIN-SUFFIX 与 DOMAIN-KEYWORD 怎么选

DOMAIN：只匹配完整域名

DOMAIN 适合单一主机名。下面的规则只匹配 api.example.com，不会匹配 www.example.com，也不会自动覆盖 v2.api.example.com。

rules:
  - DOMAIN,api.example.com,PROXY

需要给登录接口、更新服务器或某个固定 API 单独指定策略时，优先使用 DOMAIN。它的范围明确，不容易误伤同一主域下的其他服务。

DOMAIN-SUFFIX：匹配主域及其子域

DOMAIN-SUFFIX,example.com,PROXY 通常会匹配 example.com、www.example.com 和 a.b.example.com。这是自定义域名分流中使用频率最高的类型，适合一个站点的多个子域需要采用相同策略的情况。

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN-SUFFIX,example.net,DIRECT

后缀内容应写成域名本身，不要附加 https://、路径、端口或通配符。正确内容是 example.com，不是 https://example.com/path，也不是 *.example.com。Clash 规则匹配的是连接目标，不解析网页 URL 的完整路径。

DOMAIN-KEYWORD：按域名中的字符串匹配

DOMAIN-KEYWORD 会检查域名中是否含有指定字符串。例如 DOMAIN-KEYWORD,google,PROXY 可以匹配多个含有 google 的域名。它写起来简短，但范围比后缀规则宽，可能同时命中与目标服务无关的域名。

规则类型 示例目标 是否命中 适用场景
DOMAIN,api.example.com api.example.com 是 固定接口或单一主机
DOMAIN,api.example.com v2.api.example.com 否 不向下覆盖子域
DOMAIN-SUFFIX,example.com img.example.com 是 整站及子域统一分流
DOMAIN-KEYWORD,example example-cdn.net 是 域名分散且具有稳定关键词

IP-CIDR、IP-CIDR6 与 no-resolve 的作用

CIDR 表示一个地址范围

IP-CIDR 用于匹配 IPv4 地址或网段。192.168.1.0/24 覆盖从 192.168.1.0 到 192.168.1.255 的地址；1.1.1.1/32 只匹配单个 IPv4 地址。IPv6 使用 IP-CIDR6，例如 2001:db8::/32。

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - 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

这些规则常用于本机回环、家庭局域网和企业内网直连。若电脑通过 HTTP 或 mixed 端口向同网段设备共享代理，内网规则通常应位于大范围代理规则之前，避免访问路由器管理页、NAS 或打印机时绕到代理节点。

no-resolve 不是“禁用 DNS”

当连接目标还是域名时，内核为了判断某条 IP 类规则是否命中，可能需要先取得该域名对应的 IP。把 no-resolve 附加到 IP-CIDR 或 GEOIP 规则末尾，表示不要仅为匹配这条规则主动触发域名解析。如果当前连接目标本来就是 IP，规则仍可正常比较。

rules:
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - IP-CIDR,10.20.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

在这组规则里，internal.example 先由域名规则决定；目标直接写成 10.20.3.8 时，由 IP-CIDR 规则决定。no-resolve 不会关闭配置中的 DNS 模块，也不会阻止应用自身发起 DNS 查询，更不会把域名规则变成 IP 规则。

IP 规则为什么可能不稳定

大型网站常使用 CDN，同一个域名在不同网络、时间和 DNS 服务器下可能得到不同 IP。把某个临时解析结果写成 /32 规则，短期内可能命中，地址变化后就会失效。能用稳定域名描述的服务优先使用域名规则；只有目标本身是固定地址、内网网段或确实需要按地址区域判断时，再使用 IP 规则。

规则优先级：不是类型优先，而是从上到下首次命中

Clash 规则的核心原则是顺序匹配。连接从 rules 列表第一项开始检查，命中某一条后立即采用该条指定的策略，不再继续检查后面的规则。不存在“DOMAIN 天生高于 IP-CIDR”或“REJECT 自动高于 DIRECT”的固定类型优先级。

rules:
  - DOMAIN,download.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,FINAL

访问 download.example.com 时，第一条已经命中，所以结果是 DIRECT。访问 www.example.com 时，第一条不匹配，第二条命中，结果是 PROXY。如果把两条调换位置，下载域名会先被后缀规则捕获，原本的精确直连规则就没有执行机会。

建议采用的排列顺序

  1. 本机、局域网和明确要求直连的固定目标。
  2. 需要覆盖通用规则的精确 DOMAIN、DOMAIN-SUFFIX 或 IP-CIDR。
  3. 广告拦截、服务分类、GEOSITE 或外部规则集。
  4. 地区类 GEOIP 规则以及其他大范围判断。
  5. 最后使用 MATCH 接住此前没有命中的连接。

这不是内核强制格式，而是一种便于维护的组织方式。原则是“范围越具体、例外优先级越高，就越靠前”。如果某条例外规则需要覆盖订阅提供的大型规则集，它必须出现在对应 RULE-SET 之前。

MATCH 应放在末尾

MATCH 不带匹配内容，会接住所有尚未命中的连接。经典配置中也可能看到 FINAL 作为末尾规则类型；当前 mihomo 配置普遍使用 MATCH。无论使用哪一种，只要它位于列表中间，后面的规则都不会再有机会执行。

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - RULE-SET,private,DIRECT
  - RULE-SET,streaming,MEDIA
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

GEOIP、GEOSITE 与 RULE-SET 的边界

GEOIP 按目标 IP 的地区归属判断

GEOIP,CN,DIRECT 的判断对象是目标 IP，不是域名注册地、服务器运营公司或网页语言。数据库内容会影响结果，因此客户端内核与地理数据库需要保持可用。CDN 边缘节点、Anycast 地址和数据库更新延迟都可能造成与直觉不同的分类。

如果配置使用 Fake-IP DNS 模式，域名连接仍可保留域名信息供规则系统判断；具体解析和映射由内核处理。不要因为连接列表中出现 198.18.0.0/16 范围的 Fake-IP，就把整个地址段写成代理规则。该保留网段是 Fake-IP 映射用途，并不代表网站真实服务器地址。

GEOSITE 按域名分类

mihomo 支持 GEOSITE 规则，按地理数据文件中的域名分类匹配。例如 GEOSITE,cn,DIRECT 使用的是域名集合，而 GEOIP,CN,DIRECT 使用的是 IP 地区数据。两者名称相似，但判断阶段和数据来源不同。

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

GEOSITE 分类名称依赖当前使用的数据集，并非每个旧版 Clash 内核都支持。配置需要在不同客户端之间迁移时，应先确认内核类型和规则支持情况。可在客户端“设置”中的内核信息页查看实际运行内核，也可以在命令行执行 mihomo -v 检查版本输出。

RULE-SET 引用规则提供器

RULE-SET 不是直接写域名，而是引用 rule-providers 中定义的规则集合。下面的 private 必须与提供器键名一致。提供器的 behavior 可能是 domain、ipcidr 或 classical，文件内容需要与行为类型匹配。

rule-providers:
  private:
    type: http
    behavior: classical
    format: yaml
    path: ./ruleset/private.yaml
    url: https://rules.example.com/private.yaml
    interval: 86400

rules:
  - RULE-SET,private,DIRECT
  - MATCH,PROXY

interval: 86400 表示每 86400 秒检查一次更新，也就是 24 小时。规则提供器下载失败时，先检查 URL 是否能访问、文件格式是否符合 behavior，再看客户端是否允许写入 ./ruleset/。仅把远程地址粘贴进 rules 不会自动变成规则集。

端口、进程与网络入口规则

DST-PORT 与 SRC-PORT

DST-PORT 按目标端口匹配，例如 DST-PORT,443,PROXY 会覆盖大量 HTTPS 和其他使用 443 端口的连接，范围通常很宽。SRC-PORT 按本机源端口判断，但应用的临时源端口经常变化，因此较少作为长期分流依据。

rules:
  - DST-PORT,22,DIRECT
  - DST-PORT,853,PROXY
  - MATCH,FINAL

端口规则中的端口是目标服务端口，不是 Clash 的监听端口。配置中的 mixed-port: 7890 表示本机代理入口监听在 7890；它与访问网站时的目标端口 80 或 443 属于不同概念。不要用 DST-PORT,7890 试图匹配所有经过 mixed-port 的流量。

PROCESS-NAME 的支持取决于平台和接管方式

mihomo 可在部分桌面平台按进程名或进程路径分流，例如 PROCESS-NAME,curl,DIRECT。进程规则依赖操作系统提供的连接与进程信息，在 Android、iOS、容器或权限受限环境中可能不可用。不同系统中的可执行文件名称也不相同，Windows 常见名称可能带 .exe，迁移配置时需要重新核对。

rules:
  - PROCESS-NAME,curl,DIRECT
  - PROCESS-NAME,backup-client.exe,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,FINAL

系统代理模式主要接收遵循 HTTP 或 SOCKS 代理设置的应用流量；TUN 模式则通过虚拟网络接口接管更广的 IP 流量。规则顺序在两种模式下不变，但内核能看到的目标信息可能不同。排查进程规则前，先确认该连接确实进入了 Clash，并检查连接详情里是否显示进程名称。

规则写了不生效：按这套顺序定位

第一步：确认编辑的是当前启用配置

客户端可能同时保存订阅配置、本地配置和覆写配置。先查看当前启用项的名称与更新时间，再确认规则最终写入运行配置。有些客户端更新订阅时会替换原配置，自定义内容应放入客户端支持的覆写、合并配置或独立本地配置中。

第二步：从连接日志读取实际命中项

打开客户端的“连接”或“日志”页面，再重新发起一次请求。浏览器可能复用已有 TCP、QUIC 或 HTTP/2 连接，因此修改规则后仅刷新页面不一定建立新连接。可以关闭对应标签页，等待数秒后重试，或在连接列表中终止旧连接。

假设希望 api.example.com 直连，但日志显示命中 DOMAIN-SUFFIX,example.com 并进入代理组，说明更宽的规则排在前面。若日志直接显示 MATCH，则通常意味着域名拼写、规则格式或规则集加载存在问题。

第三步：检查看到的是域名还是 IP

应用直接访问 IP 时，DOMAIN 类规则自然不会命中。应用使用自己的加密 DNS、内部缓存或 QUIC 建连时，内核看到的信息也可能与浏览器地址栏不同。连接详情中的 Host、目标地址、网络类型和进程字段，比凭网页域名猜测更可靠。

如果配置启用 TUN，可临时对比系统代理模式与 TUN 模式下的连接记录，但不要同时反复改动 DNS、规则和节点。每次只改一个变量：先确认流量进入内核，再确认目标信息，最后确认规则顺序。

第四步：验证策略组而不是只看规则名

规则命中 PROXY 只代表连接被交给该策略组。若 PROXY 当前手动选择的是 DIRECT，实际出口仍是直连；若它选择了延迟测试组，实际节点会由组内测试结果决定。连接详情通常会显示类似“规则 → 策略组 → 节点”的完整链路。

第五步：用最小规则集复现

大型订阅可能包含数万条规则，直接在完整配置里移动项目不易判断冲突。可以建立一个临时本地配置，只保留必要代理、一个策略组、两三条测试规则和末尾 MATCH。测试成功后，再把精确规则放回正式配置中对应规则集之前。

rules:
  - DOMAIN,test.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

测试时记录目标域名、连接时间、命中规则和最终策略。连续测试 3 次，每次先关闭旧连接；如果三次结果一致，才说明规则顺序稳定生效。若第一次命中旧策略、后两次命中新策略，通常是连接复用或 DNS 缓存造成，而不是匹配算法随机变化。

一份便于维护的完整规则示例

下面的结构先处理内网和明确例外，再处理广告、业务分类、国内域名与国内 IP，最后把剩余连接交给代理组。它展示的是排列方法，策略组名称和规则集地址需要按照实际配置调整。

rules:
  # 本机与局域网
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - 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

  # 明确例外
  - DOMAIN,updates.example.com,DIRECT
  - DOMAIN-SUFFIX,work.example,WORK
  - DOMAIN-SUFFIX,github.com,PROXY

  # 分类规则
  - GEOSITE,category-ads-all,REJECT
  - RULE-SET,private,DIRECT
  - RULE-SET,streaming,MEDIA

  # 大范围规则
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve

  # 兜底
  - MATCH,PROXY

维护时给规则分组加注释，并把人工例外集中放在大型规则集之前。每次修改后先验证一个明确域名、一个国内站点、一个代理站点和一个局域网地址，例如路由器的 192.168.1.1。四类连接都符合预期，再继续扩大规则范围。

规则分流的关键不是堆叠更多条目，而是保证每条规则的范围可解释、顺序可验证、命中结果能从日志复现。遇到异常时，从当前配置、连接目标、首次命中规则、策略链和实际出口五个位置逐层检查，通常可以快速找到问题所在。

下载 Clash 按平台选择客户端