适用条件与放置原则
在 Clash（mihomo）的 rules 列表中新增一行时，位置本身就会决定它能不能生效。官方规定：规则按从上到下的顺序匹配，列表顶部的规则优先级高于其底下的规则。适用条件是：已有一份按顺序排列的 rules，准备插入 DOMAIN、DOMAIN-SUFFIX、IP-CIDR、RULE-SET、逻辑规则等任意一条，并且能说明这条新规则相对现有规则应当“抢先”还是“仅在前面未命中时才用”。
MATCH 匹配所有请求、无需条件。新规则若写在 MATCH 之下，普通请求到不了这一行。UDP 有单独说明：若请求为 udp，而该行所用代理节点没有 udp 支持（例如 ss 节点没写 udp: true），则会继续向下匹配。放置时要把这一例外算进去，不能只按“第一行命中就结束”来选位置。
按意图把新规则插入列表
第一步，标出列表里已经能覆盖同一类请求的行，包括完整域名、后缀、关键字、通配符、正则、GEOSITE、GEOIP、RULE-SET 以及 AND/OR/NOT。新规则与其中任何一行在集合上相交，就必须先决定谁优先。
第二步，若新规则应当覆盖旧规则（更具体、或要改出站），插在相交的旧规则之上。例如已有 DOMAIN-SUFFIX,google.com 与 DOMAIN-KEYWORD,google，再新增 DOMAIN,ad.com 或某一主机的精确 DOMAIN，应放在更宽的关键字、后缀、GEOSITE 之前，否则请求会先被宽规则收走。判断依据：同一请求若能同时满足上下两行，实际生效的是靠上的那一行。
第三步，若新规则只是补漏，插在更具体的域名、进程、端口规则之后，但仍须在 MATCH 之前。MATCH 应保持在列表最底部，作为无条件兜底。把新规则插到 MATCH 后面，等于未加入路由。
第四步，处理逻辑规则、子规则与 IP 规则的位置。AND、OR、NOT、SUB-RULE 在列表中各占一行，官方要求注意括号；NOT,((DOMAIN,baidu.com)),PROXY 这类范围很宽，放在顶部会截走大量请求，通常只应放在明确需要取反的区段，且仍高于 MATCH。RULE-SET 同样只占列表中的一个位置，集合整体的优先级就是这一行的位置。目标 IP 类规则可加 no-resolve：匹配这类规则时会触发 DNS 解析，选用 no-resolve 可跳过；但若更早的匹配已经触发过 DNS，带 no-resolve 的目标 IP 规则依旧能匹配。因此“先解析、后 no-resolve”与“全程不解析”取决于 IP 规则之间的上下关系，新增 IP-CIDR / GEOIP 时要看它与已有目标 IP 规则的相对顺序。
第五步，涉及 NETWORK,udp 或可能命中无 UDP 节点的出站时，不要假设命中即停止。官方写明：udp 请求遇到未开启 udp 的节点会继续向下。若新规则要承接这类“被上层节点拒绝的 udp”，必须放在那条出站规则之下；若新规则自己的出站也无 udp，它同样留不住该请求。
位置是否正确的判断依据与失败时下一步
判断依据：新规则位于 MATCH 之上；与之相交且应当让路的宽规则在其下方；与之相交且应当保留的旧规则仍在其上方；UDP 续配路径上的出站是否支持 udp 已核对。四条同时成立，位置才可接受。
若新规则从未命中，下一步先查它是否写在 MATCH、宽泛 NOT 或大范围 RULE-SET 之下，上移到相交宽规则之前，而不是在底部重复同一条。若新规则抢走了本应走旧规则的请求，下一步把它下移到那条更具体规则之后。若只有 UDP 异常，下一步对照该行出站是否具备 udp 支持，需要续配时保持“无 udp 的节点在上、承接规则在下”。目标 IP 规则行为与预期不符时，下一步检查上方是否已触发 DNS，以及新增行是否误加或漏加 no-resolve。不要用调换 MATCH 与业务规则的方式“试位置”，那会让其后全部规则失效。