Mihomo DNS设置教程：最小配置、Fake-IP与生效验证
简答：Mihomo DNS 设置的最短路径是：备份当前配置，在实际运行的配置文件中启用 dns，先使用 listen、default-nameserver、nameserver 和 enhanced-mode 四个核心字段，再重载配置。若监听端口是 127.0.0.1:1053，应使用 <code>dig @127.0.0.1 -p 1053 example.com</code> 验证，不能把普通 nslookup 命令当成 1053 端口测试。Fake-IP 返回 198.18.0.0/16 只能作为辅助现象，且域名必须没有命中 fake-ip-filter。
定义：Mihomo DNS 是内置的域名解析模块，负责接收客户端或 TUN 流量的 DNS 请求，并根据 enhanced-mode、nameserver、nameserver-policy 等字段决定解析方式与上游 DNS。
先试这一步：备份并放入最小配置
本文面向已经安装 Mihomo 或使用兼容 Mihomo 内核客户端的读者。不同客户端的菜单名称、配置合并方式和实际运行文件可能不同，因此不要只修改下载目录里的模板；应在客户端显示的“当前配置、编辑配置、覆写或 Merge”位置操作，并先复制一份备份。
官方文档说明，dns.enable 关闭时会使用系统 DNS，listen 用于开启 DNS 监听，enhanced-mode 可选 fake-ip 或 redir-host。字段默认值和兼容行为应以当前文档及你的 Mihomo 版本为准。参考：Mihomo DNS 配置文档。
可先使用下面这份最小示例。示例中的上游地址只是配置示意，实际使用前应确认当前网络能访问，并按你的分流需求替换。
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
nameserver:
- https://dns.google/dns-query
- https://cloudflare-dns.com/dns-query
不要直接复制的部分：如果你的客户端已经有完整的 dns: 段落，应合并字段，不要重复写两个顶层 dns:。如果本机 1053 端口被占用，应换成未占用端口，并在后续验证命令中同步修改。
字段怎么选：fake-ip、redir-host与上游 DNS
| 字段 | 作用 | 新手建议 |
|---|---|---|
enable | 是否启用 Mihomo 内置 DNS | 要使用内置 DNS 时设为 true |
listen | 提供 DNS 服务的监听地址和端口 | 本机测试可用 127.0.0.1:1053，避免直接占用系统 53 端口 |
default-nameserver | 解析其他 DNS 服务域名所需的基础 DNS | 优先填写 IP；不要把无法解析的域名直接放在这里 |
nameserver | 常规域名查询使用的上游 DNS | 先配置一组可访问的 UDP、DoT 或 DoH 地址 |
enhanced-mode | 选择 fake-ip 或 redir-host | 遇到局域网、设备发现或特殊应用异常时，先切换到 redir-host 对比 |
fake-ip-filter | 指定不分配 Fake-IP 的域名 | 只添加确有问题的局域网、主机名或特殊服务域名 |
官方文档将 fake-ip 和 redir-host 列为两种增强模式，并说明 Fake-IP 过滤规则支持通配符。Fake-IP 模式下，未被过滤的域名可能得到 Fake-IP 映射；命中过滤规则的域名则不会按同一方式返回。因此，“查询结果是 198.18.0.0/16”不能单独证明所有 DNS 或代理链路都正确。参考：DNS 字段说明。
建议先不要同时加入 fallback、复杂的 nameserver-policy、respect-rules 和 TUN 接管。先确认基本解析可用，再一次只增加一个字段，便于定位是哪项配置造成异常。
nameserver-policy、proxy-server-nameserver与fallback怎么处理
nameserver-policy 用于按域名或规则集指定解析服务器，而且优先级高于普通的 nameserver 与 fallback 查询。它适合在你已经确认基础配置稳定后，再为内网域名、特定域名或规则集分流。官方文档也提醒，规则键支持域名通配形式，具体语法要以当前版本文档为准。
proxy-server-nameserver 只用于解析代理节点域名。当节点地址本身是域名、而普通 DNS 又无法解析时，该字段可能成为关键排查点。若启用了 respect-rules，官方文档要求同时考虑代理节点域名的解析，否则可能出现 DNS 查询依赖代理、代理又依赖 DNS 的循环问题。参考：proxy-server-nameserver 与 respect-rules 说明。
fallback 是备用解析服务器。配置后，相关 fallback-filter 行为会参与结果筛选；官方文档还标注 fallback-filter.geosite 已弃用，建议使用 nameserver-policy。因此，不建议把旧教程中的复杂 fallback 模板原样复制到新版本。
一个更稳妥的升级顺序是：先只保留 nameserver；节点域名解析失败时再增加 proxy-server-nameserver；确实需要按域名分流时再增加 nameserver-policy；最后才评估是否需要 fallback。
正确验证：1053端口、Fake-IP与实际连接要分开看
- 先重载配置。在客户端执行重载、切换配置或重启内核，并记录日志中是否出现 YAML 解析错误、端口占用或 DNS 初始化失败。
- 确认监听端口。配置为
127.0.0.1:1053时，使用系统中可用的dig执行：dig @127.0.0.1 -p 1053 example.com。若要查看简短结果，可用：dig +short @127.0.0.1 -p 1053 example.com。 - Windows用户的替代方法。Windows 自带的 nslookup 常用写法不能按
nslookup example.com 127.0.0.1指定 1053 端口，因此不能用它证明 1053 监听生效。可在 WSL 或已安装 dig 的环境中运行上面的命令；如果暂时没有 dig，只能先用客户端日志、监听端口检查和实际请求记录进行辅助判断。 - 再看 Fake-IP现象。在未命中
fake-ip-filter的普通域名上，查询结果可能落在198.18.0.0/16。但这只是 DNS 返回结果或映射现象，不等于应用一定通过代理连接，也不代表局域网域名必须返回 Fake-IP。 - 最后复测应用。分别测试一个普通公网域名、一个明确需要直连的内网域名，以及你的节点域名。记录查询结果、Mihomo 日志中的请求、规则命中和应用是否能建立连接，不能只看出口 IP 或一次网页打开。
Mihomo 官方 DNS 流程文档将域名规则、nameserver-policy、nameserver、fallback-filter、direct-nameserver 和最终连接区分为不同阶段；因此验证时也应分阶段记录，而不是把一次 DNS 返回结果当成完整链路证明。参考：Mihomo DNS resolve process。
按症状排查：DNS不生效、节点失败和局域网异常
| 现象 | 先检查 | 处理方式 |
|---|---|---|
| dig 连接被拒绝 | 配置是否真的加载、1053 是否被占用 | 看启动日志，确认监听地址与验证命令端口一致 |
| dig 有结果但应用仍打不开 | 系统 DNS、浏览器 DoH、TUN 或系统代理是否绕过客户端 | 暂时关闭浏览器自定义 DoH，复测应用请求与 Mihomo 日志 |
| 节点域名解析失败 | 节点地址是否为域名、是否配置 proxy-server-nameserver | 先为节点域名配置专用解析，再复测节点连接 |
| 局域网设备或内网域名异常 | fake-ip-filter、直连规则和局域网 DNS | 把确有问题的内网域名加入过滤规则，或切换 redir-host 对比 |
| 所有域名都返回真实 IP | 是否实际使用了当前配置、是否误用 whitelist 或过滤规则 | 检查配置合并结果和 fake-ip-filter-mode，不要仅凭结果下结论 |
如果客户端显示有“配置覆写”“Merge”“运行配置”或“当前配置”页面，应优先以该页面呈现的最终配置为准。模板文件写对但没有被合并，和配置错误的表现可能相同。
升级前后字段行为可能变化。官方发布页当前列出的稳定版本为 v1.19.33，但你的客户端可能内置其他版本；涉及新字段、弃用字段或 TUN DNS 行为时，应先查看客户端内核版本与对应文档。参考：Mihomo 官方发布页。
回滚与复测清单
- 保留修改前的原配置文件，不要直接覆盖唯一备份。
- 如果新增字段后启动失败，先恢复到最小配置，再逐项加回。
- 每次只改变一个变量，例如只切换
fake-ip与redir-host，或只新增nameserver-policy。 - 记录 Mihomo 内核版本、客户端名称、监听地址、查询命令和返回结果。
- 确认普通公网域名、内网域名、节点域名分别通过了复测。
- 不要把 Fake-IP、DNS 返回结果、规则命中和应用实际连接地址混为同一个判据。
如果问题只发生在 TUN 模式，应另行检查 TUN 的 DNS 接管、系统 DNS 和浏览器 DoH；不要仅通过修改 nameserver 反复尝试。本文先聚焦 Mihomo DNS 基础配置，TUN 深度排查应按独立问题处理。
常见问题
Mihomo DNS监听设置为127.0.0.1:1053，为什么不能用 nslookup example.com 127.0.0.1 验证？
因为这类 nslookup 写法通常只指定 DNS 服务器地址，不能证明请求发送到了 1053 端口，实际可能访问本机 53 端口。应使用 <code>dig @127.0.0.1 -p 1053 example.com</code>，或将监听端口明确改为 53 后再使用适合 53 端口的工具验证。
DNS查询返回198.18.0.0/16，就代表Mihomo配置成功了吗？
不能单独这样判断。只有在使用 fake-ip、查询域名没有命中 fake-ip-filter、查询确实发给 Mihomo DNS 的前提下，198.18.0.0/16 才能作为辅助现象。还要结合监听端口、日志、规则命中和应用实际连接复测。
Mihomo应该使用fake-ip还是redir-host？
没有适用于所有设备的固定答案。fake-ip 便于进行域名映射和部分规则处理，但局域网、设备发现或特殊应用可能需要过滤；redir-host 返回真实解析地址，遇到兼容性问题时可作为对照方案。建议先用一种模式完成验证，再切换另一种模式比较。
nameserver和proxy-server-nameserver有什么区别？
nameserver 用于普通域名查询；proxy-server-nameserver 专门用于解析代理节点域名。节点地址是域名且普通 DNS 解析失败时，应重点检查后者。官方文档说明，proxy-server-nameserver 为空时会跟随其他 DNS 配置。
配置了DNS但浏览器仍然像没有生效，怎么办？
先确认最终运行配置已加载，再检查浏览器是否启用了独立 DoH、系统 DNS 是否被其他软件接管，以及 TUN 或系统代理是否绕过 Mihomo。使用 dig 验证内置 DNS 后，再结合 Mihomo 日志和浏览器实际请求复测。