进阶功能 约 9 分钟阅读

Clash DNS 配置与防泄漏设置实操指南

讲解 fake-ip 与 redir-host 两种 DNS 模式的取舍、上游 DNS 服务器的选择原则，以及验证 DNS 请求是否绕过代理泄漏的实用方法。

DNS 解析在代理链路中的位置

代理软件本身只处理已经建立的网络连接，而域名解析发生在连接建立之前。如果 DNS 请求走了系统默认的解析器而不是 Clash 内置的 DNS 模块，会出现两个问题：一是本机的 DNS 请求直接发往运营商或本地网络的解析服务器，暴露访问了哪些域名，即所谓的 DNS 泄漏；二是规则引擎里的 DOMAIN、DOMAIN-SUFFIX 等域名类规则可能匹配不到正确的目标，因为客户端拿到的 IP 和规则预期的域名对应关系不一致，导致分流出错。

Clash 和 Clash Meta（mihomo 内核）都提供独立的 dns 配置块，接管客户端的域名解析流程，不再依赖系统 hosts 或系统网络设置里配置的 DNS。这个模块的核心配置项包括 enhanced-mode（解析模式）、nameserver（上游 DNS）、fallback（备用 DNS）以及是否开启 fake-ip 相关的过滤规则。理解这几个字段的作用，是排查分流异常和 DNS 泄漏的前提。

说明：只有开启了 dns.enable 且客户端处于系统代理或 TUN 模式接管流量的状态下，DNS 模块才能真正拦截请求。单独打开 DNS 配置不接管系统代理，效果有限。

fake-ip 与 redir-host 两种模式的取舍

Clash 的 enhanced-mode 支持两种取值，工作原理和适用场景差异很大，选错模式是很多分流异常和访问失败问题的根源。

fake-ip 模式

客户端查询某个域名时，DNS 模块不去真正解析这个域名，而是从一个预先划定的地址段（例如 198.18.0.1/16）里分配一个虚构的 IP 返回给系统。应用程序拿着这个假 IP 发起连接，Clash 在建立 TCP/UDP 连接时再根据这个假 IP 反查出原始域名，交给规则引擎判断走哪条代理线路，真正的域名解析在这一步才发生。这种方式的优点是不会向任何上游 DNS 泄漏真实访问记录，规则匹配也更精确，因为规则引擎拿到的是原始域名而不是解析后的 IP。缺点是依赖假 IP 到域名的映射表，某些强校验客户端 IP 的服务、局域网设备发现协议、以及部分需要真实解析结果的场景（比如某些下载软件的多线程测速）可能出现异常，需要用 fake-ip-filter 把这些域名排除在假 IP 之外，改用真实解析。

redir-host 模式

这种模式下，DNS 模块直接用配置的上游服务器把域名解析成真实 IP 返回给系统，客户端拿到的就是真实地址。它的历史用途是配合早期的透明代理（iptables REDIRECT、TPROXY）场景，代理服务器需要靠 Host 头或 SNI 还原目标域名再匹配规则，因为透明代理拦截的是 IP 连接而不知道域名。这种模式的局限也很明显：真实解析结果会经过 Clash 配置的上游 DNS，如果上游选得不当，解析出的 IP 可能和实际就近节点不匹配，对 CDN 多线路服务不友好；同时因为客户端直接拿到真实 IP，部分基于 IP 段做识别的检测机制更容易发现代理痕迹。

综合来看，现在的主流做法是优先使用 fake-ip，只在极少数确实需要真实 IP 的场景里用 fake-ip-filter 做局部例外，而不是整体切换到 redir-host。redir-host 更适合没有域名嗅探能力的老旧透明代理链路，普通用户在 TUN 模式或系统代理模式下几乎不需要用到它。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'
    - 'time.*.com'
    - 'ntp.*.com'

上游 DNS 服务器的选择原则

nameserver 字段决定域名最终解析用哪个服务器完成，fallback 字段则作为备用解析源，通常配合 fallback-filter 的地理位置判断使用。选择上游 DNS 时可以参考以下几条原则：

  • 优先使用支持加密的协议。普通的明文 UDP 53 端口查询容易被中间网络节点观察甚至篡改，条件允许时优先配置 DoH（DNS over HTTPS）或 DoT（DNS over TLS），格式分别是 https://域名/dns-query 和 tls://域名:853。
  • 区分国内和国外解析路径。访问国内站点建议走国内公共 DNS 保证解析速度和 CDN 就近效果，访问境外站点则走境外或加密 DNS，避免国内解析结果指向了不适用的节点。这一步通常靠 nameserver-policy 按域名后缀分流，或者靠 fallback-filter.geoip 判断解析结果是否属于境内 IP 段来决定是否采用。
  • 避免使用代理节点所在地区与解析服务器地区严重不匹配的组合。如果所有域名都统一走境外 DNS 解析，国内网站可能被解析到不利于访问的节点，出现访问缓慢或验证码频繁触发的情况。
  • 保留至少一个 fallback。主 DNS 不可达或超时时，fallback 能保证解析不中断，建议主备使用不同运营商或不同协议，避免同时失效。
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://doh.pub/dns-query
    - tls://223.5.5.5:853
  fallback:
    - https://1.1.1.1/dns-query
    - tls://8.8.4.4:853
  fallback-filter:
    geoip: true
    geoip-code: CN
  nameserver-policy:
    'geosite:cn': 'https://doh.pub/dns-query'
    'geosite:geolocation-!cn': 'https://1.1.1.1/dns-query'

上面示例的思路是：默认走国内加密 DNS，命中境外域名分类（geosite 规则集）时改走境外 DNS，同时用 fallback-filter 兜底判断解析出的 IP 是否属于境内地址段，避免因为域名分类库未及时更新而误判。这套组合基本能兼顾国内站点访问速度和境外站点的正确分流。

验证 DNS 请求是否绕过代理泄漏

配置好 DNS 模块后，需要用实际手段确认请求真的走了 Clash 而不是系统默认解析器，常见方法如下。

方法一：查看客户端连接日志

大多数 Clash 图形客户端（Clash Verge、Mihomo Party、FlClash 等）都带有连接日志或活动连接面板，正常情况下每一条经过代理的连接都会显示对应的目标域名，而不是裸露的 IP。如果发现大量条目只显示 IP 没有域名，说明这些请求在到达代理引擎之前域名信息已经丢失，通常是因为系统代理没有覆盖到发起请求的应用，或者该应用使用了不走系统代理设置的直连方式，这类流量建议改用 TUN 模式统一接管。

方法二：抓包核实是否有明文 DNS 流量外泄

用抓包工具（如 Wireshark 或命令行 tcpdump）过滤 UDP 53 端口和常见 DoH 端口，观察本机网卡上是否存在发往非 Clash 配置的上游服务器的查询包。如果在开启代理的情况下依然能捕获到系统网络设置里配置的运营商 DNS 地址的查询记录，说明存在旁路泄漏，需要检查系统代理是否覆盖了 UDP 流量，或者是否需要切换到 TUN 模式接管全部网络层流量。

方法三：命令行直接比对解析结果

在终端里分别使用系统默认解析器和指定 Clash 配置的上游服务器解析同一个域名，比对返回的 IP 是否一致，以及请求耗时是否吻合预期路径。

# 使用系统默认解析器
nslookup example.com

# 强制指定服务器解析，对比结果是否一致
nslookup example.com 223.5.5.5

如果开启 fake-ip 后用系统自带工具查询域名，得到的应该是 fake-ip-range 范围内的地址而不是真实公网 IP，这是正常现象，说明假 IP 机制生效，并不代表解析失败。

方法四：使用在线 DNS 泄漏检测页面

浏览器访问专门的 DNS 泄漏检测网站，页面会列出实际发起解析请求的服务器信息。正常情况下应该只显示配置的上游 DNS 或对应的加密解析节点，如果列表中出现本地网络运营商的解析服务器信息，说明部分流量绕开了代理直接查询，需要回头检查系统代理范围、TUN 模式开启状态，或者浏览器自身是否启用了独立的 DoH 设置和 Clash 的 DNS 模块产生冲突。

常见误区：部分浏览器自带的安全 DNS 功能会绕过系统代理直连指定的加密 DNS 服务器，即便 Clash 配置正确也会造成域名查询绕过代理。排查泄漏时记得同时检查浏览器自身的 DNS 设置是否已关闭或调整为跟随系统。

常见配置问题与排查思路

实际使用中遇到的 DNS 相关问题大多集中在以下几类，逐一排查可以快速定位。

  1. 规则分流命中不准确。多数情况下是因为使用了 redir-host 或未开启 fake-ip，规则引擎拿到的是解析后的 IP 而不是原始域名，导致按域名配置的规则失效。切换回 fake-ip 通常能解决。
  2. 局域网设备无法互相发现或访问。这是 fake-ip 模式的典型副作用，需要把局域网相关域名（如 *.lan、路由器管理域名）加入 fake-ip-filter，让这些请求走真实解析而不是假 IP。
  3. 境内站点访问变慢或触发额外验证。通常是国内域名走了境外 DNS 解析出了不适用的 IP，需要检查 nameserver-policy 或 fallback-filter 的地区判断是否配置正确。
  4. 解析长时间超时。检查配置的上游 DNS 服务器本身是否可达，加密协议（DoH/DoT）在部分网络环境下可能被干扰，可以先换成明文 UDP 服务器验证是否是协议层面的问题，再决定是否保留加密配置。
  5. 系统代理模式下 UDP 类应用（游戏、视频通话）解析异常。系统代理通常只接管 TCP 流量，UDP 请求包括部分 DNS 查询可能不受控制，这类场景建议直接使用 TUN 模式，从网络层统一接管所有协议的流量和解析请求。

把 DNS 模式选对、上游服务器按地区分流配置好，再用连接日志、抓包和在线检测三种手段交叉验证，基本可以确认解析路径没有绕开代理，规则引擎也能拿到准确的域名信息用于分流判断。

配置好 DNS 之后，记得同步检查客户端整体设置

下载对应平台的最新客户端，或查看完整的安装与配置教程，确认代理模式、订阅规则和 DNS 设置协同生效。

前往下载页 查看教程
下载客户端