Clash 自定义规则写法:DOMAIN-SUFFIX、IP-CIDR 与匹配顺序

规则行结构：类型、匹配内容、出站策略

Clash 自定义规则写在配置文件的 rules 列表中。FlClash 使用 mihomo 内核时，会根据请求信息逐条判断，命中后交给指定策略。先确认客户端已选择需要修改的配置，并将出站模式设为「规则」。全局模式和直连模式不按这份常规规则列表完成分流。

多数规则采用三段结构：规则类型,匹配内容,出站策略。段与段之间用英文逗号分隔，YAML 列表项以短横线和空格开头。下面是一段可以并入现有配置的规则示例：

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,REJECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,DIRECT

DOMAIN 是类型，表示完整域名匹配；login.example.com 是条件；DIRECT 表示直连。
REJECT 是拒绝策略。第二行用于演示拦截，实际配置前应确认要阻止的域名范围。
no-resolve 是第四段可选参数，用于相关 IP 规则，不属于策略名称。
MATCH 是兜底规则，没有匹配内容，所以只有两段。

DOMAIN 与 DOMAIN-SUFFIX：精确域名和域名后缀

只调整一个登录入口、接口或下载域名时，优先使用 DOMAIN。需要覆盖主域名及其所有子域名时，使用 DOMAIN-SUFFIX。两者匹配的是主机名，不是浏览器地址栏里的完整 URL。

规则	可匹配的主机名	范围说明
`DOMAIN,api.example.com,DIRECT`	`api.example.com`	不包含其下级子域名
`DOMAIN-SUFFIX,example.com,DIRECT`	`example.com`、`api.example.com`	主域名及下级子域名
`DOMAIN-KEYWORD,example,DIRECT`	主机名中包含 example 的域名	范围更宽，可能影响无关服务

域名规则不填写协议、路径和端口

访问 https://api.example.com:8443/v1/status 时，域名规则的匹配内容仍然是 api.example.com，而不是整段网址。规则里也不写 *.example.com 来表达后缀；使用 DOMAIN-SUFFIX,example.com,DIRECT 即可。

如果只希望调整某个端口，可以另行考虑 DST-PORT。例如 DST-PORT,8443,DIRECT 会匹配目标端口为 8443 的请求，而不限于该域名。需要同时限定域名和端口时，应查阅当前 mihomo 版本的逻辑规则语法，不能把两个条件随意拼成普通三段规则。

域名可见性决定能否命中

通过 HTTP 代理或 SOCKS 传递域名时，内核通常能拿到主机名。TUN 接管的连接则可能先表现为目标 IP，域名能否恢复还与 DNS 模式、映射记录及嗅探配置有关。连接详情里只有 IP 时，新增域名规则未必立即生效；应先确认客户端实际识别到的目标信息。

IP-CIDR 与 no-resolve：地址范围和解析时机

IP-CIDR 用于 IPv4 地址范围，IP-CIDR6 用于 IPv6。CIDR 中斜杠后的数字是前缀长度：192.168.50.0/24 覆盖 192.168.50.0 到 192.168.50.255；192.168.50.10/32 只匹配一个 IPv4 地址。它不是端口范围。

rules:
  - IP-CIDR,192.168.50.10/32,DIRECT,no-resolve
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - MATCH,DIRECT

上面的 IPv6 规则覆盖 fd00::/8，常见于本地分配的 ULA 地址。这里仅展示特定网段，并不是一份完整的内网直连清单。实际应根据局域网、VPN 和远程办公网段调整，避免把需要通过代理或专用隧道访问的地址一概交给直连。

no-resolve 的准确含义

当请求携带域名而尚未获得目标 IP 时，IP 类规则可能触发 DNS 解析，以便判断目标地址是否在网段中。加上 no-resolve 后，该规则不会为了自己的 IP 匹配而主动触发这次解析；请求已有目标 IP 时，仍然可以进行匹配。

它不代表关闭 DNS，也不代表整条连接永远不会解析域名。
前面的规则可能已经触发解析，DNS 映射或入站连接也可能已经提供目标 IP。
若原本希望某个域名通过解析结果命中 IP 网段，加上该参数后，可能会继续落到后面的规则。

因此，局域网地址规则常配合 no-resolve，减少为了网段判断而额外解析外部域名的机会；需要基于解析结果分类的规则，则应先确认是否确实需要这个参数。

匹配顺序：从上往下，首次命中即停止

Clash 规则没有自动按域名长度或网段大小排序的机制。普通规则按配置列表从上往下检查，命中第一条后确定策略。更精确的规则放得太靠后，仍会被前面的宽泛规则遮住。

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,REJECT
  - MATCH,DIRECT

这份列表中，login.example.com 先命中第一条并直连；cdn.example.com 命中第二条并被拒绝；其他未命中的请求进入最后的直连兜底。如果把前两条交换位置，登录域名也会被后缀规则拒绝。

建议按例外、分类、兜底整理

明确例外：单个域名、单个主机地址等特殊处理，放在对应的大范围规则之前。
业务分类：域名后缀、规则集、地区或网络分类，按预期优先级排列。
最终兜底：将 MATCH 放在列表末尾，明确剩余流量的出站策略。

订阅中如果已有一整套规则，新增规则不应简单追加在文件最末尾。位于 MATCH 后面的规则不会获得匹配机会。客户端提供「前置规则」「追加规则」或覆写机制时，应核对最终合并位置，而不是只看编辑框里已经保存了几行。

RULE-SET：将规则内容与出站策略分开维护

域名数量增加后，可以用 mihomo 的 rule-providers 管理规则集，再用 RULE-SET 引用。规则集保存匹配内容，主配置决定命中后走哪个策略。下面使用本地文件，适合先验证结构，再决定是否接入远程更新源。

主配置：声明提供者并放入规则列表

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

rules:
  - RULE-SET,local-work,DIRECT
  - MATCH,DIRECT

local-work 是规则提供者名称，引用时必须保持一致。相对路径以核心的工作目录为基准，不一定是下载文件夹。FlClash 在移动系统中还受应用文件访问权限限制，不能仅把文件放到任意目录，就假定内核可以读取。

规则集文件：只写匹配条件

payload:
  - DOMAIN,portal.example.com
  - DOMAIN-SUFFIX,example.net
  - IP-CIDR,192.168.50.0/24,no-resolve

这是 behavior: classical、format: yaml 对应的文件内容。每项不再填写 DIRECT 或策略组名，出站由主配置中的 RULE-SET,local-work,DIRECT 统一指定。不要把完整的三段普通规则原样复制进该文件。

behavior: domain 用于域名集合，内容格式不同于上面的 classical 示例。
behavior: ipcidr 用于 IP 网段集合，不能混入普通域名规则。
使用 HTTP 类型的提供者时，需要配置可访问的 url，并可用 interval: 86400 表示每 86400 秒更新一次，即 24 小时。

规则集更新与订阅更新是两件事。订阅更新主配置，规则提供者更新对应的规则数据。若规则集未加载，先查看提供者的错误日志和文件格式；反复刷新订阅并不能修复一个格式错误的规则文件。

FlClash 应用与验证：检查有效配置和新连接

自定义规则是否生效，应以核心实际加载的配置和连接记录为准。客户端版本不同，编辑或覆写入口名称可能变化；可先打开 FlClash 的「配置」页，确认当前选中项，再通过该项的操作菜单检查可用的编辑功能。只有明确存在的编辑入口才用于修改，订阅更新持久化方式也应单独确认。

保留原始配置：导出或复制当前配置，记录原来的出站模式及策略组选择。远程订阅更新可能覆盖直接编辑的内容。
每次只加少量规则：先加入一条精确域名规则，放在相关宽泛规则及 MATCH 之前；已有 rules 时合并列表，不重复创建同名顶层键。
应用并查看日志：保存后按客户端提供的方式重新加载配置。出现解析失败、未知策略或文件读取失败时，先处理错误，再测试访问。
使用新连接测试：关闭原有页面或相关连接后重新发起请求。HTTP/2、HTTP/3 和应用连接池可能复用已有连接，旧连接不会因为新增规则自动重新选择出站。
核对连接详情：在「连接」页查看目标主机、目标 IP、命中规则和出站链。不同版本展示字段可能不同，可结合日志核对规则类型与策略名称。

TUN 负责把更多应用流量接入内核，规则负责对进入内核的请求分类。开启 TUN 不会自动提高某条规则的优先级。若连接列表中始终找不到目标请求，应先检查流量接管、应用自身代理设置和路由，再继续修改规则。

常见写错：按现象定位规则问题

现象	常见原因	处理方法
保存后配置无法加载	中文逗号、Tab 缩进、策略名不存在	使用英文标点和空格缩进，对照日志指出的行检查
规则存在但总不命中	放在 MATCH 或更宽泛规则之后	把具体例外移到相关规则前面
主页面直连，资源仍走其他策略	页面调用了其他域名	检查连接记录中的图片、接口及资源主机名
IP 规则对域名请求无效	目标 IP 尚不可用，且配置了 no-resolve	确认解析状态，或使用准确的域名规则
更新订阅后自定义内容消失	编辑内容被远程配置覆盖	使用当前版本支持的持久化覆写方式，或维护独立配置
规则集加载失败	behavior、format 与实际内容不一致	检查 payload 结构、文件路径和提供者日志

规则命中，但访问仍然失败

命中规则只证明分流判断完成，不保证目标服务一定可达。直连仍依赖本地网络和 DNS，代理策略仍依赖所选节点，REJECT 则会主动阻止连接。若连接详情已经显示预期策略，应把排查范围转向该出站链路，而不是继续叠加同样的规则。

维护规则时，保留「为什么需要这条例外」的 YAML 注释，并定期删除失效条目。优先使用准确域名、较小网段和明确的兜底策略。需要补齐客户端操作流程，可查看快速上手；需要核对规则、策略组和 TUN 的概念，可查阅协议详解。