官方本页没有单独给出「记录开关」或界面名称，但把两件关键事实写进了匹配过程：实际目标 IP 在什么条件下出现，以及哪一条规则会被视为命中。要把这两件事记录清楚，只能沿着类型字段、解析时机和从上到下的优先级来做，而不是补充未在文档中出现的操作项。
按规则类型记录当时真正用到的对象
每一条规则的类型已经规定要记录什么。DOMAIN 记录完整域名；DOMAIN-SUFFIX、DOMAIN-KEYWORD、DOMAIN-WILDCARD、DOMAIN-REGEX 记录域名的不同比较方式；GEOSITE 记录域名是否落在 Geosite 集合。它们命中时，决策数据是域名，文档没有要求此时必须存在目标 IP。把这类命中写成「某个国家的 IP」，属于记录对象错误。
目标 IP 类规则才需要记录 IP 本身：IP-CIDR、IP-CIDR6、IP-SUFFIX 记录地址是否落在范围；IP-ASN 记录 IP 所属 ASN；GEOIP 记录 IP 所属国家代码。来源侧对应 SRC-IP-CIDR、SRC-IP-SUFFIX、SRC-IP-ASN、SRC-GEOIP。附加参数 src 把目标 IP 匹配转为来源 IP 匹配，记录时必须标明用的是哪一侧，否则「实际 IP」会对错主体。
端口、入站、进程、UID、NETWORK、DSCP 命中时，记录的是这些条件而不是目标 IP。IN-TYPE 可写 SOCKS/HTTP 这种用斜线分隔的形态；IN-USER 也支持用斜线分隔多个用户名。适用条件：只有当你的问题是「为什么走了某出站」时，才需要把上述非 IP 条件一并记下，避免只盯着地理或地址段。DSCP 仅限 tproxy udp 入站，记录前要确认入站形态是否满足这一限制。
记录目标 IP 是在哪一步产生的
文档说明：域名开始匹配关于目标 IP 的规则时，mihomo 将触发 DNS 解析来检查域名的目标 IP 是否匹配规则。因此对域名请求，应记录两件事：解析是否被触发，以及触发发生在列表中的哪一条目标 IP 规则。字面 IP 请求则直接记录该地址，不依赖这次解析。没有记录「IP 从何而来」，就无法解释后面的 GEOIP 或 IP-CIDR 为何命中或未命中。
no-resolve 仅支持关于目标 IP 的规则，用于跳过 DNS 解析。记录时的判断依据如下。若走到某条 GEOIP 或 IP-CIDR 时历史上从未解析，且该条带 no-resolve，则不应期待用域名对应的 IP 去命中它。若更早的匹配已经触发解析，则即便后续规则写了 no-resolve，文档规定依旧会匹配到这些目标 IP 类规则，此时应记录「IP 来自前置解析，而不是本条自己发起」。这是区分「没有 IP」和「有 IP 但本条没发起解析」的关键。
具体操作可以把一次请求写成固定字段：请求域名或字面 IP、传输是 TCP 还是 UDP、目标端口、入站端口与类型、从上到下第一条命中的规则类型与 payload、该规则是否依赖目标 IP、解析是否已发生。文档指出请求为 UDP 而节点没有 UDP 支持（例如 ss 节点没写 udp: true）时会继续向下匹配，因此还要记录最终出站是否因为 UDP 能力不足而跳过了原本看起来会命中的代理。
用优先级把命中规则记成唯一结果
规则从上到下匹配，顶部优先。一次请求的命中规则只有一条有效决策：第一条完全满足条件的规则，其出站即结果。AND、OR、NOT 要把括号内每条 payload 的真假记全，文档强调注意括号。SUB-RULE 要记下是否进入子规则。RULE-SET 记下引用的集合名，前提是已配置 rule-providers。MATCH 无需条件，若记录到它，含义是此前全部失败，而不是又产生了一个新的目标 IP。
失败时下一步按记录缺口补齐。若没有目标 IP 却期望 GEOIP 命中，检查解析是否被 no-resolve 跳过、上方是否根本没走到 IP 规则。若有 IP 但未命中国家代码或 CIDR，检查匹配的是目标还是来源，以及上方域名规则是否已经出站。若逻辑规则未按设想成立，回到括号和 NETWORK 组合。进程路径、名称的通配符仅支持 * 与 ?，文档注明与配置文件其他地方的 Clash 格式通配符不相同；DOMAIN-WILDCARD 同样仅支持 * 和 ?。记录匹配失败时要核对所用的是哪一种通配规则。把类型、对象、解析、顺序四项补全后，实际目标 IP 与命中规则就可以在官方语义下对齐。