Clash DNS 泄漏检测方法与防泄漏配置：Fake-IP 与 nameserver 设置

DNS 泄漏判断：先定义预期解析路径

Clash DNS 泄漏通常指域名查询没有经过预期的解析路径。例如，业务连接已经走代理，但系统仍把查询发送给路由器或运营商 DNS。网页可以正常打开，出口 IP 也可能是代理节点，域名查询却走了另一条链路。因此，“网页能访问”和“DNS 已按配置处理”需要分别验证。

先明确目标：是让所有传统 DNS 查询进入本机内核，还是要求上游解析也通过代理出口？前者关注流量接管，后者还涉及 DNS 上游连接的路由策略。使用 DoH 或 DoT 只能说明查询链路被加密，不能单独证明查询从代理节点发出。

客户端：管理配置、系统代理、服务权限与界面开关。
内核：执行 DNS 解析、Fake-IP 映射、规则匹配与连接转发。
订阅：提供节点、规则或完整配置；更新时可能覆盖本地改动。
应用：可能使用系统解析器，也可能内置 DoH，绕过系统 DNS 设置。

检测步骤：出口、解析器与本机流量分开检查

第一步：建立关闭代理时的基线

在允许直接联网的测试环境中，关闭系统代理和 TUN，记录公网出口 IP、系统 DNS 地址，以及 DNS 检测页面列出的解析器归属。企业网络或受管理设备不宜擅自停用既定网络策略。基线只用于对照，不应把检测站显示的国家或城市直接当成泄漏结论。

Windows 可用 PowerShell 查看各网卡 DNS。无线网卡、以太网、VPN 和虚拟网卡可能同时存在；不能只看当前界面的第一项。

Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClientServerAddress -AddressFamily IPv6
ipconfig /all

第二步：启用配置后重复同一组测试

启用预期使用的系统代理或 TUN，确认当前配置与策略组选择。
重新检查出口 IP，记录浏览器是否启用了“安全 DNS”。
运行 DNS 检测，记录解析器 IP、归属和测试时间，而不是只保存“通过”提示。
在客户端连接记录或调试日志中查找上游 DNS 连接，核对目标地址和实际出站策略。
更换一个未缓存的域名重复查询，避免把缓存命中误判成 DNS 没有工作。

公共 DNS 可能采用任播和分布式出口。检测页面显示的解析器位置不一定等于连接入口位置，也不必与代理节点城市完全一致。若配置本来就要求部分域名使用本地解析器，出现本地解析结果也可能是预期行为；关键是结果能否与域名策略和出站记录对应。

第三步：用明确的本地端口验证内核

假设内核监听 127.0.0.1:1053，可用支持指定端口的 dig 验证解析服务。下面的 1053 是本文示例端口，不是所有客户端的默认值；系统没有安装 dig 时，不必为测试强行更换工具。

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

直接查询本地监听端口成功，只能证明内核 DNS 可响应。还需要测试应用的真实请求，才能确认系统 DNS、TUN 劫持和浏览器解析行为均符合预期。Windows 的 nslookup 默认使用 53 端口，不能把针对默认端口的失败直接归因于监听在 1053 的服务。

Fake-IP：保留域名映射，不等于加密 DNS

enhanced-mode: fake-ip 让内核为适用的域名返回虚拟地址，并维护域名与虚拟地址的映射。应用随后连接该地址时，内核可以恢复域名，进行规则匹配或向代理出站传递域名。真实地址可能在后续连接阶段才需要解析，也可能由远端代理服务处理，取决于协议与出站实现。

常见的 Fake-IP 地址池是 198.18.0.1/16。这个范围用于虚拟映射，不是节点公网出口。查询返回其中一个地址通常是模式正常工作的表现，不应把它填入远程服务器地址或手动添加到系统公网 DNS 列表。

设置	直接作用	不能单独保证
`fake-ip`	返回虚拟地址并保存域名映射	上游查询加密或经代理出站
`redir-host`	向应用返回实际解析地址	应用 DNS 一定进入内核
`fake-ip-filter`	让匹配域名按过滤规则处理，常用于返回真实地址	替代代理分流规则

局域网发现、部分设备管理页面或依赖真实地址的应用可能需要例外。先限定到具体域名，再考虑扩大范围。把大量公共域名加入 Fake-IP 过滤列表，会改变解析行为，也会使排查结果更难解释。过滤列表控制 DNS 返回方式，rules 控制连接的出站，两者不能互相替代。

nameserver 配置：区分业务解析与启动解析

下面是一段用于理解字段的 mihomo DNS 配置，不是完整订阅。保留现有的节点、策略组与规则，将对应字段合并到实际生效配置；同一个 YAML 层级只保留一个 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"
    - "localhost"
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

listen：绑定回环地址，避免把解析服务直接暴露给局域网。若确需供其他设备使用，还要单独配置访问边界。
default-nameserver：主要用于解析 DNS 上游自身的域名，解决启动阶段“先知道解析器地址”的问题。
nameserver：常规域名解析的上游列表；实际处理还会受到域名策略等字段影响。
proxy-server-nameserver：用于解析代理节点域名，帮助避免节点解析依赖尚未建立的代理链路。
ipv6: false：限制该 DNS 模块的 IPv6 解析响应，不等于关闭操作系统 IPv6，也不等于阻断所有 IPv6 连接。

不要为了让 DoH 连通而关闭证书验证。优先检查系统时间、上游地址、网络可达性与引导解析。若要求 DNS 上游也遵循分流规则，mihomo 可使用 respect-rules 等配置，但必须同时处理节点域名解析和 DNS 上游的出站依赖。仅增加 respect-rules: true 而不核对规则，可能形成解析循环，或仍然命中直连策略。

fallback 与域名策略：备用解析不是失败后才启动

fallback 容易被误解为“第一个 DNS 超时才请求备用 DNS”。在使用 fallback 的常见解析流程中，内核可能同时向主解析器与 fallback 发起查询，再依据 fallback-filter 选择结果。因此，把某个公共解析器放入 fallback，并不意味着它平时收不到查询。

fallback-filter 可以依据地理信息、地址段或域名等条件影响结果选择。地理数据库可能过时，CDN 也会返回跨地区地址；不能把某个地区代码当成通用的污染判定标准。排障时先使用一组可验证的上游，再按需求引入 fallback，通常比同时堆叠多个解析器更容易定位问题。

指定域名上游：nameserver-policy

局域网域名通常需要内网 DNS。下面示例将 +.home.arpa 交给 192.168.1.1；只有该地址确实是当前网络的内网解析器时才适用。它属于明确保留的本地查询路径，不应再以“全部查询都从代理节点发出”为验收标准。

dns:
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1

这段只是字段片段，应合并进前一段已有的 dns 映射，不能直接在文件末尾重复追加。对需要真实内网地址的域名，还要检查 Fake-IP 过滤策略。域名解析走内网并不自动决定业务连接走内网，连接规则仍需允许相应的局域网访问。

TUN DNS 劫持：接管 53 端口，不等于接管全部解析

系统代理主要影响遵循代理设置的应用，不负责统一接管系统 DNS。TUN 通过虚拟网卡和路由接管流量，配合 dns-hijack 才能把匹配的传统 DNS 请求送入内核。以下片段需要客户端服务权限及对应平台支持；应与已有 TUN 配置合并。

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

any:53 用于匹配 UDP 53 查询，tcp://any:53 补充 TCP 53。具体接管效果仍受操作系统路由、TUN 栈、排除网段与其他 VPN 影响；尤其是指向局域网 DNS 的请求，应以实际抓包确认是否进入 TUN。网卡切换后也要重新测试，不能只验证启动时的单一网络。

需要单独处理的三类流量

浏览器 DoH：通常表现为 HTTPS 443 连接，不会被 53 端口劫持规则自动改写。排查时临时关闭浏览器安全 DNS，或把它纳入明确的加密解析方案。
DoT 与其他加密解析：DoT 常用 TCP 853；应用内加密 DNS 需要按实际协议和出站连接检查。
IPv6 与多网卡：IPv4 已接管并不能证明 IPv6 同样接管。检查 IPv6 路由、DNS 地址和客户端支持，不要仅依赖 dns.ipv6 开关。

抓包时可用 udp.port == 53 || tcp.port == 53 作为 Wireshark 显示过滤器。物理网卡上持续出现发往非预期解析器的明文 DNS，是值得追踪的信号；回环或虚拟网卡上出现被接管前的查询，不一定表示已经外泄。过滤器看不到 DoH 的具体查询内容，也不能证明其他端口没有解析流量。

排障顺序与配置验收

现象	优先检查	验证方法
本地 1053 端口没有响应	DNS 开关、端口冲突、配置加载错误	检查内核启动日志和端口监听
本地查询正常，浏览器结果不同	浏览器安全 DNS、缓存、扩展代理	统一解析设置后用新域名重测
开启 TUN 后所有域名超时	权限、上游可达性、解析循环	先验证节点域名与上游启动解析
公网正常，内网名称失败	域名上游策略、Fake-IP 过滤、局域网规则	分别查询内网 DNS 和内核 DNS
订阅更新后问题复现	覆写顺序与生效配置	对比更新前后的 DNS、TUN 字段

修改解析模式或上游后，应清除相应缓存再复测。Windows 可执行 ipconfig /flushdns 清理系统缓存；浏览器与内核可能还保留独立缓存，需要通过各自的清理入口或重启处理。已有连接不一定重新解析，测试时应新建连接，避免只刷新一个长期保持连接的页面。

配置有效：内核成功加载，DNS 监听地址和端口与测试命令一致。
接管有效：真实应用的传统 DNS 按预期进入内核，例外路径有明确用途。
上游有效：能够解释业务解析、启动解析与节点域名解析分别使用哪个上游。
出站有效：需要经过代理的 DNS 上游连接，实际命中正确策略，而非仅凭 DoH 地址推断。
重启后有效：重启客户端、更新订阅和切换网络后重复检测，确认配置持久化。

DNS 防泄漏不是一个开关，而是应用解析方式、系统路由、内核配置与上游出站的组合。Fake-IP 解决域名映射问题，nameserver 决定解析服务，TUN 劫持负责接管符合条件的请求。把三者分别验证，才能判断异常发生在哪一层。更多概念可查阅Fake-IP 协议参考；配置导入和覆盖方式见使用文档。