mihomo DNS 配置详解：nameserver、fallback 分组与 fake-ip 劫持写法

先确认 DNS 请求经过哪里

配置 mihomo DNS，先分清三个环节：应用把查询交给谁、mihomo 向哪个上游解析、最终连接按什么规则转发。把 nameserver 换成加密 DNS，只改变中间一环；如果浏览器仍在使用自己的安全 DNS，这次查询可能根本没有进入 mihomo 的 DNS 模块。

本文面向 Clash Meta 后续发展的 mihomo 内核。不同客户端会在界面中覆盖 DNS 或 TUN 字段，因此应以实际加载的运行配置为准，而不是只看订阅原文件。旧版 Clash 内核不能保证支持本文涉及的全部字段。

备份当前配置，记录系统代理、TUN、DNS 覆写三个开关的状态。
查看客户端的内核信息，确认正在运行 mihomo，而不是仅凭客户端名称判断。
先用本地 127.0.0.1:1053 测试解析，再决定是否启用 TUN 接管。
一次只调整一组字段；每次重新加载后检查日志，再测试同一域名。

nameserver 与 default-nameserver：先跑通最小配置

下面是一段用于合并进现有配置的 DNS 示例，不是完整的代理订阅。它不包含节点和规则，也不需要你删除原有的 proxies、proxy-groups 或 rules。配置中只保留一个顶层 dns:，把字段合并进去，避免重复键导致加载结果不明确。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "localhost"
    - "*.lan"
    - "*.local"
    - "+.home.arpa"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

字段	这段配置中的作用
`enable`	启用 mihomo 内置 DNS 模块。
`listen`	在本机回环地址的 1053 端口接受 DNS 查询，不对局域网开放。
`default-nameserver`	为上游 DNS 服务的域名提供引导解析，避免一开始就不知道 DoH 服务器的地址。
`nameserver`	配置常规解析使用的上游；示例使用两个 HTTPS DNS 地址。
`ipv6: false`	在 DNS 模块中对 AAAA 查询返回空结果，便于先排查 IPv4 链路；不是关闭操作系统 IPv6。

不要把上游列表当作固定主备顺序

nameserver 写两项，不表示“第一项失败后才使用第二项”。内核可能并发查询并采用可用响应，不应依赖列表位置实现严格主备。先选择当前网络确实可达的上游，再考虑延迟；添加十几个地址通常只会增加排查变量。

default-nameserver 也不是“所有网站默认都走这里”。它主要解决 DNS 服务域名本身如何解析的问题。示例用 IP 地址提供引导，但这些初始查询并不会因为后续采用 DoH 就自动变成加密查询。

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

fallback 是另一组解析上游，不是代理策略组，也不会创建一个可供节点选择的分组。当配置同时包含 nameserver 和 fallback 时，内核可并行进行解析，并结合 fallback-filter 判断是否采用 fallback 的结果。把它理解成“主 DNS 超时才启动的备用 DNS”，容易误判查询流量。

需要按 IP 地理位置筛选结果时，可以把以下字段合并到前面的同一个 dns: 下。先单独确认这些上游在当前网络可达；写入一个不可达的 DoH 地址，不能自动解决污染或连接问题。

  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

按这三个条件理解筛选过程

地理位置条件：启用 geoip: true 并设置 geoip-code: CN 后，常规解析结果不属于指定地区时，会倾向采用 fallback 结果。这里检查的是解析出的 IP，而不是域名后缀。
地址段条件：ipcidr 标出应排除的常规解析结果地址段。示例中的 240.0.0.0/4 是一个明确的筛选条件，不是网站流量的代理路由。
数据依赖：GeoIP 判断依赖内核所用的地理数据。数据缺失、过旧或 CDN 地址归属变化，都可能影响选择结果。

这套机制不保证“国内域名用国内 DNS，国外域名用国外 DNS”。域名可以部署在多个地区，CDN 也会返回不同地址。对内部业务域名或已知服务需要确定性分流时，使用 nameserver-policy 比依赖地理判断更直接。

nameserver-policy：为指定域名选择解析上游

办公网络、家庭 NAS 和打印机常使用只有内部 DNS 才知道的名称。这类域名不适合交给公共解析器。下面以家庭网络为例：仅当路由器地址确实是 192.168.1.1，且它能解析 home.arpa 内部记录时，才采用这段配置。

  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1

这仍是合并进现有 dns: 的局部字段。匹配的域名按该策略选择上游，不要再假设它完整沿用普通的 nameserver/fallback 筛选流程。这里的 +.home.arpa 用于匹配该域及其子域；换成公司内部域名前，先向网络管理员确认解析服务器和访问要求。

nameserver-policy 与 fake-ip-filter 解决不同问题：前者决定向谁询问，后者决定是否向应用返回假地址。给内部域名设置 DNS 策略后，如果设备发现或直连服务还需要真实 IP，也应把对应域名加入 fake-ip 排除列表。

fake-ip 与 redir-host：返回假地址还是实际地址

enhanced-mode 控制 DNS 增强模式。fake-ip 给应用返回一个保留地址范围内的映射地址；连接再次进入 mihomo 时，内核根据映射恢复域名，再执行规则和出站处理。这个地址不是网站的真实服务器，也不能交给没有经过 mihomo 的设备直接访问。

比较项	fake-ip	redir-host
应用收到的 A 记录	通常是配置地址池中的映射地址	真实解析得到的地址
域名关联	通过假地址映射保留域名信息	依赖 DNS 缓存关联等机制恢复域名
连接要求	访问假地址的连接必须回到对应的 mihomo 实例	拿到真实 IP，但连接仍须按预期进入代理或路由链路
常见兼容问题	局域网发现、校验真实 IP 的应用、绕过接管的连接	共享 IP、缓存关联和应用自带 DNS 带来的域名识别限制

何时加入 fake-ip-filter

局域网域名、需要真实地址的设备发现服务，可以先加入排除列表。默认黑名单式过滤下，命中列表的域名不返回 fake-ip，而按真实地址解析。不要把所有域名都加进去，否则虽然配置仍写着 fake-ip，实际效果却已大幅改变。

如果只是某个应用异常，先排除它依赖的具体域名，而不是立刻切换全局模式。切换到 redir-host 后，应清理客户端 DNS 缓存并重启相关应用，必要时刷新系统 DNS 缓存；旧的 198.18.x.x 记录不会因为修改 YAML 就立即从所有应用中消失。

TUN DNS 劫持：接管传统 53 端口查询

DNS 劫持在这里指把经过 TUN 的指定 DNS 流量交给 mihomo DNS 模块处理，并不是修改远端网站的解析记录。桌面系统要接管未使用系统代理的应用时，通常需要先正确启用 TUN 路由，再配置 DNS 劫持。

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

any:53 用于匹配经过 TUN 的 UDP 53 查询，tcp://any:53 补充 TCP 53。auto-route 用于自动配置路由，auto-detect-interface 用于检测出站接口。实际接管范围仍受操作系统、路由和客户端实现影响，不能仅凭这段 YAML 判断所有 DNS 都已被接管。

保留权限：桌面客户端通常需要服务模式或相应管理员权限来创建虚拟网卡和路由。先检查权限报错，再调整 DNS 字段。
区分端口：listen: 127.0.0.1:1053 是显式查询入口；TUN 的 53 端口劫持由内核处理，不要求把系统 DNS 地址写成带 1053 的字符串。
检查加密 DNS：DoH 通常使用 443 端口，DoT 通常使用 853 端口。仅匹配 53 端口无法强制接管它们，排查时可暂时关闭浏览器“安全 DNS”后对照测试。
避免开放解析：只有确实为局域网设备提供 DNS 时才考虑监听局域网地址，同时配置防火墙。不要为方便测试直接开放到公网。

Android 客户端通常通过系统 VPN 接口接管流量，桌面的自动路由字段不一定原样适用；iOS 客户端也受自身网络扩展实现限制。不要把桌面 TUN 段直接复制到所有平台，优先使用客户端提供的 VPN、DNS 和绕过设置。

验证与排错：分开检查解析、接管和连接

第一步：直接查询本地 DNS

启用配置后，在安装有 dig 的系统上运行下面两条命令。第一条查询 UDP，第二条查询 TCP，用于确认本地 DNS 入口是否响应。它们显式指定了服务器，因此不能单独证明系统 DNS 已被 TUN 接管。

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

Windows 可使用系统自带的 nslookup 指定测试端口：

nslookup -port=1053 example.com 127.0.0.1

fake-ip 模式下，未被过滤的普通 A 查询通常返回 198.18.0.1/16 地址池中的地址；它只证明当前查询命中了假地址映射，不证明上游真实解析和代理出站均正常。命中排除列表的域名则应按真实解析路径检查。

第二步：确认连接回到同一内核

打开客户端连接面板，访问一个 HTTPS 网站，检查是否出现对应域名。
确认命中了预期规则，查看最终出站是 DIRECT 还是代理策略中的节点。
若解析得到 fake-ip 却没有连接记录，优先检查 TUN、路由和应用绕过设置。
若连接已进入内核但超时，再检查节点、规则与上游连接，不要反复更换 DNS 模式。

第三步：按症状缩小范围

症状	优先检查	下一步操作
本地 1053 查询超时	DNS 是否启用、配置是否加载、端口是否被占用	查看启动日志，确认监听地址，再重新查询
DoH 日志出现 TLS 错误	系统时间、证书、上游可达性与引导解析	校准时间并测试单个上游，不关闭证书验证来掩盖问题
网页可用但 NAS 域名失效	内部 DNS 策略与 fake-ip 排除	为内部域名指定路由器 DNS，并检查它是否需要真实地址
改配置后结果没变化	客户端覆写、订阅更新、应用及系统缓存	核对运行配置，重新加载并刷新缓存
仅浏览器表现不同	浏览器安全 DNS、代理扩展、独立缓存	临时关闭相关功能，用相同域名对照测试

Windows 可执行 ipconfig /flushdns 刷新系统解析缓存，但浏览器和应用仍可能保留自己的记录。共享诊断日志时，保留时间、错误类型和相关字段即可，删除订阅 URL、认证信息及敏感内部域名。

最后把确认有效的 DNS 调整放进客户端支持的覆写或合并配置入口，避免订阅刷新后丢失。保留“最小可用配置”和“当前配置”两份记录：出现故障时先回退，再逐项恢复 fallback、域名策略和 TUN 接管，比一次修改所有开关更容易定位原因。需要了解配置文件与代理规则的整体关系，可继续查看完整手册。