Mihomo 规则不生效怎么排查

更新于 2026-10-26 · xn--mesv7f5toqlp.shop

简答：Mihomo 规则不生效，先确认运行模式是 rule，再检查规则是否加载、顺序是否正确、策略组名称是否存在，最后区分 DNS 或 TUN 造成的流量未进入内核。排查后可明确是未加载、未命中、策略组选错，还是入口问题。

定义：Mihomo 规则不生效，是指请求没有按预期匹配 DOMAIN、RULE-SET、IP-CIDR 等规则，或规则已经命中但最终策略组、DNS 解析或流量接管结果不符合预期。

先用五层顺序判断：规则到底卡在哪一层

本文是第三方使用指南，重点放在 Mihomo 内核本身的配置和诊断，不代表任何客户端或服务的官方页面。最快的做法不是立刻重写规则，而是按下面顺序确认：流量有没有进入 Mihomo、当前是不是 rule 模式、规则或规则集有没有加载、请求有没有命中、命中后策略组是否正确。

五层排查速查表

现象	优先检查	判断结果
所有请求都像没有规则	运行模式、TUN、系统代理或代理端口	可能是 global、direct，或流量没有进入 Mihomo
只有某个规则集不生效	provider 名称、下载状态、behavior、format	规则集可能为空、格式不匹配或仍使用旧文件
部分域名走错策略	规则从上到下的顺序、宽泛规则、MATCH	前面的规则已经提前匹配
规则显示命中但出口不对	规则目标与 proxy-groups 名称	命中后指向了错误策略组，或策略组当前选择不对
域名规则正常、IP 规则异常	DNS、Fake-IP、no-resolve、TUN	可能是解析路径或流量入口问题，不一定是规则语法问题

先试这一步：打开当前 Mihomo 配置，确认存在 mode: rule。官方文档将 rule 定义为按规则匹配，global 为全局代理，direct 为全局直连；如果当前是后两者，改规则不会产生预期的分流结果。参考 Mihomo General configuration。

第一步：确认运行模式和流量确实进入 Mihomo

先检查配置中的 mode。排障时不要把 global 或 direct 的结果当作规则失效。若使用系统代理，确认浏览器或应用实际使用了 Mihomo 的 HTTP、SOCKS 或 mixed 端口；若依赖 TUN，则确认 TUN 已启用并且系统路由或 VPN 状态已经建立。

Mihomo 官方说明，流量可以通过代理端口、TUN 或 listener 进入；顶层 tun 配置用于捕获系统流量、DNS 劫持和按应用路由。参考 Mihomo inbound configuration。因此，浏览器没有走系统代理、应用绕过 VPN，或者 TUN 没有接管时，连接记录中自然不会出现对应规则。

在 Mihomo 的运行配置中确认 mode: rule。
只用一个测试应用访问实际可访问的测试域名，避免多个客户端同时接管流量。
如果使用系统代理，确认应用的 HTTP 或 SOCKS 代理端口与 Mihomo 当前监听端口一致。
如果使用 TUN，暂时关闭其他 VPN、网络过滤器或第二个代理内核，再重新测试。

如果日志或控制页面完全没有这次请求，优先处理流量入口，不要先修改规则。Mihomo 的 log-level 控制台和控制页面输出，临时设为 debug 可获得更详细的运行信息；排查结束后可改回 info。参考 Mihomo General configuration。

第二步：检查规则顺序、类型和 MATCH 兜底

Mihomo 规则按从上到下匹配，越靠前优先级越高。一个宽泛的 DOMAIN-SUFFIX、GEOSITE 或较早出现的 RULE-SET，可能在目标规则之前已经匹配；如果前面的规则没有命中，最后的 MATCH 才会接管剩余请求。规则顺序说明见 Mihomo Route Rules。

常见写法需要对应实际数据类型：DOMAIN 匹配完整域名，DOMAIN-SUFFIX 匹配域名后缀，GEOSITE 使用地理域名数据，IP-CIDR 匹配 IP 网段，RULE-SET 引用规则提供者。不要把 IP 地址写进只用于域名的规则，也不要把包含完整经典规则行的文件配置成单纯的 domain 类型。

下面是仅用于演示顺序的最小片段。example.com 和 Proxy 都必须替换为你实际可访问的测试域名和现有策略组名称，不能直接当成完整配置：

rules: - DOMAIN,example.com,Proxy - DOMAIN-SUFFIX,example.com,Proxy - MATCH,DIRECT

测试时先把目标规则放到 MATCH 前面，再访问同一个域名。如果仍然落到 MATCH，说明请求可能没有进入当前内核、域名没有按预期呈现，或配置没有成功加载。

第三步：规则集显示更新但仍不生效怎么办

RULE-SET 不是独立规则文件，它需要对应的 rule-provider 配置。官方文档要求根据文件实际内容设置 behavior：可选 domain、ipcidr、classical；format 可选 yaml、text、mrs，默认是 yaml。详细字段见 Mihomo Rule-Providers。

逐项核对以下字段：

name：必须与 rules 中 RULE-SET,名称,策略组 的名称完全一致。
url：确认地址返回的是规则文件，而不是 HTML 错误页、登录页或空响应。
path：确认本地缓存路径可写，并且当前运行实例使用的是这个配置目录。
proxy：如果规则文件需要通过指定代理更新，确认该代理或策略组确实存在。
behavior 与 format：必须和文件实际格式对应，不能只根据文件扩展名猜测。
interval：它是 provider 的更新间隔，修改后需重新加载配置或按客户端提供的方式更新。

排查时不要只看“更新时间成功”。还要确认 provider 对象已被当前运行实例读取，且规则内容不是空文件。使用外部控制 API 时，接口地址、端口和认证方式取决于你的配置；不要把认证 token 粘贴到公开日志或截图中。

第四步：用日志和 API 区分“未加载”与“未命中”

先把 log-level 临时设为 debug，然后只访问一个测试域名。日志应在 Mihomo 控制页面或运行控制台查看；官方文档说明日志级别控制核心输出，debug 会输出尽可能多的运行信息。若你使用的图形客户端没有显示日志面板，应直接查看该客户端启动 Mihomo 时的控制台输出或其运行日志入口，不要把配置文件内容当成命中证据。

如果已启用 External Controller，可以用 GET 请求读取规则信息。下面命令只读取本机 API，不会打印 token；把端口号替换成你的实际外部控制端口。

curl -A "mihomo-rule-check/1.0" "http://127.0.0.1:9090/rules"
PowerShell 中执行：Invoke-RestMethod -Method Get -Headers @{"User-Agent"="mihomo-rule-check/1.0"} -Uri "http://127.0.0.1:9090/rules"

官方 API 文档定义 /rules 为 GET 请求，并返回规则数组、索引、类型、匹配内容、目标策略以及部分规则集的条目数量等字段。读取规则集总览可请求 /providers/rules；更新单个规则集则是对对应 provider 路径发起 PUT。具体接口说明见 Mihomo APIs。

结果可以这样判断：规则列表没有出现，先回到配置加载；规则列表出现但测试请求没有命中，检查规则顺序、域名类型和流量入口；规则命中且目标策略正确但出口不对，检查该策略组当前选择、代理节点状态和组名拼写。不要把 API 中存在某条规则误认为这条规则已经被当前请求命中。

第五步：区分 DNS、Fake-IP 和 no-resolve 造成的假象

DNS 问题和规则未命中很容易混在一起。域名规则可以正常匹配，但 IP-CIDR 规则可能因为解析路径、Fake-IP 或 TUN 接管方式不同而表现异常。Mihomo 文档说明，针对目标 IP 的规则在域名匹配开始时可能触发 DNS 解析；加入 no-resolve 可以跳过这次解析，但如果更早的规则已经触发解析，后续带有 no-resolve 的目标 IP 规则仍可能继续匹配。参考 Route Rules 的 no-resolve 说明。

检查 DNS 配置时重点看：

enhanced-mode 是 fake-ip 还是 redir-host；官方文档列出了这两种模式。
fake-ip-filter 是否把测试域名排除，导致该域名返回真实地址而不是 Fake-IP。
是否启用了 respect-rules。该选项让 DNS 连接遵守路由规则，同时需要配置 proxy-server-nameserver。
测试的是域名规则还是 IP 规则。两者命中条件不同，不要用域名规则的结果替代 IP-CIDR 验证。

如果域名规则能命中、连接也有记录，但应用仍打不开，先把问题标记为“规则已命中，连接阶段异常”，再检查 DNS、节点、MTU、IPv6 或 TUN，而不是继续改规则顺序。相关字段可核对 Mihomo DNS configuration。

最后核对：按结果选择修复动作

模式不是 rule：切换到 rule，重新加载配置，再测试同一域名。
流量没有进入 Mihomo：检查系统代理、应用代理、TUN 状态以及是否存在其他 VPN 或代理接管。
规则没有加载：检查 YAML 缩进、配置文件是否为当前运行实例，以及 provider 的名称和路径。
规则集为空或格式错误：按实际内容修正 behavior 和 format，再通过控制页面或 API 更新。
规则被前项提前匹配：把更具体的规则放在宽泛规则前，并将 MATCH 保持为兜底项。
规则已命中但策略不对：核对规则目标与 proxy-groups 名称，并确认该组当前选择的出口。
域名命中但 IP 结果异常：单独检查 DNS、Fake-IP、no-resolve、IPv6 和 TUN，不要直接判定规则失效。

完成一次修改后只测试一个变量，并记录“配置版本、测试域名、命中规则、目标策略组、DNS 模式和日志结果”。这样可以避免同时改规则、DNS 和 TUN 后无法判断真正原因。

常见问题

Mihomo 规则里有 MATCH，为什么所有请求都走 MATCH？

先确认当前模式是 rule，并确认请求确实进入 Mihomo。然后检查前面的规则是否加载、域名类型是否写对，以及测试应用是否绕过系统代理或 TUN。只有在规则未命中时，MATCH 才会接管剩余请求。

RULE-SET 更新成功但规则仍然不生效，最常见的检查点是什么？

重点核对 RULE-SET 引用的名称是否与 rule-providers 完全一致，再检查 provider 的 behavior、format、url 和 path。更新成功只说明请求可能完成，不等于文件内容非空、格式正确或当前运行实例已经加载新内容。

如何判断是规则问题还是策略组问题？

先用 API 的 GET /rules 查看规则是否存在，再通过日志或连接记录确认测试请求是否命中。规则已命中且目标策略组正确，但实际出口仍不符合预期时，应检查该策略组当前选择、节点状态和组名，而不是继续修改规则匹配条件。

DNS 会导致 Mihomo 规则看起来不生效吗？

会，尤其是 IP-CIDR、Fake-IP、TUN 和 no-resolve 同时参与时。域名规则能命中并不代表 IP 规则也会按相同路径判断。应分别测试域名规则和 IP 规则，并核对 enhanced-mode、fake-ip-filter、respect-rules 与 proxy-server-nameserver。