Clash 路由规则在配置里是按行排列的列表，每一行由规则类型、匹配内容和策略名组成。官方语法没有单独的备注或目的字段，复杂规则若要让后来者读懂「为什么存在这一行」，只能把目的写进类型选择、payload、第三段策略名、规则集合名、子规则名、附加参数，以及从上到下的排列顺序。下面只说明如何用规则结构本身保留可读的目的说明。
适用条件：目的必须写进结构的场景
规则将按照从上到下的顺序匹配，列表顶部的规则优先级高于其底下的规则。位置本身就是优先级说明：越靠上，越表示要优先处理的意图。当同一份列表混用域名、IP、端口、入站、进程、逻辑组合、规则集合和兜底项时，如果策略名含糊或顺序随意，目的就无法从文件中恢复。
选用类型时即在声明目的。DOMAIN 匹配完整域名；DOMAIN-SUFFIX 匹配后缀，例如 google.com 可匹配 www.google.com、mail.google.com 和 google.com，但不匹配 content-google.com；DOMAIN-KEYWORD、DOMAIN-WILDCARD、DOMAIN-REGEX 分别对应关键字、仅支持 * 与 ? 的通配符、正则。GEOSITE 匹配 Geosite 内域名。IP-CIDR 与 IP-CIDR6 效果一样，后者只是别名；此外还有 IP-SUFFIX、IP-ASN、GEOIP 以及 SRC-GEOIP、SRC-IP-CIDR 等来源侧匹配。MATCH 匹配所有请求且无需条件，只适合放在列表末尾表达兜底。
判断依据：不借助外部口述，只看类型、payload、第三段名称和行序，能否回答「这条拦什么、命中后去哪、为何排在此」。不能回答，就说明目的还没有写进结构。
用策略名、集合名和附加参数承担说明
第三段必须是策略或策略组名称，例如 REJECT、DIRECT 或自定义组名。把组名写成能概括出口意图的词，阅读者就不必猜测命中后的去向。RULE-SET 写作 RULE-SET,providername,proxy，其中 providername 应能看出集合主题，避免无意义编号。
针对目标 IP 的规则可加 no-resolve：域名开始匹配目标 IP 规则时，可跳过为此触发的 DNS 解析；若更早的匹配已经触发过解析，则仍会匹配带该选项的目标 IP 规则。src 将目标 IP 匹配转为来源 IP 匹配。这两项仅支持关于目标 IP 的规则。写上它们，等于声明「是否为了匹配去解析、看的是来源还是目的」。写在不支持的类型上，既不能成为有效说明，也会误导后续排错。
进程路径与进程名的通配符类型仅支持 * 和 ?，且与配置文件其他地方的 Clash 格式通配符不相同。选择 PROCESS-PATH 还是 PROCESS-PATH-WILDCARD、PROCESS-NAME 还是 PROCESS-NAME-REGEX，本身就是在声明匹配松紧，应视为目的的一部分来选类型。
逻辑规则、子规则的拆分和失败时下一步
AND、OR、NOT 的形式为 LOGIC_TYPE,((payload1),(payload2)),Proxy，payload 为规则类型和其他 payload，例如 DOMAIN,baidu.com。必须注意括号。可读写法是：每个内层括号只放一条完整条件，外层 AND 表示必须同时满足，OR 表示任一满足，NOT 表示取反。不要把多层逻辑挤进一行导致括号无法配对。
SUB-RULE 写作 SUB-RULE,(NETWORK,tcp),sub-rule，同样要注意括号。把「TCP 走另一套细则」这类目的放到具名子规则中，主列表只保留入口条件，阅读者可以沿子规则名称继续读，而不必在主列表堆叠全部细节。
失败时下一步：配置无法加载时，先核对逻辑规则与 SUB-RULE 的括号是否成对，以及 RULE-SET 的集合名是否已经配置。行为与预想目的不符时，严格按从上到下的顺序检查是否被更靠前的规则截走，MATCH 是否出现过早。目标 IP 规则要核对 no-resolve 与 src 是否用在支持的类型上。请求为 udp 而代理节点没有 udp 支持时，会继续向下匹配，应检查承担该目的的策略是否因此被跳过。不要插入引擎无法识别的说明字段，应调整类型、payload、名称和顺序。