访问验证

Mihomo 规则组不生效怎么办？按 5 层快速排查

更新于 2026-10-28 · liuheng2024.store

简答：Mihomo 规则组不生效时，先不要急着重写配置：确认当前是 rule 模式、目标流量确实进入 Mihomo，再在连接详情中查看实际命中的规则和最终策略组。之后按规则顺序、组名引用、规则集状态、旧连接复用依次排查，通常可以定位到具体层级。

定义：Mihomo 规则组不生效，通常是指规则没有命中、命中后引用的策略组不可用，或目标流量根本没有进入 Mihomo 内核。

先做 5 分钟判断：到底是哪一层出了问题

本文是第三方使用指南，按 2026-10-28 检索到的 Mihomo 文档整理；不同客户端的菜单名称可能不同，最终以当前客户端和内核版本为准。Mihomo 的规则按配置中的顺序从上到下匹配，越靠前优先级越高；MATCH 会匹配所有请求，因此通常应放在规则末尾，而不是放在自定义前置规则的开头。详情可查看Mihomo 路由规则文档。

现象优先检查判断方法
所有请求都走同一个组运行模式、规则顺序、提前出现的 MATCH确认不是 global 或 direct，并查看连接的 rule 与 rulePayload
规则显示已命中，但组内节点不对proxy-groups 的 name、type、成员和当前选择检查规则末尾的目标名称是否与组名完全一致
规则集没有效果rule-providers 下载、behavior、format 和引用名称查看规则提供者状态及本地缓存是否更新
改完配置仍走旧策略配置是否重载、旧连接是否复用、DNS 或假 IP 缓存关闭旧连接后重新访问，并在必要时刷新对应缓存
浏览器有效、某个应用无效系统代理、TUN、应用自带代理或 VPN 冲突确认该应用的流量是否真的进入 Mihomo

先试这一步：将客户端临时切到 rule 模式，打开连接详情，访问一个明确的测试域名，记录 rule、rulePayload 和 chains。如果连接列表里没有这条请求，先排查流量接入，不要继续修改规则。

第一层：确认 Mihomo 正在按规则工作

  1. 确认运行模式。配置中的 mode 应为 rule。Mihomo 文档列出的模式包括 rule、global 和 direct，默认模式为 rule，但客户端界面可能覆盖配置文件设置。可参考Mihomo 通用配置文档。
  2. 确认流量入口。普通系统代理只能接收遵循系统代理设置的应用；TUN、应用自带代理、其他 VPN 或网络过滤工具可能改变流量路径。假如浏览器请求能在 Mihomo 的连接列表看到，而某个应用完全没有记录，问题更可能在系统代理、TUN 路由或应用自身代理设置，而不是规则内容。
  3. 检查实际生效配置。不要只看订阅原文或本地模板。客户端可能通过订阅覆写、配置合并或启动参数生成另一份运行配置。若启用了外部控制接口，可以通过 /configs 查看当前运行配置，通过 /version 查看内核版本；相关接口说明见Mihomo API 文档。
  4. 用新请求验证。修改模式或配置后，先重载，再关闭旧连接，最后重新打开目标页面。已有连接可能继续沿用原来的连接链路，不能用“旧页面还没变化”直接证明新规则无效。

第二层：检查规则顺序、匹配范围和兜底规则

Mihomo 规则不是同时竞争，而是按顺序逐条判断。具体规则应放在宽泛规则前面，MATCH 应作为兜底放在最后。下面是一个最小诊断片段，只用于核对规则写法和顺序，不是完整可运行配置：

  • DOMAIN,example.com,办公组：匹配完整域名。
  • DOMAIN-SUFFIX,example.com,办公组：匹配该域名及其子域名，但不匹配仅包含相同文字的其他域名。
  • DOMAIN-KEYWORD,example,办公组：按域名关键词匹配，范围更宽，误命中风险也更高。
  • RULE-SET,work_domains,办公组：调用名为 work_domains 的规则提供者。
  • MATCH,默认组：匹配所有尚未被前面规则处理的请求，应放在末尾。

例如，若前面已经有一个宽泛的 DOMAIN-KEYWORD,example，后面的精确 DOMAIN,api.example.com 就可能没有机会命中。排查时可以暂时只保留一条明确的 DOMAIN 规则和最后一条 MATCH，然后重新发起请求。

注意：如果你使用订阅覆写的前置规则，不要在前置规则模板末尾添加 MATCH,你的原代理策略组。这样会让兜底规则排在订阅原有规则之前，导致后面的分流规则失去机会。前置规则应只放需要提前匹配的具体规则，兜底规则应保留在最终规则列表末尾。

第三层：核对策略组名称和组内成员

规则右侧写的是策略组名称，不是随意的显示文字。例如规则写成 DOMAIN,example.com,办公组，就必须在 proxy-groups 中存在名称完全相同的 办公组。空格、大小写、标点和全角半角差异都可能导致引用失败。

  1. 在最终配置中搜索规则目标名称。
  2. 在 proxy-groups 中搜索同名 name。
  3. 检查该组的 type 是否存在且写法正确。
  4. 检查 proxies 或 use 是否真的提供成员。
  5. 打开策略组详情，确认组内不是空列表，也不是所有成员都不可用。

Mihomo 官方文档说明，策略组的 name 是必填项，proxies 可引用出站代理或其他策略组，use 可引用代理集合；这些字段不能混为一谈。可对照Mihomo 策略组配置文档。

还要区分策略组类型：select 需要检查当前手动选择；url-test 会依据健康检查结果选择成员；fallback 会在当前节点超时时按顺序选择可用节点。节点延迟测试通过，只能说明测试地址在当时可访问，不能单独证明目标业务网站、DNS、TLS 和完整分流都正常。

第四层：排查 RULE-SET 规则集没有加载

如果普通 DOMAIN 规则能命中，而 RULE-SET 没有效果，优先检查 rule-providers。官方文档要求 HTTP 类型提供 url，规则提供者名称必须唯一；behavior 要与规则内容类型匹配，例如 domain、ipcidr 或 classical，格式还可能是 yaml、text 或 mrs。具体字段以Mihomo rule-provider 文档为准。

  1. 确认 rules 中引用的提供者名称与 rule-providers 下的键完全一致。
  2. 确认 URL 可被当前网络访问，且没有被 DNS、代理或证书错误阻断。
  3. 确认 behavior 与远端文件内容匹配，不能把纯域名列表当成 classical 规则。
  4. 在面板或 API 的规则提供者页面查看更新时间、状态和规则数量。
  5. 更新提供者后重新加载配置，再关闭旧连接重新访问。

如果日志出现 provider 下载失败、解析失败、找不到提供者或规则为空，不要先修改策略组；先恢复规则集的下载和解析。若规则集来源不稳定，可以先用一条明确的本地 DOMAIN 规则验证策略组链路，再单独处理 provider。

第五层：用日志和连接详情确认最终结果

只看“规则配置页面”不够，真正有用的是一次新连接的实际记录。Mihomo API 的连接对象包含目标元数据、代理链、匹配到的 rule 和 rulePayload；日志接口也支持获取实时日志并设置 debug 级别。可参考官方 API 接口说明。

  • 没有连接记录：优先排查系统代理、TUN、应用自带代理、VPN 冲突或应用绕过设置。
  • 有连接记录但 rule 不符合预期：检查规则顺序、域名实际解析结果和匹配类型。
  • rule 正确但 rulePayload 指向错误组：检查规则右侧目标名称和订阅覆写。
  • 规则和组都正确但连接失败：检查组内节点、协议、DNS、TLS 和目标站点，不要把规则命中等同于连接成功。
  • 修改后仍显示旧结果：关闭该连接，必要时使用 API 的连接删除接口清理旧连接；涉及 DNS 或 fake IP 时，再按实际配置刷新对应缓存。

完成验证后，把日志级别恢复为原来的设置，并撤销临时关闭 TUN、停用 DNS 或切换直连等高风险测试动作，避免留下与日常使用不一致的状态。

一份可照做的恢复顺序

  1. 备份当前配置或导出订阅覆写内容。
  2. 确认客户端当前使用的是 Mihomo 内核，并记录内核版本。
  3. 切换到 rule 模式，确认目标请求能出现在连接列表。
  4. 用一条明确的 DOMAIN 规则测试，不要一开始就调复杂规则集。
  5. 检查规则目标名称与策略组 name 是否完全一致。
  6. 确认策略组不是空组，手动选择组先使用一个可识别的成员。
  7. 将宽泛规则和 MATCH 移到具体规则之后。
  8. 单独检查 rule-provider 的下载、缓存、behavior 和 format。
  9. 重载配置，关闭旧连接，重新访问测试域名。
  10. 确认恢复正常后，再逐项恢复自动选择、TUN、DNS 优化和复杂规则集。

这套顺序的目的，是把“流量没进内核”“规则没命中”“组名不可用”“规则集没加载”“旧连接未更新”分开验证，避免一次改动多个变量后无法判断到底是哪一步起作用。

常见问题

Mihomo 规则组不生效，最常见的原因是什么？

最常见的排查方向有五类：当前不是 rule 模式、目标流量没有进入 Mihomo、前面的宽泛规则或 MATCH 抢先命中、规则目标名称与策略组 name 不一致、rule-provider 没有成功加载。建议按流量接入、规则匹配、策略组、规则集、旧连接的顺序检查。

规则已经命中，为什么实际节点还是不对？

规则命中只说明某条规则被选中，还要检查该规则右侧的策略组名称、组内成员和当前选择。select 组要看手动选择，url-test 或 fallback 组还会根据健康检查和可用性改变最终成员。

前置规则里可以放 MATCH 吗？

通常不应放。Mihomo 按从上到下的顺序匹配，前置规则中的 MATCH 会提前匹配所有请求，可能让订阅原有分流规则全部失效。前置规则只放需要提前处理的具体规则，兜底 MATCH 保留在最终规则列表末尾。

RULE-SET 和普通 DOMAIN 规则有什么区别？

DOMAIN 是直接写在 rules 中的单条匹配规则；RULE-SET 会引用 rule-provider 提供的一组规则。RULE-SET 额外依赖提供者名称、下载状态、缓存文件、behavior 和 format，任何一项不匹配都可能导致规则集看似配置了但没有效果。

改完规则后需要重启客户端吗？

不一定。优先使用客户端提供的重载配置功能；如果客户端没有可靠的重载入口，再按其文档重启。无论采用哪种方式，都应关闭旧连接并重新发起请求，因为旧连接可能仍沿用修改前的代理链路。

相关阅读

参考资料

  1. Mihomo 官方文档：路由规则
  2. Mihomo 官方文档：策略组配置
  3. Mihomo 官方文档：规则提供者
  4. Mihomo 官方文档：通用配置与运行模式
  5. Mihomo 官方文档：API 接口