Mihomo DNS设置、Fake-IP解析、nameserver与DNS处理机制指南

把入口、上游与答案分开

一次DNS设置至少包含三件事：应用将查询发给哪里，核心使用哪个上游解析，以及最终返回何种答案。dns.enable 控制是否启用内部DNS，listen 定义监听；仅修改nameserver不一定会改变系统和应用的查询路径。

系统DNS、浏览器安全DNS、应用独立解析与TUN接管都可能参与其中。检查时应先确认查询确实进入核心，再讨论上游的优先级。具体操作可以沿DNS请求路径逐层对照。

字段	主要职责	容易混淆的地方
`nameserver`	一般域名的默认解析服务器	不自动改变所有应用的DNS入口
`default-nameserver`	解析DNS服务器自身的域名	不是所有业务查询的统一最高优先级
`nameserver-policy`	为匹配域名指定解析服务器	会影响nameserver与fallback的预期路径
`proxy-server-nameserver`	代理节点域名解析	与业务目标域名不是同一任务
`direct-nameserver`	直连出口的域名解析	需结合专用字段及策略配置判断
`fallback`	与过滤条件共同参与备用解析	不是仅在首个上游断线后才生效

fallback-filter 影响结果采用条件，检查时还要查看域名策略是否先匹配。专用字段为空时如何继续解析，应对照当前配置。上游本身使用域名、且连接又依赖代理时，需要避免解析与代理建立之间的循环依赖。

enhanced-mode 可以选择fake-ip或redir-host。前者对适用查询分配虚拟映射地址，后者以真实解析结果处理DNS。Fake-IP地址不是你的公网IP，也不是网站真实服务器IP。应用后续连接应进入理解这份映射的核心，不能把虚拟地址随意交给其他网络环境。

fake-ip-range 定义地址池；fake-ip-filter 需要结合过滤模式，决定匹配域名如何处理。局域网名称与某些应用可能需要有针对性的设置，详细机制与局部示例见Fake-IP映射与过滤规则。模式选择应基于实际兼容性验证，不能用“虚拟”或“真实”判断优劣。

系统、浏览器和核心可能各有缓存。配置已加载后，用同一名称、同一记录类型、同一查询入口做对照，避免把缓存结果当作上游仍未变更。A与AAAA记录应分别查看；DNS的IPv6设置与系统IPv6出口可用性需要分开验证。

DoH和DoT通过不同加密传输承载DNS消息。应用独立使用加密DNS时，可能不会经过预期的传统DNS监听或53端口接管。先读取应用设置与核心记录，再决定是否需要改变查询路径。不要通过跳过TLS证书验证处理上游失败。

DNS成功不代表目标服务可用，DNS失败也不一定是Fake-IP造成。区分没有收到查询、上游超时、返回空记录和答案正常但连接失败。后一种情况应进入连接排查流程；若查询入口不明确，先核对TUN与DNS接管的关系，再调整具体字段。

技术参考：Mihomo DNS 官方文档。字段支持与系统行为请结合实际核心版本核对；示例不代表当前设备的真实状态。