Clash Verge Rev 规则不生效怎么办？

更新于 2026-10-18 · ifanqiang.cyou

简答：Clash Verge Rev 规则不生效时，先在客户端切换到“规则”模式，打开“日志”和“连接”查看请求是否进入内核、命中了哪条规则；然后检查自定义规则是否位于 MATCH 之前、目标策略组是否存在，最后核对 rule-providers 的 type、behavior、format、URL 和引用名称。若应用只连接 IP，还要检查 DNS 的 fake-ip/redir-host、sniffer 域名嗅探，以及 GEOIP 或 IP-CIDR 规则的 no-resolve。

定义：Clash Verge Rev 规则不生效，是指请求没有进入 Mihomo 内核、没有命中预期规则，或虽然命中规则但被更靠前的规则、错误的策略组或 DNS 与 IP 匹配逻辑影响。

先判断：规则没有命中，还是命中后结果不对

Clash Verge Rev 是基于 Mihomo 内核的桌面客户端。本文按官方文档中 v1.7.x 之后的界面命名说明，使用“编辑规则”“扩展配置”“扩展脚本”等入口；不同安装版本可能出现菜单名称或位置差异，实际操作时以当前版本界面和官方发布说明为准。官方文档说明，扩展配置与扩展脚本可以通过配置卡片的右键菜单进入，且 v1.7.x 之后原先的 Merge、Script 名称和规则编辑方式发生过调整。可先查看 Clash Verge Rev 项目仓库与官方发布页面。

不要一开始就重写整份 YAML。先用一个明确的域名测试，再观察客户端的日志和连接记录：

• 没有任何连接记录：目标应用的流量可能没有进入 Clash Verge Rev，常见方向是系统代理未启用、TUN 未接管、应用使用独立代理，或者应用直接连接 IP。
• 有连接记录，但命中了 DIRECT 或其他策略组：通常是规则模式、规则顺序、MATCH 兜底、域名写法或策略组名称存在问题。
• 命中了预期规则，但访问仍失败：规则可能已经生效，应继续检查策略组当前选择、节点可用性、DNS、目标站点和应用协议，而不要继续修改规则语法。

第一步：确认当前是规则模式并打开日志

1. 切换到规则模式。在客户端的运行模式或代理模式区域，选择“规则”而不是“全局”或“直连”。Mihomo 的配置模式包括 rule、global 和 direct；其中 rule 才会按规则列表逐条匹配。相关定义见 Mihomo 通用配置文档。
2. 打开“日志”页面。在客户端主界面进入日志查看区域，重新访问测试域名。若日志信息太少，进入当前配置的扩展配置或配置编辑区域，把日志等级设为 info；仍无法判断时可临时改为 debug。Mihomo 文档说明，info 会输出常规运行信息，debug 会输出更多运行细节。修改后重新载入配置，必要时重启内核。
3. 打开“连接”页面。观察测试请求的目标地址、协议、进程和最终策略。Mihomo 的控制接口可以提供当前连接信息、规则信息和命中统计；如果客户端页面没有显示足够内容，可先以客户端自带的日志和连接列表为准。相关接口说明见 Mihomo API 文档。
4. 确认请求确实进入客户端。浏览器通常需要系统代理才能被普通代理端口接管；不遵循系统代理的应用，可能需要启用 TUN 或配置应用自身代理。Mihomo 文档将代理端口、TUN 和 listeners 都列为流量入口，具体是否接管成功取决于系统路由、权限和应用设置，可参考 Mihomo 入站配置文档。

第二步：检查规则顺序、MATCH 和策略组名称

Mihomo 按规则从上到下匹配，排在前面的规则优先级更高。因此，自定义规则必须放在会提前匹配的宽泛规则和最终的 MATCH 规则之前。官方路由规则文档明确说明，规则按照从上到下的顺序匹配，MATCH 会匹配所有没有被前面规则处理的请求。可参考 Mihomo 路由规则文档。

例如，下面的顺序通常更容易检查：

DOMAIN-SUFFIX,example.com,实际策略组名称
GEOIP,CN,DIRECT
MATCH,实际兜底策略组名称

如果把自定义规则放在 MATCH 后面，它就没有机会命中。若前面已经有宽泛的 DOMAIN-KEYWORD、GEOIP、IP-CIDR 或其他 RULE-SET，也可能在到达自定义规则前就结束匹配。

1. 在客户端的订阅或配置卡片上右键，优先选择“编辑规则”，检查自定义规则是否出现在规则列表前部。
2. 如果使用 v1.7.x 之后的扩展功能，不要把旧版 prepend-rules 或 append-rules 写法直接当成通用配置。官方说明显示，扩展配置主要用于配置覆盖或合并，规则前置、后置可以通过订阅右键菜单的“编辑规则”完成；需要编程处理时再使用“扩展脚本”。
3. 确认规则最后的策略组名称与当前配置完全一致，包括大小写、空格和特殊字符。规则目标可以是实际存在的代理组，也可以是 DIRECT 或 REJECT。
4. 如果日志显示命中了策略组，但策略组当前选中的是 DIRECT，这不是规则失效，而是策略组的当前选择导致结果为直连。
5. 修改后保存，重新载入当前配置，再访问同一个测试域名。不要同时修改模式、DNS、规则顺序和节点，否则很难判断具体是哪一项起作用。

如果需要对所有订阅统一插入规则，可在订阅卡片右键菜单进入全局扩展脚本，再通过 config.rules 调整规则数组；官方扩展脚本文档提供了前置规则示例。可参考 Clash Verge Rev 官方扩展脚本文档。

第三步：按规则类型核对域名、IP 和规则集格式

规则内容要与实际请求类型匹配。DOMAIN 用于完整域名，DOMAIN-SUFFIX 用于域名后缀，DOMAIN-KEYWORD 用于关键字，IP-CIDR 用于 IP 网段。只想匹配 example.com 及其子域名时，通常应写成：

DOMAIN-SUFFIX,example.com,实际策略组名称

不要把 https://、网页路径、查询参数或完整 URL 直接填入域名规则。若应用访问的是 IP 地址，单纯的域名规则可能没有匹配对象，这时需要查看连接日志中的目标地址和域名信息。

使用 RULE-SET 时，要逐项检查以下内容：

• provider 名称：定义中的名称必须唯一，并且与规则列表中的 RULE-SET,名称,策略组 完全一致。
• type：http 类型需要填写 url；file 和 inline 的配置方式不同。
• behavior：应与文件实际内容对应，可选 domain、ipcidr、classical。
• format：应与文件格式对应，可选 yaml、text 或 mrs。
• URL 返回内容：打开或下载后应是规则文件，而不是登录页、错误页、HTML 页面或空文件。

Mihomo 官方文档明确列出了 provider 的 type、url、behavior 和 format 字段，详见 Rule-Providers 配置文档。其中，classical 可以包含完整规则行，domain 应使用域名或通配形式，ipcidr 应使用 IP 网段；三种格式混用会导致规则集无法按预期匹配，具体格式见 Rule-Providers 内容格式文档。

第四步：只连接 IP 时检查 DNS、sniffer 和 no-resolve

有些应用不会把域名交给代理客户端，而是先解析成 IP，再直接连接 IP。这时域名规则可能无法按预期工作。排查时可以按下面方向检查：

• 检查 DNS enhanced-mode。Mihomo 支持 fake-ip 和 redir-host 两种模式。进入当前配置查看 dns.enhanced-mode，不要因为切换模式后结果改变就直接认定某一种模式一定更好，应结合应用、TUN 和规则表现测试。
• 检查 fake-ip 过滤规则。如果目标域名被放入 fake-ip-filter，它可能返回真实 IP；如果没有过滤，则可能使用 fake IP。改动后可以重新载入配置并清理 DNS 或 fake-ip 缓存，再用同一域名测试。
• 检查 sniffer。对已经变成 IP 的 TLS、HTTP 或 QUIC 连接，域名嗅探可能帮助内核恢复域名信息。Mihomo 示例配置展示了 sniffer.enable、HTTP/TLS/QUIC 端口以及 override-destination 等字段，但是否启用应根据隐私、兼容性和实际需求决定，不能把它当成所有应用都适用的固定方案。可参考 Mihomo 示例配置。
• 检查 IP 规则的 no-resolve。对于 GEOIP、IP-CIDR 等目标 IP 规则，Mihomo 可能为了判断目标 IP 而触发 DNS 解析；添加 no-resolve 可以跳过这次解析。例如 IP-CIDR,192.168.0.0/16,DIRECT,no-resolve。官方规则文档说明，no-resolve 只适用于目标 IP 相关规则，具体行为见 路由规则文档。
• 确认应用没有自带 DNS 或独立代理。浏览器、游戏、终端和安全软件可能使用自己的网络栈。若连接页面能看到请求但规则仍不符合预期，先检查应用自身的代理、DNS、QUIC 或 IPv6 设置。

第五步：正确保存自定义规则，避免订阅更新后消失

直接修改订阅下载的原始配置，可能在下次更新订阅后被覆盖。更稳妥的做法是根据修改范围选择对应入口：

官方扩展说明指出，扩展执行顺序涉及全局扩展配置、全局扩展脚本、订阅扩展配置和订阅扩展脚本；不同版本可能对旧配置的访问方式进行过调整。因此，升级或重新导入订阅后，如果规则突然消失，应先检查扩展入口是否仍存在，再重新载入配置。

一个可照做的最小化测试流程

1. 准备一个明确的测试域名，并确认该域名确实会产生网络请求。
2. 在客户端选择“规则”模式。
3. 打开系统代理；如果目标应用不遵循系统代理，再检查 TUN 是否启用并获得必要权限。
4. 在订阅卡片上右键，进入“编辑规则”，添加一条使用现有策略组的测试规则，例如 DOMAIN-SUFFIX,example.com,实际策略组名称。
5. 把该规则放在相关规则集和 MATCH 之前。
6. 保存并重新载入配置，必要时重启内核。
7. 打开“日志”和“连接”，访问测试域名，记录命中的规则、策略组、目标地址和进程。
8. 如果测试规则命中，说明流量接管和基本规则语法大体正常，再回头检查原规则的顺序、类型、策略组或 provider。
9. 如果测试规则也不命中，优先检查流量入口、模式、DNS、应用独立代理和 TUN，不要继续堆叠更多规则。

常见现象对照表

结论：最快的排查顺序

可以把 Clash Verge Rev 规则排查压缩为八个检查点：规则模式 → 日志等级 → 连接是否进入 → 规则顺序 → MATCH 位置 → 策略组名称 → provider 格式 → DNS 与 IP 匹配。其中，最常见的问题不是规则语法本身，而是当前模式不对、流量没有被客户端接管、自定义规则位于 MATCH 之后、策略组名称不存在，或者应用只连接 IP 导致域名规则没有足够的匹配信息。

建议先用一条最小化的 DOMAIN-SUFFIX 规则验证链路，再逐步恢复复杂的规则集、TUN、DNS 和 sniffer 设置。每次只改变一个变量，并以连接日志中的实际命中结果作为判断依据。

常见问题

Clash Verge Rev 添加规则后为什么没有效果？

先确认当前处于“规则”模式，并在“日志”和“连接”页面确认目标请求确实进入客户端。然后检查自定义规则是否位于 MATCH 之前、是否被更靠前的规则拦截，以及规则目标策略组是否真实存在。

Clash Verge Rev 里的 MATCH 规则应该放在哪里？

MATCH 会匹配所有没有被前面规则处理的请求，通常应作为兜底规则放在规则列表最后。自定义 DOMAIN、IP-CIDR 或 RULE-SET 规则必须放在 MATCH 之前，否则不会有机会命中。

在哪里添加 Clash Verge Rev 自定义规则？

对单个订阅修改时，在订阅或配置卡片上右键进入“编辑规则”。需要统一处理多个订阅时，可以使用全局扩展配置或全局扩展脚本。v1.7.x 之后的菜单名称与旧版 Merge、Script 有差异，具体以当前版本界面为准。

为什么 RULE-SET 在 Clash Verge Rev 中不生效？

检查 rule-providers 定义与 RULE-SET 引用是否使用同一个名称，再核对 type、url、behavior、format 和文件内容。classical、domain、ipcidr 分别对应不同内容格式，不能随意混用。

只连接 IP 的应用为什么无法匹配域名规则？

应用如果直接连接 IP，域名规则可能没有匹配对象。应查看连接日志中的目标地址，并检查 DNS 的 fake-ip 或 redir-host、sniffer 域名嗅探，以及 GEOIP、IP-CIDR 规则是否需要使用 no-resolve。还要确认应用没有绕过系统代理。

修改规则后需要重启 Clash Verge Rev 吗？

先保存并重新载入当前配置，确认内核已经应用新配置；如果日志等级、内核状态或界面没有变化，再重启内核或客户端。最终应以连接日志中的实际命中结果为准。

参考资料

1. Clash Verge Rev 官方 GitHub 仓库
2. Clash Verge Rev 官方发布页面
3. Clash Verge Rev 官方文档：扩展配置
4. Clash Verge Rev 官方文档：扩展脚本
5. Mihomo 官方文档：通用配置
6. Mihomo 官方文档：路由规则
7. Mihomo 官方文档：Rule-Providers
8. Mihomo 官方文档：Rule-Providers 内容格式
9. Mihomo 官方文档：DNS 配置
10. Mihomo 官方文档：示例配置
11. Mihomo 官方文档：API、连接与规则信息
12. Mihomo 官方文档：入站配置