Mihomo DNS 怎么配置？fake-ip、TUN 劫持与 DNS 不生效排查
简答：Mihomo DNS 建议先启用 dns 并使用最小 redir-host 配置，确认网页和节点域名可解析后，再按需切换 fake-ip、加入 nameserver-policy 和 TUN 的 dns-hijack。若修改后无变化，先检查客户端 DNS 覆写、当前运行配置、核心重启与本地查询结果。
定义：Mihomo DNS 配置是通过配置文件顶层的 dns: 段设置解析开关、监听地址、fake-ip 或 redir-host 模式、上游 DNS 及域名分流规则。
先试最小配置：从 redir-host 确认基础解析
本文是第三方使用指南，与 Mihomo 项目及其开发者无隶属关系。Mihomo 官方文档将 enhanced-mode 定义为 fake-ip 或 redir-host，默认值为 redir-host；enable 控制是否启用 Mihomo DNS，listen 用于提供 DNS 服务监听。参考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://cloudflare-dns.com/dns-query
- https://dns.quad9.net/dns-query先这样判定：客户端配置校验通过，Mihomo 核心能够重启，普通网页和节点域名可以解析。上面的域名和地址只是示例，实际可替换为能够访问的 DoH 或 DoT 上游；Cloudflare 官方公布的 DoH 地址是 https://cloudflare-dns.com/dns-query，Quad9 官方公布的 DoH 地址是 https://dns.quad9.net/dns-query，分别见Cloudflare DoH 文档和Quad9 服务地址文档。
监听地址安全提示：127.0.0.1:1053只监听本机，适合桌面单机。0.0.0.0:1053会监听所有网卡，可能向局域网提供 DNS 服务；只有路由器或网关确实需要被其他设备查询时才考虑使用，并应同时检查防火墙和访问范围。官方文档说明 listen 支持 UDP 和 TCP，但没有替你完成系统 DNS 或 TUN 流量接管。
场景速查卡：先选模式，再加字段
| 场景 | 先尝试 | 需要关注的字段 | 判定标准 |
|---|---|---|---|
| 电脑日常使用 | redir-host | enable、nameserver | 网页、节点域名和常用应用均可解析 |
| 手机或需要规则接管 | 先验证 redir-host，再对照 fake-ip | fake-ip-filter、TUN、dns-hijack | 切换后应用、系统联网检测和局域网仍正常 |
| 路由器或网关 | 按实际拓扑选择 | listen、路由、防火墙、TUN | 客户端和局域网设备能查询，且未意外开放公网 DNS |
| 游戏、局域网设备 | 优先用 redir-host 做兼容性对照 | 局域网域名、fake-ip-filter | 局域网主机名、游戏登录和语音连接不受影响 |
| 需要检查 DNS 泄漏 | 明确 DNS 接管路径 | TUN、dns-hijack、strict-route | 开关 TUN 前后，查询出口和客户端日志符合预期 |
这张表是排查顺序，不是对所有设备的统一官方推荐。Mihomo 官方只定义了两种 DNS 处理模式，并说明不同 TUN 字段具有平台条件；实际应以设备、客户端和当前配置共同验证，参考DNS 文档与TUN 文档。
fake-ip 和 redir-host 怎么选
redir-host返回域名解析得到的真实地址，适合先验证基础联网和应用兼容性。fake-ip会为域名分配 fake IP，Mihomo 再结合域名处理后续连接，适合需要 TUN 与规则分流的场景。官方文档明确列出这两种模式，但没有给出适用于所有设备的统一最佳选择，参考enhanced-mode 与 fake-ip-filter 说明。
dns:
enable: true
ipv6: false
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter-mode: blacklist
fake-ip-filter:
- '*.lan'
default-nameserver:
- 1.1.1.1
- 9.9.9.9
nameserver:
- https://cloudflare-dns.com/dns-query
- https://dns.quad9.net/dns-queryfake-ip-filter支持域名通配写法，官方示例包含 *.lan；这不代表所有局域网都使用 .lan。如果 NTP、STUN、系统联网检测、游戏或局域网设备异常，应先切回 redir-host确认是否由 fake-ip 引起，再根据日志和实际域名逐项增加过滤项，不要一次复制大量未经核验的名单。
DNS 字段和查询流向怎么理解
| 字段 | 用途 | 先写还是后写 |
|---|---|---|
default-nameserver | 解析 DNS 服务器自身的域名；官方要求使用 IP，也可以配置加密 DNS | 使用 DoH、DoT 上游时先写 |
nameserver | 普通域名查询的默认上游 | 最小配置建议写 |
nameserver-policy | 按域名通配或规则集合指定解析服务器，优先于默认查询 | 需要分流时再写 |
proxy-server-nameserver | 只解析代理节点域名 | 节点域名解析异常时再写 |
direct-nameserver | 指定直连出口使用的 DNS | 直连解析需要独立出口时再写 |
fallback | 备用解析服务器；启用后会配合 fallback-filter 逻辑 | 基础配置稳定后再写 |
文字流向：DNS 服务器自身的域名先由 default-nameserver 解析；普通域名优先检查 nameserver-policy，没有匹配时使用 nameserver，必要时才进入 fallback；节点域名单独看 proxy-server-nameserver，直连出口单独看 direct-nameserver。这些职责和优先级见mihomo DNS 字段说明。
官方文档明确将 fallback-filter.geosite标为已弃用，并建议使用 nameserver-policy做按域名分流。不要为了“完整”一开始同时加入 fallback、复杂过滤和多个策略，否则启动失败时难以判断是哪一项造成问题。
dns:
enable: true
default-nameserver:
- 1.1.1.1
- 9.9.9.9
nameserver:
- https://cloudflare-dns.com/dns-query
nameserver-policy:
'+.example.com':
- https://dns.quad9.net/dns-query
proxy-server-nameserver:
- https://cloudflare-dns.com/dns-query
direct-nameserver:
- 9.9.9.9example.com是示例域名，请替换为你实际需要分流的域名。增加策略后，普通域名、节点域名和直连应用都应分别完成解析；如果全部无法联网，先删除后三项，回到最小配置。
国际化 DoH 与 DoT 上游怎么替换
| 服务 | DoH 写法 | DoT 写法 | 说明 |
|---|---|---|---|
| Cloudflare 1.1.1.1 | https://cloudflare-dns.com/dns-query | tls://one.one.one.one | 地址和协议见官方文档 |
| Quad9 | https://dns.quad9.net/dns-query | tls://dns.quad9.net | 官方同时公布安全解析服务地址 |
| AdGuard DNS | https://dns.adguard-dns.com/dns-query | tls://dns.adguard-dns.com | 默认服务包含广告和跟踪器拦截 |
Cloudflare 的 DoT 使用标准 853 端口，官方公布的主机名是 one.one.one.one；Quad9 和 AdGuard 也分别公布了 DoH、DoT 地址，见Cloudflare DoT 文档、Quad9 服务地址和AdGuard 公共 DNS 地址。不同网络对上游的可达性可能不同，不能把某个公共 DNS 的可用性或速度当成固定结论。
TUN 下 dns-hijack 怎么配置
TUN 的 DNS 路径要分开理解：dns-hijack负责把匹配到的 DNS 连接导入 Mihomo 内部 DNS 模块；listen则是本机或局域网显式查询使用的监听地址，两者不是同一条路径。官方 TUN 文档列出 dns-mode 的可选值为 disabled、native、hijack，并说明 hijack在 Windows 需要 strict-route，Linux 需要 auto-redirect；如果担心不同客户端对字段支持不一致，可先只使用客户端界面提供的 TUN/DNS 开关，再核对生成配置。参考mihomo 官方 TUN 文档。
tun:
enable: true
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
- tcp://any:53
strict-route: true上面配置中的 strict-route可用于 Windows 的 DNS 泄漏防护；Linux 的 auto-redirect仅适用 Linux，并且官方要求同时启用 auto-route。macOS 和 Windows 不能自动劫持发往本地网络的 DNS 请求；Android 开启 Private DNS 时，也不能自动劫持 DNS 请求。遇到局域网或系统 DNS 异常，先关闭 TUN 做对照，再按平台条件恢复，以上平台限制见官方 TUN 文档。
配置修改后不生效：完整验证流程
- 确认配置来源。在客户端确认当前运行的是哪份配置，避免只修改订阅原文却实际运行了覆写文件。
- 检查 DNS 覆写。Clash Verge Rev、Mihomo Party 等图形客户端可能提供独立的 DNS 设置或 DNS 覆写开关。若开关启用，界面设置可能覆盖 YAML 中的
dns:段；修改无变化时先关闭覆写，或直接修改客户端 DNS 设置。 - 检查顶层位置和缩进。
dns:应位于配置顶层，子字段保持两个空格缩进，不要放进rules、tun或proxy-groups。 - 校验并重启核心。先使用客户端配置校验，再重启 Mihomo 核心；只刷新面板通常不能证明核心已加载新配置。
- 清理系统或客户端缓存。切换 fake-ip 与 redir-host 后，优先使用客户端提供的 DNS 缓存或 fake-ip 映射清理功能；没有该选项时完全退出并重新启动客户端。
- 查询本地监听。以下命令用于验证
listen: 127.0.0.1:1053是否响应，不用于证明 TUN 的 dns-hijack 已经接管全部系统流量。
nslookup -port=1053 example.com 127.0.0.1dig @127.0.0.1 -p 1053 example.comexample.com是示例域名，请替换为实际测试域名。Windows 默认更容易使用 nslookup；dig需要系统已安装对应工具。看到有效的 A 或 AAAA 记录，说明该监听至少返回了响应；超时或拒绝连接时，检查监听地址、端口占用和核心状态。
Windows 可执行ipconfig /flushdns清理系统缓存；macOS 可执行sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder。清缓存后重新查询，并查看客户端日志是否记录了 DNS 请求。命令由操作系统提供，不需要额外安装工具。
如何检查 fake-ip 是否生效与 DNS 泄漏
fake-ip 不能只凭“查询返回了一个 IP”判断。先确认配置中的 enhanced-mode: fake-ip已加载，再查看客户端日志或连接详情是否显示域名与 fake-ip 映射；同时用局域网域名、系统联网检测域名和实际异常应用做对照。官方 DNS 文档说明 fake-ip-filter中的匹配项不会获得 fake-ip 映射，参考fake-ip-filter 文档。
- 关闭 TUN，记录一次 DNS 检测页面或客户端日志中显示的解析出口。
- 开启 TUN，并确认
dns-hijack、auto-route和平台所需的路由字段已加载。 - 重复访问同一检测页面或执行同一查询，比较两次显示的解析服务和客户端日志。
- 如果仍看到系统或路由器 DNS，检查客户端 DNS 覆写、Windows 的
strict-route、Linux 的auto-redirect以及 Android Private DNS。
Quad9 官方提供 on.quad9.net用于确认查询是否到达 Quad9，并提供协议测试方法；它适合验证是否使用了 Quad9，不等于对所有上游的通用测速或绝对防泄漏保证，参考Quad9 协议测试说明。发现泄漏后，先关闭复杂的 fallback和分流规则，回到最小配置逐项恢复。
常见症状与处理顺序
| 症状 | 优先检查 | 处理动作 |
|---|---|---|
| 启动时报 DNS 字段错误 | 字段拼写、缩进和客户端支持情况 | 删除新增字段，回到最小 redir-host 配置 |
| 改 YAML 后完全没变化 | DNS 覆写、当前运行配置、核心是否重启 | 确认生效文件，关闭覆写并重启核心 |
| 网页能开但局域网失效 | fake-ip、局域网域名和 TUN 路由 | 先切回 redir-host，再按实际域名增加过滤 |
| 节点域名无法解析 | proxy-server-nameserver及上游可达性 | 暂时删除复杂策略，单独为节点域名指定上游 |
| TUN 开启后仍使用系统 DNS | dns-hijack、平台依赖和客户端覆写 | 按系统检查 strict-route或 Linux 的 auto-redirect |
结论：先能解析，再做分流和防泄漏
Mihomo DNS 最稳妥的配置顺序是：先用最小 redir-host确认网页和节点域名可解析；再单独切换 fake-ip；之后增加 nameserver-policy、proxy-server-nameserver或direct-nameserver；最后才启用 TUN 的 DNS 接管并做开关前后对照。
如果客户端界面提供 DNS 覆写，YAML 中的修改可能不会直接生效。出现配置不变、局域网异常或 DNS 泄漏时，不要继续堆叠字段，先确认当前配置来源、核心状态、查询路径和平台条件。
常见问题
Mihomo DNS 配置应该放在哪里？
通常放在当前生效配置文件的顶层 dns: 段。使用图形客户端时，还要确认当前运行配置和 DNS 覆写开关；界面设置可能覆盖 YAML 中的 dns: 内容。
fake-ip 和 redir-host 哪个更好？
没有适用于所有设备的统一答案。redir-host适合先验证基础联网和兼容性，fake-ip适合需要 TUN 与规则分流的场景。切换后若局域网或特定应用异常，应先回退并逐项排查。
为什么改了 Mihomo DNS 配置却没有效果？
优先检查当前运行配置、客户端 DNS 覆写、YAML 缩进和核心是否重启，再用 nslookup 或 dig 查询本地监听。若查询正常但系统行为不变，继续检查 TUN 和 DNS 接管路径。
default-nameserver 和 nameserver 有什么区别？
default-nameserver主要用于解析 DNS 服务器自身的域名，官方要求使用 IP；nameserver是普通域名查询的默认上游，两者职责不同。
Mihomo TUN 一定要配置 dns-hijack 吗？
不一定。dns-hijack用于把匹配到的 DNS 连接导入 Mihomo 内部 DNS 模块，是否需要取决于系统、客户端和流量接管方式。Windows 与 Linux 还涉及 strict-route 或 auto-redirect 等平台条件。
listen 和 dns-hijack 是不是同一个功能？
不是。listen提供本机或局域网显式查询使用的 DNS 监听；dns-hijack负责把匹配到的 DNS 流量导入内部 DNS 模块。TUN 接管不等于必须把所有流量指向 listen 端口。
Mihomo DNS 如何检查是否泄漏？
先关闭 TUN 记录检测结果，再开启 TUN 重复测试，并查看客户端日志中的 DNS 查询出口。若仍出现系统或路由器 DNS，检查 DNS 覆写、dns-hijack、Windows strict-route、Linux auto-redirect 和 Android Private DNS。
相关阅读
参考资料
- mihomo 官方文档：DNS 配置
- mihomo 官方文档：DNS 解析流程
- mihomo 官方文档：TUN 配置
- Cloudflare 官方文档：DoH 请求地址
- Cloudflare 官方文档：DoT 配置
- Quad9 官方文档：服务地址（docs.quad9.net）
- Quad9 官方文档：协议测试与确认方法（docs.quad9.net）
- AdGuard DNS 官方文档：公共 DNS 地址（adguard-dns.io）