规则命中错位要先留下证据。Clash Verge Rev 只是桌面壳，真正按规则判断的是 Mihomo 内核；界面里选中了某个策略组，不代表每个域名都进了那一组，用一个固定域名复现，再看日志和连接面板，比直接改大段 YAML 更快。

判断是哪一种命中错误

表现更可能原因看哪里
目标域名落到 MATCH前面的规则没命中、provider 未加载、规则顺序错debug 日志里的 match 行
命中 DIRECT 后访问失败私有地址、GEOIP、手写直连规则过宽命中的规则类型和规则集名
命中 REJECT广告过滤或黑名单规则误收录RULE-SET 名称、本地规则文件
主站正常，登录或图片异常浏览器调用了额外子域名连接面板按域名筛选
日志里只有 IP，没有域名DNS 没进入 Mihomo 或 fake-ip 映射失效DNS、TUN、DoH、fake-ip-filter
改规则后仍是旧结果provider 更新了但配置没重载provider path、reload、核心重启

Mihomo 规则按从上到下的顺序判断，MATCH 没有条件，通常应该放在最后。旧 Clash 配置里常见 FINAL 兜底，迁到 Mihomo / Clash Verge Rev 时要确认当前内核实际接受的写法；无论叫 MATCH 还是旧模板里的 FINAL，兜底规则提前出现都会盖住后面的细分规则。

日志要怎么取样才够用？

把问题缩小到一个域名，例如 api.example.com，不要同时测试 10 个网站。记录当前时间、系统、Clash Verge Rev 版本、Mihomo 核心版本、是否开启 TUN，以及你期望它命中的策略组。

在 Clash Verge Rev 的日志页短时间切到 debug，或者在配置里写：

log-level: debug
mode: rule

复现 30 秒后切回 info。debug 长期开着会产生大量日志，也容易把订阅 URL、节点地址、controller secret 和内网结构带出去。

排查规则时只抓这几类行：

[dns] query api.example.com A
match DomainSuffix(example.com) using Proxy
match RuleSet(github) using Proxy
match GeoIP(private) using DIRECT
match Match() using Manual

如果日志里完全没有目标域名，先不要改规则。入口可能还没进入 Mihomo：系统代理没接管、TUN 没生效、浏览器用了自己的 DoH，或者应用复用了旧 DNS 缓存。

规则顺序为什么会让域名走错？

规则不是按“更聪明的那条”自动选择，而是从上往下碰到第一条可用规则就停。更具体的 DOMAIN 或 DOMAIN-SUFFIX 通常要放在宽泛的 RULE-SET、GEOIP、MATCH 前面。

一个容易出错的例子：

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

这会让 example.com 永远没有机会命中第二行。改成：

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

DIRECT 和 REJECT 也要按同样逻辑看。DIRECT 放得太靠前，会让本该进入指定策略组的域名提前结束；REJECT 所在规则集误收录主域名，会让页面表现像“网站坏了”，实际是本机规则拒绝了连接。

rule-providers 要查哪些字段？

RULE-SET 命中错误时，重点不在规则行本身，而在 rule-providers 是否真的加载了你以为的文件。Mihomo 文档里 provider 常见字段包括 type、url、path、interval、behavior、format。

字段排查点错误后果
typehttp、file、inline 是否符合来源文件没拉取或没读取
url返回的是规则文件，不是 HTML 或错误页provider 更新失败
path本地路径唯一且可写读到旧文件或写入失败
behaviordomain、ipcidr、classical 对上文件格式规则解析异常或命中异常
formatyaml、text、mrs 与文件一致加载失败或空规则
interval更新间隔合理改了上游但本地还没刷新

如果同一份配置来自订阅、merge 文件和本地覆写，provider 名称更要逐字比对。RULE-SET,github,Proxy 只会找名为 github 的 provider；你把 provider 改成 github-domain 后，规则行不跟着改，界面可能仍能启动，但目标域名不会命中那份新规则。

团队共享配置时，如果上游订阅已经带了规则集，自己又叠加本地 provider，把名称、path 和策略组写清楚。使用兼容 Clash / Singbox / V2Ray 的订阅也要区分“完整配置”和“provider 片段”，不要把两种入口混在同一个 YAML 里。

MATCH、FINAL、DIRECT、REJECT 分别该怎么看？

MATCH 是 Mihomo 配置里常见的兜底规则。它的价值是兜住所有未命中的连接，风险是放错位置后吞掉后面的规则。

FINAL 常见于旧 Clash、Surge 或 Shadowrocket 语境。Clash Verge Rev 使用 Mihomo 时，优先按当前 Mihomo 文档校验 MATCH 写法；如果订阅转换器输出了旧字段，要用日志确认内核是否按预期解释。

DIRECT 不等于“安全无误”，它只是让当前连接不走代理出站。局域网、内网服务、系统更新域名放 DIRECT 很常见；把大型公共域名规则集全放 DIRECT，才容易出现目标服务走错路径。

REJECT 用来拒绝广告、跟踪或明确不想访问的域名。误伤时，症状通常是页面主框架能开，图片、验证码、登录接口或支付组件失败。不要直接删整个 REJECT 规则集，先找具体子域名，再写一条更靠前的精确规则覆盖。

DNS 和 fake-ip 会怎样影响规则命中？

规则需要知道“连接对应哪个域名”。在 fake-ip 模式下，Mihomo 会给域名分配一段虚拟 IP，并把连接映射回原始域名；如果 DNS 没进入 Mihomo，这个映射就断了，日志里可能只剩目标 IP。

Mihomo DNS 文档里，enhanced-mode 可选 fake-ip 或 redir-host。Clash Verge Rev 的配置示例也常见 enhanced-mode: fake-ip、fake-ip-range: 198.18.0.1/16 与 store-fake-ip: true。这些字段不只是“DNS 设置”，它们会影响规则引擎能不能在连接阶段识别域名。

排查 DNS 时按这个顺序：

  1. Clash Verge Rev 是否开启 TUN，系统代理是否真的被应用使用。
  2. DNS 查询是否进入 Mihomo，日志里有没有 [dns] query。
  3. 浏览器是否开启安全 DNS / DoH，导致它绕开系统 DNS。
  4. fake-ip-filter 是否把目标域名排除得过宽。
  5. 系统和浏览器缓存是否还保存旧解析。

切换 fake-ip / redir-host 后，要清系统 DNS 缓存并重启浏览器。否则你以为在测新规则，实际应用还拿着旧 IP 连接。

浏览器子域名为什么会误导判断？

很多人只测主域名，例如 example.com。真实网页会同时请求 www.example.com、api.example.com、static.examplecdn.com、login.example.net、字体域名、验证码域名和统计域名。主域名命中正确，页面仍可能因为某个子域名落到 REJECT 或 DIRECT 而异常。

用 Clash Verge Rev 连接面板按时间倒序看最近 20 条连接。不要只看网页地址栏，把失败时出现的每个子域名都记录下来，再逐个对照命中规则。

子域名类型常见异常处理方式
api.*页面能开，数据加载失败给 API 域名写精确规则
static.* / CDN图片、脚本、字体缺失查 CDN 域名是否被 REJECT
login.*登录页循环或验证码不出单独测试登录域名命中
第三方支付域名付款页跳转失败不要只按主站规则判断
DoH resolver日志里看不到原始查询关闭浏览器安全 DNS 或明确纳管

改完配置后怎么确认真的生效？

Clash Verge Rev 有 profile、merge、script、provider、本地覆写和 Mihomo 核心几层。你改了其中一层，不代表运行中的核心已经读到新规则。

验收顺序固定下来：

  1. 保存当前 profile 备份。
  2. 更新 rule-provider。
  3. 打开 provider 的本地 path，确认文件内容变化。
  4. 重载配置；必要时重启 Mihomo 核心。
  5. 清 DNS 缓存和浏览器连接池。
  6. 用同一个失败域名复测。
  7. 在日志里确认命中规则名、策略组和 DNS 查询一致。

只看网页能打开还不够。排错结束时，至少保存三条证据：失败前命中行、修改的规则片段、修复后命中行。下次订阅更新或客户端升级后，同样的证据能帮你判断是规则回退、provider 变更，还是 DNS 链路又变了。

相关阅读