要解释「这一条请求为什么走到最终规则」，必须把该请求已有字段按官方路由规则定义从上到下对照，而不是先改 MATCH。文档写明：规则按从上到下的顺序匹配，列表顶部优先级更高；MATCH 无需条件、匹配所有请求。因此走到 MATCH 表示：它之前每一条对该请求都不成立，或某条本可命中的代理规则因节点没有 udp 支持被跳过。
适用条件：先锁死这一条请求的字段
适用条件：已经能指出具体的目标主机或 IP、目的端口、tcp 或 udp，并且实际出站等于 MATCH。判断依据：不能用「很多站点都不走代理」这种集合说法代替单条对照，否则无法把现象对应到 DOMAIN 与 GEOIP 等不同语义。
具体操作：写下完整域名（若有）、目标 IP（若已有解析结果）、目的端口、NETWORK 为 tcp 还是 udp、入站端口与入站类型、来源 IP 与来源端口、进程完整路径或进程名（Android 上可为包名）、Linux UID（若适用）。某一类字段缺失时，对应类型的规则在对照表里应记为「无法证明命中」。
按从上到下顺序做纸面命中判定
从 rules 第一项开始，只回答「按文档这条是否应匹配该请求」。DOMAIN 要求完整域名相等。DOMAIN-SUFFIX 比较后缀，官方例子中 google.com 不匹配 content-google.com。DOMAIN-KEYWORD、DOMAIN-WILDCARD（仅 * 与 ?，且不同于配置其他处的 Clash 格式通配符）、DOMAIN-REGEX、GEOSITE 分别按其定义衡量。IP-CIDR、IP-CIDR6（别名）、IP-SUFFIX、IP-ASN、GEOIP 比较目标 IP；SRC-*、IN-*、PROCESS-*、UID、NETWORK、DSCP、DST-PORT、SRC-PORT 比较来源、入站、进程或端口。RULE-SET 的名称必须能对上已配置的规则集合。AND 要求全部 payload 成立，OR 要求其一成立，NOT 为取反；SUB-RULE 转入子规则。逻辑规则与 SUB-RULE 需要注意括号，括号结构不对就把该行记为无效。
判断依据：若第一处按文档应命中的规则指向非 MATCH 出站，实际却走到 MATCH，则应怀疑列表未按文件加载，或命中后因 udp 被继续匹配；若直到 MATCH 之前全部为「不应命中」，则行为与文档一致，原因是条件没有覆盖这条请求。
把 DNS、no-resolve 与 UDP 跳过写入原因
域名开始匹配关于目标 IP 的规则时，mihomo 将触发 DNS 解析来检查目标 IP；可选择 no-resolve 跳过解析。如在更早的匹配中已触发解析，则依旧会匹配到带 no-resolve 的目标 IP 类规则。判断依据：该请求若还没有目标 IP，则未解析前的 GEOIP、IP-CIDR（尤其带 no-resolve 且前方没有解析）在纸面上不应记为命中。附加参数 src 将目标 IP 匹配转为来源 IP 匹配，对照时必须用来源地址，不能继续看目的地址。
若该请求是 udp，且你设想命中的那条规则指向没有 udp 支持的节点（例如 ss 节点没写 udp: true），则会继续向下匹配。判断依据：即使纸面上域名规则已经成立，仍须问出站是否支持 udp；不支持就不能把 MATCH 当成误匹配，而应把原因写成「命中后继续匹配，后续规则仍不成立」。MATCH 本身没有可调条件。
失败时下一步：若纸面显示 DOMAIN-SUFFIX 或 GEOSITE 应命中、实际仍到 MATCH，则检查规则集合是否已配置、Geosite 是否包含该域名、通配符是否误用了其他位置的 Clash 格式。若纸面也显示全部不命中，应补写对该请求成立的域名或 IP 规则，而不是调整 MATCH。