Mihomo DNS 设置：可复制配置、Fake-IP 与 TUN 排查

更新于 2026-10-20 · uziport.shop

简答：Mihomo 改完 DNS 后启动失败、局域网打不开或节点域名解析不了？先用多行 YAML 配置启用内置 DNS，监听本机未占用端口，再根据是否使用 TUN 选择 fake-ip 或 redir-host。开启 respect-rules 时，同时配置 proxy-server-nameserver；排查 DNS 泄露时重点检查 TUN 的 dns-hijack、系统 DNS 和 Mihomo 日志。

定义：Mihomo DNS 设置，是通过配置文件中的 dns 区块控制域名解析、Fake-IP 映射、DNS 上游、节点域名解析、直连解析和按域名分流的过程。

先试这一步：使用合法的多行 YAML

Mihomo 的 DNS 配置必须按 YAML 缩进书写，不能把字段压成一行并用分号连接。本文为第三方客户端使用指南，非 Mihomo 或任何服务商官方页面；字段行为以你使用的 Mihomo 版本文档和配置校验结果为准。

先备份原配置，在已有的 dns: 区块中合并下面字段，不要重复添加两个顶层 dns:。此版本示例让 DNS 只监听本机回环地址，适合桌面系统代理场景；官方文档示例也展示了 listen: 0.0.0.0:1053，但监听所有网卡会扩大可访问范围，因此不应作为桌面端默认值。Mihomo DNS 配置文档

桌面系统代理版：

dns: enable: true listen: 127.0.0.1:1053 ipv6: false enhanced-mode: redir-host use-hosts: true use-system-hosts: true default-nameserver: - 1.1.1.1 nameserver: - https://1.1.1.1/dns-query

上面的地址只是配置格式和连通性测试用的占位示例，不代表在所有网络中都可达。若该上游无法访问，应替换为你所在网络可访问且信任的 DNS 服务，并保留同样的 YAML 结构。default-nameserver 用于解析 DNS 服务器自身的域名，官方文档要求这里使用 IP，也可以使用加密 DNS；nameserver 才是普通域名查询的默认上游。Mihomo 支持的 DNS 类型

只有需要让局域网设备共享 Mihomo DNS，或在软路由上接收其他设备的查询时，才考虑把 listen 改为 0.0.0.0:1053。改动后应配合防火墙限制来源，不要直接把未加密的 DNS 监听暴露到互联网；Mihomo 入站文档明确提醒，0.0.0.0 会监听所有网络接口。Mihomo 入站配置文档

Fake-IP、redir-host 与旧版 normal 怎么选

三种常见解析模式的判断方法

模式	适用场景	常见故障表现	建议
`fake-ip`	TUN、DNS 劫持、需要按域名规则接管应用流量	局域网、本地发现、时间同步或特殊应用异常	同时检查 `fake-ip-filter`，逐项放行实际需要的域名
`redir-host`	普通系统代理、需要保留真实解析地址、兼容性优先	某些域名规则或透明接管场景不符合预期	作为桌面端排错起点，先确认域名和节点都能连接
`normal`	一些旧版 Clash 配置中用于表达普通真实地址解析	当前版本校验失败，或字段被忽略	当前 Mihomo 文档未将其列为 `enhanced-mode` 可选值，填写前必须用所在版本校验确认

当前 Mihomo DNS 文档将 enhanced-mode 的配置示例和说明集中在 fake-ip、redir-host 两种模式。对于旧配置中的 normal，更稳妥的说法是：它在部分旧版 Clash 配置里常见，通常被用来表示不建立 Fake-IP 映射的普通解析，但不能据此断言所有 Mihomo 版本都接受它。遇到校验错误时，应改用当前版本文档列出的值，或先测试 redir-host。查看当前 enhanced-mode 字段说明

Fake-IP 模式下可先保留最小过滤项：

fake-ip-filter-mode: blacklist fake-ip-filter: - '*.lan' - '*.local'

不要一开始复制来源不明的长过滤列表。过滤项会让匹配域名不获得 Fake-IP 映射，列表过大可能改变原本的分流和解析路径；应根据可复现的局域网、NTP、STUN 或应用故障逐项增加。

DNS 字段的职责边界：不要全部指向同一个上游

Mihomo DNS 关键字段速查

字段	职责	排错重点
`default-nameserver`	解析 DNS 服务器自身的域名	优先使用 IP 或可直接访问的加密 DNS
`nameserver`	默认域名解析上游	确认协议、地址格式和网络可达性
`fallback`	备用解析上游	配置后会与 `fallback-filter` 配合，不能默认认为一定更快
`nameserver-policy`	按域名或规则集指定解析上游	策略可能覆盖默认 `nameserver`，先从少量规则开始
`proxy-server-nameserver`	专门解析代理节点域名	节点地址是域名时，优先保证该上游可用
`direct-nameserver`	用于 direct 出口的域名解析	只在需要为直连流量指定独立 DNS 时添加
`respect-rules`	让 DNS 连接遵守路由规则	开启时必须同时考虑节点域名的引导解析

nameserver-policy 用于按域名指定解析服务器，并优先于普通 nameserver 与 fallback 查询；proxy-server-nameserver 只用于代理节点域名解析；direct-nameserver 则面向 direct 出口。不要把这三个字段都指向同一个无法确认可达的上游，再用“DNS 泄露”解释所有连接失败。字段职责和优先级见 Mihomo DNS 文档

respect-rules: true 时，DNS 连接遵守路由规则，但官方文档要求配置 proxy-server-nameserver。否则可能出现节点地址本身尚未解析，却已经尝试通过该节点访问 DNS 的循环问题。官方还不建议把 respect-rules 与 prefer-h3 一起使用。respect-rules 与 proxy-server-nameserver 说明

可在基础配置确认正常后，再增加下面字段：

dns: respect-rules: true proxy-server-nameserver: - 1.1.1.1 nameserver-policy: '+.lan': - system

这里的上游仍是示例，实际使用时要根据网络可达性替换。官方文档已将 fallback-filter.geosite 标记为弃用方向，新的分域名需求优先考虑 nameserver-policy。Mihomo 中文 DNS 文档

国内网络与境外网络：DNS 上游不要直接照搬

按网络环境选择 DNS 上游的思路

环境	优先做法	不要直接照搬
国内网络	先选择本地网络可访问的普通 DNS 或 DoH，再测试常用域名、节点域名和内网域名	不要把境外 DoH、DoT 地址当成必然可达
境外网络	先选择当前网络可访问的 DoH、DoT 或普通 DNS，观察解析日志和连接结果	不要只复制面向国内网络的 DNS、地理策略或固定 IP 示例
企业办公或内网	为企业内网域名使用 `nameserver-policy` 或 `direct-nameserver`	不要让内网域名全部交给公共 DNS

“加密 DNS”不等于“必然更快”或“必然没有泄露”。DoH、DoT 和普通 UDP DNS 都需要先确认地址可达；Mihomo 文档支持 UDP、TCP、DoT、DoH、DoQ、系统 DNS 等类型。选择时应以所在网络的可达性、企业 DNS 要求和应用兼容性为准，而不是照搬某个地区的示例地址。DNS 类型与地址格式

如果只是排查启动失败，建议先使用一个确认可达的简单上游，不同时启用 fallback、nameserver-policy、respect-rules 和 TUN。基础解析确认后，再一次只增加一个变量。

TUN 版配置：重点是 dns-hijack 与 Fake-IP

TUN 会接管更多系统流量，并可用于自动路由、DNS 劫持和按应用路由；普通系统代理则只影响支持代理设置的应用。因此，TUN 版的 DNS 配置除了 dns: 区块，还要检查顶层 tun: 配置。Mihomo 入站与 TUN 总览

需要 TUN 时的基础示例：

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-mode: blacklist fake-ip-filter: - '*.lan' - '*.local' default-nameserver: - 1.1.1.1 nameserver: - https://1.1.1.1/dns-query proxy-server-nameserver: - 1.1.1.1 tun: enable: true auto-route: true auto-detect-interface: true dns-hijack: - any:53 - tcp://any:53

dns-hijack 会把匹配到的 DNS 连接导入 Mihomo 内部 DNS 模块；不写协议时默认是 UDP。官方文档指出，在 Windows 和 macOS 上不能自动劫持发往局域网的 DNS 请求；Android 开启 Private DNS 时，也无法自动劫持 DNS 请求。Mihomo TUN 文档

先确认基础 dns: 能启动，再打开 tun.enable。
确认 dns-hijack 同时覆盖需要的 UDP 53 和 TCP 53。
如果局域网设备异常，把实际使用的本地域名加入 fake-ip-filter，不要直接放行所有域名。
开启 respect-rules 时保留 proxy-server-nameserver，先确认节点域名能解析。
每次只改一个选项，并查看启动日志，避免把 TUN 权限、DNS 上游、解析模式和规则集问题混在一起。

DNS 泄露怎么理解和自查

本文所说的 DNS 泄露，是指应用或系统的 DNS 查询绕过 Mihomo 内置 DNS，直接发往系统、路由器或网络服务商提供的 DNS；它与“解析结果来自某个地区”不是同一个概念。一个 DNS 测试页面显示本地或企业 DNS，并不能单独证明泄露，因为你的 nameserver-policy、direct-nameserver 或网络本身可能就设计成使用该解析器。

先看 Mihomo 日志：在能复现问题时记录查询域名、使用的上游、是否命中 nameserver-policy，以及节点域名是否走了 proxy-server-nameserver。
对比普通代理和 TUN：关闭 TUN，只保留系统代理，测试一个域名；再开启 TUN 和 dns-hijack 重复测试。如果 TUN 开启后请求仍明显绕过内置 DNS，检查系统 DNS、应用的 Private DNS 或 DoH 设置。
检查 TUN 劫持范围：确认 dns-hijack 包含需要的 DNS 流量。Windows、macOS 的局域网 DNS 不能自动全部劫持，这是 Mihomo 文档明确说明的限制。TUN DNS 劫持限制
不要只看测试网页：同一页面可能同时显示系统 DNS、企业 DNS、直连 DNS 或代理出口 DNS。应结合 Mihomo 日志、应用设置和 TUN 状态判断。

如果排查目标是“DNS 请求有没有经过 Mihomo”，最有价值的证据是：复现时的 Mihomo DNS 日志、配置中的 dns-hijack、系统或应用是否启用了独立 DNS，以及关闭和开启 TUN 后的差异。

53 端口、监听地址与权限：跨平台速查

不建议把 Mihomo DNS 固定绑定到 53 端口作为第一步。低于 1024 的端口可能被系统服务或其他软件占用，并且在部分系统或运行方式下需要更高权限；先用 127.0.0.1:1053 验证，确认稳定后再考虑是否需要接管 53。

检查监听端口的命令

系统	命令	怎么看
Windows	`netstat -ano \| findstr :1053`	查看本机端口和 PID；微软文档说明 `-o` 会显示进程 ID，随后可在任务管理器中定位进程。Microsoft netstat 文档
macOS	`sudo lsof -nP -iTCP:1053 -iUDP:1053`	查看占用 1053 端口的进程；无输出通常表示该端口当前没有匹配的网络文件。lsof 参数说明
Linux	`sudo ss -lntup \| grep ':1053'`	查看 TCP、UDP 的监听套接字和进程信息；`-l` 用于只看监听套接字。Linux ss 手册

先检查端口是否已被占用。
若被占用，把 listen 改为其他未使用的本机端口，例如 127.0.0.1:1054。
让客户端的 DNS 转发或 TUN 相关设置指向同一个端口，不能只改 dns.listen。
如果绑定 53 端口失败，先恢复到 1053 等非特权端口，再判断是否真的需要接管 53。
监听 0.0.0.0 时，确认防火墙和访问范围，避免把本机 DNS 服务暴露给不需要的设备。

从 DNS 请求到节点连接：按这条路径看日志

应用发起域名请求：先判断应用走的是系统代理、TUN、应用自带 DoH，还是直接使用系统 DNS。
进入 Mihomo DNS：检查 dns.enable、监听地址、端口和 TUN 的 dns-hijack 是否生效。
匹配 nameserver-policy：命中策略时按策略指定的上游查询；未命中时进入默认 nameserver。
处理 fallback：配置了备用上游时，再根据 fallback-filter 判断是否采用备用结果；其中旧式 geosite 过滤方向已被当前文档标记为弃用。
判断出站方向：如果域名或结果命中代理规则，连接交给代理；如果命中 DIRECT 并配置了 direct-nameserver，则按直连 DNS 重新解析。
解析代理节点域名：节点地址是域名时，优先检查 proxy-server-nameserver；节点本身解析不了，后续 DNS 规则再正确也无法建立连接。

这条路径对应 Mihomo 官方 DNS 解析流程：策略匹配、默认上游、备用上游、直连重新解析和代理连接是不同阶段，不能只看到“域名打不开”就直接更换所有 DNS。Mihomo DNS 解析流程

常见故障的最短排查顺序

Mihomo DNS 设置故障排查表

现象	先查什么	下一步
启动失败	YAML 缩进、重复 `dns:`、字段拼写	删除重复区块，改用多行列表，并使用客户端配置校验
DNS 端口无响应	`enable`、`listen`、端口占用	先改为 `127.0.0.1:1053`，再用系统命令确认监听
节点域名无法解析	`proxy-server-nameserver`、`default-nameserver`	先使用可直连且可达的上游，暂时关闭复杂规则
局域网设备打不开	`fake-ip`、`fake-ip-filter`、TUN 劫持	为实际本地域名增加过滤项，或临时切换到 `redir-host`
开启 `respect-rules` 后断网	`proxy-server-nameserver` 是否配置	先关闭 `respect-rules` 验证基础解析，再单独测试规则跟随
DNS 测试网页显示本地 DNS	是否配置了直连 DNS、策略 DNS 或企业 DNS	结合 Mihomo 日志和 TUN 状态，不要只凭网页结果下结论

排查时建议遵循“先启动、再监听、再解析普通域名、再解析节点域名、最后增加分流和 TUN”的顺序。不要同时更换上游、解析模式、规则集和系统网络设置，否则很难确定是哪一个改动导致故障。

常见问题

Mihomo DNS 设置中 nameserver 和 proxy-server-nameserver 有什么区别？

nameserver 是普通域名查询的默认上游；proxy-server-nameserver 专门用于解析代理节点域名。节点地址是域名时，后者可以帮助 Mihomo 在建立代理连接前完成节点解析。若开启 respect-rules，官方文档要求同时考虑 proxy-server-nameserver。

Mihomo 应该选择 fake-ip 还是 redir-host？

普通系统代理或兼容性排查可以先测试 redir-host；需要 TUN、DNS 劫持和按域名规则接管流量时，可测试 fake-ip。使用 fake-ip 时要检查 fake-ip-filter，尤其是局域网、本地域名和实际受影响的特殊应用。

当前 Mihomo 可以直接填写 normal 模式吗？

当前检索到的 Mihomo DNS 文档没有把 normal 列为 enhanced-mode 的可选值；但它在一些旧版 Clash 配置中常见，通常用于表达普通真实地址解析。不要据此断言所有版本都支持，填写前应使用所在版本的配置校验确认；校验失败时优先测试 redir-host。

为什么开启 respect-rules 后 Mihomo 反而连不上？

respect-rules 会让 DNS 连接遵守路由规则。如果没有配置可用的 proxy-server-nameserver，或者代理节点域名本身无法完成引导解析，就可能形成节点解析与 DNS 出站之间的循环。先关闭 respect-rules 验证基础 DNS，再单独启用它。

fake-ip-filter 应该怎么填写？

先只加入能够复现故障的局域网或本地域名，例如 *.lan、*.local，再根据 NTP、STUN 或应用兼容性逐项增加。过滤列表过大可能改变分流和解析路径，不建议直接复制来源不明的完整列表。

DNS 测试网页显示本地或企业 DNS，是否一定是泄露？

不一定。nameserver-policy、direct-nameserver、企业网络或本地解析设计都可能让结果显示为本地 DNS。应同时查看 Mihomo 日志、TUN 的 dns-hijack、应用是否启用独立 DoH，并对比关闭和开启 TUN 时的查询路径。

Mihomo 的 DNS 监听端口一定要使用 53 吗？

不一定。桌面端排查时可先使用 127.0.0.1:1053 等未占用的本机端口；只有确实需要接管系统或局域网设备的 53 端口时，才进一步处理端口占用、权限和防火墙问题。