你给一个网站新增了规则，网页表现却没有变化。此时应暂停继续加规则，先追踪一次具体请求。分流是否生效，取决于请求有没有进入内核、实际匹配对象是什么、哪条规则先命中，以及代理组最后选择了什么。配置文本只是意图，运行记录才显示执行结果。
选一条能够重复的请求
关闭无关页面或停止多余操作，只访问一个明确目标，再查看相应连接记录。页面可能调用多个域名，地址栏里的域名未必就是失败资源的域名。如果记录中没有对应连接，先检查应用代理设置与接管方式。请求没有经过内核时，往配置末尾补再多规则也不会让它自动进入。
确认编辑对象就是活动配置
检查当前配置名称、加载状态与最近一次重载结果。有些客户端保留多个副本，也可能通过覆写生成运行配置；你改动的文件未必直接被内核使用。若修改引起解析错误，程序还可能继续使用此前有效状态。先确认新配置实际被接受，再讨论规则是否写对，否则很容易在错误副本上反复操作。
读懂顺序比增加数量更重要
在 mihomo 的规则机制中，较靠前的匹配项具有优先级。完整域名、域名后缀和关键词条件覆盖范围不同，不能因为文字相似就视为同一条件。检查目标请求是否已经被前面的宽泛规则处理，再考虑调整位置。移动规则前应记录原顺序，避免修好一个网站却影响更大范围。
继续追到代理组的最终选择
命中某个代理组，并不等于固定使用你心里想的那个节点。代理组可能还引用其他组，或根据当前选择提供出口。假设规则正确指向“资料阅读组”，但该组当前选择了直连，结果仍可能与预期不同。要同时核对命中项和最终出口，不能只在日志里看到组名就结束检查。
以最小修改验证假设
保留一份可恢复配置，只调整已经定位的条件、顺序或组选择，再对同一个目标重新发起请求。避免把所有相关域名都无差别加入一条广泛规则，也不要同时修改 DNS 和接管方式。验证时还应检查一个原本正常的邻近任务，确认修正没有把局域网或其他业务一起改道。
让规则长期可维护
如果订阅更新会覆盖手工修改，应使用客户端支持的本地扩展或覆写机制，并确认合并后的实际结果。为自定义规则写一句用途说明，保留必要范围即可。分享排查截图时遮住订阅凭据和私人访问记录。最后应能说清这条规则为什么存在、匹配什么、交给谁，以及更新后如何确认它仍然生效。