Clash DNS 泄漏检测与防护配置：从测试结果到规则修正

先判断什么属于 DNS 请求绕行

访问域名之前，设备通常需要把域名解析为 IP 地址。Clash 可以接管这一步，也可能只代理解析完成后的 TCP 或 UDP 连接。如果网页流量经过代理，而域名查询仍直接发往本地网络提供的 DNS 服务器，查询路径与业务流量就发生了分离。检测网站通常把这种现象标记为 DNS 泄漏。

不过，检测结果中出现本地运营商、公共 DNS 或不同地区的解析器，并不必然等于配置失效。公共 DNS 经常使用任播网络，同一个服务器地址可能在不同城市落地；解析服务还可能把查询转交给其他出口节点。检测页面看到的是递归解析器或出口基础设施，不一定是配置文件中填写的地址。

更准确的判断需要同时回答三个问题：应用把查询交给了谁，Clash 核心如何访问上游解析器，以及解析后的业务连接匹配了哪条代理规则。只看检测页面上的国家、城市或服务器名称，无法完整还原这条链路。

建立可重复的 Clash DNS 泄漏检测流程

排查前先固定测试条件。不要在切换配置、切换节点和修改浏览器设置的同时反复刷新页面，否则很难确认是哪一项改变了结果。建议保留当前配置副本，并记录核心类型、运行模式、系统代理状态、TUN 状态和浏览器安全 DNS 状态。

第一步：建立未启用代理时的基线

暂时关闭系统代理与 TUN，访问检测页面并记录解析器名称、数量和大致位置。这一组结果代表当前网络的常规 DNS 路径。随后启用 Clash，再使用新的浏览器隐私窗口测试。若两次结果完全相同，说明系统查询可能仍在沿用原路径，但还需要结合缓存与应用自带 DoH 继续确认。

第二步：清理缓存并使用新域名

系统、浏览器、Clash 内核和上游服务器都可能缓存解析结果。只刷新同一个页面，可能不会产生新的 DNS 查询。测试时应清理操作系统 DNS 缓存，关闭并重新打开浏览器，再使用检测工具提供的新随机域名。若客户端提供清理 DNS 缓存或重启核心功能，也应在修改配置后执行。

第三步：区分系统代理与 TUN

系统代理主要影响遵循 HTTP 或 SOCKS 代理设置的程序。普通 UDP 53 查询通常不会因为打开系统代理而自动进入 Clash。TUN 模式则在网络层接收更多流量，并可通过 DNS 劫持规则把传统 DNS 查询交给内核。因此，同一配置在系统代理模式与 TUN 模式下可能得到不同检测结果。

第四步：查看核心日志与连接记录

检测期间打开客户端日志，搜索测试域名、DNS、UDP、DoH 或规则匹配记录。日志中能看到域名被 fake-ip 映射、查询发往某个 nameserver，或连接命中 DIRECT、PROXY 等策略，证据通常比检测页面的地理标签更直接。若日志完全没有测试域名，查询很可能没有进入当前核心。

1. 固定一个配置文件和一个代理节点。
2. 记录系统代理、TUN、IPv6 与浏览器安全 DNS 状态。
3. 清理缓存后执行一次检测。
4. 只修改一个选项，再进行下一轮检测。
5. 对照核心日志、连接列表和检测结果。

fake-ip 与 redir-host 的路径差异

Clash 常见的增强 DNS 模式包括 fake-ip 和 redir-host。两者都能让核心参与域名解析，但工作方式不同。选择模式时要同时考虑规则匹配、局域网设备兼容性和应用行为，不能只看检测页面显示了几个解析器。

fake-ip：先返回保留地址，再由核心恢复域名

在 fake-ip 模式下，Clash 会从专用地址段中返回一个映射地址。应用向该地址建立连接时，核心根据映射表找回原始域名，再按域名规则选择策略。这样可以减少系统先取得真实目标 IP 后才交给代理的情况，也便于域名规则保持有效。

fake-ip 并不表示所有 DNS 流量都会自动被接管。应用仍需把查询发送到 Clash 的 DNS 监听端口，或者由 TUN 的 DNS 劫持规则转交给核心。若浏览器直接访问外部 DoH 服务，查询封装在 HTTPS 中，普通的 53 端口劫持无法识别其中的 DNS 内容。

局域网名称、打印机发现、网络连通性检测和部分游戏平台可能不适合使用 fake-ip。此类域名可加入 fake-ip-filter，让核心返回真实地址。过滤范围应按实际故障添加，过宽会削弱 fake-ip 的域名映射效果。

redir-host：返回真实地址并保留域名处理

redir-host 会向应用返回真实解析地址。它对部分依赖真实 IP 的程序更容易兼容，但解析动作会更早发生，也更依赖上游 DNS 的可达性和返回结果。旧版 Clash 客户端中常见此模式；mihomo 仍可处理相关配置，但新配置通常需要结合客户端能力和网络环境测试。

修正上游 DNS 与规则路径

下面的配置用于说明各字段职责，不应直接覆盖现有订阅。不同 Clash 分支支持的字段并不完全一致。原版 Clash 的旧核心通常支持基础的 enable、enhanced-mode、nameserver、fallback 和 fake-ip-filter；proxy-server-nameserver、direct-nameserver、nameserver-policy 与 respect-rules 等能力主要见于较新的 mihomo 内核。

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
    - 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

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

  fake-ip-filter:
    - "*.lan"
    - "localhost"

default-nameserver 负责启动阶段解析

加密 DNS 地址本身通常包含域名，例如 dns.alidns.com。核心需要先取得该域名的地址，才能建立 DoH 连接。default-nameserver主要承担这一类初始解析，也可能参与代理服务器域名的引导解析。它不是所有业务域名的最终上游，填写后仍要配置 nameserver。

nameserver 是常规查询入口

nameserver定义常规域名查询使用的上游。同时列出多个服务器可以提高可达性，但测试时也可能观察到多个解析基础设施。若排查目标是确定请求从哪里发出，可以先保留一个稳定上游，确认路径后再增加备用项。

DoH 或 DoT 可以避免传统 DNS 报文在本地链路上以明文传输，但加密本身不决定连接走 DIRECT 还是代理。上游连接若按直连发出，其出口仍是本地网络；若希望它依据规则选择出口，需要确认核心是否支持并启用了相应规则跟随能力。

proxy-server-nameserver 处理节点域名

订阅中的代理服务器可能使用域名而不是固定 IP。核心必须先解析节点域名，才能建立代理连接。若解析节点域名的过程又依赖尚未建立的代理，就会形成循环。mihomo 的 proxy-server-nameserver用于明确这类查询的解析器，应选择当前网络可直接访问且稳定的上游。

nameserver-policy 只选择解析器

nameserver-policy可以按域名或规则集选择上游，例如让私有域名交给系统解析，让特定区域域名使用对应解析器。它控制的是“向哪个 DNS 服务器查询”，不是“网站连接最终走哪个策略组”。业务流量仍由 rules中的域名、IP、规则集和兜底规则决定。

示例中的 geosite依赖核心已加载对应规则数据。若客户端没有规则集、数据版本过旧或规则名称不存在，策略可能无法按预期匹配。遇到此类情况，应先使用明确的域名后缀测试，再检查规则数据来源与更新时间。

谨慎处理 fallback 与过滤条件

旧配置常用 fallback配合地理 IP 判断选择解析结果。配置不当时，常规上游和备用上游可能同时查询，于是检测页面显示多个 DNS 服务。这不一定是绕行，而可能是并发查询机制。迁移到 mihomo 后，可根据实际需求改用 nameserver-policy明确划分域名，减少难以解释的并发结果。

处理操作系统、浏览器与应用内 DNS

Clash 核心配置正确，并不代表所有程序都会使用它。DNS 请求可能从系统解析器、浏览器安全 DNS、应用内置 DoH、虚拟机、容器或局域网中的另一台设备发出。排查时应按请求来源逐层确认。

系统代理不会接管全部 DNS

启用系统代理后，浏览器通常把 HTTP 或 HTTPS 连接交给代理，但系统服务和不遵循代理设置的程序仍可能直接联网。传统 DNS 查询主要通过 UDP 或 TCP 53 端口发送，不会自然进入 HTTP 代理。若使用的客户端只打开了系统代理，应预期部分系统级查询仍走网络适配器配置的 DNS。

部分客户端会在启用 TUN 时自动修改系统 DNS 或安装网络服务。此时不宜同时手动把多个网卡改成不同 DNS，否则可能产生竞争。应先查看客户端文档与运行日志，确认它是否负责 DNS 设置，再决定是否手动调整。

浏览器安全 DNS 可能形成独立路径

现代浏览器可直接连接指定的 DoH 服务。此连接表现为普通 HTTPS 流量，可能绕过系统解析器，也不会被 dns-hijack: any:53捕获。测试 Clash 内置 DNS 时，可暂时把浏览器安全 DNS 设置为跟随系统，清理浏览器 DNS 缓存后重新检测。

如果需要保留浏览器 DoH，则应把它视为独立的 DNS 方案。此时需要检查 DoH 服务域名对应的代理规则、连接出口和失败回退行为，而不是期待 Clash 的 fake-ip 配置接管浏览器内部查询。

IPv6 需要单独核对

关闭 Clash DNS 配置中的 ipv6通常表示不向应用返回 AAAA 结果，但不会自动关闭操作系统的 IPv6 网络。应用仍可能使用缓存中的 IPv6 地址，或者通过自己的解析器取得 AAAA 记录。若测试结果只在 IPv6 环境出现异常，应分别检查系统 IPv6、核心 IPv6 支持、代理节点能力和规则中的 IPv6 路径。

不建议仅为让检测页面显示单一结果而永久关闭整个系统的 IPv6。更可靠的方法是先用受控测试确认异常是否确实来自 IPv6，再根据节点与网络支持情况调整。

局域网与容器可能不使用主机解析器

虚拟机、Docker 容器、安卓模拟器和局域网设备往往拥有独立 DNS 设置。即使宿主机的 Clash 已正确接管查询，这些环境仍可能向路由器或外部服务器发出请求。需要让其他设备使用 Clash DNS 时，还应检查监听地址、防火墙与局域网访问权限，避免只绑定回环地址后期待其他设备接入。

TUN 模式下检查 DNS 劫持与路由顺序

TUN 模式可以接收不遵循系统代理的流量，是处理系统级 DNS 绕行的常用方式。mihomo 配置中可使用 dns-hijack捕获传统 53 端口查询，再交给内置 DNS 模块。实际字段还会受到客户端生成配置和运行权限影响。

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

auto-route用于自动设置路由，auto-detect-interface帮助核心选择当前出口网卡。若设备同时连接有线网络、无线网络、其他 VPN 或虚拟网卡，自动检测可能选到不符合预期的接口。出现 DNS 超时或启用 TUN 后完全断网时，应检查默认路由和接口变化，而不是只修改 nameserver。

any:53主要处理传统 DNS。它不能解密外部 DoH，也不能保证 QUIC、私有 DNS 或应用自建隧道进入内置解析器。对于这些协议，应在应用设置中统一 DNS 行为，或通过域名与网络策略控制对应连接。

启用 TUN 后还要确认 Clash 自己访问上游 DNS 的连接不会再次被错误送回 TUN，形成循环。成熟客户端通常会为核心进程、路由标记或出站接口做处理。若日志持续重复同一 DNS 请求并最终超时，应检查客户端的服务模式、核心权限和排除规则。

按检测现象修正规则与配置

最终核对清单

• 当前启用的 Profile 与正在编辑的文件一致。
• 核心类型和版本支持所使用的 DNS 字段。
• 测试域名能够在核心日志中找到。
• 系统代理与 TUN 的适用范围已经区分。
• 浏览器和应用内置 DoH 状态已经确认。
• nameserver、fallback 与策略规则没有无目的地重复查询。
• 节点域名存在独立且可达的启动解析路径。
• 修改配置后已重启核心并清理相关缓存。
• IPv4、IPv6 与局域网设备分别完成测试。

DNS 防护的目标不是让所有检测页面只显示一个固定名称，而是让查询路径可解释、可控制，并与代理规则保持一致。先确认请求是否进入 Clash，再确认内核选择哪个上游，最后检查上游连接和业务流量的出站策略。按这个顺序处理，可以避免在多个 DNS 字段之间反复试错。