Mihomo 路由分流规则怎么写？

更新于 2026-11-03 · xingtu.buzz

简答：Mihomo 路由分流规则主要写在 rules 中，格式通常是“规则类型,匹配内容,策略名称”。规则按从上到下的顺序匹配，第一条命中的规则决定连接走直连、代理或拒绝；写完后要重点检查策略组名称、规则集格式、YAML 缩进和 MATCH 兜底。

定义：Mihomo 路由分流规则，是根据域名、目标 IP、进程、端口或规则集等条件，把连接交给 DIRECT、代理策略组或其他目标策略处理的配置项。

先看最短写法：rules 到底由什么组成

如果你只想先写出一条规则，可以记住这个结构：规则类型,匹配内容,策略名称。例如 DOMAIN-SUFFIX,example.com,DIRECT 表示匹配 example.com 及其子域名，并交给名为 DIRECT 的策略。本文是第三方使用指南，不代表任何客户端或服务品牌的官方页面。

官方文档说明，Mihomo 会按照 rules 从上到下匹配，排在前面的规则优先级更高；MATCH 可以匹配所有未被前面规则处理的请求。可参考 Mihomo 路由规则文档。

先试这一步：在已有配置中确认存在 mode: rule，再确认 rules 里引用的策略名称确实存在。若策略组叫 Proxy，规则中就不能写成不存在的 PROXY。

DOMAIN、DOMAIN-SUFFIX 和 DOMAIN-KEYWORD 怎么选

三种域名规则的差异，主要在匹配范围。写规则时优先使用范围最小、含义最明确的类型，避免关键词规则过宽导致不相关网站被错误分流。

例如，DOMAIN-SUFFIX,example.com,PROXY 通常可以匹配 example.com、www.example.com 和 mail.example.com，但不会因为包含相似字符就匹配无关域名。需要更复杂条件时，官方规则还支持 IP、端口、进程和逻辑组合规则，具体字段以 当前 Mihomo 规则文档 为准。

策略组、rule-providers 与 RULE-SET 如何联动

rules 只负责“匹配后交给谁”，并不会自动创建策略组。因此，规则第三列必须对应配置中已有的策略名称。一个常见关系是：代理节点先由 proxy-providers 或 proxies 提供，再由 proxy-groups 生成策略组，最后由 rules 引用策略组。

规则集的基本关系可以理解为：rule-providers 定义规则集来源，RULE-SET 在 rules 中调用它。官方文档列出的 provider 类型包括 http、file 和 inline；behavior 包括 domain、ipcidr 和 classical，format 可使用 yaml、text 或 mrs，但具体组合要符合规则集内容格式。可查看 Mihomo rule-providers 配置文档 和 规则集内容格式说明。

下面是演示配置骨架，其中策略组名称、规则集地址和本地路径都是占位内容，不能不经替换就直接使用：

mode: rule
proxy-groups:
- name: PROXY
type: select
proxies:
- 节点名称占位
- DIRECT
rule-providers:
custom_domain:
type: http
url: "https://example.invalid/custom.yaml"
path: ./rules/custom_domain.yaml
interval: 86400
behavior: domain
format: yaml
rules:
- DOMAIN,router.example,DIRECT
- RULE-SET,custom_domain,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY

配置前要完成四项替换：把“节点名称占位”替换为实际节点或策略；把示例域名换成你要处理的域名；把 example.invalid 换成已确认格式的规则集地址；根据规则集实际内容选择 domain、ipcidr 或 classical。rule-providers 的 path 还需要符合当前运行环境允许的路径范围。

一份更稳妥的规则排序模板

规则排序的核心不是越多越好，而是先处理明确例外，再处理范围较大的规则，最后使用兜底项。以下顺序适合用来检查已有配置，具体策略名称需要按你的配置修改。

1. 局域网和本机地址：把路由器、局域网网段和本地服务放在前面，避免被后续代理规则接管。
2. 个人例外：需要固定直连或固定代理的域名放在规则集之前，便于覆盖默认分类。
3. 广告或拒绝规则：如果使用拦截策略，应放在会匹配同一域名的放行规则之前；不确定时先用日志确认。
4. 明确的业务规则：按 DOMAIN、DOMAIN-SUFFIX 或自定义 RULE-SET 处理特定服务。
5. 国内或本地 IP 规则：例如 GEOIP 或 IP-CIDR 规则，但要确认 DNS 和目标 IP 的行为符合预期。
6. 范围较大的规则：关键词、宽泛规则和大型规则集不要过早放置，否则可能抢先命中。
7. MATCH 兜底：放在最后，否则后面的规则不会再有机会匹配。

一个简化排序示例是：局域网直连 → 明确域名例外 → 自定义规则集 → 国内域名或 IP → 其他代理规则 → MATCH。不要把 MATCH 放在中间，也不要把宽泛的 DOMAIN-KEYWORD 放在所有精确域名规则之前。

对于目标 IP 规则，官方文档说明 Mihomo 在进行匹配时可能触发 DNS 解析；添加 no-resolve 可以跳过这次解析。例如：IP-CIDR,192.168.1.0/24,DIRECT,no-resolve。但这并不适合所有场景，若规则需要依赖域名解析得到的目标 IP，就不要机械添加。

规则不生效时，按这个顺序排查

1. 先确认模式：检查是否使用 mode: rule，并确认客户端当前没有处于全局或其他模式。不同客户端界面名称可能不同，应以当前页面显示为准。
2. 再确认策略名：检查 rules 第三列是否与 proxy-groups 中的 name 完全一致，包括大小写、空格和特殊字符。
3. 检查 YAML：重点看缩进、冒号、列表短横线、引号和重复键。不要把 tab 与空格混用。
4. 检查规则集：确认 URL 可访问、文件格式与 behavior 对应、format 与实际文件一致，并确认本地 path 可以被当前运行目录写入。
5. 检查顺序：如果日志显示请求命中了前面的 DOMAIN-KEYWORD、GEOIP 或 RULE-SET，说明后面的规则不会再生效，应将更具体的规则前移。
6. 检查 DNS 与 TUN 边界：在 TUN、Fake-IP 或 DNS 劫持开启时，域名和目标 IP 的观察方式可能不同。不要只根据浏览器能否打开网页判断某条规则是否命中。
7. 复测并回滚：每次只改一组规则，保存原配置；若启动失败，恢复上一份配置，再逐项加入修改。

如果启用了外部控制器，可使用官方 API 查看当前规则信息。Mihomo 文档列出的 /rules 接口可以返回规则索引、类型、匹配内容、目标策略以及部分命中统计；连接信息中也可能包含 rule 和 rulePayload，可用于判断实际请求命中了哪条规则。参考 Mihomo API 文档。

预期结果：配置能够正常加载，目标请求在日志或控制器信息中显示预期的 rule 和策略名称，其他未匹配请求由最后的 MATCH 处理。若只出现网页打不开而没有规则命中信息，应先区分是规则问题、DNS 问题、节点问题还是系统代理/TUN 授权问题。

适用范围、复测与回滚建议

本文适合已经能打开 Mihomo 配置文件、知道当前客户端使用哪个配置，并且能够看到日志或运行状态的读者。不同系统、客户端封装版本和图形界面可能改变菜单名称；本文没有假设所有平台都提供相同的配置校验按钮。

推荐采用“改一项、验一次”的流程：先备份原配置；只新增一条明确的 DOMAIN 规则；重新加载配置；观察日志或规则信息；确认结果后再加入 RULE-SET、GEOIP 或更宽泛的规则。若出现启动失败、策略不存在或规则集加载错误，直接回滚到备份文件，再检查最近一次改动。

不要把示例中的域名、节点名、策略名、规则集地址或文件路径当成通用固定值。它们只是说明结构的占位内容，是否可用必须以当前客户端配置、规则集发布者说明和实际日志为准。

常见问题

Mihomo 的 rules 是从上往下匹配吗？

是。规则按从上到下的顺序匹配，前面的规则优先级更高。一般应把局域网、明确域名例外和精确规则放在前面，把范围较大的规则和 MATCH 兜底放在后面。

DOMAIN 和 DOMAIN-SUFFIX 有什么区别？

DOMAIN 用于匹配完整域名；DOMAIN-SUFFIX 用于匹配一个域名后缀及其子域名。例如只处理 api.example.com 时可用 DOMAIN；要覆盖 example.com 及其子域名时通常使用 DOMAIN-SUFFIX。

为什么写了 RULE-SET 却没有生效？

常见原因包括 rule-providers 的名称与 RULE-SET 引用不一致、behavior 与文件内容不匹配、format 配置错误、规则集地址无法访问、path 无法写入，或前面的规则已经抢先命中。应先看配置加载日志和规则集状态。

MATCH 应该放在哪里？

通常放在 rules 最后一行，作为所有未被前面规则匹配请求的兜底。若 MATCH 提前出现，后面的规则通常就没有机会处理请求。

no-resolve 是不是所有 IP-CIDR 规则都应该加？

不是。no-resolve 用于跳过目标 IP 规则匹配时触发的 DNS 解析，适合不希望为该规则额外解析域名的场景；如果规则判断依赖解析得到的目标 IP，添加后可能改变匹配结果，应结合日志和 DNS 配置验证。

相关阅读

• Mihomo 规则配置语法与顺序
• Mihomo DNS 设置与解析失败排查
• Mihomo Fake-IP 与 redir-host 设置
• Mihomo TUN 模式启动失败排查

参考资料

1. Mihomo docs：Route Rules
2. Mihomo docs：Rule-Providers
3. Mihomo docs：rule-provider 内容格式
4. Mihomo docs：API