进阶配置 预计阅读 13 分钟

Clash DNS配置详解：nameserver、fallback与DNS劫持的作用

梳理常用DNS字段的处理顺序、适用场景和配置边界，帮助理解解析异常与规则匹配之间的关系。

先分清DNS解析、代理规则与连接出口

Clash配置中的DNS模块负责把域名解析为地址，并在特定增强模式下保留域名与连接之间的对应关系。代理规则负责判断请求进入DIRECT、REJECT、某个代理节点或策略组，最终连接则由选定出口建立。这三部分相互影响，但不是同一件事。

例如，浏览器访问一个域名时，系统可能先向本地DNS发起查询。Clash接管该查询后，根据配置选择上游解析器，并向浏览器返回真实地址或Fake IP。随后浏览器发起连接，Clash再结合域名、目标地址、规则顺序和当前模式确定出口。单纯把某个DNS服务器写进配置，并不意味着所有连接都会经过代理；同样，把某条域名规则指定为代理，也不代表应用一定会使用Clash的DNS模块。

排查解析问题时，首先要回答三个问题：DNS请求是否真正到达Clash、Clash选择了哪个上游、解析结果如何参与后续规则匹配。若只观察“网页打不开”，很容易把解析失败、规则误判、节点不可用和系统代理未生效混在一起。

普通解析与增强模式的差别

在常见实现中，enhanced-mode可选择fake-ip或redir-host。Fake IP模式向应用返回保留地址段中的合成地址，并在内核中保存该地址与原始域名的映射。当应用连接这个合成地址时，Clash可以恢复域名，再执行域名规则和后续解析。该方式通常有利于保持域名信息，也能减少应用在Clash之外自行解析后造成的规则偏差。

Redir-host模式通常向应用返回真实解析结果。它更接近传统DNS行为，但后续连接是否仍能保留完整域名信息，要看流量入口、嗅探能力、应用协议与内核实现。两种模式没有脱离场景的固定优劣：局域网设备、游戏、打印服务、需要真实地址的程序以及某些连接检查机制，可能需要加入Fake IP过滤；希望域名规则稳定参与匹配时，则常优先测试Fake IP。

nameserver与default-nameserver分别做什么

nameserver是Clash DNS模块处理常规域名查询时使用的主要上游。它可以包含传统UDP/TCP DNS，也可以在内核支持时使用DoH或DoT地址。配置多个上游后，具体并发、缓存和结果选择行为由内核版本决定，因此不能把列表简单理解为严格从上到下逐个重试。

default-nameserver主要用于解析DNS服务器自身的域名，也就是引导解析。假设nameserver里填写了https://dns.example.net/dns-query，Clash必须先获得dns.example.net的地址，才能建立DoH连接。如果引导解析仍依赖这个尚未连接的DoH服务器，就会形成依赖环。为避免这种情况，默认解析器通常填写可直接访问的IP形式DNS地址。

这两个字段并不是“首选DNS”和“备用DNS”的关系。常规查询主要交给nameserver，而default-nameserver承担基础引导工作。若主要上游使用纯IP地址，例如223.5.5.5，引导环节不明显；一旦使用带主机名的DoH或DoT端点，默认解析器的重要性就会增加。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29

  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

示例关闭了AAAA结果处理，但这不等于关闭操作系统的IPv6能力，也不等于所有应用都停止发起AAAA查询。它表示Clash DNS模块在该配置下不向调用方提供IPv6解析结果。若网络具备稳定IPv6出口、规则与代理节点也完整支持IPv6，可以再启用并分别验证直连与代理路径。

nameserver-policy的适用范围

Mihomo等较新的内核还提供nameserver-policy，允许按域名、规则集或Geosite分类指定解析器。它适合处理不同域名需要不同解析出口的情况，例如本地域名交给局域网DNS，特定业务域名交给指定DoH。策略匹配成功时，所指定的解析器会覆盖普通nameserver选择。

该字段依赖内核支持和规则数据，迁移配置时应核对客户端实际使用的内核版本。规则集未加载、分类名称不受支持或语法来自其他分支时，可能导致策略没有按预期生效。基础配置尚未验证前，不建议一次堆叠过多按域名分流的DNS策略。

代理节点域名也需要解析

代理服务器地址若填写域名，内核必须先解析节点域名，才能建立到节点的连接。Mihomo配置中的proxy-server-nameserver可专门处理这一类查询，避免节点域名解析依赖普通业务查询路径。若解析节点域名时又试图通过该节点访问远程DNS，就可能出现启动阶段的循环依赖。

同理，支持direct-nameserver的内核可以为直连流量指定解析器。是否需要这些扩展字段，取决于配置规模与网络环境。对多数入门配置而言，先保证default-nameserver和nameserver工作正常，再逐步拆分节点解析和直连解析，更容易定位问题。

fallback不是简单的故障备用

fallback经常被误解为“nameserver超时后才启用的备用服务器”。在经典Clash DNS设计中，主要解析器与fallback解析器可以并行查询，再由fallback-filter判断是否采用fallback结果。因此，fallback更接近另一组候选解析路径，而不是传统网络设备中按顺序切换的备用DNS。

常见的过滤依据包括GeoIP、指定网段和域名列表。启用geoip: true并设置geoip-code: CN时，内核可根据主要解析结果所属区域决定是否使用fallback候选。domain可以指定一批始终交给fallback判断的域名，ipcidr则可把特定地址范围视为需要切换结果的条件。

dns:
  enable: true
  enhanced-mode: fake-ip

  default-nameserver:
    - 223.5.5.5

  nameserver:
    - https://dns.alidns.com/dns-query

  fallback:
    - https://1.1.1.1/dns-query
    - tls://8.8.4.4:853

  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - +.google.com
      - +.github.com

这个示例表达的是结果筛选思路，不代表所有网络都需要照搬。远程DoH或DoT端点能否连接，还取决于路由、代理出口、证书校验、系统时间和内核对协议的支持。若fallback服务器本身无法访问，增加再多过滤规则也不会产生可用结果。

GeoIP过滤的局限

GeoIP判断依赖数据库内容，而大型网站经常使用CDN、Anycast和区域化调度。同一域名可能在不同地区返回不同地址，一个地址的地理标签也不能完整说明它是否适合当前网络。因此，GeoIP适合作为筛选信号，不应被理解为绝对准确的可用性检测。

如果业务目标明确，按域名设置解析策略通常比依赖宽泛的GeoIP切换更容易解释。例如，局域网域名应发送给路由器DNS，公司内部域名应发送给企业DNS，指定公网服务应使用某个DoH。此时可优先考虑nameserver-policy，而不是让所有查询同时进入两组解析器再依靠结果归属地判断。

DNS劫持在TUN模式中的作用

这里的“DNS劫持”指本机代理内核主动接管进入TUN接口的DNS请求，不是修改公共DNS记录。启用TUN后，应用流量进入虚拟网络接口；配置dns-hijack可将发往指定地址和端口的传统DNS请求转交给Clash内置DNS模块处理。这样即使系统仍把DNS请求发往路由器或其他地址，内核也有机会统一执行Fake IP、缓存和上游选择。

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

any:53通常表示接管目标为任意地址、端口为53的DNS流量。不同系统、内核版本和TUN栈对UDP、TCP及具体写法的支持存在差异，应以客户端生成的有效配置和启动日志为准。若只开启TUN却没有让DNS请求进入内置解析器，系统可能继续使用原有DNS路径，Fake IP与域名规则的效果也会偏离预期。

DNS劫持不能接管所有加密DNS

浏览器或应用可能内置DoH，通过HTTPS的443端口直接连接自己的解析服务。此类流量在网络层表现为普通HTTPS连接，端口53劫持不会自动把它转换为Clash DNS查询。DoT通常使用853端口，也不属于常规的53端口接管范围。遇到某个浏览器与系统解析结果不同，应检查应用是否启用了独立的安全DNS功能。

即使应用自带DoH流量能够被代理规则转发，域名解析仍由应用选择的DoH服务完成，而不是由Clash配置中的nameserver直接完成。这可能带来两种表现：应用获得真实IP后再连接，或者规则只能基于目标IP匹配。若需要统一DNS路径，应从应用设置、系统DNS和TUN接管范围三个位置共同检查。

局域网与特殊域名需要过滤

Fake IP模式下，部分本地域名、设备发现域名、NTP服务、游戏平台连接和依赖真实地址的程序可能需要加入fake-ip-filter。过滤后的域名通常返回真实解析结果，不再分配Fake IP。应按实际故障逐项添加，而不是把大量顶级域名整体排除，否则会削弱Fake IP模式保留域名映射的价值。

dns:
  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"

.local常与mDNS设备发现相关，实际查询可能并不经过普通单播DNS。把它写入过滤列表只能避免分配Fake IP，不能代替局域网组播转发、系统防火墙或设备发现服务。局域网设备无法访问时，还应检查TUN路由、绕过网段和本地接口选择。

DNS结果如何影响代理规则匹配

Clash通常按规则从上到下匹配。DOMAIN、DOMAIN-SUFFIX和RULE-SET中的域名规则可以直接使用请求域名；IP-CIDR、GEOIP等规则则需要目标地址。若连接入口只提供IP，内核是否能恢复域名，要看Fake IP映射、协议嗅探和连接方式。DNS配置的意义之一，就是尽量让域名信息在连接阶段仍可被规则使用。

规则中的no-resolve参数表示匹配该IP类规则时不要为了获得地址而额外触发DNS解析。它可以减少不必要的查询并避免某些循环，但若当前连接没有目标IP，该条规则也可能无法完成预期判断。使用时应明确规则前面是否已有域名匹配，以及连接入口是否提供真实目标地址。

DNS服务器的出口规则同样重要。DoH服务器是一个HTTPS目标，它自身会被Clash规则匹配。若配置希望某个DoH通过代理访问，就要保证代理节点已可连接，并避免节点域名解析依赖这个尚未建立的DoH链路。若希望本地DNS直连，则应确认相应地址不会被宽泛的代理规则错误送入代理组。

缓存会让修改看起来没有生效

DNS结果可能同时存在于浏览器、操作系统、Clash内核和上游解析器的缓存中。修改nameserver后立即重复访问，看到旧地址并不一定表示配置未加载。应先确认客户端完成配置重载，再关闭受影响应用的现有连接，必要时清理系统DNS缓存，并等待上游记录的TTL影响消退。

HTTP/2、HTTP/3和连接池还会复用已经建立的连接。即使新的DNS查询返回了不同地址，浏览器也可能继续使用旧连接。排查时可结合无痕窗口、完全退出应用、查看Clash连接列表和日志时间戳，判断问题发生在新查询还是旧会话。

按处理链路排查解析异常

DNS故障适合从入口到出口逐层检查。每一步只改变一个变量，能避免把多个配置问题叠加在一起。下面的顺序适用于“域名打不开但IP可连接”“系统代理正常但TUN异常”“启用Fake IP后个别应用失效”等常见情况。

  1. 确认配置已被内核接受。

    先查看Clash Verge的配置检查结果与启动日志。YAML缩进错误、字段拼写错误或当前内核不支持某个选项时，DNS模块可能未按预期启动。重点确认监听地址、增强模式和上游服务器已经加载。

  2. 确认查询是否到达Clash。

    系统代理只接管支持代理设置的应用流量，不会天然接管操作系统的全部DNS请求。若依赖DNS劫持，应确认TUN已启用、自动路由有效，并检查请求是否走入虚拟接口。仅修改Clash中的nameserver，但应用继续直接查询系统DNS时，两边结果会保持不同。

  3. 验证上游能否建立连接。

    传统DNS检查53端口的UDP或TCP可达性；DoH检查HTTPS连接、证书和系统时间；DoT检查853端口及TLS握手。域名形式的上游还要验证default-nameserver能否完成引导解析。

  4. 检查结果类型。

    Fake IP模式下看到198.18.0.0/16一类保留地址通常属于预期表现，不应直接把它判断为解析错误。真正需要检查的是后续连接是否进入Clash，以及内核能否从Fake IP恢复原始域名。

  5. 核对规则与DNS出口。

    观察解析器域名或IP最终命中了DIRECT还是代理策略组。若远程DoH被分配给不可用节点，查询会超时；若内部DNS被发送到公网代理，局域网域名也可能无法解析。

  6. 缩减配置后逐项恢复。

    暂时保留一组可用nameserver，关闭复杂的fallback过滤和按域名策略，验证基础解析。随后依次恢复fallback、nameserver-policy、代理节点专用DNS和Fake IP过滤，每次修改后查看日志与查询结果。

选择配置方式的简化原则

  • 只需要统一常规解析时，先配置可靠的default-nameserver与nameserver。
  • 需要保留域名映射并配合TUN时，测试fake-ip与DNS劫持，再为特殊域名添加过滤。
  • 需要两组候选结果筛选时，再使用fallback与fallback-filter。
  • 需要按业务域名指定解析器时，优先评估内核支持的nameserver-policy。
  • 代理节点地址为域名且启动解析复杂时，单独设置节点域名解析路径。

稳定的Clash DNS配置通常不是字段越多越好，而是每条解析路径都能说明来源、出口和使用条件。先建立可工作的基础链路，再根据局域网、IPv6、TUN和特定应用需求扩展，出现异常时才能快速判断问题位于系统DNS、Clash内核、上游解析器还是代理规则。

继续安装 Clash Verge

前往下载页选择系统与架构，或先阅读完整安装步骤。

前往下载页 查看安装教程
下载Clash