Mihomo怎么设置DNS？最小配置与生效验证步骤
简答：Mihomo设置DNS，先确认正在运行的配置入口，再在顶层<code>dns:</code>下加入<code>default-nameserver</code>、<code>nameserver</code>和需要的解析模式。最稳妥的做法是：备份配置、粘贴最小YAML、校验并重载、查看日志，最后用系统命令或客户端日志确认查询确实进入Mihomo。本文讲通用YAML、Fake-IP与TUN排查，不绑定某个图形客户端的菜单路径。
定义：Mihomo DNS配置是内核用于域名解析、代理节点域名解析、Fake-IP映射和直连解析的一组顶层配置，主要写在当前实际加载的YAML文件的<code>dns</code>字段中。
先照抄最小配置：先确认DNS模块能启动
如果你只是想先把Mihomo DNS设置好，不要同时修改TUN、规则、代理组和多个DNS策略。先备份正在使用的配置，然后在最终会被内核加载的YAML中找到或新增顶层dns:字段。Mihomo文档说明，default-nameserver用于解析DNS服务器域名，nameserver用于常规域名查询，enhanced-mode可选择fake-ip或redir-host。Mihomo官方DNS配置文档
带注释版：
dns:
enable: true
ipv6: false
listen: 127.0.0.1:1053
enhanced-mode: redir-host
default-nameserver:
- 1.1.1.1
- 8.8.8.8
nameserver:
- https://dns.cloudflare.com/dns-query
- https://dns.google/dns-query
无注释版：
dns:
enable: true
ipv6: false
listen: 127.0.0.1:1053
enhanced-mode: redir-host
default-nameserver:
- 1.1.1.1
- 8.8.8.8
nameserver:
- https://dns.cloudflare.com/dns-query
- https://dns.google/dns-query
- enable：启用Mihomo内置DNS。设置为
false时会使用系统DNS。 - listen：让Mihomo在本机的1053端口提供DNS服务，方便使用
dig验证。若该端口冲突，可换成其他未占用端口。 - default-nameserver：用于解析DoH服务器域名。它应先使用可直接访问的IP地址，避免出现“DoH地址本身无法解析”的循环问题。
- nameserver：实际处理常规域名查询的上游DNS。DoH、DoT、UDP等格式应以当前官方文档和所用内核版本为准。
- ipv6: false：这里只是临时排障策略，用于先排除IPv6路径影响，不是所有网络环境都应长期关闭IPv6。
- enhanced-mode: redir-host：先返回实际解析地址，便于观察基础解析是否正常；确认基础链路后，再按需要切换Fake-IP。
上面两个公共DNS地址只是格式示例，不保证在每个网络环境都能访问。如果日志显示上游超时，可以先改用当前网络可达的DNS地址，再逐一测试DoH或DoT。Mihomo官方示例同样将default-nameserver与加密DNS上游分开配置。Mihomo官方配置示例
配置入口速查：先找到真正被加载的文件
| 使用方式 | 优先寻找的入口 | 需要确认的事项 |
|---|---|---|
| Windows、macOS、Linux图形客户端 | 配置文件、Profiles、Config、编辑配置、覆写或Mixin | 当前运行的配置名称、最终合并内容，以及保存后是否需要重载内核。 |
| 订阅配置 | 订阅详情、配置覆写、Mixin、Override或本地补丁 | 订阅更新是否会覆盖手动修改，DNS字段是否合并到最终配置。 |
| OpenWrt或路由器服务 | 服务设置中的配置文件路径、运行配置或导入配置 | 后台显示的运行文件是否就是你编辑的文件，端口是否与dnsmasq等服务冲突。 |
| 命令行运行Mihomo | 启动参数指定的配置目录或配置文件 | 启动日志中的配置路径、运行用户权限和配置校验结果。 |
不同图形客户端的菜单名称和配置合并方式可能不同，因此不要只修改下载目录里的旧YAML。应先在客户端中查看当前配置名称、配置路径或最终配置预览；如果没有预览功能，就从启动日志确认实际加载路径。本文不把某个客户端的菜单路径推广到所有客户端，字段兼容性以当前官方文档和你使用的Mihomo内核版本为准。
固定操作顺序是：编辑配置—保存—校验—重新载入—查看日志—验证业务。如果校验失败，先恢复备份，再只修改缩进、字段名和端口，不要同时改动规则与TUN。
nameserver、default-nameserver和节点解析字段怎么区分
| 字段 | 作用 | 排查重点 |
|---|---|---|
default-nameserver | 解析DNS服务器域名，例如DoH地址中的域名。 | 使用DoH时不要省略；优先选择可直接访问的IP或已验证可达的加密DNS。 |
nameserver | 常规域名解析服务器。 | 只改它不一定能解决代理节点域名解析失败。 |
nameserver-policy | 按域名、域名集合或规则指定解析服务器，优先级高于普通查询。 | 域名匹配写错时，查询不会按预期分流。 |
proxy-server-nameserver | 仅用于解析代理节点域名。 | 适合“节点IP能连、节点域名超时”的场景，但不会自动替代全部业务DNS。 |
direct-nameserver | 为直连出口指定DNS服务器。 | 还要确认是否让它遵循nameserver-policy。 |
fallback-filter.geosite | 旧式备用DNS筛选字段。 | 官方文档已标记该字段弃用，新配置优先使用nameserver-policy。 |
这些字段的名称和行为可能随Mihomo内核版本变化，尤其是DNS策略、节点解析和弃用字段。写配置前应对照当前官方DNS文档；本文只使用官方文档当前列出的字段说明。Mihomo官方DNS字段说明
如果普通网页能打开，但节点域名一直超时，可在基础配置中增加节点专用解析：
dns:
enable: true
default-nameserver:
- 1.1.1.1
- 8.8.8.8
nameserver:
- https://dns.cloudflare.com/dns-query
proxy-server-nameserver:
- 1.1.1.1
这里的IP只是示例。若日志显示节点域名查询失败，先确认该上游DNS本身可达，再判断是解析问题还是节点协议、规则和链路问题。
Fake-IP、redir-host与TUN如何配合
fake-ip与redir-host是DNS处理模式，TUN是流量接管方式，三者不能互相替代。开启TUN不代表必须使用Fake-IP；使用系统代理也不代表所有DNS请求都会进入Mihomo。
- redir-host：返回实际解析结果，适合先做基础DNS排查，也更容易观察域名对应的真实地址。
- fake-ip：为域名分配Fake-IP，再利用映射处理连接。它适合需要更完整域名接管的场景，但局域网、本地域名和部分应用可能需要过滤。
- TUN：可以接管不遵循系统代理的应用，但实际DNS接管还取决于
dns-mode、dns-hijack、路由、系统Private DNS和IPv6环境。
Mihomo官方TUN文档说明，dns-mode可设为disabled、native或hijack；hijack需要结合平台条件使用，Windows通常需要strict-route，Linux通常需要auto-redirect。官方还注明，Windows和macOS不能自动劫持发送到局域网的部分DNS请求，Android启用Private DNS时也可能无法自动劫持。Mihomo官方TUN配置文档
建议按以下顺序测试：先使用redir-host并暂时关闭TUN，确认普通域名、节点域名和直连业务正常；再开启TUN，检查dns-mode、dns-hijack与strict-route；最后才切换Fake-IP。每次只改一项，日志才能说明是哪一步产生影响。
Fake-IP下局域网、NAS和打印机打不开怎么办
如果切换Fake-IP后局域网设备、本地域名或打印机发现异常，可以先使用最小过滤范围：
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-filter-mode: blacklist
fake-ip-filter:
- '*.lan'
- '*.local'
- localhost
nameserver:
- https://dns.cloudflare.com/dns-query
Mihomo官方文档说明，fake-ip-filter支持域名通配符，过滤模式包括blacklist、whitelist和rule。不要一开始把所有域名都放进过滤列表，否则可能失去Fake-IP接管的意义。先加入实际使用的局域网后缀、本地域名或出现问题的设备域名。Mihomo官方Fake-IP配置说明
修改后重新载入配置，清理相关应用的DNS缓存，再分别测试NAS地址、打印机地址和普通网站。如果只有某个局域网域名失败，先查看Mihomo日志中该域名由哪个上游回答，再决定是否增加过滤规则。
Windows、macOS、Linux和OpenWrt如何验证是否生效
Windows：如果Mihomo监听本机53端口，可在PowerShell或命令提示符执行：
nslookup example.com 127.0.0.1
本文示例监听的是127.0.0.1:1053，Windows原生nslookup不能可靠地使用“主机#端口”写法。此时应使用支持指定端口的dig，例如在WSL或已安装DNS工具的环境中执行：
dig @127.0.0.1 -p 1053 example.com
如果Windows没有可用的dig，就用客户端DNS日志和配置中的监听端口验证，不要把nslookup example.com 127.0.0.1#1053当作原生命令。
macOS和Linux：执行：
dig @127.0.0.1 -p 1053 example.com
如果使用默认53端口，也可以执行：
dig @127.0.0.1 example.com
OpenWrt：先在服务界面确认Mihomo的实际配置文件和DNS监听端口，再从路由器终端执行相同的dig命令。若53端口被dnsmasq占用，不要直接抢占端口；先确认系统DNS转发关系，再决定让Mihomo监听其他端口或由TUN接管。
图形客户端：先看配置校验结果和启动日志，再使用客户端的DNS查询日志、连接日志或配置预览。不同客户端可能把订阅、覆写和Mixin合并后再交给内核，因此“文件保存成功”不等于“运行配置已改变”。
三行生效判断：
- 命令或客户端测试能够收到DNS响应，而不是超时。
- Mihomo日志出现对应域名查询，说明请求至少进入了内置DNS模块。
- Fake-IP模式下，返回地址落在配置的
fake-ip-range地址池内，并且业务连接可以继续建立。
如果命令有响应但日志没有查询记录，说明请求可能绕过Mihomo；如果日志有查询但网页仍打不开，再检查规则命中、代理组、节点连接、IPv6、MTU和丢包。Fake-IP地址出现并不单独证明业务一定正常，也不能把DNS响应直接等同于代理连接成功。
DNS设置不生效时，按现象逐项排查
| 现象 | 先检查 | 处理方法 |
|---|---|---|
| 保存后完全没有变化 | 是否修改实际运行配置，是否完成重载。 | 查看启动日志或最终配置预览，确认存在有效的dns.enable。 |
| 启动提示端口占用 | listen端口是否被dnsmasq、其他客户端或系统服务占用。 | 改用空闲端口，或停止冲突服务后再校验和重载。 |
| DoH上游无法连接 | 是否配置default-nameserver，该IP是否可达。 | 先使用可达IP测试，再恢复DoH；查看日志中的域名解析和TLS错误。 |
| 节点域名解析失败 | 日志是否显示代理节点域名超时。 | 增加proxy-server-nameserver，单独验证该上游DNS。 |
| 开启TUN后DNS异常 | dns-mode、dns-hijack、strict-route、Private DNS和IPv6。 | 先关闭TUN验证基础DNS，再逐项恢复接管参数。 |
| 浏览器和命令行结果不同 | 浏览器是否启用了Secure DNS或独立DoH。 | 临时关闭浏览器独立DNS，再对照Mihomo日志测试。 |
| 局域网设备打不开 | 是否启用Fake-IP，局域网后缀是否被过滤。 | 为实际局域网域名增加最小范围的fake-ip-filter。 |
排查时不要一次修改多个变量。先保留备份，记录原配置、重载后的日志和验证命令结果；确认问题已经解决后，再把临时关闭的IPv6、TUN或Fake-IP设置逐项恢复，避免把临时排障配置误当成长期方案。
结论：先用最小配置验证，再扩展Fake-IP和TUN
第一次设置Mihomo DNS时，建议先使用带default-nameserver的最小配置，选择redir-host，确认上游可达、配置能重载、日志能看到查询、命令能收到响应。只有当基础DNS正常后，才增加proxy-server-nameserver、nameserver-policy、Fake-IP过滤或TUN接管。
如果你使用订阅、Mixin、图形客户端或OpenWrt，最重要的不是找到一个看起来正确的YAML，而是确认它确实进入了最终运行配置。Mihomo的字段、TUN行为和弃用项可能随内核版本变化，实际部署前应以当前官方文档和所用版本为准。
常见问题
Mihomo的DNS配置写在哪里？
写在当前实际运行的配置文件或最终合并配置的顶层dns字段中。图形客户端、订阅、Mixin和OpenWrt服务可能使用不同入口，先确认运行配置路径、配置预览或启动日志，不要只修改未被加载的旧文件。
为什么最小配置还要写default-nameserver？
因为nameserver使用DoH域名时，Mihomo需要先解析这些上游服务器的域名。default-nameserver用于这一步，使用可达IP可以减少“上游地址本身无法解析”的循环问题。
Windows怎么验证1053端口的Mihomo DNS？
Windows原生nslookup不能可靠地使用主机加井号端口写法。可以在WSL或已安装DNS工具的环境中执行dig @127.0.0.1 -p 1053 example.com；没有dig时，使用Mihomo客户端的DNS日志和配置监听端口验证。
Mihomo应该用fake-ip还是redir-host？
没有适合所有环境的唯一答案。redir-host更适合先排查基础解析，Fake-IP适合需要更完整域名接管的场景，但局域网、本地域名和部分应用可能需要fake-ip-filter。建议先用redir-host验证，再按实际需求切换。
只修改nameserver后，为什么节点还是连接失败？
普通域名解析和代理节点域名解析可能走不同路径。先看日志是否是节点域名解析超时；如果是，可增加proxy-server-nameserver，并单独确认该上游DNS可达。若解析正常，再检查规则、代理组、节点协议、MTU和丢包。
开启TUN后DNS为什么像没有生效？
TUN还涉及dns-mode、dns-hijack、strict-route、auto-redirect、系统Private DNS、浏览器独立DoH和IPv6。先关闭TUN确认基础DNS，再逐项恢复接管参数，并用日志确认请求是否进入Mihomo。
fallback-filter.geosite还能继续使用吗？
Mihomo官方DNS文档已将fallback-filter中的geosite字段标记为弃用。新配置应优先根据当前文档使用nameserver-policy，并结合所用内核版本进行校验。