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

先区分 DNS 泄漏与解析器地区差异

网页走代理，不代表 DNS 查询也走代理。系统代理通常只影响遵循代理设置的应用；系统解析、浏览器安全 DNS、其他程序自带的 DoH，都可能有自己的出口。修复需要分别确认“谁发起查询”“使用哪个解析器”“到解析器的连接走哪条策略”，仅切换 fake-ip 并不足够。

本文配置以 mihomo 内核为对象。旧版 Clash、不同客户端封装的字段支持不完全相同。先在客户端的内核信息或启动日志中确认名称；若配置检查提示未知字段，应对照当前内核文档处理，不要把同名开关视为相同能力。

• DNS 泄漏：原本希望经代理发送的域名查询，经本地网络发送给了运营商或其他非预期解析器。
• 解析器位置不同：检测页显示的国家通常来自解析器出口 IP 的数据库，不等于代理节点的真实位置。
• 有意直连：局域网名称、直连站点或代理服务器域名可能采用直连解析。是否接受这种查询，需要先明确自己的分流目标。

建立检测基线：浏览器、系统与内核分别检查

用同一测试条件比较两次结果

1. 暂停其他 VPN 和代理工具，固定一个代理节点。记录系统代理、TUN、浏览器安全 DNS 的当前状态。
2. 打开 DNSLeakTest，运行 Extended test。记录页面列出的解析器 IP、运营组织与地区。
3. 在能够接受一次直连测试的前提下，关闭代理再测一次，作为本地网络基线。恢复代理后重新测试，不要把旧标签页里的结果当作新结果。
4. 若代理开启后仍出现基线中的运营商解析器，继续排查。若只显示预期公共解析器，也仍需确认其连接究竟直连还是代理。

检测站主要看到递归解析器访问其权威 DNS 的出口，并不能独立证明“电脑到递归解析器”的传输路径。共享解析服务、Anycast 与缓存都会影响结果。因此，检测页要与客户端连接记录一起使用，不能只凭一个国家名称下结论。

临时统一浏览器的 DNS 路径

以桌面 Chrome 为例，进入「设置」→「隐私和安全」→「安全」→「使用安全 DNS」。为了先检查系统到 mihomo 的路径，可临时关闭这一项，测试完再决定是否恢复。受组织策略管理的浏览器可能无法修改该选项。

浏览器自带 DoH 使用 HTTPS，通常不是 UDP 53 流量。它在 TUN 下可能仍经代理传输，但不会因为设置了 dns-hijack 就自动改用 mihomo 的 DNS 模块。Android 的「私人 DNS」也应单独记录，避免把不同解析通道的结果混在一起。

确认内核 DNS 是否真正接收查询

下文示例把内核 DNS 监听在本机 1053 端口。安装了 dig 的 macOS 或 Linux 可以直接指定该端口测试：

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

Windows 可在 PowerShell 中执行下列命令，检查系统默认解析路径；它不等价于直接查询本机 1053 端口。开启 TUN 后，应同时观察内核 DNS 日志是否收到这次请求。

Resolve-DnsName example.com -Type A
Get-DnsClientServerAddress

fake-ip、nameserver 与引导解析分别负责什么

fake-ip 通常向应用返回映射地址，再由内核把后续连接关联到原始域名。示例使用的 198.18.0.1/16 属于用于基准测试的地址范围，不是实际网站的公网地址。查到这类地址并不表示网站解析损坏，也不证明上游查询已经受到代理保护。

fake-ip-filter 则决定哪些域名不返回 Fake-IP。某些局域网服务需要真实地址，可以按需添加例外；不要为了消除一个兼容性问题就把所有域名放进过滤列表。过滤影响返回地址的处理方式，不能替代上游路由设置。

配置上游 DNS：明确指定代理策略

下面是用于说明解析路径的 mihomo 配置片段，不是完整配置文件。它假设现有配置已经定义名为 Proxy 的策略组，且组内有可用节点。示例把常规查询和 example.com 测试域名的查询发往代理上游，同时保留明确的直连引导路径。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
  nameserver:
    - "https://1.1.1.1/dns-query#Proxy"
  nameserver-policy:
    "+.example.com":
      - "https://8.8.8.8/dns-query#Proxy"

• #Proxy 为该 DNS 上游指定已有出站策略。策略组名称必须逐字匹配，包括大小写；引号保证整个地址清晰地作为 YAML 字符串读取。
• +.example.com 匹配该域名及其子域名。这只是可复现的测试项，不是实际业务域名清单；上线前应按需要替换或删除。
• 示例中的 default-nameserver 是直连引导解析器，proxy-server-nameserver 也是有意保留的直连解析路径。节点服务器使用域名时，后者的查询会向该解析器披露节点域名。
• 示例使用 IP 形式的 DoH 端点，可减少解析上游主机名的依赖，但仍需网络可达、证书验证正常以及代理节点支持相应连接。

已有配置使用 respect-rules 时怎么处理

mihomo 的 respect-rules: true 可以让 DNS 连接遵循路由规则，但“遵循规则”不等于“必然代理”：规则将解析器目标匹配到 DIRECT 时，连接仍会直连。采用该方式时，需要设置合适的 proxy-server-nameserver，并检查规则对上游解析器地址的实际匹配结果。

先选一种容易验证的上游路由方式，再逐步整合。不要同时新增一组 fallback、多条策略与多层规则后才测试，否则很难定位哪一次修改改变了查询出口。也不要只在文件末尾再写一个 dns:；应编辑现有映射，避免重复键导致配置覆盖或加载失败。

TUN 接管系统 DNS：补上端口 53 的入口

只启用系统代理时，不使用代理设置的程序仍可能直接调用系统 DNS。TUN 可以接管更多 IP 流量，再配合 DNS 劫持把传统 DNS 请求送入内核。以下片段适用于支持相应 TUN 功能的 mihomo 环境，需要客户端获得创建虚拟网卡及修改路由的权限。

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

any:53 对应 UDP DNS，tcp://any:53 补上 TCP DNS。这里的劫持作用于进入 TUN 处理路径的连接，不是给整个局域网强制改 DNS。某些系统对访问本地网段 DNS 的路由有特殊处理，仍需通过实际日志确认请求是否进入内核。

• DoH 与 DoT：HTTPS DNS 常用 443 端口，DoT 常用 853 端口，不属于上述 53 端口劫持范围。应检查它们自身的出站策略。
• 多网卡：有线、Wi-Fi、虚拟机网卡和其他 VPN 可能改变默认出口。开启 TUN 后若断网，先确认自动识别的出口网卡。
• IPv6：dns.ipv6 控制 DNS 的 AAAA 响应行为，不是系统 IPv6 总开关。即使只测试 A 记录，也不能据此认定 IPv6 流量已被接管。
• 局域网：NAS、打印机与企业内网名称可能需要专用解析器。为这些域名单独设置策略，并把预期的直连查询纳入测试记录。

如果不准备使用 TUN，也可以在操作系统支持时把 DNS 指向内核监听地址，但普通系统 DNS 设置通常不能填写自定义端口。示例监听的是 1053，而不是系统常用的 53，不能只填 127.0.0.1 就期待自动连通。改监听端口还需考虑权限与端口占用。

保存、清缓存、复测：按顺序确认修复结果

先检查生效配置，再检查缓存

订阅管理客户端可能在更新时重建配置。应使用客户端支持的覆写或合并机制保存 DNS 修改，并查看最终生效配置，而不只是编辑下载后的临时文件。命令行部署可以先运行配置测试；二进制名称为 mihomo 时，命令如下：

mihomo -t -f config.yaml

测试通过后再重载。测试通过只表示配置可被内核接受，不保证节点、解析器或网络可达。若使用图形客户端，重载后查看启动日志中是否出现 DNS 监听失败、权限不足或策略组不存在等错误。

Windows 可清理系统解析缓存后重新查询。浏览器仍可能保留独立缓存或已有连接，必要时完全退出浏览器再打开检测页；移动设备则可断开并重新连接当前网络后复测。

ipconfig /flushdns
Resolve-DnsName example.com -Type A

三项证据同时核对

1. 入口证据：系统查询发生时，内核能收到 DNS 请求；直接查询 1053 端口与经系统查询要分开验证。
2. 路由证据：连接记录中，发往示例 DoH 端点 1.1.1.1:443 或 8.8.8.8:443 的连接使用预期代理策略。必要时临时使用 log-level: debug 排查，结束后恢复原日志级别。
3. 外部证据：重新运行检测页，解析器组织与预期相符，没有出现未计划使用的本地运营商解析器。地区不同本身不能判定失败。

调试日志可能包含访问域名、节点地址或其他网络信息。分享日志前应删除订阅链接、认证信息及不需要公开的域名；不要把完整配置直接贴到公开讨论区。

常见结果与下一步

最终验收标准是解析路径符合既定策略，而不是检测页只剩一个 IP。先明确哪些域名允许直连解析，再让系统入口、内核上游与代理路由相互对应，才能区分真实泄漏、正常分流和解析器显示差异。更多字段说明可查阅 配置进阶；基础启用步骤见 客户端配置教程。

配置依据与核对入口

• mihomo 文档：DNS 配置，核对上游解析、域名策略、Fake-IP 与代理服务器解析字段。
• mihomo 文档：TUN 入站，核对 DNS 劫持、自动路由及系统差异。
• DNSLeakTest 检测入口，用于观察递归解析器出口；结果需结合内核日志解释。