进阶配置 预计阅读 14 分钟

Clash DNS 配置详解:nameserver、fallback、fake-ip 与 DNS 劫持设置

从 dns 段每个字段讲起,说明 nameserver 与 fallback 的分工、fallback-filter 判定逻辑、fake-ip 与 redir-host 的差异,以及 TUN 下劫持 DNS 的写法。

先确认内核，再修改 DNS 配置

Clash DNS 配置是否生效，取决于两件事：当前内核是否支持这些字段，以及应用的解析请求是否真正进入内核。只把 dns.enable 改为 true，不代表 Windows 上所有应用都会改用这套 DNS；开启系统代理，也不等于自动接管系统的 UDP 53 查询。

Clash for Windows 已停止维护。它是客户端界面，实际处理连接的是其所用内核；传统 Clash、Clash Premium 与 Clash Meta（现名 mihomo）的功能范围并不完全相同。本文先解释常见 DNS 字段，再单独给出 mihomo 的 TUN 示例。不要把新内核的整段配置直接覆盖到旧客户端。

  1. 在客户端的 General（常规） 页面查看内核信息；若界面未显示，在 Logs（日志） 中检查启动记录。
  2. 在 Profiles（配置） 中确认当前选中的配置，先保存一份副本。订阅更新可能覆盖直接编辑的内容。
  3. 检查是否启用了 Mixin 或配置覆写。排错时应查看最终生效配置，而不只是订阅原文件。
  4. 每次只改一组参数，重载后检查日志。出现未知字段、启动失败或监听失败时，先恢复上一份可用配置。

dns 基础字段：监听、上游与引导解析

下面是一份便于排错的 DNS 基础片段，采用 redir-host 返回真实地址。它不是完整订阅，须合并到已有配置的顶层；同一文件只保留一个 dns: 映射，避免重复键带来的覆盖或解析错误。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
字段 示例值 作用与边界
enable true 启用内核 DNS 模块；不会单独修改所有应用的解析入口。
listen 127.0.0.1:1053 本地 DNS 监听地址，仅向本机开放。1053 是本文选用的测试端口。
ipv6 false 控制内核 DNS 的 AAAA 应答行为，不等同于禁用系统 IPv6 网卡。
default-nameserver 223.5.5.5 主要用于解析 DNS 上游自身的域名，解决加密解析器的引导问题。
nameserver 两个 DoH 地址 普通域名查询使用的主要上游；列表不是严格的逐个重试顺序。

1053、53 与 7890 不要混用

常规 DNS 查询通常发往端口 53。示例用 1053，便于避免与已有服务冲突，但 Windows 网卡的 DNS 地址输入框通常不能指定这个自定义端口。需要用支持指定端口的查询工具测试，或让 TUN 将 DNS 请求交给内核。代理端口如 7890 则处理 HTTP/SOCKS 等代理连接，不能当成 DNS 端口使用。

DoH 解决传输加密，不保证路径可达

https://dns.alidns.com/dns-query 是 DNS over HTTPS 地址。内核须先知道解析器域名对应的 IP，再建立 HTTPS 连接，因此需要引导解析。DoH 使用 HTTPS 加密查询内容，但服务器仍能看到发给它的查询；若路由不通、证书验证失败或系统时间错误，解析一样会失败。

不要为了“更快”一次堆入十几个上游。先保留一到两个本地网络能稳定访问的解析器，确认响应后再增加其他逻辑。这里的地址用于展示合法写法，不构成对任意运营商网络下可用性或延迟的保证。

nameserver 与 fallback：按结果筛选，不只是超时备用

fallback 容易被理解为“第一台 DNS 断了再查第二台”，但 Clash 这套机制还会结合 fallback-filter 判断应采纳哪一组结果。配置了两组上游时，内核通常会并行查询；普通查询优先考虑 nameserver 的结果，再根据过滤条件决定是否采用 fallback 的结果。

下面片段展示传统的 GeoIP 筛选写法。将它合并进上一节的 dns，而不是另起第二个顶层 dns。示例中的 GeoIP 判断依赖内核实际加载的数据库。

  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - '+.example.com'

fallback-filter 的判断顺序怎么理解

  • domain：命中指定域名条件时，直接偏向使用 fallback 解析结果。这里的 +.example.com 是用于说明语法的保留示例域名，实际配置时应改为确有需要的域名，或删除这一项。
  • ipcidr：当 nameserver 的返回地址落入列出的网段时，视为需要改用 fallback 的候选结果。240.0.0.0/4 是常见示例，不是完整的异常地址清单。
  • geoip：启用后，根据 geoip-code 判断主要结果是否属于预期地区。设为 CN 时，非 CN 的主要结果会触发采用 fallback 结果的逻辑。

可以把它理解为：某域名由 nameserver 得到一个被数据库识别为 CN 的地址，且没有命中其他过滤条件，通常保留该结果；若得到非 CN 地址，则转向 fallback 结果。这里举的是判断流程，不是实测记录。实际 CDN 地址、数据库归属和查询结果都可能变化。

另外，把某个 DoH 写进 fallback，并不意味着它必定经过代理。DNS 上游的出站行为受内核类型、版本和相关配置影响。如果这组解析器从当前网络无法直连，应先确认可达路径，不能用“换成国外 DNS”代替排错。若没有明确的筛选需求，先只用 nameserver，往往更容易定位问题。

fake-ip 与 redir-host：返回虚拟地址还是真实地址

两种模式的关键差异是发给应用的 DNS 应答。redir-host 通常返回上游解析出的真实地址，并维护域名与地址关系；fake-ip 则为域名分配一个虚拟 IP，内核接到发往这个地址的连接后，通过映射找回域名，再进行规则匹配与出站处理。

比较项 fake-ip redir-host
应用看到的地址 通常是内核分配的虚拟地址。 通常是上游返回的真实地址。
域名识别 通过虚拟地址映射还原域名，适合透明接管场景。 依靠解析记录建立映射，共享 IP 等情况可能增加判断复杂度。
兼容性关注 直接使用 DNS 结果进行探测、局域网发现的程序可能需要例外。 更贴近普通 DNS 行为，但更早依赖真实解析结果。
测试方式 看连接是否进入内核及域名映射，不以 ping 成败定论。 检查真实解析地址、规则命中及后续连接。

fake-ip 的基础片段

  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'

198.18.0.0/16 位于专用的基准测试地址空间内，不是目标网站的真实公网地址。看到查询返回 198.18.x.x，不应直接认定 DNS 被污染；在 fake-ip 模式下，这可能正是预期结果。应用连接必须继续经过能识别该映射的内核，否则虚拟地址没有正常的访问意义。

fake-ip-filter 用来让匹配域名不再获得虚拟地址，但它不会顺便为域名创建直连规则。过滤局域网域名后，还要有能解析这些名称的路径。尤其 .local 常用于 mDNS，多播发现是否正常还取决于系统与局域网环境，不能仅靠加入过滤列表解决。

fake-ip 也不等于必须开启 TUN；关键是 DNS 结果对应的连接是否会进入内核。反过来，TUN 也可以配合 redir-host 使用。切换两种模式后，建议清理系统 DNS 缓存并重启受影响的应用，避免旧的真实地址或虚拟地址仍被继续使用。

TUN DNS 劫持：把 53 端口请求交给内核

TUN 创建虚拟网络接口，将符合路由条件的 IP 流量引入内核。dns-hijack 则识别其中的 DNS 请求并交给内置 DNS 模块。它不是修改所有 DNS 报文，也不是破解加密流量；请求首先得进入 TUN，劫持规则才有机会处理。

mihomo 的 UDP 与 TCP 53 示例

以下为 mihomo 的常见字段组合，需要与已启用的 dns 一起使用。请先确认当前内核支持这些选项；旧版 Clash for Windows 所带内核不应直接套用。Windows 上通常还需要客户端服务或足够权限来创建接口和路由。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53
  • stack: mixed 选择混合协议栈，是内核能力选项，不是任意旧版本都支持的通用开关。
  • auto-route: true 自动配置相关路由，但不保证覆盖所有应用、网卡及其他 VPN 创建的路径。
  • auto-detect-interface: true 自动判断出站接口；多网卡或其他虚拟网卡并存时仍需核对。
  • any:53 用于匹配 UDP 53 查询，tcp://any:53 补充 TCP 53。大应答或重试场景可能使用 TCP。

为什么开了劫持仍可能出现其他 DNS 连接

浏览器的“安全 DNS”可能直接连接 DoH 服务，Android 的“私人 DNS”通常使用 DoT。这些不是普通 UDP/TCP 53 查询，不能指望上述两条规则把它们转成内核 DNS。应用自己发起的 DoH 请求也可能作为普通 HTTPS 连接进入代理，但“流量进入代理”和“解析交给内核 DNS”是两回事。

排查时先暂时关闭浏览器安全 DNS，用系统解析路径做对照，再决定是否恢复。不要仅凭一次在线 DNS 检测页面就判断泄漏；页面可能显示的是递归解析器的出口地址，并非本机或代理节点地址。应结合连接记录、实际出口、系统设置和抓包结果判断。

按顺序验证：监听、解析、接管、规则

出现“开启 TUN 后打不开网页”时，不要同时更换节点、DNS 和协议栈。下面的顺序能把问题缩小到具体环节，也能避免把解析失败误当作节点故障。

  1. 查监听：确认配置已重载，日志没有地址占用或权限错误。本文测试端口为 127.0.0.1:1053；如果实际配置使用别的端口，测试命令也要同步修改。
  2. 直查内核 DNS：显式指定本地服务器和端口，绕开系统默认解析器。若这里失败，先查上游连通性、引导解析及配置语法。
  3. 查默认路径：开启 TUN 后，再用不指定服务器的查询测试，并对照内核日志，判断系统请求是否被接管。
  4. 查实际连接：在客户端连接列表中查看目标域名、命中规则、策略组及出站节点。解析成功但连接超时，应继续排查规则、节点和网络路径。

Windows 查询与缓存清理

在命令提示符中输入 nslookup 进入交互模式，再依次执行下面三行。这里用 example.com 做基础查询，示例未预设任何响应值。

server 127.0.0.1
set port=1053
example.com

退出交互模式后，可以执行以下命令清理 Windows DNS 缓存。浏览器可能另有缓存，必要时完全退出后重新打开。

ipconfig /flushdns

macOS 或 Linux 查询示例

在已安装 dig 的系统上，可以分别测试 UDP 和 TCP。两条命令都直查本机 1053 端口，不用于验证系统默认 DNS 是否已经改动。

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com A +tcp

常见问题与配置收尾

只开启系统代理，为什么 DNS 仍走系统设置？

系统代理主要影响遵循代理设置的应用，不能统一接管系统 DNS。不同应用还可能选择本地解析或交给代理解析。若需要接管普通 DNS，可考虑正确配置 TUN 与 DNS 劫持，并单独检查浏览器自带的加密 DNS。

订阅更新后，手动修改的 nameserver 为什么消失？

订阅文件通常会被新下载的内容替换。应使用当前客户端支持的 Mixin 或配置覆写功能保留本地设置，并确认最终合并结果。不同客户端对列表是替换还是追加的处理可能不同，不能只看编辑框中是否保存成功。

配置了 fallback，是否就能避免所有异常解析？

不能。筛选依赖返回地址、域名条件、GeoIP 数据库与上游可达性。错误结果可能未命中过滤条件，正常 CDN 地址也可能触发地区筛选。应根据具体域名的查询记录调整，而不是无限增加 fallback 服务器。

局域网打印机、NAS 在 fake-ip 下异常怎么办？

先确认设备真实地址、局域网域名的解析来源和直连规则，再对确有兼容性问题的域名设置 fake-ip-filter。若网络同时使用 mDNS、广播发现或企业内部 DNS，还需要保留对应的本地发现与解析路径。

最终检查可以归纳为四点：DNS 监听可访问、上游可达、应用解析请求进入预期路径、连接命中正确规则。先把这四点逐一验证，再增加 fallback 筛选、fake-ip 例外或更复杂的分域解析。这样既能保留可复现的基线，也更容易在订阅更新或更换客户端后恢复配置。

Clash 下载