故障排查 预计阅读 12 分钟

Clash DNS 泄漏怎么查：检测结果解读与 fake-ip、nameserver-policy 防泄漏设置

讲清 DNS 泄漏检测页面上各项结果的含义，对比 fake-ip 与 redir-host 的差异，并给出 nameserver、fallback 与 nameserver-policy 的实操配置思路。

一、先明确 DNS 泄漏的判断标准

浏览器显示代理出口 IP，并不代表域名解析也经过同一条路径。一次访问至少涉及两类请求：解析域名的 DNS 请求，以及连接目标服务器的业务流量。Clash 的系统代理、TUN 接管、内核 DNS 和浏览器安全 DNS，分别作用于不同环节，排查时需要把它们拆开。

本文将“DNS 泄漏”限定为：本应交给指定解析器或代理路径的查询，实际被发送给了预期之外的解析器。例如，要求境外网站的域名通过代理解析，却在检测中持续出现本地宽带运营商的递归 DNS，这才是需要追踪的异常。若配置本来就让本地域名走运营商解析，出现对应结果并不意外。

先写下预期，再看检测结果：哪些域名允许本地解析，哪些需要代理解析，浏览器是否允许自行使用 DoH。没有这三项边界，单凭“检测到了几个国家”无法判定泄漏。

检测页实际能看到什么

检测项目可以说明什么不能直接证明什么
网页出口 IP当前网页连接对外呈现的地址系统中所有应用都经过代理
DNS 服务器 IP检测域名的权威服务器观察到的递归解析器出口本机直接连接的 DNS 上游就是该地址
国家与运营商名称地址数据库提供的归属参考解析请求真实经过的全部网络路径
出现多个解析器可能存在并行查询、集群出口或多个上游数量超过 1 就一定泄漏

公共 DNS 通常采用 Anycast 和分布式递归集群。客户端连接的是一个服务地址，检测页展示的可能是另一个递归出口，国家标注也可能滞后。因此，代理出口在日本、DNS 结果标为美国，并不能单独作为泄漏证据；应结合解析服务提供商、配置中的上游和实际连接日志判断。

二、用固定步骤复测，区分系统与浏览器

先记录当前内核名称、客户端版本、已启用配置、代理模式、系统代理和 TUN 开关。以下配置以 mihomo 为对象，旧 Clash 内核不一定支持全部字段。Clash Nyanpasu 不同版本的设置分组可能变化，找不到选项时，应检查最终生效配置，而不是只看订阅原文件。

  1. 建立基线：在允许直连测试的网络中，关闭系统代理与 TUN，运行一次 DNS 检测，记录网页出口、解析器 IP 和服务商。对查询隐私有严格要求时可跳过直连基线。
  2. 只开启系统代理：保持浏览器设置不变，再测一次。系统代理主要覆盖遵守代理设置的应用，不等于接管系统的 UDP 53 查询。
  3. 开启 TUN 与 DNS 劫持：确认内核启动成功，再重复检测。如果这一步结果才改变，优先排查此前未进入内核的 DNS 流量。
  4. 临时统一浏览器 DNS：记录原设置后，暂时关闭浏览器安全 DNS，再测一次。Chrome 可在「设置」→「隐私和安全」→「安全」中查找「使用安全 DNS」；组织策略可能锁定该选项。
  5. 重复两轮：每轮重新触发检测，不只刷新旧结果页。必要时清理缓存并重启浏览器，避免把历史解析结果当成当前路径。

浏览器 DoH 是通过 HTTPS 进行的域名解析。它可能绕过 mihomo 的 DNS 模块，但其 HTTPS 连接仍可能被代理或 TUN 接管。因此，“绕过内核 DNS”和“查询直接发往本地运营商”不是同一件事，需要分别确认。

用命令确认内核 DNS 是否响应

假设内核 DNS 监听在 127.0.0.1:1053，可用下面的命令直接查询。Windows 的 PowerShell 清缓存命令需按系统权限执行；安装了 dig 的系统可以用第二条查询。此处的 example.com 是诊断域名，不是代理节点。

# Windows PowerShell：清除系统 DNS 缓存
Clear-DnsClientCache

# 安装了 dig 的 macOS / Linux：直接查询内核 DNS
dig @127.0.0.1 -p 1053 example.com A

# 再查询 IPv6 记录，分别观察结果
dig @127.0.0.1 -p 1053 example.com AAAA

在 fake-ip 模式下，普通 A 查询可能返回 198.18.0.0/16 范围内的地址，这通常是正常映射，不是 DNS 污染。命中 fake-ip 排除规则、特殊域名处理或缓存时，返回行为可能不同。命令查询成功只证明这个监听端口可用，不能证明浏览器或系统默认查询已经指向它。

三、fake-ip 与 redir-host：差别在解析时机

模式返回给应用的地址排查重点
fake-ip普通查询可获得虚拟地址，内核维护域名映射后续连接必须回到内核，排除列表应保持精简
redir-host通常返回上游解析得到的真实地址上游解析质量、域名关联与 IP 规则的匹配结果

fake-ip 让内核在收到应用连接后，通过虚拟地址找回域名，再按规则决定出口。对于由远端代理解析目标的连接，本地可能无需先取得目标真实 IP；但直连、IP 规则判断以及部分协议场景仍可能需要解析。它并不是“开启后所有 DNS 都自动走代理”的开关。

redir-host 更接近传统的真实地址解析流程。它可以配合可靠的加密上游工作，同样不能仅因使用此模式就判定存在泄漏。选择模式时，应以应用兼容性、连接是否完整接管和规则需求为依据，而不是把模式名称当作隐私等级。

不要用大范围排除来修复单个应用

某个局域网服务、游戏或设备发现功能不兼容 fake-ip 时，可以对具体域名设置 fake-ip-filter。不要一开始就排除整个常用公共后缀。排除越宽，越多请求会回到真实解析路径，原先依赖虚拟映射的行为也会改变。切换模式后应重启相关应用，避免其继续使用旧的虚拟地址缓存。

四、nameserver、fallback 与策略解析配置

先区分三个字段的职责：nameserver 是常规解析上游；nameserver-policy 为匹配域名指定上游；fallback 与过滤条件配合选择解析结果。它们决定“向谁问”，并不天然决定“经哪个出口去问”。加密 DNS 解决传输方式，代理路由解决连接路径，两者需要分别配置。

先建立可验证的 DNS 基线

下面是需要合并进现有配置的 DNS 片段，不是完整订阅。使用 IP 形式的 DoH 地址，便于减少上游域名的引导解析依赖。网络若无法直连所列服务，需要进一步设置代理路径；不要把超时误判成 YAML 解析错误。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  • default-nameserver 主要用于解析 DNS 上游自身的域名，不等于所有目标域名都交给它。这里的 223.5.5.5 是明文引导解析器；若要求连引导查询也加密，应使用当前内核支持且可达的加密引导上游，并实际验证。
  • listen 只监听回环地址，避免将这个示例直接变成局域网开放解析服务。系统 DNS 设置通常不能填写 1053 这样的自定义端口，需要接管机制或本机转发。
  • ipv6: false 控制内核 DNS 的 AAAA 响应，不会关闭操作系统 IPv6，也不能阻止应用访问已知 IPv6 地址。IPv6 连接仍须由路由或 TUN 正确处理。

用 nameserver-policy 分开局域网与公共域名

下列片段放在同一个 dns 对象下。示例假设路由器 DNS 为 192.168.1.1；实际地址应从当前网络获取。PROXY 必须是现有配置中的真实策略组名称，大小写也要一致，否则应改为实际组名后再应用。

  nameserver-policy:
    "+.lan":
      - 192.168.1.1
    "+.github.com":
      - "https://1.1.1.1/dns-query#PROXY"

+.github.com 匹配该域名及其子域名。引号中的 #PROXY 是 mihomo 支持的 DNS 上游出站指定写法，使这条 DoH 连接使用指定策略。该组如果选中 DIRECT，请求依然直连；选择了不可用节点则会超时。策略解析只覆盖列出的域名，不会自动覆盖所有公共网站。

fake-ip 排除列表和策略解析不是同一功能：前者影响返回虚拟地址还是走真实解析，后者选择解析上游。将 *.lan 加入排除列表后，还需要确保对应的局域网解析器确实知道这些记录。

fallback 不是单纯的超时备用

配置 fallback 后，内核可能并行进行解析，并依据 fallback-filter 判断采用哪个结果。不要认为主解析器可用时，fallback 就绝不会收到域名查询。下面仅展示一种依赖 GeoIP 数据的结果筛选方式，不要求与前面的最小配置一起启用。

  fallback:
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

这一示例以 GeoIP 的 CN 判定和指定网段过滤辅助选择结果。数据库过旧、CDN 地址归属变化，都可能影响选择。fallback 也不是默认代理通道；其 HTTPS 连接仍按实际出站设置运行。如果目标是缩小查询接收方范围，先用单一明确上游排查，再考虑是否需要增加 fallback。

五、TUN 接管与 DNS 出站：补齐两段路径

第一段是应用到内核，第二段是内核到上游。只设置 dns.enable 不会自动让所有应用使用内核 DNS；只开启 TUN，也应检查 DNS 劫持是否实际生效。下面是常见 mihomo TUN 片段，启用前需确认客户端已获得必要的系统权限，且没有与其他 VPN 的路由冲突。

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

这里覆盖的是进入 TUN 的普通 UDP/TCP 53 流量。浏览器 DoH 使用的通常是 HTTPS 443，DoT 常用 853，它们不会因为配置了 53 端口劫持就自动交给内核 DNS。部分系统的局域网路由、接口绑定和多网卡行为也会影响接管，必须结合日志和复测确认。

需要让 DNS 遵循路由规则时

mihomo 的 respect-rules 可让 DNS 上游连接遵循路由规则。启用时还应配置 proxy-server-nameserver，给代理节点域名提供独立解析入口，避免“先连代理才能解析、先解析才能连代理”的循环依赖。

  respect-rules: true
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

这两行同样属于 dns 对象。示例中的节点域名解析入口应在代理尚未建立时可达；如果当前网络无法直连它，需要改用本网络可达的入口，并接受相应的解析可见范围。不要将所有 DNS 上游都强行指向一个尚未能建立连接的代理组。

合并配置时只保留一个 dns 顶层键。不要逐块追加多个同名段落。订阅更新还可能覆盖手工修改，应通过客户端支持的覆写或合并机制保存，并在重新加载后核对最终配置。具体入口随客户端版本变化，可结合使用指南确认操作方式。

六、按症状定位，并完成最后一次复测

现象优先检查下一步动作
网页已走代理，仍出现本地运营商 DNS系统查询未接管，或引导解析与策略直连核对 TUN、53 劫持和各上游出站
只在一个浏览器出现不同解析器浏览器安全 DNS、扩展或独立代理设置临时统一设置后重新检测
启用 respect-rules 后全部解析超时节点域名解析循环、组名错误、上游不可达先验证 proxy-server-nameserver 的可达性
局域网域名失效公共上游不知道内网记录添加精确策略和必要的 fake-ip 排除
关闭 IPv6 DNS 后仍看到 IPv6 连接应用缓存、硬编码地址、系统 IPv6 路由清理缓存并检查 IPv6 接管情况

检查日志时，围绕刚发起的查询观察三件事：内核是否收到请求、选中了哪个上游、该上游连接走哪个策略。DoH 请求在连接面板中通常表现为到解析服务的 HTTPS 连接，不能仅凭一条 443 连接就认定业务网站走错出口。必要时短时提高日志级别，完成排查后恢复，分享日志前删去订阅地址、凭据和私人域名。

  1. 保存配置后重新加载内核，确认没有未知字段、YAML 缩进或端口占用错误。
  2. 用 dig @127.0.0.1 -p 1053 验证监听，再用真实浏览器访问验证完整接管。
  3. 重复 DNS 检测，分别记录普通窗口、另一浏览器以及 IPv4/IPv6 的结果。
  4. 逐项恢复原有浏览器安全 DNS、应用和网络环境，找到造成结果变化的具体设置。
  5. 重启客户端或更新一次订阅后复测，确认覆写仍然保留，而不是只在本次运行中有效。

最终目标不是让检测页只剩一个地址，而是让每类查询符合预先设定的路径：局域网域名交给内部解析器，需要代理的域名按指定策略解析，节点域名有可用的引导入口。把接管、上游和出站这三层分别验证，比反复切换 fake-ip 与 redir-host 更容易定位问题。

Clash 客户端下载