TrustedAccessPath - 全球网络加速服务

Mihomo 规则不生效怎么排查？从命中日志到 DNS、TUN 的完整流程

更新于 2026-11-03 · tapcloud.shop

简答：Mihomo 规则不生效，最常见原因不是语法本身，而是当前处于 Global/Direct 模式、流量没有进入 Mihomo、最终运行配置没有包含自定义规则，或宽泛规则和 MATCH 提前命中。最快排查顺序是：切换 Rule 模式→确认流量进入→查看连接命中的规则和策略组→检查规则顺序→再处理 DNS、TUN、规则集和进程匹配。

定义：Mihomo 规则不生效，是指请求已经产生，但没有按预期命中指定规则、策略组或出站，最终可能落入 DIRECT、错误策略组或 MATCH 兜底。

先试这一步：用 5 分钟确认问题属于哪一层

本文是第三方使用指南，不代表任何客户端或内核官方。本文内容已按 2026-11-03 可检索到的 Mihomo 文档核验；不同客户端的菜单名称、权限和面板位置可能不同，应以当前客户端显示为准。

先看现象，再决定排查方向
现象优先检查判断标准
所有请求都像直连运行模式、系统代理、TUN必须确认模式为 rule，并确认目标流量确实经过 Mihomo
只有某个域名不按预期分流最终配置、规则顺序、DNS 识别连接详情中应能看到实际命中的规则和策略组
域名规则有效，IP 或应用规则无效DNS、TUN、进程匹配模式域名解析、流量接管方式和真实进程名必须分别核对
RULE-SET 不生效provider 类型、behavior、format、更新状态规则集已加载，且在 rules 中被引用
改完规则仍显示旧结果旧连接、长连接、缓存和客户端配置覆盖关闭目标应用后重新发起全新请求
  1. 把运行模式切到 Rule，不要在 Global 或 Direct 模式下判断自定义规则是否生效。Mihomo 文档将三者分别定义为规则匹配、全局代理和全局直连。
  2. 确认系统代理或 TUN 已开启，并用一个新请求触发测试。只打开客户端界面，不代表浏览器、应用或后台进程的流量已经进入 Mihomo。
  3. 打开客户端的连接详情、Logs 或控制面板，记录四项：目标域名或 IP、命中的规则、策略组、最终出站。
  4. 如果没有任何新连接记录，先排查流量接管；如果有连接但命中错误规则，再检查最终配置和顺序。

官方文档说明，Mihomo 默认运行模式为 rule，但客户端可以切换运行模式；因此“配置文件里写了规则”不等于当前请求一定会按规则匹配。参考：Mihomo 全局配置文档。

第一层：确认客户端使用的是最终运行配置

很多规则“不生效”其实是改错了文件。订阅、覆写、脚本或客户端生成过程可能在启动后重新组合配置，所以应检查客户端当前加载的最终配置，而不是只看本地编辑器里的 YAML。

  1. 在客户端中找到当前配置的预览、编辑或运行配置页面。
  2. 搜索你刚刚添加的域名、规则集名称或策略组名称。
  3. 确认自定义规则确实位于最终 rules: 列表中。
  4. 确认规则引用的策略组名称真实存在，大小写和标点也一致。
  5. 如果规则来自 rule-providers，同时确认 provider 已加载、文件可更新，并且 rules: 中存在对应的 RULE-SET。

官方配置示例显示，rule-providers 需要单独定义 provider，随后才能在 rules 中使用 RULE-SET,provider-name,策略组 引用。provider 的 type、behavior、format 应与实际规则文件匹配；不能只修改文件扩展名来代替正确配置。参考：Mihomo 官方配置示例 和 Mihomo 官方 rule-provider 文档。

最小化测试片段：先不用复杂规则集

下面是用于定位问题的演示片段，不是完整配置。请把 PROXY 替换成你当前配置中确实存在的策略组，把“你的测试域名”替换成你能够控制或明确知道结果的域名。先测试简单的 DOMAIN-SUFFIX，再测试其他规则类型。

rules:
  - DOMAIN-SUFFIX,你的测试域名,PROXY
  - MATCH,DIRECT

如果这条简单规则都没有出现在命中详情中，优先回到运行模式和流量接管检查，不要继续增加复杂的 AND、OR、正则或多个规则集。

第二层：检查规则顺序，尤其是宽泛规则和 MATCH

Mihomo 按规则从上到下匹配，排在前面的规则优先级更高。一个宽泛规则、提前出现的 GEOIP、RULE-SET 或 MATCH，都可能让后面的自定义规则没有机会执行。

常见顺序错误与修复方式
错误写法为什么会失效调整方法
自定义域名规则写在 MATCH 后MATCH 会匹配所有请求，后面的规则无法命中把 MATCH 放到规则列表末尾
具体域名规则写在宽泛规则后前面的 DOMAIN-KEYWORD、GEOSITE 或规则集先命中把更具体的 DOMAIN、DOMAIN-SUFFIX 放前面
PROCESS-NAME 写在通用规则后请求已经被域名、IP 或其他规则处理将进程规则提前，并用新连接复测
IP-CIDR 规则没有考虑解析目标域名对应的 IP 可能变化，或规则触发了 DNS 解析查看实际目标 IP；仅在确认无需解析时考虑 no-resolve
RULE-SET 引用名称拼写不一致规则集名称必须与 provider 定义一致逐字符核对 provider 名称和 RULE-SET 引用

官方规则文档明确说明规则按从上到下的顺序匹配，并列出了 DOMAIN、DOMAIN-SUFFIX、IP-CIDR、PROCESS-NAME、RULE-SET 和 MATCH 等类型。参考：Mihomo Routing Rules 文档。

推荐的基础排列思路

rules:
  - DOMAIN,精确域名,PROXY
  - DOMAIN-SUFFIX,目标后缀,PROXY
  - PROCESS-NAME,目标进程名,PROXY
  - RULE-SET,自定义规则集,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

这只是排列思路，不应直接覆盖你的完整配置。实际策略组名称、规则集名称和是否使用 GEOIP，应以当前配置为准。

第三层：在连接详情或日志里确认“到底命中了什么”

不要只根据网页能否打开来判断规则是否生效。一个网页能打开，可能是直连、代理、缓存或应用自身代理造成的。应以 Mihomo 的连接详情或日志为准。

  1. 保持日志等级为能够显示普通运行信息的级别；如果日志过少，再临时提高到 debug，复测后恢复，避免长期产生过多日志。
  2. 关闭目标应用或浏览器中原有页面和长连接。
  3. 重新打开应用，访问一个新的目标地址。
  4. 记录连接详情中的目标、入站、命中规则、策略组和出站。
  5. 如果显示 MATCH，说明前面的规则没有匹配成功，继续检查规则类型、顺序和域名识别。
  6. 如果命中目标规则但出站不对，检查策略组当前选择、策略组是否为空，以及节点是否支持该请求类型。

如果客户端提供控制 API，也可以通过官方 API 文档中的 /logs 查看实时日志，并使用连接接口查看活动连接。API 监听地址和权限由当前配置决定，不要把控制接口暴露到不可信网络。参考：Mihomo API 文档。

第四层：按规则类型分别测试，别把所有问题归咎于 YAML

DOMAIN 与 DOMAIN-SUFFIX

DOMAIN 用于匹配完整域名，DOMAIN-SUFFIX 用于匹配域名后缀。假如目标是 sub.example.test，应先确认你想匹配的是完整主机名，还是该后缀下的多个子域名。规则命中详情中的目标域名必须与预期一致。

IP-CIDR

IP 规则依赖实际目标 IP。域名解析结果变化、IPv4 与 IPv6 走不同路径，或者请求尚未被解析为你预期的地址，都可能造成判断偏差。官方文档说明，针对目标 IP 的匹配在域名匹配开始时可能触发 DNS 解析；no-resolve 可以跳过该解析，但不应在没有明确理由时随意添加。

RULE-SET

先单独确认 provider 是否下载或读取成功，再确认 rules: 中确实引用了它。对于 behavior: domain、ipcidr 和 classical，规则文件内容格式不同；配置错误时，规则集可能加载失败或部分内容不起作用。

PROCESS-NAME 与 PROCESS-PATH

进程规则必须匹配真实发起连接的进程，而不是你看到的应用名称。Windows、macOS、Linux 和 Android 的进程名表现可能不同；官方文档特别说明，Android 上的 PROCESS-NAME 还可以匹配应用包名。

如果进程规则无效，先把 find-process-mode 纳入排查。官方全局配置文档列出 always、strict 和 off 三种模式；在不确定客户端当前行为时，先确认实际配置值，再用全新连接测试。不要仅凭应用图标或窗口标题猜测进程名。

第五层：DNS、fake-ip 与 TUN 可能改变你看到的目标

当域名规则有效、IP 规则异常，或只有 TUN 模式下分流不对时，检查 DNS 处理方式。Mihomo 的 DNS 配置包含 enhanced-mode、fake-ip、redir-host、fake-ip-filter 和 nameserver-policy 等选项；这些设置会影响应用拿到的地址以及 Mihomo 识别请求的方式。

  1. 先确认 DNS 模块是否启用；如果未启用，系统 DNS 可能直接参与解析。
  2. 确认目标域名是否落入 fake-ip-filter，以及当前是 fake-ip 还是 redir-host。
  3. 如果只有某个应用异常，检查该应用是否自带 DNS、DoH、代理或加密解析功能。
  4. 如果使用 TUN，确认 TUN 已获得系统 VPN 或网络权限，且目标应用流量确实被接管。
  5. Android 开启“私人 DNS”时，官方文档提示 DNS 请求可能无法被自动劫持；Windows 和 macOS 对局域网 DNS 也存在限制。

TUN 的 auto-route 用于自动设置全局路由，dns-hijack 会把匹配到的 DNS 连接导入内部 DNS 模块；Windows 使用 DNS 劫持时还涉及 strict-route，Linux 则涉及 auto-redirect。这些字段不是所有平台都能按同样方式使用。参考：Mihomo TUN 文档 和 Mihomo DNS 文档。

第六层：区分系统代理、TUN、应用代理和浏览器插件

规则没有生效，可能是目标流量绕过了 Mihomo。常见路径包括：系统代理未开启、TUN 未启动、应用自带代理覆盖系统设置、浏览器代理插件单独接管，或者应用只使用 UDP 而当前接入方式没有覆盖该流量。

不同接入方式的判断点
接入方式适合确认的问题排查重点
系统代理浏览器等遵循系统代理的应用系统代理地址和端口是否与 Mihomo 监听端口一致
TUN需要接管更多系统流量的场景VPN/TUN 权限、路由、DNS 劫持、应用排除项
应用自身代理应用不遵循系统设置时应用内部代理是否绕过 Mihomo
浏览器插件只针对特定浏览器或标签页插件规则是否覆盖客户端规则

最稳妥的复测方法是暂时只保留一种接入方式：例如先关闭浏览器代理插件，使用系统代理测试；或者在确认 TUN 权限正常后，只用 TUN 测试。每次只改变一个变量，并记录连接详情中的入站名称。

第七层：改规则后必须关闭旧连接，再复测和回滚

长连接、HTTP/2、WebSocket、应用缓存和 DNS 缓存都可能让旧请求继续沿用原来的连接。改完规则后，建议按以下顺序复测：

  1. 保存配置并让客户端重新加载；如果客户端提供配置校验，先通过校验再启动。
  2. 关闭目标应用、浏览器页面和相关后台进程。
  3. 必要时清理应用自身的 DNS 或连接缓存；不要一开始就清空全部系统网络配置。
  4. 重新打开应用，发起新的请求。
  5. 在连接详情中确认新的命中规则、策略组和出站。
  6. 如果新配置导致断网，立即恢复上一个已知可用配置，再逐条加入变更。

建议每次只修改一个因素：先改规则顺序，再测；再改 DNS，再测；最后才调整 TUN 或进程匹配。这样可以避免多个改动同时发生后无法判断真正原因。

Windows、macOS、Android 的差异化检查清单

按平台快速分流
平台优先观察常见边界
Windows系统代理、TUN 权限、防火墙、真实进程名TUN 的 DNS 劫持和严格路由可能涉及防火墙规则；部分应用可能使用独立网络路径
macOS系统代理、网络扩展权限、TUN 接口、应用自身代理macOS 的 TUN 设备名和网络扩展行为由客户端实现，不能套用 Windows 菜单
AndroidVPN 授权、应用包名、私人 DNS、应用排除列表PROCESS-NAME 可匹配包名；开启私人 DNS 可能影响 DNS 劫持

如果某个平台没有连接记录，优先处理权限和流量接管；如果有连接记录但规则错误，再回到规则顺序和最终配置。不要把“网页能打开”当作 TUN 已经成功的证明。

一张可执行的最终排障清单

  1. 模式：确认是 Rule，不是 Global 或 Direct。
  2. 接管：确认系统代理或 TUN 开启，并确认目标请求出现在连接列表。
  3. 最终配置：搜索自定义规则、provider 和策略组，确认它们确实被当前运行配置加载。
  4. 顺序：把具体规则放在宽泛规则前，把 MATCH 放到末尾。
  5. 命中：查看连接详情中的规则、策略组和出站，不只看网页结果。
  6. 类型：分别验证 DOMAIN、DOMAIN-SUFFIX、IP-CIDR、RULE-SET 和 PROCESS-NAME。
  7. DNS：检查 fake-ip、redir-host、fake-ip-filter、应用自带 DNS 和私人 DNS。
  8. 复测：关闭旧连接和应用进程，重新发起请求。
  9. 回滚：一次只改一个变量，异常时恢复上一个可用配置。

如果完成以上步骤后仍然异常，保留一份最小配置、当前内核版本、平台、运行模式、连接详情和相关日志，再向客户端或内核维护方反馈。无法确认的版本兼容性，不要仅凭配置字段名称推断。

常见问题

Mihomo 规则写对了，为什么还是走 DIRECT？

先确认当前模式是 Rule，并确认请求确实进入 Mihomo。然后查看连接详情：如果命中 MATCH，通常是自定义规则没有加载、顺序靠后或域名没有被当前规则类型识别；如果已经命中自定义规则但仍显示直连，则检查该规则指向的策略组是否实际选择了 DIRECT。

为什么 MATCH 规则会让后面的规则全部失效？

因为 MATCH 是无条件匹配规则，放在前面时会先匹配所有请求。应把 MATCH 作为兜底规则放在 rules 列表末尾，并在修改后关闭旧连接、重新发起请求。

RULE-SET 不生效要看哪些字段？

先看 provider 的 type、url 或 path、behavior、format 和加载状态，再看 rules 中是否使用了完全一致的 provider 名称。domain、ipcidr 和 classical 对规则文件内容的要求不同，不能只改文件后缀。

PROCESS-NAME 规则为什么匹配不到？

确认真实发起连接的进程名，而不是窗口名称或应用显示名称；同时检查 find-process-mode 是否关闭进程匹配。在 Android 上，还要核对应用包名以及是否被 TUN 的 include-package 或 exclude-package 影响。

只有 TUN 模式下规则异常，系统代理却正常，怎么办？

先比较两种模式下是否都能在连接列表看到目标请求。若 TUN 下没有记录，检查 VPN/TUN 授权、路由和应用排除项；若有记录但域名或 IP 不同，再检查 DNS、fake-ip、DNS 劫持和应用自身 DNS。

改完规则后为什么测试结果没有变化？

旧连接、长连接、浏览器缓存或应用自身连接池可能仍在使用旧路径。重新加载配置后，关闭目标应用和相关页面，再发起全新请求，并以新的连接详情作为判断依据。

相关阅读

参考资料

  1. Mihomo 官方全局配置文档
  2. Mihomo 官方 Routing Rules 文档
  3. Mihomo 官方配置示例
  4. Mihomo 官方 rule-provider 文档
  5. Mihomo 官方 TUN 文档
  6. Mihomo 官方 DNS 文档
  7. Mihomo 官方 API 文档