要确认 Clash（mihomo）是否接受某种规则格式，应用尽量短的 rules 列表对照本页示例，而不是一次导入完整仓库。格式是否成立，看类型名、载荷形态、出站位置、括号和附加参数能否与文档逐段对齐。本页没有规定菜单或日志字段，因此检查依据是配置文本本身是否与示例同构。
适用条件
适用于新写规则、把外部行粘贴进 rules、或准备增加 RULE-SET 引用之前。最小列表应只含待验类型加一条 MATCH（MATCH 匹配所有请求、无需条件，可托住未命中项）。一次只验一种类型，避免多条错误互相掩盖。不适用于用这条最小列表去判断节点是否支持 udp：文档写明请求为 udp 且节点没有 udp 支持时会继续向下匹配，那是运行时优先级，不是格式检查。
用文档示例搭最小列表
先写两条，形态必须能拆成「类型,载荷,出站」：
- 复制总表中已有示例，如
DOMAIN,ad.com,REJECT，下一行MATCH,auto。 - 若验 IP 类，改用
IP-CIDR,127.0.0.0/8,DIRECT,no-resolve这类目标 IP 示例；IP-CIDR6与IP-CIDR效果相同，只作为别名检查。 - 若验集合引用，只写
RULE-SET,providername,proxy这种三段，并确认需配置rule-providers，不要在第二段粘贴域名列表。 - 若验逻辑规则，使用
AND,((DOMAIN,baidu.com),(NETWORK,UDP)),DIRECT或文档中的OR/NOT形式，内层 payload 必须带类型；SUB-RULE,(NETWORK,tcp),sub-rule用来检查子规则括号。
判断「被接受」：类型标题能对上；载荷属于该节匹配对象；出站在第三段；no-resolve/src 仅出现在目标 IP 规则末尾；通配类仅含 * 与 ?，且未套用配置其他处的 Clash 格式通配符；NETWORK 仅为 tcp 或 udp。
按类型逐条替换载荷
最小列表能对齐后再只改中间载荷，观察是否仍落在该类型说明内：
- 域名类分别试完整域名、后缀、关键字、通配、正则、Geosite 名，不要把后缀示例写进
DOMAIN。 - 地址类分别试 CIDR、IP 后缀、ASN、国家代码；来源条件改用
SRC-*，不要在目标类型上写来源语义。 - 端口与入站类试端口或端口范围、
IN-TYPE、IN-USER（/分隔多用户名）、IN-NAME。 - 进程类区分
PROCESS-PATH与PROCESS-NAME及其 WILDCARD/REGEX；Android 包名只放在进程名类说明里检查。 - 每改一次，保持列表仍短，
MATCH仍在最后，顺序仍从上到下。
不要在检查用列表里混入未记载的第四段字段。DSCP 仅限 tproxy udp 入站，不满足该条件时不要用它当通用样本。
不被接受时下一步
先数逗号：普通规则至少类型、载荷、出站三段；MATCH 只有类型与出站；逻辑规则检查双层括号是否与 ((payload1),(payload2)) 一致。类型名不在列表中则改回文档标题，不要用近义词。载荷跨类时，回到该类型示例整段替换，而不是插入另一个类型的写法。RULE-SET 不被接受时，只核对名称是否已配置 rule-providers 以及是否多写了域名。附加参数出现在域名或进程行上则删除。通配与正则用错类型时，改到 -WILDCARD 或 -REGEX 对应类型。仍无法与任一示例同构，就丢弃该行，从总表再复制一条已知形态重新开始，不要在同一行叠加多种载荷。