Clash DNS 配置详解:nameserver、fallback 与 DNS 劫持怎么填

先给结论：安卓端先确认 DNS 请求确实进入 Clash，再调整解析服务器。nameserver 是常规解析上游，fallback 是参与结果筛选的另一组上游，不是简单的“主服务器断线后才启用”。fake-ip 决定怎样向应用返回地址，DNS 劫持决定哪些请求会被接进内核。这几件事不在同一层，不能互相代替。

1. 安卓 DNS 请求怎样进入 Clash

应用打开一个域名时，通常先向系统解析器查询地址，再发起连接。安卓客户端取得系统 VPN 授权后，可以通过虚拟网络接口接收流量；是否同时接管 DNS，还取决于客户端的 VPN 实现、DNS 设置和应用访问控制。

应用调用系统解析接口，系统向当前网络指定的 DNS 地址发起查询。
VPN 接口接收到符合接管条件的流量，客户端或内核把 DNS 请求交给内部解析器。
内部解析器读取缓存、域名策略以及 nameserver 等设置；需要时向上游发出查询。
内核向应用返回真实地址或 Fake IP。应用再连接该地址，内核按规则决定直连或使用代理节点。

因此，“VPN 已连接”只代表服务启动，不代表每个应用的 DNS 都已进入内核。被排除在 VPN 外的应用、启用了独立加密 DNS 的浏览器，都可能走不同链路。排查时先用一个未被排除的浏览器测试，暂时关闭其“安全 DNS”，再对照日志观察。

DNS 劫持主要接管普通 53 端口请求

常见 DNS 劫持针对 UDP 或 TCP 的 53 端口。Android“私人 DNS”的严格模式通常使用 DNS over TLS，端口为 853；浏览器自带的 DNS over HTTPS 通常使用 443。它们不能靠一条普通的 53 端口劫持规则直接变成内核 DNS 查询。

“私人 DNS”的入口随系统变化，常见路径为“设置”→“网络和互联网”→“私人 DNS”；部分设备放在“连接与共享”中。排障时可记录原值，临时关闭严格模式并重新连接 VPN，验证后再决定是否恢复。不要把关闭它当作所有设备的固定要求。

2. dns 段字段分别负责什么

字段	用途与填写要点
`enable`	启用内核 DNS。客户端可能用运行时配置覆盖订阅中的值。
`listen`	内核 DNS 的监听地址，不是 HTTP 代理端口，也不等于已接管系统 DNS。
`default-nameserver`	主要用于解析 DNS 上游自身的域名，解决启动时的引导解析问题。
`nameserver`	常规域名查询所用的上游列表，也可能被更具体的域名策略覆盖。
`fallback`	备用解析结果来源；与过滤条件配合选择结果，不宜理解为串行重试列表。
`fallback-filter`	描述何时使用 fallback 的结果，例如主解析返回指定网段地址。
`enhanced-mode`	选择 fake-ip 或 redir-host，改变返回地址和域名关联方式。
`ipv6`	控制内核 DNS 对 AAAA 查询的处理；不等于关闭设备全部 IPv6 流量。

default-nameserver 不是“默认解析全部网站”

例如上游写成 https://dns.alidns.com/dns-query，客户端首先要知道 dns.alidns.com 的地址，才能连接这个 HTTPS 服务。引导服务器就是用来解决这一步。使用 IP 形式的引导地址，可以避免“为了解析 DNS 服务器，又必须先访问同一台 DNS 服务器”的循环。

经典配置常用普通 IP 地址作为 default-nameserver。不同内核对该字段支持的协议范围有差异，迁移旧配置时先保留简单写法。不要把解析上游域名失败，误判成所有代理节点同时失效。

listen 不填 7890

7890 常被用作 HTTP 或混合代理端口，它与 DNS 监听是两种服务。下方示例使用 127.0.0.1:1053 监听本机 DNS，避免直接绑定需要特殊权限的低端口。安卓客户端可能自行安排内部端口或不使用这一监听入口，应以运行时配置为准。仅填写 listen，不会自动让 Android 把查询发送过来。

3. nameserver 与 fallback 的基础配置

下面是便于理解字段关系的配置片段，不是适配所有订阅的完整配置。它使用一个常规 DoH 上游、一个 fallback DoH 上游，并关闭 GeoIP 筛选，只用明确的保留地址段展示过滤逻辑。两个 HTTPS 服务都必须能在当前网络和路由条件下访问。

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
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: false
    ipcidr:
      - 240.0.0.0/4

198.18.0.1/16 是 Fake IP 地址池配置，用于建立域名与虚拟地址的映射，不应填写代理节点地址。
240.0.0.0/4 在这里作为异常返回值筛选示例；这不是一份完整的异常地址清单，也无法识别所有错误解析。
geoip: false 表示不按 GeoIP 条件挑选 fallback，避免把地理数据库差异混入这次测试。
ipv6: false 用于先缩小排查范围。需要 IPv6 时，应确认节点、网络和接管路径均支持，再单独开启验证。

上游不是越多越好。多个服务器可能增加查询量，返回结果也可能不同。先用一组可达且行为可解释的上游建立基线，再添加域名策略或 fallback。加密 DNS 保护的是设备到该解析服务之间的查询传输，不代表后续网站连接自动经过代理。

4. fallback-filter 怎样决定采用哪组结果

在经典 Clash 的常见实现中，配置了 fallback 后，两组查询可能并发进行。内核根据过滤条件判断采用哪组答案，而不是先等待 nameserver 完全超时，再开始询问 fallback。具体并发、缓存和错误处理行为仍应结合使用的内核确认。

三种常用筛选条件

GeoIP：经典配置常以 geoip: true 配合 geoip-code: CN，将主解析的地址归属作为选择依据。判断依据是 GeoIP 数据库中的 IP 地理归属，数据库版本也会影响结果。
IP 网段：ipcidr 用于识别主解析答案中的指定地址范围。例如命中上方配置的保留网段时，改用 fallback 结果。
域名：domain 可让匹配的域名使用 fallback 结果。具体匹配语法需按内核文档确认，不能直接把代理规则里的整行语法粘进列表。

开启 GeoIP 筛选后，某个使用海外 CDN 地址的正常网站也可能触发 fallback。这是筛选规则的结果，不足以证明主解析遭到干扰。相反，异常答案也可能落在看似正常的地址范围内。因此，不要把 fallback-filter 当作能自动鉴定所有解析真伪的安全检测器。

mihomo 的域名策略与节点域名解析

mihomo 提供 nameserver-policy，可为指定域名单独选择解析器；还有 proxy-server-nameserver，专门处理代理节点服务器域名的解析。后者有助于将“节点自身地址解析”与“用户访问的网站解析”拆开排查。这些扩展字段不应直接套进旧 Clash 内核。

# 仅作为 mihomo 的 dns 段内字段示例
nameserver-policy:
  '+.example.com':
    - https://dns.alidns.com/dns-query
proxy-server-nameserver:
  - https://dns.alidns.com/dns-query

这里的 example.com 是语法演示域名，不会替你匹配业务网站。需要按域名指定上游时，填写实际需要处理的域名，并检查客户端是否保留这些字段。不要同时改策略、fallback 和节点解析，否则难以判断是哪一步改变了结果。

5. fake-ip 与 redir-host 如何选择

比较项	fake-ip	redir-host
应用收到的地址	内核地址池内的虚拟 IP	上游查询得到的真实 IP
域名关联	通过虚拟 IP 映射保留域名关系	通过解析记录等信息关联域名与真实 IP
常见注意点	依赖真实 DNS 地址的应用可能需要例外	更依赖实际解析结果和地址关联，可能受缓存影响
排查观察	出现 198.18.x.x 不一定是错误	收到真实 IP 也不代表连接已走正确出口

一般代理浏览可先沿用客户端默认的 fake-ip。应用连接虚拟地址后，内核能找回对应域名，再结合规则决定如何建立实际连接。它并不要求每次向应用返回地址前，都先完成目标网站的真实地址解析；但实际出口、IP 类规则和具体路由仍可能需要解析。

如果只有投屏、局域网发现或某个应用异常，可以考虑 fake-ip-filter，让特定域名不返回 Fake IP。先确认域名，再添加最小范围例外，不要一开始就排除所有域名。不同版本的过滤模式和匹配能力可能不同，加入字段后应看配置加载日志。

切换到 redir-host 后，应用往往仍保存旧的 DNS 或连接缓存。应停止并重新启动代理服务，彻底退出测试应用后再打开。对 Fake IP 地址执行 ping，不能作为代理网站是否可用的判断依据。

6. 安卓 DNS 劫持与 TUN 配置的边界

原版 Clash for Android 的 VPN 接管由安卓客户端与内核协同实现，不等于把桌面 TUN 配置原样搬到手机。先在客户端“设置”中检查 DNS 覆盖、网络栈和应用访问控制相关选项；不同分支的菜单名称不统一，不能把某个分支的按钮位置当作通用路径。

对于明确支持 mihomo TUN 配置的客户端，下面是常见字段形式。它只用于说明劫持目标，不是一份可以替代安卓客户端 VPN 设置的完整方案。

tun:
  enable: true
  dns-hijack:
    - any:53
    - tcp://any:53

any:53 用于常见的 UDP DNS 接管，tcp://any:53 补充 TCP DNS。是否生效，还取决于流量有没有进入该 TUN、客户端是否允许这些设置，以及是否有额外路由排除项。安卓端由客户端创建 VPN 接口时，应优先使用其支持的配置方式，不要为套用片段而重复创建另一套接管设置。

7. 修改后的验证顺序与常见故障

确认配置已加载。保存后重新加载配置，检查是否出现 YAML 缩进、未知字段或地址格式错误。确认选中的配置就是刚才编辑的那一份。
检查运行时覆盖。若客户端提供“覆写”或“DNS 设置”，对照其中的开关与服务器列表。订阅文件改了，不等于最终运行参数已经改变。
固定测试条件。只使用一个浏览器、一个网络和一个节点；记录 Wi-Fi 或移动数据状态。先排除浏览器独立 DoH，再访问一个此前没有打开的域名。
查看日志。临时提高到客户端支持的调试日志级别，寻找上游超时、TLS 错误、节点域名解析失败等记录。测试后恢复日常级别，分享日志前隐藏订阅地址和认证信息。
每次只改一项。按“接管路径 → 上游可达性 → 模式 → fallback 筛选”依次验证。恢复网络后再逐项加回个性化设置。

开启劫持后，所有网站都打不开

先看 DNS 上游是否超时。如果上游只能通过代理访问，而代理节点的域名又依赖该上游才能解析，就可能出现启动依赖循环。优先修复可达的引导解析路径；在 mihomo 中，再考虑单独配置节点域名解析。不要仅靠反复切换规则模式掩盖问题。

网页能开，但内网设备或投屏失效

检查内网域名是否需要路由器或企业 DNS 才能解析。公共 DNS 通常不知道家庭路由器维护的设备名称，也无法自动取得企业内网记录。可按内核支持情况为这些域名指定本地上游，必要时添加 Fake IP 例外；同时检查局域网地址是否被错误送进代理。

订阅一更新，DNS 修改就消失

远程订阅通常会用新内容覆盖旧文件。若客户端提供持久化覆写、合并或补丁机制，应使用该机制保存 DNS 定制；没有这类功能时，先保留本地副本，并明确更新时需要重新合并哪些字段。不要把临时编辑的结果误当成已经固定生效。

最后，把“解析到了什么地址”和“连接从哪里出去”分开验证。前者由 DNS 配置、缓存和接管路径决定，后者还受代理规则、策略组与节点状态影响。需要核对完整配置结构时，可继续查看完整文档，避免只改 DNS 却遗漏规则或网络入口。