Clash DNS 泄漏怎么检测：浏览器测试、日志定位与防泄漏配置

先确定什么算 DNS 泄漏

访问网站时，应用通常先把域名交给 DNS 解析器，再使用返回的 IP 建立连接。代理连接已经经过 Clash，并不代表域名查询也经过了同一条路径。系统可能继续向路由器、运营商解析器或公司网络中的内部 DNS 发送请求。此时目标网站的正文流量走代理，域名查询却从本地网络发出，这就是排查 Clash DNS 泄漏时要关注的核心现象。

判断结果不能只看检测页面是否列出了多个 DNS 服务器。公共 DNS 服务会使用任播、转发集群和不同出口，检测站点看到的服务器地址未必等于配置中填写的地址。多个结果也可能属于同一家解析服务。更可靠的判断方法是同时核对解析器所属网络、地理位置、测试期间的 Clash 日志以及本机实际发出的 53、853 或 HTTPS 请求。

还要区分 DNS 泄漏、WebRTC 地址暴露和代理出口变化。WebRTC 测试可能显示局域网地址或公网候选地址，但它属于浏览器实时通信链路，不等于 DNS 查询绕过。代理出口检测显示本地公网 IP，则应先检查代理模式、规则命中和 UDP 接管，而不是直接修改 DNS。三类问题需要分别取证。

常见的泄漏表现

• 启用代理后，DNS 检测页面仍显示家庭宽带或移动网络运营商的解析器。
• 切换到其他地区的代理节点后，DNS 查询持续从本地网络直接发出。
• Clash 日志能看到网站连接，却看不到对应域名进入内置 DNS 模块。
• 浏览器与命令行测试结果不同，只有其中一个应用绕过了预期解析路径。
• 系统代理模式下网页流量正常，但本机抓包仍出现发往路由器的 UDP 53 请求。

浏览器测试、命令行查询与抓包要分层执行

浏览器 DNS 检测适合作为入口。此类页面通常生成一批随机子域名，迫使浏览器发起新查询，再由权威 DNS 端记录实际递归解析器。测试前应关闭其他正在联网的软件，清理操作系统与浏览器 DNS 缓存，并使用新的隐私窗口。缓存命中会跳过查询，让结果看起来比实际情况更干净。

执行标准测试与扩展测试后，先记录解析器 IP、网络运营方和国家或地区。预期结果取决于配置目标：如果 Clash 使用指定的远程 DoH，结果应对应那项服务的递归出口；如果按域名策略将国内域名交给本地加密解析、其他域名交给远程解析，检测结果可能出现两组服务。重点是每一组是否符合明确配置，而不是强求页面只出现一个地址。

用命令行区分系统 DNS 与指定解析器

浏览器可能启用自身的安全 DNS，因此还要测试操作系统解析路径。Windows 可使用 nslookup 或 PowerShell 的 Resolve-DnsName，macOS 与 Linux 可使用 dig。先查询一个此前没有访问过的域名，再查看命令输出中的服务器地址。若显示家庭路由器地址，例如局域网网关，则系统仍把查询交给路由器；这本身不代表查询最终一定泄漏，但说明 Clash 尚未直接成为该命令的 DNS 入口。

nslookup example.net

Resolve-DnsName example.net

dig example.net
dig @127.0.0.1 -p 1053 example.net

最后一条命令显式查询 Clash 或 mihomo 的本地监听端口，适合与系统默认查询作对比。如果显式查询符合预期、默认查询却仍走路由器，问题位于系统 DNS 指向或 TUN 的 DNS 劫持环节。如果两种查询都落到不期望的解析器，则继续检查内核配置和上游 DNS。

抓取端口与目标地址

需要确定本机是否向局域网或公网直接发送传统 DNS 时，可在测试窗口内抓取 UDP/TCP 53 流量。Linux 可使用 tcpdump，Windows 可借助系统网络跟踪工具，macOS 也可在活动接口上运行 tcpdump。接口名应按实际环境替换。

sudo tcpdump -ni any 'port 53 or port 853'

sudo tcpdump -ni en0 'udp port 53 or tcp port 53'

抓包中出现发往路由器或运营商 DNS 的 53 端口请求，是直接解析仍在发生的强证据。看不到 53 流量也不能立即结束排查，因为应用可能使用 DoH，将 DNS 封装进 443 端口的 HTTPS。此时要结合 Clash 连接日志、浏览器安全 DNS设置和目标地址判断。

沿系统、Clash 内核和上游解析器定位路径

DNS 路径可以拆成三个节点：应用把查询交给谁、Clash 是否接收到查询、Clash 又通过哪条网络访问上游。把这三个问题分别确认，比反复替换公共 DNS 地址更有效。

第一段：应用到系统或浏览器解析器

多数桌面应用调用操作系统解析接口，但浏览器可能启用独立 DoH，部分命令行程序也可直接查询指定服务器。系统代理只设置 HTTP、HTTPS 或 SOCKS 代理地址，通常不会自动改写所有系统 DNS。浏览器先在本地完成解析，再把目标交给代理，是系统代理场景中的常见路径。

如果只有浏览器测试异常，先检查浏览器的安全 DNS。它可以关闭后交给系统与 Clash 管理，也可以明确设置为与 Clash 方案一致的 DoH 服务。若多个应用同时出现本地解析请求，则优先检查操作系统 DNS、TUN 接管和客户端的 DNS 开关。

第二段：查询是否进入 Clash 内置 DNS

确认配置中的 dns.enable 已开启，并检查本地监听地址是否与客户端界面显示一致。部分图形客户端会从界面生成运行配置，订阅文件中的 DNS 字段可能被覆写。排障时应查看内核实际载入的配置，而不是只看订阅原文。

将日志级别临时调整为 debug，清空日志后查询一个随机子域名。日志格式因 Clash 分支和客户端而异，但应重点查找 DNS 查询、规则命中、上游请求失败、超时和回退选择。日志中完全没有该域名，说明请求尚未进入内核；出现域名但上游走了直连，则需要检查 DNS 上游的拨号路径。

第三段：Clash 到上游 DNS 的连接

即使查询进入内置 DNS，上游 DoH 或 DoT 也可能通过 DIRECT 访问。加密能够保护查询内容在传输中的完整性与可读范围，但上游连接仍会暴露解析服务的目标地址。若目标是让远程解析连接随代理策略转发，需要使用当前内核支持的代理指定方式，或启用基于规则的 DNS 上游连接，并为代理服务器域名准备独立的引导解析器。

代理节点本身若以域名填写，内核必须先获得节点服务器 IP，才能建立代理隧道。这个启动依赖不能再递归地要求通过尚未建立的代理连接。mihomo 中的 proxy-server-nameserver 就用于处理代理服务器域名解析；default-nameserver 则负责解析 DoH 上游自身的域名等基础任务。两者职责不同。

用 fake-ip、远程解析与回退策略收拢查询

在支持 Clash Meta 配置的 mihomo 内核中，fake-ip 是常用的增强解析模式。应用查询域名时，内置 DNS 先返回保留地址池中的映射地址。应用连接这个地址后，内核根据映射恢复原始域名，再执行规则匹配和代理选择。这样可减少应用提前在本地取得真实 IP 的机会，也有利于按域名规则分流。

下面是一份用于理解字段关系的基础片段。公共解析端点只是结构示例，部署时应根据所在网络的可达性、服务条款和隐私要求选择。不同客户端内置的 mihomo 版本可能支持不同语法，修改前应核对当前内核文档并保留原配置。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "time.*.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  respect-rules: true

listen 决定内置 DNS 的监听位置。只供本机使用时应结合客户端实现限制访问范围；TUN 模式下，客户端通常会自动管理监听与劫持。fake-ip-range 使用专门地址段维护域名映射，不应与本地局域网、容器网络或企业路由重叠。

fake-ip-filter 用来排除不适合 fake-ip 的域名。局域网设备发现、时间同步、部分游戏平台和依赖真实局域网地址的服务可能需要返回真实 IP。过滤项应从实际故障出发逐项添加。把大范围域名全部放入过滤列表，会让大量请求重新走真实 IP 解析，削弱 fake-ip 对解析路径的收拢效果。

respect-rules 让 DNS 上游连接遵循规则，但启用后必须保证代理服务器域名能够通过 proxy-server-nameserver 解析，否则可能出现内核为建立代理而等待 DNS、DNS 又等待代理的循环依赖。旧版 Clash 或部分维护停止的分支可能没有同名字段，应以实际内核能力为准。

nameserver-policy 精确指定域名解析器

如果不同域名需要不同解析路径，可使用 nameserver-policy。它的优先级通常高于通用 nameserver，适合为内网域名、特定规则集或地区域名指定解析器。策略过宽会导致检测页面出现多组递归出口，因此每条规则都应有明确用途。

dns:
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "+.internal.example":
      - 192.168.10.1
  nameserver:
    - https://1.1.1.1/dns-query

内部域名交给企业或家庭 DNS 时，对应请求会进入本地网络。这是有意设计的分流，不应与意外泄漏混为一谈。不过应避免让通配规则覆盖普通公网域名，也要确认内部解析器只在可信网络中使用。

理解 fallback，而不是机械复制模板

部分配置使用 fallback 与 fallback-filter。内核可并发查询主要和回退解析器，再依据地理 IP、域名类别或保留地址判断采用哪个结果。这套机制主要用于处理解析污染、错误结果或不同网络的可用性，并不天然保证 DNS 查询经过代理。

dns:
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    geosite:
      - gfw

如果主解析和回退解析都从本地直连发出，检测仍可能看到不期望的路径。配置回退时应同时核对上游连接如何路由、远程端点是否稳定以及规则集能否正常加载。现代 mihomo 配置也可通过 nameserver-policy 实现更明确的域名级选择，是否保留 fallback 应按场景决定。

TUN 模式要同时处理 DNS 劫持与应用绕过

系统代理主要影响遵循代理设置的应用。游戏、系统服务、部分命令行程序和自行建立连接的软件可能忽略它。TUN 模式通过虚拟网络接口接管更广的 IP 流量，因此更适合统一处理 UDP、非代理感知应用和系统 DNS，但它依赖管理员权限、路由设置与平台网络栈。

mihomo 的 TUN 配置通常包含自动路由和 DNS 劫持。具体字段会随版本与客户端封装变化，典型结构如下：

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

dns-hijack 将经过 TUN 的传统 53 端口查询送入内置 DNS。启用后应重新抓包，确认请求没有继续从物理网卡直接发往路由器。某些平台的安全软件、虚拟机、容器、VPN 或企业网络客户端会安装更高优先级的路由与过滤驱动，导致部分流量绕过 TUN。此时要检查路由表、接口优先级以及客户端日志中的接口选择。

DNS 劫持通常针对传统 UDP/TCP 53。浏览器自带 DoH 使用 HTTPS 443，不能仅靠端口 53 劫持接管。如果浏览器安全 DNS 指向独立服务，它可能通过 DIRECT 或依据普通连接规则访问。处理方式有两种：关闭浏览器独立解析，让请求统一进入系统和 Clash；或者保留浏览器 DoH，并为该端点设置明确代理规则。混合使用时应记录每条路径，避免把浏览器测试结果误判为内核 DNS 失效。

IPv6 也要纳入测试

本地网络支持 IPv6 时，应用可能优先请求 AAAA 记录并直接建立 IPv6 连接。只检查 IPv4 出口和 A 记录会遗漏这条路径。若代理节点、规则和 TUN 完整支持 IPv6，可保持 DNS 中的 IPv6 功能并分别测试 A、AAAA 查询与双栈出口。若当前代理链不支持 IPv6，则应在内核、系统接口和路由层做一致处理，而不是只删除某一项 DNS 记录后继续保留可直连的 IPv6 路由。

修改后按固定清单复测

防泄漏配置是否有效，要在清理缓存后重新产生查询。只刷新已经打开的页面，可能继续使用浏览器、系统或 Clash 的缓存结果。建议先重启客户端内核，清理系统 DNS 缓存，关闭旧浏览器进程，再用随机子域名开始测试。

1. 确认内核配置已生效：查看客户端运行配置与启动日志，确认 DNS 模块、fake-ip 和 TUN 没有解析错误。
2. 核对代理出口：分别测试浏览器与不遵循系统代理的应用，确认连接按规则进入 DIRECT 或目标策略组。
3. 执行浏览器 DNS 测试：记录每个递归解析器的网络归属，并与 nameserver、策略解析和浏览器 DoH 设置对照。
4. 执行系统命令查询：比较默认解析与直接查询 Clash 本地端口的结果，确认系统入口是否已经统一。
5. 查看内核日志：用新域名触发解析，确认查询进入 DNS 模块，上游请求成功，规则与代理链符合预期。
6. 抓取物理接口流量：检查是否还有发往路由器或公网服务器的意外 53、853 端口请求。
7. 测试双栈和故障切换：分别检查 IPv4、IPv6，并临时停用一个上游，确认回退不会转向未计划的本地解析器。

常见故障与对应检查点

最终目标不是让检测页面呈现某个固定国家或固定数量的 DNS 地址，而是让解析路径与配置一致：应用查询进入预期入口，Clash 按规则选择上游，上游连接通过计划中的 DIRECT 或代理策略发出，回退和 IPv6 也没有绕开该设计。只要这四个环节都能由日志、命令行和抓包互相验证，DNS 泄漏排查才算完成。