DNS 配置 预计阅读 12 分钟

Clash DNS 泄漏检测方法与 fake-ip 防泄漏配置实操

先用检测页判断解析请求是否外泄,再逐行讲解 dns 段的 enhanced-mode、nameserver 与 fallback 设置,给出可直接套用的示例。

先确定 DNS 泄漏的判断边界

DNS 泄漏，是解析请求走了不符合预期的出口。例如，目标是让某个网站的访问与域名解析都经过代理，但检测发现解析仍由本地运营商完成。网页能够打开，并不能证明 DNS 路径正确；启用了 fake-ip，也不能直接得出“解析不会外泄”的结论。

排查时，把三个环节分开看：应用向谁查询、Clash 内核如何处理查询、内核通过哪条连接访问上游 DNS。fake-ip 主要改变第二个环节：先向应用返回一个映射地址，内核再根据连接找回域名并执行分流。它不是加密协议，也不会自动接管所有应用。

  • 系统代理：主要影响遵循系统代理设置的应用，不等同于接管系统的全部 DNS 请求。
  • TUN 模式：可以接管更多网络流量，但仍要核对路由、DNS 劫持、IPv6 与其他 VPN 的影响。
  • DoH：通过 HTTPS 传输 DNS 内容，减少沿途明文暴露；直连 DoH 和经代理访问 DoH，仍是两条不同路径。

本文配置面向 Clash Meta，也就是 mihomo 内核。旧版 Clash、不同客户端的覆写机制可能不支持相同字段。先在客户端的「关于」或内核信息页确认内核名称，再修改配置。

检测流程：先留基线，再比较代理状态

第一轮：记录本地网络的解析器

  1. 在可信的个人网络中测试，先退出其他 VPN，避免多套接管规则叠加。
  2. 关闭 Clash 的系统代理与 TUN。打开 DNS 泄漏检测网站，例如 DNSLeakTest，先执行 Standard test，记录解析器的 IP、运营机构和时间。
  3. 如果平时依赖代理连接网络，关闭代理后检测页无法加载，就跳过这一轮，不必为了得到基线修改路由器。

第二轮：启用代理并重复检测

启动当前配置，确认代理策略选择的是可用节点。再次运行同一检测，再执行 Extended test，观察是否出现第一轮的本地运营商解析器。另开一个网页确认出口 IP，分别记录“网页出口”和“DNS 解析器”，不要把两者合成一个指标。

检测现象可能原因下一步
网页走代理，解析器仍为本地运营商系统 DNS 未接管，或存在直连解析策略核对 TUN、53 端口劫持与实际生效配置
出现公共 DNS 服务商可能是内核上游，也可能是浏览器安全 DNS对照上游配置并临时关闭浏览器安全 DNS复测
解析器位置与节点位置不同公共 DNS 使用任播或不同出口结合机构与连接日志判断，不只看国家标签
检测超时，但缓存网页能打开新域名解析失败，旧连接仍可使用检查 DoH 连通性与代理节点域名解析

检测页能看到的是为其测试域名执行递归查询的解析器，并不能独立证明所有应用都遵守同一路径。更换浏览器、切换网络或开启另一个 VPN 后，结果也可能变化。不要仅凭一次测试的绿色提示结束排查。

fake-ip 配置：先核对策略组，再合并 DNS 段

下面是一个可合并到现有 mihomo 配置的 DNS 段，不是完整订阅文件。前提是现有配置包含名为 PROXY 的代理策略组，并且该组已经选中可用代理节点，而不是 DIRECT。如果实际组名为“节点选择”，把两处 #PROXY 改成 #节点选择。这里的后缀用于明确指定上游 DNS 连接的出站策略。

先备份原配置，再替换原有的顶层 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"
    - "localhost"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - "https://1.1.1.1/dns-query#PROXY"
  fallback:
    - "https://9.9.9.9/dns-query#PROXY"
  fallback-filter:
    geoip: false
    ipcidr:
      - 0.0.0.0/8
      - 127.0.0.0/8

此例把普通业务域名的上游查询显式送入 PROXY，但保留直连引导解析和节点域名解析。因此它不是“所有 DNS 都经过代理”的承诺。如果要求本地网络完全看不到任何明文 DNS，还需要单独设计引导解析路径，并验证节点在冷启动时能够建立连接。

enable、listen 与 enhanced-mode

enable: true 启用内核 DNS。listen: 127.0.0.1:1053 只在本机回环地址的 1053 端口监听，避免意外向局域网开放解析服务。仅写这个地址，不会自动把系统 DNS 指向它；多数系统 DNS 设置只能填写服务器地址，不能顺便指定 1053 端口。

enhanced-mode: fake-ip 启用映射模式。示例地址池位于 198.18.0.0/16，属于用于基准测试的保留地址空间，不是网站的真实公网地址。普通域名查询得到类似 198.18.0.2 的结果，可能是正常现象；这个地址只是说明形式，实际分配值不固定。

nameserver 与节点域名解析

nameserver 是普通查询的上游入口。示例使用 IP 形式的 DoH 地址，避免为这个上游地址再做一次域名解析，并用 #PROXY 指定代理策略。引号必须保留，避免 YAML 将带特殊字符的内容解释出错。

proxy-server-nameserver 用来解析代理节点的服务器域名。节点连接尚未建立时，不能要求其域名解析依赖同一个节点，否则会形成循环依赖。示例为这一步提供直连 DoH；default-nameserver 则为需要解析的 DNS 服务域名提供引导。它们的可见范围与普通网站域名查询不同，必须分别评估。

fallback 不是简单的超时备用

fallback 配合 fallback-filter 决定结果取舍，不能把它理解为“主 DNS 超时后才开始查询”。根据内核处理路径，两组上游可能并发查询。示例把两组都指定到 PROXY，避免备用上游成为未预期的直连出口。

这里关闭 GeoIP 筛选，只保留对指定异常地址段的结果筛选，避免默认地理判断改变预期。这个短列表不是完整的污染识别方案。fake-ip 返回映射地址，也不代表每次查询都会立即触发所有真实地址解析。如果只需要一个可信上游，可以删除 fallback 和 fallback-filter，先把链路简化。

TUN 与 DNS 劫持：让系统查询进入内核

DNS 段准备好后，还要解决“请求有没有进入内核”。对于希望接管系统普通 DNS 的桌面场景，可以在支持的 mihomo 客户端中启用 TUN。以下片段应与现有顶层 tun: 合并；如果客户端用界面管理 TUN，以界面生成的最终配置为准。

TUN 配置片段
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53
    - tcp://any:53
  • auto-route 让内核建立接管所需路由，通常需要管理员权限或客户端的系统服务。
  • dns-hijack 将已进入 TUN 的普通 UDP、TCP 53 端口查询交给内部 DNS；它不是对任意 DNS 协议的通用拦截器。
  • strict-route 可约束部分旁路行为，但不同系统效果有差异，也可能影响局域网访问或与其他 VPN 的兼容性。
  • 浏览器 DoH 使用 HTTPS，DoT 通常使用 853 端口，均不等同于普通 53 端口查询。它们还需要检查各自的连接路由。

多网卡、虚拟机、公司 VPN 与旁路由场景，不建议直接照搬自动路由片段。先确认默认出口网卡，并在日志里观察是否出现路由循环。如果开启后整个网络中断，先关闭 TUN 恢复网络，再逐项核对，不要同时修改 DNS、路由和节点。

验证配置：端口、映射与真实出口分别检查

先直接查询内核的 1053 端口

在已安装 dig 的 macOS 或 Linux 终端中执行下面的命令。它直接指定本机内核，不依赖系统 DNS 当前指向哪里。Windows 也可在交互式 nslookup 中设置端口测试。

macOS / Linux
dig @127.0.0.1 -p 1053 example.com A
Windows：依次输入
nslookup
server 127.0.0.1
set port=1053
set type=A
example.com
exit

没有命中过滤规则的普通域名，通常会返回地址池中的 A 记录。若超时，先查内核是否加载成功、1053 端口是否被占用，以及日志是否提示未知字段。若直接查询正常，但系统应用仍绕过内核，问题就在接管链路，而不是继续更换上游 DNS。

再清理缓存并观察连接

  1. Windows 可执行 ipconfig /flushdns 清理系统 DNS 缓存；浏览器还可能保留自己的缓存与连接，复测前彻底退出后重新打开。
  2. 在 Chrome 的「设置」→「隐私和安全」→「安全」中检查「使用安全 DNS」。为隔离变量，可临时关闭，测试后按自己的策略恢复。
  3. 查看客户端连接面板，核对到 1.1.1.1:443、9.9.9.9:443 的上游连接是否选择了预期代理。日志展示形式可能不同，不必要求每次查询都生成一条新连接。
  4. 再次运行 DNS 泄漏检测。先比较解析器机构，再结合出口和日志判断，不仅看地图上的位置。

系统设置与浏览器设置可能被组织策略管理。若是工作设备，先确认管理要求，不要通过关闭安全策略来强行完成测试。普通 DNS 检测也不等于 WebRTC 检测，网页暴露本地或公网地址的问题需要另行判断。

常见问题：IPv6、局域网与订阅覆写

设置 ipv6: false 后，为什么还有 IPv6 流量？

DNS 段的 ipv6: false 主要影响内核对 AAAA 查询的处理，不是关闭操作系统 IPv6 的总开关。应用缓存、硬编码 IPv6、浏览器自带解析或未被接管的网络接口，仍可能产生 IPv6 连接。需要保留 IPv6 时，应完整配置并测试接管；暂时不用时，也要同时核对系统与客户端设置，而不是只修改一个 DNS 字段。

打印机、NAS 或局域网域名打不开怎么办？

先区分域名解析问题和路由问题。fake-ip-filter 只让匹配域名不返回映射地址，不会自动将这些域名交给路由器 DNS。若局域网真实解析器是 192.168.1.1，可以在确认实际网段后，为内部域名配置 nameserver-policy。下面只展示合并字段，不要再次创建顶层 DNS 段。

合并到现有 dns 段
  nameserver-policy:
    "+.lan":
      - 192.168.1.1

这里的内网 DNS 查询是有意保留的本地解析，不应与公共网站的意外泄漏混为一谈。.local 常用于 mDNS，不能假定路由器的普通 DNS 一定能回答。若直接访问 NAS 的局域网 IP 也失败，应先检查 TUN 路由和防火墙。

订阅更新后，为什么结果又变了？

客户端可能重新生成配置，订阅也可能带入 nameserver-policy、额外 DNS 上游或其他分流字段。修改编辑器里的文件不代表运行内核已经使用它。每次更新后，核对实际生效配置中的 DNS、TUN 与策略组名称，再做一次简短复测。若采用 respect-rules 让 DNS 遵循规则，应单独设计对应规则及节点引导解析，不要与本文显式指定出站的方案混杂后凭感觉判断。

判断完成：保留一份可重复的检查记录

最后记录四项：使用的内核与配置、浏览器安全 DNS 状态、代理出口、检测到的解析器机构。合格的结果应与预先设定的边界一致：普通业务查询进入指定代理上游，必要的本地解析有明确用途，节点引导链路可解释。fake-ip 负责映射，TUN 负责接管，上游与出站策略负责解析路径，三者配合才构成可验证的配置。

下载客户端