代理已走节点，为什么还会 DNS 泄漏？检查 IP 规则的 no-resolve

代理客户端的连接日志显示 FINAL,PROXY，DNS 泄漏测试却仍显示本地网络的解析器。这两件事可以同时发生：网页连接走代理，不代表连接前的域名查询也走代理。

一个容易漏掉的触发点是 IP 分流规则。客户端为了判断某个域名是否落在指定 IP 段，可能先把域名解析成 IP。如果这次解析使用系统 DNS，查询就会到达本地路由器；即使后续 HTTPS 连接仍走代理，DNS 测试也能看到本地解析路径。

一次对照：连接都走代理，DNS 日志却不同

我们在同一台 Mac、同一浏览器和同一代理节点上，用 BrowserLeaks 的 IP 页面运行 DNS 检测。该页面会请求一组随机生成的测试域名，因此可以在客户端日志中逐条对照。

两份配置的通用 DNS 设置相同；其中一份额外加入两条指定 IP 直连规则，规则没有写 no-resolve。

这说明问题不在网页连接最终选择了哪个节点。差异发生在连接之前的域名解析阶段。客户端的内部决策没有做源码级追踪，但规则差异与两次日志吻合：没有 no-resolve 的 IP 规则需要考虑域名解析，而解析器恰好是系统 DNS。

no-resolve 改变了什么

假设某个规则集专门让一个 IP 地址直连。规则集里若这样写：

IP-CIDR,203.0.113.7/32

客户端检查一个域名请求时，可能先解析域名，再拿解析结果与这条 IP 规则比较。把规则改为：

IP-CIDR,203.0.113.7/32,no-resolve

就表示不要仅为了匹配这条 IP 规则而解析域名。示例中的 203.0.113.7 是文档示例地址，并非实际节点或检测服务器。上面是规则集文件的写法；若直接写在主配置中，通常还要按客户端语法加上策略字段。

no-resolve 只限制这条规则引发的解析。其他规则、应用本身、浏览器的安全 DNS 设置或系统网络设置仍可能产生 DNS 查询。因此，补上选项之后还要重新检测，不能把它当作通用的“防泄漏开关”。

遇到同样现象，怎样确认原因

先固定同一浏览器、网络和代理节点，再运行一次 DNS 检测。随后对照客户端的连接日志与DNS 日志：

1. 找到检测生成的随机域名，确认网页连接命中了哪条策略。显示 PROXY 只能证明连接路径。
2. 在 DNS 日志中查同一批域名。如果它们被发往路由器或系统 DNS，就找到了本地解析的证据。
3. 检查靠前的 IP-CIDR、GEOIP 和被引用的规则集，重点看 IP 类规则是否缺少客户端支持的 no-resolve 选项。
4. 修改规则后刷新远程规则集或重新载入配置，再用新一批随机域名复测。仅保存文件、没有让客户端加载新规则，测试结果不会改变。

本例的解析器是系统 DNS，所以额外的 IP 规则触发查询后，请求进入本地网络。两份配置都有相同的系统 DNS 设置，单看这一行找不到差异；把规则顺序、DNS 日志和连接日志放在一起，才看清了原因。