客户端指南

Clash 规则里的 no-resolve 是什么？为什么有些 IP 规则会触发 DNS

Mihomo 在用 IP-CIDR、GEOIP 等目标 IP 规则匹配域名请求时可能发起解析；no-resolve 只跳过这一步，不会关闭 DNS 或自动修复泄漏。

发布于 2026/8/21 · 更新于 2026/8/21 · 4 项可核验来源

先看重点no-resolve 只告诉 Mihomo：不要为了判断当前这条目标 IP 规则而主动解析域名。目标本来就是 IP，或更早的规则已经取得 IP 时，它仍可能命中；它不会关闭 DNS，也不能单独解决 DNS 泄漏。只有确认这条规则不需要依赖解析结果时，才适合保留。

配置里经常能看到这样一行：IP-CIDR,192.168.0.0/16,DIRECT,no-resolve。名字看起来像“不要做 DNS”，可加上以后，日志里仍可能出现解析请求；有时某个内网域名反而不再命中直连规则。

问题不在开关失效，而在它管得很窄。no-resolve 跳过的只是“为了判断这条目标 IP 规则而临时解析域名”，不是把客户端、系统和应用的 DNS 一起关掉。

域名为什么会走到 IP 规则

Mihomo 的路由规则从上到下匹配。DOMAIN、DOMAIN-SUFFIX 和 GEOSITE 可以直接拿域名判断；IP-CIDR、IP-ASN、GEOIP 这类规则关心的则是目标 IP。

当请求携带的是域名，规则走到目标 IP 匹配时，内核需要知道这个域名对应哪个地址，才能判断它是否落在某个网段、ASN 或国家代码里。Mihomo 官方路由文档说明，这一步可能触发 DNS 解析。

在目标 IP 规则末尾加上 no-resolve，就是告诉内核：当前没有目标 IP 时，不要为这条规则临时去查。它会继续看后面的规则，而不是把这条域名请求直接判为 DIRECT 或 REJECT。

加了以后，规则仍可能命中

no-resolve 不是“禁止使用 IP”。几种请求放在一起就容易看清：

到达规则时已有的信息	这条目标 IP 规则会怎样
目标本来就是一个 IP	可以直接判断，无需 DNS
只有域名，也没有已有解析结果	跳过为当前规则主动解析，继续向下匹配
更早的匹配过程已经触发解析	仍可使用已有 IP 判断并命中

第三种情况由 Mihomo 官方文档明确说明。这也解释了为什么同一条 no-resolve 规则在两次连接里可能表现不同：区别可能来自到达它之前是否已经有可用的目标 IP，而不是选项被随机忽略。

规则顺序也会改变结果。靠前的域名规则已经命中时，后面的 IP 规则根本不会参与；靠前的目标 IP 规则若先触发了解析，后面的 no-resolve 规则仍可能使用那份结果。只截取一行配置，很难判断整条匹配链。

RULE-SET 还要看它装的是什么

RULE-SET 只是引用规则集合，集合内容并不都一样。官方文档把常见 behavior 分为 domain、ipcidr 和 classical：

domain 集合保存域名匹配项，不需要把它当成目标 IP 规则；
ipcidr 集合保存 IP 网段，匹配域名时才可能遇到本文讨论的解析问题；
classical 可以包含多类规则，需要看集合里的具体条目。

官方快捷配置在私网 IP 规则集上使用了 RULE-SET,private_ip,DIRECT,no-resolve。这是一个配置示例，不代表所有 RULE-SET 都该照抄同样的尾参数。把它加在域名集合后面，并不会把域名规则变成 IP 规则。

DNS 仍有请求，不等于选项无效

浏览器、操作系统或其他应用可能已经发起解析；配置若启用了 DNS 接管、TUN 或 fake-ip，Mihomo 的 DNS 模块也可能参与。代理节点使用域名时，还存在专门的节点地址解析路径。no-resolve 不负责选择这些请求交给哪一个 nameserver，也不会关闭缓存、DoH 或 IPv6 查询。

因此，看到 DNS 日志继续出现，最多只能说明还有解析发生，不能反推出当前这条 IP 规则一定触发了它。节点域名究竟交给哪组解析器，可对照Mihomo 四类 nameserver 的分工；担心真实解析路径暴露，则应按DNS 泄漏的判断方法核对出口，而不是给规则批量追加 no-resolve。

改动前要保留真正需要的命中

私网网段是最直观的取舍。一个公司内网域名可能解析到 10.0.0.0/8，并依赖 IP-CIDR 规则直连。若这条规则跳过解析、前面又没有对应的域名规则，请求就可能落到后面的代理或兜底策略。此时更合适的处理可能是补一条准确的内部域名规则，也可能是让这条 IP 规则保留解析能力；要看网络设计，不能一键决定。

排查时可以关注两个对照：日志显示最终命中了哪条规则，以及目标以域名和已有 IP 进入时结果是否不同。日志里的 DIRECT、REJECT、MATCH 只表示路由选择，含义可参考Clash 日志规则说明；它们本身不证明 DNS 成功或目标站已经响应。

如果规则来自远程订阅，不要直接修改会被下次更新覆盖的文件。确认确有需求后，把最小改动放进客户端支持的扩展或合并配置，并保留原始配置作为对照；已有的自定义规则更新保留方法说明了这层区别。

判断一条规则是否需要 no-resolve，只需回答一个问题：它必须拿到域名对应的目标 IP 才能完成预期分流吗？不需要时可以跳过这次匹配解析；需要时，解析本来就是规则逻辑的一部分。DNS 使用哪条上游、是否经过预期出口，则要在 DNS 配置和实际请求路径里另行判断。

资料来源

以下来源于 2026/8/21 复核。版本、支持平台和发布状态以后续官方页面为准。

持续更新

收到新教程，也欢迎纠错

想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。

关注 TG 频道 Telegram 纠错邮件纠错

读者互动

这篇内容对你有帮助吗？

— 次访问— 累计日独立访问— 条评论

直接说出你的问题