DNS 配置 预计阅读 12 分钟

Clash DNS 泄漏检测与防泄漏配置:fake-ip、nameserver-policy 实操

介绍 DNS 泄漏的成因与在线检测方法,给出 enhanced-mode、fallback 过滤、nameserver-policy 与 TUN 劫持 DNS 的配置写法。

DNS 泄漏的判断边界：解析路径与连接出口

Clash 能打开网页，不等于所有 DNS 请求都经过预期路径。浏览器可以通过 HTTP 代理发送连接，也可能提前调用系统解析器；后台应用可能忽略系统代理；浏览器的安全 DNS 又可能自行建立 HTTPS 解析连接。排查时必须分开记录两件事：域名交给谁解析，以及解析请求通过哪条线路发出。

本文把“DNS 泄漏”限定为：本应进入指定解析链路的域名查询，实际交给了本地网络、运营商或其他非预期解析服务。主动为国内直连业务指定本地解析器，不应只因检测页显示国内地址就判为泄漏。判断依据是事先定义的分流目标，而不是结果里有没有某个国家名称。

观察结果实际含义下一步核对
网站出口已变化当前网页连接走了代理另查 DNS，不能据此推断解析出口
检测到运营商解析器测试域名最终由该递归服务查询检查系统 DNS、浏览器安全 DNS 与分流策略
检测到多个解析器可能存在并行查询、转发或多个出口对照 nameserver、fallback 及测试条件
查询得到 198.18 段地址可能已命中 Fake-IP 映射继续核对流量是否回到同一个内核

检测前准备：固定客户端、浏览器与网络条件

下面的配置以 mihomo 内核为对象。Clash Meta 是其历史名称；旧 Clash 原版及停更客户端不一定支持全部字段。先从客户端的“关于”或内核信息页记录内核名称、版本号，再导出当前配置。客户端版本与内核版本要分别记录，不能只写“Clash 最新版”。

  1. 保留回退入口。导出订阅配置与本地覆写；记下系统代理、TUN、浏览器安全 DNS 的原始开关状态。
  2. 固定测试样本。同一网络、同一节点、同一浏览器下比较，测试期间暂停其他 VPN 与代理工具。
  3. 先排除浏览器独立解析。Chrome 可在“设置”→“隐私和安全”→“安全”查找“使用安全 DNS”；Firefox 可在“设置”→“隐私与安全”中查找“基于 HTTPS 的 DNS”。菜单名称可能随版本调整。
  4. 确认配置生效位置。订阅原文件可能在更新时被替换。应通过客户端提供的本地覆写或合并入口持久化修改，并检查最终运行配置。

在线 DNS 泄漏检测：对照测试而非只看地理位置

可以打开 DNSLeakTest，先运行 Standard test，再运行 Extended test。检测站通过随机子域名观察递归解析器对权威服务器的查询，因此结果通常是解析服务的出口，不一定是系统设置里填写的服务器地址，也不是代理节点地址。

三组结果应如何记录

  1. 基线：关闭客户端代理接管后检测一次，记录解析器 IP、运营主体与当前网络。
  2. 系统代理：开启客户端系统代理，保持 TUN 关闭，再检测一次。若结果没变化，只说明这条测试路径仍可能使用原解析链路。
  3. TUN 接管：启用下文 DNS 与 TUN 配置后检测，记录同样字段，并在客户端连接面板中检查解析连接。

每组建议执行 2 次。结果不一致时，先检查缓存、浏览器安全 DNS 和多个上游并发，不要立即换节点。公共解析服务可能使用任播与分布式出口；检测页面标注的国家或城市可能不准确。应重点比较运营主体是否符合预期，以及关闭某条解析路径后结果是否随之变化。

在线检测仅覆盖浏览器触发的测试查询，不能证明系统中每个应用都已接管。还需执行本机查询，必要时观察物理网卡流量。不要把含订阅链接、访问域名或访问令牌的完整日志直接上传到公共讨论区。

fake-ip 基础配置：先让域名与连接对应

Fake-IP 模式先给应用返回一个虚拟地址，再由内核依据映射恢复域名并匹配规则。它能减少部分连接建立前的真实解析依赖，但不是加密协议，也不会自动拦截所有 DNS。若应用拿到虚拟地址后绕过内核连接，反而可能出现超时。

以下为合并片段，不是完整订阅；现有代理节点、策略组与规则需要保留。若运行配置已包含 dns:，请合并其子字段，不要在文件末尾重复添加同名顶层键。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "+.qq.com":
      - https://dns.alidns.com/dns-query

示例暂时关闭 DNS 的 AAAA 返回，用于减少首次排查变量；这不等于关闭操作系统 IPv6，也不会阻止应用使用缓存的 IPv6 地址。需要 IPv6 的环境应恢复相应能力，并确认 IPv6 路由、DNS 与代理接管都完整，不能长期依靠单一开关掩盖路径问题。

fallback 过滤：选择答案，不是阻止查询外发

fallback 容易被误解成“主解析器超时后才访问备用服务器”。在常见配置中，主上游与 fallback 可能并行查询，再由过滤条件决定采用哪组答案。因此它可能让同一个域名被多组服务看到，不适合作为“只允许单一解析服务”的证明。

下面是偏向国内地址优先的独立配置示例。若采用此方案，应将这些字段合并到同一个 dns: 下；它与前面的单上游方案用途不同，建议先验证基础方案，再决定是否引入 fallback。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

此例会根据 GeoIP 条件判断主解析答案；不符合 CN 条件或命中所列地址范围的答案会触发采用 fallback 结果。实际行为依赖地理数据与内核实现，不能把 IP 地理分类当成域名可信度判断。跨国 CDN、企业服务与数据更新延迟都可能让选择结果偏离预期。

如果需求只是“几个明确域名用指定解析器”，优先使用 nameserver-policy，比扩大 fallback 条件更容易验证。对已命中专用解析策略的域名，也不要假定它仍会按默认主上游与 fallback 的组合处理，应查看当前版本文档和实际查询日志。

TUN 劫持 DNS：补齐系统代理覆盖不到的查询

系统代理主要服务于遵循代理设置的应用，并不等于系统 DNS 接管。TUN 通过虚拟网卡接收流量，再将匹配的 DNS 请求转交内核解析模块。下列片段可与前面的 DNS 基础配置合并，但能否创建虚拟网卡仍取决于系统权限、客户端服务与平台支持。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

any:53 用于匹配进入 TUN 的 UDP 53 请求，第二项补充 TCP 53。它们不是系统防火墙规则：只有实际进入内核接管路径的流量才有机会被处理。多网卡、虚拟机、容器、其他 VPN 与特定系统路由都可能改变这一前提。

53 端口之外的路径

启用后若整机断网，先关闭 TUN 恢复网络，再检查管理员权限或服务模式、默认出口网卡与路由冲突。不要同时打开多个客户端的 TUN，也不要为解决端口冲突直接把 DNS 服务暴露到 0.0.0.0；监听地址调整还涉及局域网访问控制。

本机验证与验收：配置生效、流量接管、订阅更新

先验证 1053 监听与 Fake-IP 返回

在已安装 dig 的系统上运行以下命令。显式指定端口可以直接测试内核 DNS，不依赖操作系统是否已经切换解析器。未安装该工具时，可使用客户端 DNS 诊断功能；普通 nslookup 默认访问的是 53 端口。

dig @127.0.0.1 -p 1053 www.wikipedia.org A
dig @127.0.0.1 -p 1053 www.qq.com A
dig @1.1.1.1 www.wikipedia.org A

前两条直接检查内核 DNS。在示例 Fake-IP 配置下，未被过滤的 A 查询通常返回 198.18.0.0/16 范围内的映射地址；这不能证明实际采用了哪个真实上游。第三条在 TUN 开启且 53 劫持生效时，也可能被内核截获，此时即使工具显示服务器为 1.1.1.1，也不能据此认定请求真的到达该地址。

再观察物理网卡与实际连接

需要进一步确认时，可以在 Wireshark 中选择实际联网网卡，以 udp.port == 53 || tcp.port == 53 || tcp.port == 853 过滤。观察测试期间是否有非预期明文查询离开物理网卡。此过滤条件不覆盖 DoH，也不能单凭“未见 53 流量”证明所有查询都经代理；加密上游的连接出口仍要结合客户端日志和连接面板确认。

  1. 清理旧缓存。Windows 可运行 ipconfig /flushdns；采用 systemd-resolved 的 Linux 可运行 resolvectl flush-caches。随后重启测试浏览器，避免旧连接干扰。
  2. 复跑在线测试。保持相同节点和浏览器设置，比较解析器运营主体与基线差异。
  3. 复测实际业务。检查国内网站、海外网站、企业内网与局域网设备，确认专用 DNS 策略没有破坏内部域名解析。
  4. 验证持久化。更新一次订阅并重启客户端，检查运行配置中的 dns、tun 与策略字段仍然存在。
下载Clash平台与客户端选择