NT-03.1DNS 泄漏是什么,为什么代理已连上还会发生
DNS 泄漏指的是:流量转发走了代理,但域名到 IP 的解析请求没有经过代理,而是直接送到本机原有的 DNS 服务器(通常是运营商或本地路由器分配的地址)。这意味着即便网页内容通过代理传输,访问过哪些域名这条信息仍暴露在本地网络上,同时也可能因为解析结果不一致导致连接不稳定或被污染。
造成这种情况的根源通常有两个层面。一是系统代理模式下,操作系统只接管了应用层的 HTTP/HTTPS 流量转发,DNS 请求走的是独立的 UDP 53 端口,如果客户端没有专门处理这条通道,请求会绕过代理直接发出。二是即便客户端接管了 DNS,如果 dns 配置段里的 nameserver 仍指向本地或运营商地址,解析结果照样受本地网络环境影响,和"域名请求走不走代理"是两件需要分别确认的事。
Clash 与 Clash Meta(mihomo)内核都在配置文件里提供独立的 dns 配置段,通过 enhanced-mode 决定如何处理解析请求。理解这个字段的行为,是排查和修复泄漏的前提。
NT-03.2检测流程:先确认问题,再动配置
动手改配置前,先用一套可重复的流程确认是否真的存在泄漏,避免凭感觉调整参数。以下步骤在任意平台的客户端上都适用。
- 断开代理,记录一次本机的 DNS 出口地址(可在系统网络设置里查看当前网卡使用的 DNS 服务器)。
- 连接代理并确认策略组已选中可用节点,打开客户端日志面板,过滤关键字
DNS或resolve,观察解析请求的输出。 - 访问一个会回显请求来源信息的检测页面,对比两次结果:代理开启前后返回的解析服务器地址是否一致。若开启代理后仍显示本机运营商的 DNS 出口,即为泄漏。
- 在客户端的连接面板(Connections)里查看当前活跃连接的目标地址,确认解析出的 IP 是否落在预期的代理网段内,而不是被解析成了本地网络能直接触达的地址。
- 切换 TUN 模式重复上述步骤,对照系统代理模式下的结果,判断泄漏是否只在特定接管方式下出现。
只要代理开启后,解析请求的出口地址与代理关闭时保持一致,就说明这部分请求没有经过 dns 配置段的处理逻辑,需要检查 enhanced-mode 与系统层的 DNS 设置是否被其他程序覆盖。
NT-03.3enhanced-mode 的两种取值与行为差异
dns 配置段的核心字段是 enhanced-mode,决定客户端如何把域名解析纳入统一处理,常见取值为 fake-ip 与 redir-host。
| 模式 | 解析行为 | 适用场景 |
|---|---|---|
fake-ip | 客户端返回一个虚拟网段内的假 IP,真实解析延迟到连接建立时按域名匹配规则再处理 | 默认推荐,配合 TUN 模式与规则分流,兼容性最好 |
redir-host | 直接向上游 nameserver 请求真实 IP 并返回给应用 | 部分应用对返回的 IP 有严格校验、无法使用假 IP 时的兼容选项 |
一段可用的 dns 配置示例如下,重点是让 nameserver 指向支持加密传输的地址,而不是继续沿用本机原来的解析服务器:
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "+.market.xiaomi.com"
nameserver:
- https://1.1.1.1/dns-query
- https://dns.google/dns-query
fallback:
- tls://8.8.4.4:853
其中 nameserver 是主解析列表,建议统一换成走 DoH(DNS over HTTPS)或 DoT(DNS over TLS)协议的地址,这样解析请求本身也会加密传输,不会被本地网络明文抓取。fallback 列表在主 nameserver 判断为污染结果时启用,同样建议使用加密协议地址。
NT-03.4fake-ip-filter 配置不当引发的局域网访问问题
启用 fake-ip 后,一个常见的副作用是局域网内的设备名解析(如路由器管理页面、NAS、打印机)也被替换成假 IP,导致无法访问。fake-ip-filter 字段用于声明哪些域名不走假 IP 解析逻辑,直接使用真实结果:
dns:
fake-ip-filter:
- "*.lan"
- "*.local"
- "localhost.ptlogin2.qq.com"
- "+.msftconnecttest.com"
- "+.msftncsi.com"
这里 +. 前缀表示匹配该域名及其所有子域名,* 为通配符匹配。如果发现某个局域网设备或需要精确出口 IP 的服务(例如企业内网办公系统)在开启代理后无法访问,优先检查它的域名是否需要补进这个过滤列表,而不是直接关闭 fake-ip。
把 enhanced-mode 直接改成 redir-host 能绕开假 IP 带来的兼容问题,但会削弱基于域名的规则分流能力,部分依赖 SNI 或 IP 段匹配的策略组规则可能因此失效。遇到兼容性问题,先尝试补充 fake-ip-filter,而不是整体切换模式。
NT-03.5系统代理模式与 TUN 模式下的差异排查
系统代理模式只接管应用主动读取系统代理设置的那部分流量,一些命令行工具、部分 UDP 通信、以及不遵循系统代理配置的程序,其 DNS 请求可能完全绕过客户端。这类泄漏无法单靠调整 dns 配置段解决,需要开启 TUN 模式,让虚拟网卡在网络层统一接管包括 DNS 查询在内的全部流量。
开启 TUN 模式后,还需确认以下两点,避免出现"接管了流量、却没接管解析"的半成品状态:
- 确认
tun配置段中dns-hijack字段已启用(常见取值为0.0.0.0:53或any:53),这一项负责在网络层拦截所有 53 端口的 DNS 请求并转交给内置 DNS 服务处理。 - Windows 与 macOS 上如果系统同时保留了原有网卡的 DNS 设置,某些程序可能优先走系统解析缓存,建议在确认 TUN 模式生效后清空一次本机 DNS 缓存再重新测试。
具体的 TUN 模式开启步骤和各平台差异,可参考站内关于虚拟网卡接管流量的专题说明,这里不重复展开。完成 dns-hijack 与 enhanced-mode 的配置后,重复本文第二部分的检测流程,直至代理开启前后的解析出口地址不再一致,即完成一次闭环验证。
NT-03.6配置调整后的复核建议
修改 dns 配置段属于影响面较广的操作,建议按以下顺序复核,减少因为配置错误导致的连接异常:
- 先在测试环境或备用配置文件中修改,确认无误后再应用到日常使用的 Profile,避免直接覆盖正在使用的订阅配置。
- 逐项检查
nameserver地址格式是否正确(DoH 地址需为完整 URL,DoT 地址需带tls://前缀与端口号)。 - 重新执行一次本文第二部分的检测流程,记录解析出口地址的变化。
- 观察一段时间的正常使用,确认局域网设备访问、企业内网服务等场景未受影响。
DNS 泄漏的排查本质上是确认"域名解析"这一步是否也被纳入了代理链路,而不仅仅是流量转发。把 enhanced-mode、nameserver 与 fake-ip-filter 三项配对检查清楚,多数泄漏问题都能在配置层面解决。