Mihomo规则优先级与策略管理指南

规则描述条件，策略决定去向

在规则模式下，一条规则一般同时描述匹配条件和处理去向。条件可以针对域名或其他连接属性，去向可能是内置动作或配置中定义的策略。先把这两部分分开阅读，才能知道是没有匹配到条件，还是匹配之后使用了与预期不同的处理方式。

策略名称是引用关系，不是性能证明。把一个分组选项命名为快速或稳定，并不会自动改善网络质量。需要核对该名称实际指向的内容，以及前端当前选中的选项；不能仅凭界面标签推断某次请求使用了哪个出口。

从上到下理解优先级

上游文档说明路由规则按列表顺序匹配，位于前面的条件具有更高的检查顺序。因此，具体例外通常应位于宽泛条件之前，兜底规则放在末尾。若过早出现覆盖范围很大的条件，后面更细的规则可能无法产生预期效果。

这里的顺序是一种阅读起点。不同连接属性、协议能力以及特定规则参数可能影响实际处理，最终仍应结合当前版本文档和连接日志判断。不要为了修复单个目标就反复把所有规则上下移动，应先明确目标请求应满足哪个条件。

用无凭据片段练习阅读

下面片段只演示具体域名条件与末尾兜底的位置，两条规则均使用直连动作。它不含可用代理、账号或完整网络服务设置，也不应被描述成推荐给所有用户的成品配置。复制到现有文件前，要先检查是否已经存在同名顶层字段。

# 规则教学片段：全部直连
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

区分语法错误和引用错误

语法错误可能来自缩进、列表符号或标点；引用错误则可能表现为策略名称不存在、大小写不一致或集合没有正确加载。两类问题需要分别检查。文件能解析，只说明结构可读，不代表所有规则都有有效的目标和依赖。

规则集合依赖外部资源时，还应确认资源格式、路径与更新结果。远端内容变化可能影响匹配范围，修改前保留可回退副本。不要把下载失败当成规则顺序问题，也不要将前端生成配置与原始编辑文件混在一起比较。

通过一次请求验证修改

选择一个明确目标，记录修改前的连接行为，再只调整与该目标相关的一条规则。发起新请求并查看可用日志中的匹配信息。已有连接、应用缓存和 DNS 缓存可能影响观察，应先明确测试的是新请求还是仍在复用旧连接。

若结果仍不符合预期，回到入口检查：请求有没有进入内核，当前模式是不是规则模式，实际加载的是哪份配置。只有这些前提明确，分析顺序才有意义。需要补充格式知识时，阅读YAML 基础教程，再按常见错误逐项检查。

阅读后的检查清单

• 具体规则位于宽泛规则和兜底规则之前。
• 策略与集合名称的引用关系明确。
• 已使用新请求和日志验证修改结果。