故障排查 预计阅读 12 分钟

Clash DNS 泄漏检测方法与防泄漏配置实操:enhanced-mode 与 nameserver 设置

介绍用检测站点确认 DNS 泄漏的方法与读数含义,实操讲解 dns 配置段的 enhanced-mode、fake-ip 过滤名单与 nameserver 分组写法,并验证修复效果。

先确认检测对象：出口地址与 DNS 解析不是一回事

浏览器访问网站时，通常先把域名交给 DNS 解析器，再连接解析得到的 IP 地址。Clash 已经接管网页连接，并不必然代表 DNS 请求也进入了同一条处理路径。常见现象是网页出口显示为代理节点，但检测页仍列出本地宽带运营商、路由器下发的解析器，或者系统中手动填写的公共 DNS。排查时应把“连接出口”和“域名解析路径”分开记录。

DNS 检测页展示的通常是替检测域名完成递归查询的解析器出口，而不是电脑直接发送请求的目标地址。例如系统向路由器的 192.168.1.1 查询，路由器再把请求交给运营商，检测结果可能只显示运营商递归服务器。使用 DoH 时，检测页也可能显示云服务商的任播节点、合作网络或与实际节点不同的城市。因此，单凭城市不一致不能直接判定异常，应同时核对运营商名称、自治系统、请求数量和重复测试结果。

建立可复现的三组测试

  1. 记录当前公网出口 IP、网络运营商和所在地区，暂时退出 Clash，完成一次基线检测。
  2. 启动 Clash，但先关闭 TUN，仅打开系统代理，再用隐私窗口完成第二次检测。
  3. 启用本文配置与 TUN 的 DNS 劫持，清理缓存并重新建立连接，完成第三次检测。

每轮建议执行一次标准测试和一次扩展测试，并保存解析器数量、组织名称、国家或地区。单次结果容易受到浏览器缓存、检测站点负载和 DNS 任播调度影响。实验记录可连续执行 3 轮，每轮间隔 30 秒；如果同一运营商解析器在 3 轮中均出现，路径问题比偶发一次更明确。

观察项 正常含义 需要继续检查的结果
网页出口 IP 与当前代理节点出口一致 仍为本地宽带或移动网络地址
DNS 组织 与配置中的 DoH 服务或预期远端解析链路相符 出现本地运营商、家庭路由器上游或公司内网解析器
解析器数量 数量稳定，重复测试变化有限 同时混入本地与远端两组解析器
IPv6 结果 与配置的 IPv6 开关及代理能力一致 IPv4 经代理而 IPv6 连接或解析绕过预期路径

检查泄漏来自系统代理、TUN 还是浏览器 DoH

系统代理主要接管支持 HTTP 或 SOCKS 代理的应用流量。传统 UDP 53 DNS 请求通常不属于系统代理的接管范围，所以只打开系统代理时，操作系统仍可能向网卡配置中的 DNS 地址发包。Clash 的混合端口常见为 7890，这是代理入站端口，不是系统 DNS 端口；把系统 DNS 直接填写成 127.0.0.1:7890不会得到可用的 DNS 服务。

TUN 模式从网络层接管流量，可以配合 dns-hijack 捕获发往 53 端口的 DNS 请求，再交给 mihomo 内置 DNS 模块。对于不遵循系统代理设置的程序、游戏启动器和部分命令行工具，这条路径更完整。不过，应用自行建立的 DoH 或 DoT 连接仍表现为普通 HTTPS 或 TLS 流量，无法仅靠端口 53 劫持改写其解析器选择。

按请求来源逐项定位

不同客户端的菜单文字存在差异，但排查目标相同。以提供原始 YAML 编辑能力的桌面客户端为例，可从「订阅」→ 当前配置右侧菜单 →「编辑文件」进入配置文本；保存后还要执行「订阅」→ 当前配置 →「重新加载」。TUN 一般位于「设置」→「Clash 设置」→「TUN 模式」。如果客户端由订阅更新覆盖本地文件，应使用覆写或合并配置功能保存 DNS 段，而不是直接长期修改订阅缓存。

配置 enhanced-mode、nameserver 与引导解析器

以下记录以 mihomo v1.19.10 的配置结构为例。核心关系是：default-nameserver负责解析 DoH 服务器自身的域名，nameserver承担常规域名查询，proxy-server-nameserver可单独处理代理服务器域名，nameserver-policy则按域名或规则集合指定解析器。引导解析器应使用 IP 地址，避免解析 DoH 域名时再次依赖同一个尚未建立的 DoH 服务。

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"
    - "*.local"
    - "localhost"
    - "time.*.com"
    - "ntp.*.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://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query

  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query

fake-ip 为什么有助于规则分流

enhanced-mode: fake-ip启用后，mihomo 会先向应用返回 198.18.0.0/16范围内的保留地址，并保存域名与假地址之间的映射。应用连接该地址时，内核可以恢复原始域名，再按 DOMAIN、DOMAIN-SUFFIX、GEOSITE等规则匹配。这样既保留域名信息，也减少应用直接使用系统解析结果后只剩目标 IP 的情况。

fake-ip不是把真实公网地址永久替换掉，而是内核内部的映射机制。最终建立连接时仍会按策略解析并连接真实目标。它适合依赖域名规则的日常配置，但局域网发现、打印机、时间同步、部分游戏登录和使用 IP 字面量校验的程序可能不接受假地址，因此需要过滤名单。

redir-host 适合哪些情况

enhanced-mode: redir-host会向应用返回真实解析结果，兼容性通常更直接，但域名映射和规则命中行为与 fake-ip不同。如果某个旧程序在 fake-ip 下持续连接失败，先把该域名加入过滤名单；只有故障范围较大且无法列出域名时，再临时切换到 redir-host做对照测试。切换 enhanced-mode 后必须清理 DNS 缓存并新建连接，否则旧记录会干扰结论。

为 TUN 增加 DNS 劫持与严格路由

只配置 dns段还不够，系统发往其他 DNS 服务器的 53 端口请求需要被导入内置 DNS。mihomo 的 TUN 配置可以使用 dns-hijack: any:53捕获这类请求。auto-route负责添加路由，strict-route用于减少部分平台上流量从其他接口绕行的机会。不同操作系统需要相应权限，Windows 通常需要管理员授权，Linux 需要创建 TUN 与修改路由的能力。

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

any:53处理常见 DNS 请求，额外列出 tcp://any:53可覆盖使用 TCP 53 的查询。DNS 响应超过 UDP 可承载范围、服务端要求重试或应用主动选择 TCP 时，会用到后一条。该配置不会自动阻止浏览器自带 DoH，因为 DoH 使用 443 端口；若要求全部浏览器遵循 Clash DNS，应在浏览器「设置」→「隐私和安全」→「安全 DNS」中选择系统提供方或关闭自定义提供方，再重新测试。

监听端口与端口冲突

示例使用 0.0.0.0:1053作为 mihomo DNS 监听地址。1053 是非特权端口，便于本地调试；TUN 劫持会把 53 端口请求送入该模块，因此通常不需要在系统网络设置中填写带端口的 DNS 地址。若另一个本地 DNS 程序已经监听 1053，内核日志会出现绑定失败。Windows 可用 netstat -ano | findstr :1053检查占用，Linux 可用 ss -lntup | grep 1053查看监听进程。

在不使用 TUN、而是让系统直接查询本机 DNS 的方案中，系统通常只接受标准 53 端口，此时需要让 DNS 服务监听 127.0.0.1:53并确认端口权限与冲突。该方案涉及平台网络设置，容易被网络切换、VPN 软件或 DHCP 更新覆盖；对桌面 Clash Meta 客户端而言，TUN 加 DNS 劫持通常更容易保持一致。

精确设置 fake-ip-filter，避免局域网与特殊协议故障

过滤名单中的域名会跳过 fake-ip 响应，改用真实地址。名单过短可能造成设备发现、局域网后台或时间同步异常；名单过宽则会让大量域名提前解析成真实 IP，削弱基于域名映射的处理效果。配置原则是从故障日志提取具体域名，优先添加最窄的后缀或完整域名，不要直接把大型顶级域名整体排除。

dns:
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "router.asus.com"
    - "time.windows.com"
    - "time.apple.com"
    - "stun.*"
    - "+.msftconnecttest.com"
    - "+.msftncsi.com"

*.lan和*.local主要照顾家庭局域网与本地发现；时间服务器返回真实地址有助于部分只接受直接 UDP 通信的系统服务；网络连通性检测域名则可能影响系统对“是否联网”的判断。实际添加前应观察客户端日志中的查询域名，不同系统版本使用的检测域名并不完全相同。

局域网域名应交给哪台 DNS

如果公司或家庭内部域名只能由路由器解析，可通过 nameserver-policy把指定后缀交给内网 DNS。例如路由器 DNS 为 192.168.1.1，内部域名为 home.arpa，可以只为该后缀设置策略。使用前确认该地址确实提供递归查询，并避免在公共网络继续使用原局域网地址。

dns:
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1
    "+.corp.example":
      - 10.20.0.53

内部 DNS 地址通常应按直连处理，否则查询可能被送到代理节点后无法访问。若客户端支持配置合并，可以把局域网专用策略放在仅对特定网络启用的本地覆写中。笔记本从公司网络切换到家庭网络后，应检查 10.20.0.53这类私网地址是否仍被引用，避免每次查询都等待超时。

清理缓存并验证修复结果

DNS 配置修改后，旧连接和多层缓存不会立即消失。操作系统、浏览器、应用、mihomo 内核都可能保留解析结果。验证前应重新加载配置，停止并重新开启 TUN，然后清理系统 DNS 缓存。Windows 可执行 ipconfig /flushdns；使用 systemd-resolved 的 Linux 可执行 resolvectl flush-caches；macOS 可执行 sudo dscacheutil -flushcache并重启 mDNSResponder。浏览器应关闭全部窗口后重开，或使用新的隐私窗口。

一组可比较的实测记录

在 Windows 11 24H2、mihomo v1.19.10、家庭宽带与 IPv4/IPv6 双栈环境中，基线扩展测试发起 20 个查询，结果列出 2 个本地运营商递归解析器。仅启用系统代理后，网页出口变为代理节点，但 20 个查询仍由同一组运营商解析器完成。启用 fake-ip、两组 DoH nameserver、TUN 与 any:53劫持后，连续 3 轮测试均只显示配置中的公共 DNS 网络，本地运营商解析器未再出现在结果中。

这组数值用于说明前后对照方式，不是所有网络都应得到相同数量。公共 DNS 使用任播，检测页可能在不同轮次显示 1 至 4 个边缘节点；只要组织归属与配置目标一致、没有混入本地解析链路，并且网页出口与规则预期一致，就可以认为修复有效。若结果同时出现两类解析器，应继续检查浏览器 DoH、IPv6 路由或某个后台应用是否绕过系统 DNS。

测试阶段 网页出口 DNS 检测结果 结论
退出 Clash 本地宽带 2 个运营商解析器 基线记录
仅系统代理 代理节点 仍为 2 个运营商解析器 DNS 未被系统代理接管
TUN 与 DNS 劫持 代理节点 公共 DoH 网络 解析路径符合配置

命令行交叉验证

浏览器检测之外，可直接向 mihomo 的 1053 端口查询，确认内置 DNS 正在响应。Windows 安装了支持指定端口的工具后，可使用 dig @127.0.0.1 -p 1053 example.com；Linux 与 macOS 同样可执行该命令。fake-ip 模式下，返回 198.18.0.0/16内的地址属于预期现象。若请求超时，应先检查监听端口和内核日志，而不是继续调整规则组。

随后再执行系统默认查询，例如 nslookup example.com。在 TUN 劫持开启时，即使命令显示的服务器名称仍是路由器或系统配置地址，实际 53 端口流量也可能已被内核捕获。因此最终判断要结合 mihomo 日志、检测站结果和前后对照，不能只看 nslookup首行显示的服务器。

常见异常与对应修正

配置后所有域名都解析失败

检测正常，但部分应用无法登录

先从日志中找到应用访问的域名，逐个加入 fake-ip-filter做小范围验证。涉及 STUN、局域网发现、NTP 或连接状态检测时，真实 IP 响应往往更合适。若加入完整域名后恢复，再考虑是否需要扩大到同一业务后缀。不要一开始就过滤所有域名，否则测试无法判断究竟是哪类请求与 fake-ip 不兼容。

IPv4 正常，IPv6 仍显示本地网络

确认代理节点和所选 DNS 均支持预期的 IPv6 行为。如果当前代理链路不处理 IPv6，可暂时把 dns.ipv6设为false进行对照，观察检测页是否停止返回 AAAA 结果。同时检查 TUN 是否覆盖 IPv6 默认路由。长期方案应根据节点能力决定是完整接管 IPv6，还是在系统与 DNS 两侧一致地停用相关路径，避免只改一个开关。

订阅更新后配置恢复原状

订阅文件由远端生成，刷新时会替换本地缓存。应在客户端的覆写、合并配置或脚本扩展中保存 DNS 与 TUN 设置。操作路径通常位于「订阅」→ 当前配置右侧菜单 →「覆写设置」；完成后执行「订阅」→「更新」并再次打开配置预览，确认 enhanced-mode、nameserver和dns-hijack仍然存在。

下载 Clash 客户端 查看 Windows、macOS、Android、iOS 与 Linux