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

Clash 的规则系统负责回答一个具体问题：一条新连接应该交给哪个策略组、代理节点或直连动作。多数“规则不生效”并非语法完全错误，而是连接先被更靠前的规则命中、修改写进了会被订阅刷新替换的文件，或者测试流量根本没有进入当前运行中的内核。

阅读规则时，应把域名、目标 IP、进程、端口和网络协议看成不同的匹配条件。规则列表不是按“看起来更具体”自动排序，也不会因为某一条写得更长就获得更高优先级。实际判断通常沿着 rules 列表从上向下进行，首次匹配后立即采用该条规则指定的策略，后面的规则不再参与这条连接的判断。

匹配模型：连接如何走到某条规则

应用发起访问后，Clash 或 mihomo 内核需要获得目标信息。对于浏览器代理请求，内核通常可以直接看到目标域名；对于部分透明代理或 TUN 流量，内核可能先获得目标 IP，再结合 DNS 映射、嗅探结果和连接元数据恢复域名。可用信息不同，同一组规则在不同接管方式下也可能呈现不同命中结果。

假设规则列表依次包含某个完整域名的直连规则、该域名所属后缀的代理规则，以及最后的兜底规则。当访问完整域名时，第一条已经命中，后缀规则不会再执行。若把后缀规则放到前面，它会先接住整个子域范围，后面的完整域名例外便失去作用。这也是编写规则时通常把窄范围例外放在宽范围规则之前的原因。

rules:
  - DOMAIN,updates.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,节点选择
  - MATCH,漏网之鱼

上例中，updates.example.com 走直连，其他以 example.com 为后缀的域名进入“节点选择”，剩余连接交给“漏网之鱼”。这里的“节点选择”和“漏网之鱼”必须是配置中真实存在的策略组名称；名称中的中文、空格和大小写都应与 proxy-groups 定义保持一致。

规则命中与节点可用是两个阶段

规则命中只决定把连接送往哪里，并不保证策略组内所选节点一定可用。例如日志显示连接已经命中“节点选择”，但页面仍无法打开，问题可能位于策略组当前选项、节点连通性、DNS 返回、TLS 握手或上游网络。反过来，节点测速正常也不能证明自定义域名规则已经命中。测速使用的地址和真实访问目标往往不同，应分别验证。

常用规则语法与适用范围

经典规则通常采用逗号分隔形式：第一段是规则类型，中间部分是匹配内容，接着是目标策略，末尾可带该类型支持的附加参数。不同内核与客户端版本支持的规则类型并不完全相同，尤其是进程、入站、规则集合和逻辑组合相关能力。编辑前应确认客户端使用的是传统 Clash 内核还是 Clash Meta（mihomo）内核，并以该内核的配置文档和运行日志为准。

DOMAIN：精确域名

DOMAIN 只匹配指定的完整主机名，适合设置单个例外。它不会自动覆盖该域名的其他子域。例如：

- DOMAIN,api.example.com,DIRECT

这条规则可匹配 api.example.com，但不会匹配 img.api.example.com。如果一个站点同时使用主站、接口、图片和下载等多个子域，需要逐条列出，或改用后缀规则覆盖整个域名范围。

DOMAIN-SUFFIX：域名后缀

DOMAIN-SUFFIX 用于匹配某个域名及其子域，适合站点级分流：

- DOMAIN-SUFFIX,example.com,节点选择

它可覆盖 example.com、www.example.com 和更深层的子域。后缀规则范围较宽，若需要让其中一个更新域名直连，应把对应的 DOMAIN 例外放在它前面。

DOMAIN-KEYWORD：域名关键词

DOMAIN-KEYWORD 检查域名中是否包含指定文本。它写起来简短，但误命中范围通常比预期更大。例如关键词 music 可能匹配多个互不相关的域名。除非目标域名结构经常变化且有稳定特征，否则优先使用精确域名或域名后缀。

- DOMAIN-KEYWORD,example,节点选择

IP-CIDR 与 IP-CIDR6：目标地址段

IP-CIDR 匹配 IPv4 地址段，IP-CIDR6 匹配 IPv6 地址段。它们适合内网、固定服务地址和明确公布的网络段：

- 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

no-resolve 表示匹配这条 IP 规则时，不为了取得 IP 而额外解析域名。它常用于私有地址段等只需要检查现有目标 IP 的场景。是否添加该参数应依据规则目的决定：如果希望域名连接解析后也参与某个 IP 段判断，就不能机械地给所有 IP 规则附加 no-resolve。

GEOIP、GEOSITE 与规则数据

GEOIP 根据目标 IP 所属的地理数据库分类进行匹配；mihomo 常见配置还会使用 GEOSITE 对域名集合分类。此类规则依赖客户端加载的地理数据文件，命中结果也受数据版本影响。它们适合作为大范围分类工具，但不等于每个域名和地址都能永久保持同一归属。需要稳定例外时，仍应在分类规则之前添加精确规则。

- GEOSITE,category-ads-all,REJECT
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,节点选择

传统 Clash 分支未必支持相同的 GEOSITE 写法或数据加载方式。若配置检查提示未知规则类型，应先确认内核能力，而不是反复调整缩进。

端口、网络协议与进程规则

DST-PORT 可按目标端口分流，NETWORK 可区分 TCP 与 UDP。进程规则可按程序名称或路径匹配，但依赖操作系统权限、内核实现和客户端是否提供相关元数据。移动系统、受限沙箱以及某些透明代理环境中，内核不一定能可靠取得进程信息。

- DST-PORT,22,工作线路
- NETWORK,UDP,低延迟线路
- PROCESS-NAME,example.exe,DIRECT

端口规则应谨慎放置。诸如 443 这样的通用端口承载大量不同服务，若将其放在域名规则之前，几乎所有 HTTPS 连接都可能被提前接走。进程规则同样不宜仅凭程序名称处理安全边界，因为应用可能调用其他系统进程发出连接。

顺序与优先级：为什么更精确的规则也会失效

规则列表没有自动计算的“精确度优先级”。DOMAIN 不会天然压过前面的 DOMAIN-SUFFIX，IP 小网段也不会自动压过前面的大网段。只要靠前规则已经满足条件，当前连接就不会继续向下查找。因此，自定义列表常按“明确例外、具体分类、宽范围集合、地理分类、最终兜底”的顺序组织。

1. 本地与必要直连例外：局域网地址、路由器管理域名、企业内网或明确要求直连的更新服务。
2. 精确域名和进程例外：用于覆盖后续后缀规则、规则集合或地理分类。
3. 站点级后缀规则：将一组稳定子域交给同一策略。
4. 规则集合：维护较大规模的域名、地址段或服务分类。
5. GEOIP、GEOSITE 等宽范围判断：处理没有被前面规则覆盖的连接。
6. MATCH 兜底：接收仍未命中的剩余流量，并放在列表末尾。

MATCH 表示匹配剩余连接，因此它后面的普通规则在实际运行中通常没有机会生效。有些旧配置使用 FINAL 表达相近的兜底含义，但不同内核接受的名称可能不同。迁移配置时不要只替换文本，应先运行配置校验并检查内核日志。

同一域名可能产生多条连接

网页访问不是单一请求。主文档、静态资源、视频、统计接口和第三方登录可能来自不同域名，HTTP/3 还可能使用 UDP。看到主域名命中预期策略，并不代表页面涉及的所有连接都采用相同路线。排查某个站点时，应在连接列表或日志中观察实际失败的主机名、目标端口、网络协议和命中规则，而不是只为地址栏中的域名添加一条规则。

DNS 结果会影响 IP 规则观察

域名规则依据内核掌握的主机名判断，IP 规则则依赖目标地址。若应用自行加密解析、直接连接已缓存 IP，或 TUN 嗅探未恢复域名，日志中可能只出现 IP。此时域名规则未必具备可用匹配条件。相反，在 fake-ip 模式下，内核会维护虚拟地址与域名之间的映射，不能仅凭连接界面展示的地址判断真实上游 IP。应结合 DNS 模式、日志中的域名字段和最终规则名称一起分析。

规则集合与 RULE-SET：拆分大规模配置

当规则数量较多时，mihomo 等内核可通过 rule-providers 定义外部规则集合，再在主规则列表中使用 RULE-SET 引用。这样可以将域名分类、地址段和主配置分开维护。规则集合不会自动获得更高优先级；它在主 rules 列表中的引用位置，仍决定何时参与匹配。

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

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - RULE-SET,work-services,工作线路
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

behavior 用来说明集合内容的组织方式。常见取值包括 classical、domain 和 ipcidr。经典集合可以容纳带类型的规则项；域名集合与地址段集合则要求内容符合对应格式。若集合声明为 domain，却塞入完整的经典规则字符串，提供器可能下载成功但解析失败，或在配置检查阶段直接报错。

远程集合还涉及更新时间、缓存路径和网络可达性。首次启动时若集合尚未下载，而当前配置又依赖它，客户端可能提示初始化失败。排查时应查看提供器状态、最后更新时间和解析错误，不要只测试集合 URL 能否在浏览器打开。URL 可访问只能说明文件可下载，不能证明其内容格式符合当前内核要求。

多个集合发生重叠时如何决定

两个规则集合可以包含同一个域名或相交的地址段。决定结果的不是集合更新时间，也不是集合中的条目数量，而是两个 RULE-SET 引用在主规则列表中的先后位置。需要覆盖公共集合时，可先放本地精确例外，再引用自己的小型集合，最后引用范围更广的公共集合。

rules:
  - DOMAIN,build.example.com,DIRECT
  - RULE-SET,my-exceptions,专用线路
  - RULE-SET,public-services,节点选择
  - MATCH,漏网之鱼

这种结构比直接复制并修改大型公共集合更容易维护：例外清楚可见，公共集合更新时也不需要重新合并整份文件。

订阅更新、覆写与配置持久化

许多桌面和移动客户端会把远程订阅下载为本地配置文件。直接编辑这份生成文件虽然可能立即生效，但下一次自动更新、手动刷新或切换订阅时，改动常会被新内容替换。稳定的做法是使用客户端提供的覆写、合并、扩展脚本或本地配置功能，将自定义规则保存在订阅文件之外。

不同客户端对“前置规则”“后置规则”和“合并规则”的处理方式不同。前置规则通常适合精确例外，因为它们需要抢在订阅规则之前；后置规则若被追加到订阅自带的 MATCH 后面，就不会产生实际效果。使用覆写界面后，应打开最终生成配置或运行日志，确认规则真正插入到了预期位置。

策略组名称也属于依赖

自定义规则引用了“工作线路”，最终配置就必须存在同名策略组。订阅提供方更改组名、客户端转换配置或合并脚本重命名策略组后，规则可能指向不存在的目标并导致加载失败。较稳妥的方式是让自定义策略组也通过同一套持久化机制注入，并避免依赖经常变化的显示名称。

修改后需要重载运行配置

保存 YAML 文件并不一定会让正在运行的内核立即采用新规则。部分客户端会自动重载，部分客户端需要点击应用、重新选择配置或重启内核。判断是否重载成功，可以查看配置更新时间、内核日志和连接详情中的规则变化。已有长连接可能继续沿用建立时的路径，测试时应关闭相关应用连接、刷新页面或等待旧连接结束。

自定义规则不生效的分层检查

排查应从“当前到底运行了什么”开始，再逐步检查匹配条件。频繁改 DNS、切 TUN、换节点和重装客户端会同时引入多个变量，反而难以确定问题来源。下面的顺序适合域名规则、IP 规则和规则集合的大多数故障。

1. 确认正在使用正确配置。

   检查客户端当前选中的订阅或配置名称，以及最后加载时间。若有多个配置副本，确保修改的文件就是内核当前读取的文件。

2. 先做配置校验。

   查看客户端的配置检查结果和内核启动日志。重点关注 YAML 缩进、逗号分段、未知规则类型、重复键、规则集合解析失败以及不存在的策略组。

3. 确认流量进入 Clash。

   系统代理关闭、应用绕过代理、自带代理设置覆盖系统配置，或 TUN 未启动时，连接不会经过规则引擎。连接列表完全看不到测试流量，通常应先检查接管方式。

4. 查看实际命中规则。

   在连接详情或日志中找到目标域名、目标 IP、进程、端口、网络协议、规则类型和策略名称。若命中了前面的宽规则，应调整顺序，而不是重复添加相同域名。

5. 检查域名与 IP 条件是否可见。

   日志只有 IP 时，域名规则可能缺少匹配信息；域名已经命中时，则无需继续怀疑后面的 IP 规则。结合 DNS 模式、嗅探设置和应用行为判断。

6. 检查策略组当前选项。

   规则送入正确策略组后，确认组内当前选择的是具体节点、自动测试组、直连还是拒绝动作。策略组选择错误与规则顺序错误在表面上可能呈现相同结果。

7. 排除旧连接和缓存。

   关闭测试应用的现有连接，必要时清理应用 DNS 缓存，再发起一次新连接。规则主要在连接建立阶段判断，已经存在的会话不会因为列表改动而自动重新匹配。

8. 验证订阅刷新后的结果。

   手动更新一次订阅，确认自定义规则仍存在且位置未变化。若刷新后消失，应迁移到客户端支持的覆写或合并功能。

最小化测试比整份配置更容易定位

面对上千条规则时，可以临时添加一条足够精确、策略结果明显的测试规则，并放在列表前部。例如为测试域名指定一个单独策略组，再观察新连接的命中记录。测试完成后移除该规则，避免长期留下只为诊断服务的分流项。

rules:
  - DOMAIN,test.example.com,诊断线路
  - RULE-SET,main-services,节点选择
  - GEOIP,CN,DIRECT
  - MATCH,漏网之鱼

若最前面的精确规则仍未出现命中记录，优先检查流量是否经过当前内核、域名是否与实际请求一致，以及配置是否已成功重载。若它能命中，但原规则不能命中，则继续比较规则位置、类型和目标信息，而不必先改动网络底层设置。

可维护规则清单：从能用到容易复查

长期配置不应只追求规则数量。每增加一条宽范围规则，都应说明它覆盖什么场景、为何位于当前位置，以及是否会与现有集合重叠。对于仅有少量例外的用户，一组精确域名加稳定兜底通常比堆叠多个来源相近的大型集合更容易判断。

• 把局域网、企业内网和设备管理地址放在明确的直连区域。
• 把单域名例外放在对应后缀、关键词和规则集合之前。
• 避免用通用端口规则代替域名分类，尤其不要过早匹配 80、443 等常见端口。
• 为规则集合选择与内容一致的 behavior，并定期检查更新与解析状态。
• 确保 MATCH 位于末尾，且其目标策略组真实存在。
• 通过客户端覆写保存个性化规则，避免直接依赖订阅生成文件。
• 修改后重载配置，并使用新连接核对日志中的实际命中项。
• 迁移到 mihomo 或更换客户端时，重新确认规则类型和扩展语法支持情况。

一份清晰的规则配置，应当能从上向下解释每个阶段：先处理哪些例外，再进入哪些分类，最后由谁接住剩余流量。只要抓住首次命中、信息可见性、最终配置和策略组状态这四个检查点，大多数规则覆盖问题都能在日志中找到直接线索。

如果还在熟悉订阅导入、系统代理、TUN 与 DNS 的关系，可继续查看本站的使用手册和配置教程。规则只负责分流决策，完整连通还依赖客户端接管方式、DNS 设置和策略节点共同工作。