Mihomo DNS 配置怎么设置？从最小 YAML 到 TUN 排查
简答：Mihomo DNS 配置通常写在当前运行实例加载的 YAML 的 dns: 段。最快路径是：先确认生效配置并备份，只加入 enable、listen、enhanced-mode、ipv6 和 nameserver；重载后分别验证端口监听、Mihomo DNS 查询和页面加载。TUN 的 dns-mode、dns-hijack、strict-route 必须写在 tun: 段，改坏后直接恢复备份。
定义：Mihomo DNS 配置，是通过 YAML 中的 dns: 节点设置内置 DNS 是否启用、监听地址、解析模式、上游 DNS 和按域名分流规则。
先照做的 3 步速查卡
第一步：确认当前生效的配置。图形客户端可能通过订阅生成、Merge、Script 或配置覆写形成最终运行配置，不能只凭文件名判断。命令行服务可先检查启动参数；官方 systemd 示例使用 /etc/mihomo 作为配置目录，并通过 -d /etc/mihomo 启动。参考Mihomo 服务启动文档。
第二步：备份后只加入最小 DNS 段。同一个最终配置中只保留一个需要生效的 dns: 节点，使用空格缩进，不要用 Tab。先监听本机高位端口，不要一开始监听公网地址。
第三步：分层验证。先看端口是否监听，再用 Mihomo API 的 /dns/query 验证内置 DNS 是否能查询，最后测试系统代理或 TUN 下的网页加载。一个域名能返回 IP，不代表代理连接和页面加载也一定成功。
下面这份配置只用于起步验证，DNS 上游地址是语法示例，不代表在所有网络、设备或地区都可达。
dns:
enable: true
listen: 127.0.0.1:1053
ipv6: false
enhanced-mode: redir-host
nameserver:
- https://doh.pub/dns-query
- https://dns.alidns.com/dns-query
官方文档确认 listen 支持 UDP 和 TCP，enhanced-mode 可选 fake-ip 或 redir-host，默认值为 redir-host。Mihomo DNS 配置文档
预期结果：配置重载没有 YAML 错误，端口处于监听状态，API 查询能返回 DNS 响应。若重载失败，先恢复备份，再只改一个字段。
配置文件在哪里：不要改错文件
如果使用命令行服务，启动参数通常能决定配置目录；官方 systemd 示例把配置复制到 /etc/mihomo/config.yaml，并用 mihomo -d /etc/mihomo 启动。若你使用的是桌面或移动客户端，界面可能不同，应在配置详情、运行配置、配置文件管理或日志页面确认当前加载对象。
如果客户端有订阅生成、Merge 或 Script，手写文件可能在重载或更新订阅后被覆盖。此时优先查看 Mihomo API 的运行配置接口：官方文档说明 GET /configs 会返回当前运行配置，包括端口、模式、IPv6 和 TUN 等字段；API 地址和密钥以你的 external-controller 配置为准。Mihomo API 文档
可以用下面的请求检查运行配置，其中 127.0.0.1:9090 和密钥只是占位符，不要直接照抄到未核实的环境：
curl -H "Authorization: Bearer YOUR_SECRET" http://127.0.0.1:9090/configs
如果返回内容中的 dns、tun 或监听端口与文件不一致，说明你查看的文件不是最终运行配置，或者存在客户端覆写。
核心字段怎么填：先理解解析链路
| 字段 | 作用 | 建议 | 常见误区 |
|---|---|---|---|
enable | 启用 Mihomo 内置 DNS；设为 false 时使用系统 DNS。 | 最小配置中可设为 true | 开启后不代表所有应用都已经把 DNS 请求交给 Mihomo。 |
listen | 设置 DNS 服务监听地址和端口，支持 UDP、TCP。 | 先用 127.0.0.1:1053 | 直接使用 0.0.0.0:53 可能遇到端口冲突，也会扩大服务暴露范围。 |
ipv6 | 控制是否解析 IPv6；关闭时 AAAA 查询返回空解析。 | 按实际 IPv6 网络决定 | 关闭 IPv6 不能替代完整的 IPv6 路由排查。 |
enhanced-mode | 选择 fake-ip 或 redir-host。 | 首次排错先用 redir-host | 切换到 Fake-IP 后，局域网和部分应用可能需要过滤。 |
default-nameserver | 用于解析 DNS 服务器域名等基础地址。 | 只有需要时再加 | 官方文档要求使用 IP，也可以使用加密 DNS。 |
nameserver | 常规域名查询使用的默认 DNS。 | 最小配置中的主要字段 | 上游能返回结果，不等于网页、代理和应用都可用。 |
fallback | 提供备用解析服务器。 | 基础链路正常后再加 | 不会自动保证更快，也不代表所有上游都可达。 |
nameserver-policy | 按域名或规则集指定解析服务器，优先于普通 nameserver/fallback 查询。 | 有明确分流需求再加 | 域名通配符、规则集和当前构建支持情况要逐项核对。 |
proxy-server-nameserver | 仅用于解析代理节点域名。 | 节点域名解析失败时考虑 | 不是普通域名解析的替代项。 |
direct-nameserver | 指定 direct 出口使用的 DNS。 | 有直连分流需求再加 | 是否遵循 nameserver-policy 还受 direct-nameserver-follow-policy 影响。 |
官方文档还说明，respect-rules 会让 DNS 连接遵守路由规则，并要求配置 proxy-server-nameserver；同时不建议与 prefer-h3 一起使用。Mihomo DNS 配置文档
Fake-IP 和 redir-host 怎么选
redir-host 返回实际解析结果，更适合先确认普通系统代理、域名解析和局域网访问是否正常。fake-ip 会为域名返回 Fake-IP 映射，适合需要更完整接管 DNS 与流量识别的场景，但局域网域名、设备发现或特定应用可能需要过滤。
切换时只改一个变量。先备份配置，将 enhanced-mode 设置为 redir-host，重载后测试普通网页和局域网；确认基础链路后，再按实际需求切换到 fake-ip。
dns:
enable: true
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'
- '*.local'
nameserver:
- system
官方文档确认 fake-ip-filter 支持域名通配符和导入域名集合，fake-ip-filter-mode 可选 blacklist、whitelist 或 rule。除非明确知道用途，不要修改 fake-ip-ttl。Mihomo DNS 配置文档
如果 Fake-IP 导致局域网设备异常，先切回 redir-host 做对照，再增加少量明确的过滤项，不要一次加入大批规则。
普通代理、TUN、局域网软路由怎么区分
| 场景 | 先配置什么 | 验证方式 | 失败时回滚 |
|---|---|---|---|
| 普通系统代理 | dns.enable、dns.listen、dns.nameserver | 先查端口，再查 API DNS 查询，最后测试支持系统代理的应用 | 恢复最小 DNS 配置，暂时关闭额外分流 |
| TUN | tun.enable、auto-route、dns-mode、dns-hijack，按系统考虑 strict-route 或 auto-redirect | 分别测试系统 DNS、TUN 下网页和局域网 | 关闭 TUN，回到系统代理 |
| 局域网或软路由 | 明确监听网卡、允许网段、防火墙和路由范围 | 从局域网另一设备查询指定 DNS 地址 | 恢复回环监听，撤销局域网开放 |
TUN 字段的正确层级
上一稿中最容易误导的是把 TUN 字段层级写错。当前官方示例把 dns-mode、dns-hijack 和 strict-route 放在 tun: 下，而不是放在 dns: 下：
tun:
enable: true
auto-route: true
auto-detect-interface: true
dns-mode: hijack
dns-hijack:
- any:53
- tcp://any:53
strict-route: true
官方文档定义：disabled 不设置系统 DNS，native 把 TUN 地址设为系统 DNS，hijack 在此基础上拦截其他接口发往 53 端口的流量。Windows 使用 hijack 时需要 strict-route，Linux 需要 auto-redirect。Mihomo TUN 配置文档
官方还明确提示：Windows 和 macOS 不能自动劫持发往局域网的 DNS 请求；Android 开启 Private DNS 时，DNS 请求也不能被自动劫持。因此 TUN 开启后仍可能出现局域网异常或 DNS 未接管，应该先关闭 TUN 做对照，而不是长期关闭系统安全功能。
系统级验证：端口、DNS、日志和 API
Windows：检查 1053 端口。适用 PowerShell。命令为 Get-NetTCPConnection -LocalPort 1053 -ErrorAction SilentlyContinue；如果没有返回，不能证明 UDP 一定没有监听，还要结合客户端日志或 API 查询。测试 TCP 端口可使用 Test-NetConnection 127.0.0.1 -Port 1053。若端口未监听，先检查 YAML、端口冲突和客户端实际加载的配置。
macOS：检查 UDP/TCP 监听。适用终端。命令为 lsof -nP -iUDP:1053 -iTCP:1053。没有结果时，检查客户端是否启动、配置是否重载，以及是否被其他进程占用。
Linux：检查监听和服务日志。适用 systemd 服务。命令为 ss -lntup | grep 1053，再执行 systemctl status mihomo 和 journalctl -u mihomo -o cat -e。官方服务文档提供了这些服务状态和日志检查路径。Mihomo 服务启动文档
跨系统：用 API 查询 Mihomo DNS。官方 API 提供 /dns/query，请求参数包括 name 和 type。示例为 curl -H "Authorization: Bearer YOUR_SECRET" "http://127.0.0.1:9090/dns/query?name=example.com&type=A"。返回 DNS 状态和 Answer，说明内置 DNS 模块至少完成了一次查询；这仍不等于系统流量已经被接管或代理节点可以连接。Mihomo API 文档
清理缓存后复测。API 文档提供 POST /cache/dns/flush 和 POST /cache/fakeip/flush。只有在确认 API 地址、密钥和当前配置后再使用，不要把控制器端口暴露到不可信网络。
nameserver、fallback 和分流的稳妥写法
可以把解析链路分成四层：default-nameserver 负责解析 DNS 服务器域名等基础地址；nameserver 负责一般域名查询；fallback 提供备用路径；nameserver-policy 对特定域名或规则集覆盖普通选择。
下面是扩展示例，仍然只展示字段关系，不代表上游一定适合你的网络：
dns:
enable: true
listen: 127.0.0.1:1053
ipv6: false
enhanced-mode: redir-host
default-nameserver:
- 1.1.1.1
nameserver:
- system
fallback:
- tls://1.1.1.1
nameserver-policy:
'+.lan':
- system
proxy-server-nameserver:
- system
direct-nameserver:
- system
direct-nameserver-follow-policy: false
如果你的网络无法访问某种 DNS 类型，不要只凭配置示例判断故障。官方文档列出了 UDP、TCP、DoT、DoH、DoQ、system 和 dhcp 等 DNS 类型；实际选择应结合网络可达性、应用兼容性和隐私要求逐项测试。Mihomo DNS 类型文档
respect-rules 不建议作为第一步就开启。它会让 DNS 连接遵守路由规则，并要求配置 proxy-server-nameserver，否则可能出现节点域名解析与代理连接互相等待的问题。
Mihomo DNS 不生效：按现象分流并回滚
| 现象 | 最小检查 | 下一步 | 回滚方法 |
|---|---|---|---|
| 重载时报 YAML 错误 | 缩进、冒号、引号、重复的 dns: 或 tun: | 恢复备份，只添加一个字段 | 还原上一份配置后重载 |
| 端口没有监听 | 进程是否运行、1053 是否被占用、是否加载了另一份配置 | 改用回环高位端口，并查看日志 | 恢复原监听地址 |
| API DNS 查询失败 | 控制器地址、密钥、上游可达性和 DNS 字段 | 暂时只保留一个 nameserver，关闭复杂策略 | 恢复最小配置 |
| API 能查询但网页打不开 | 系统代理、TUN、路由规则和节点连接 | 分开测试代理连接与页面加载 | 关闭 TUN，回到普通系统代理 |
| 节点域名无法解析 | proxy-server-nameserver 是否缺失或不可达 | 单独为节点域名设置解析路径 | 移除新增节点解析策略 |
| TUN 开启后异常 | tun.dns-mode、dns-hijack、strict-route、权限和防火墙 | 关闭 TUN 做对照，再逐项恢复 | 关闭 TUN，保留普通代理配置 |
| 局域网设备失联 | Fake-IP 过滤、局域网网段、系统 DNS 和路由排除 | 切换 redir-host，再增加少量过滤 | 恢复 Fake-IP 前的备份 |
排查时要区分五个结果：DNS 服务是否监听、Mihomo 是否能查询上游、系统或应用流量是否被接管、代理节点是否连接成功、网页是否完成加载。只看到 DNS 返回 IP，不能直接判断后四项均正常。
常见问题 FAQ
Mihomo DNS 配置应该写在哪里？
写在当前运行实例实际加载的 YAML 的 dns: 段。图形客户端可能存在订阅生成、Merge 或 Script，因此应通过运行配置或 API 的 GET /configs 确认最终内容。
dns-mode 应该写在 dns: 还是 tun: 下面？
当前官方 TUN 文档将 dns-mode、dns-hijack 和 strict-route 放在 tun: 下。dns: 段负责内置 DNS 模块，不能把 TUN 字段随意放入其中。
Mihomo 应该用 Fake-IP 还是 redir-host？
首次排错建议先用 redir-host，因为返回实际解析结果，便于区分 DNS 和网页问题；需要更完整接管时再切换 Fake-IP，并逐步配置过滤项。
为什么 API 能查询 DNS，但系统还是打不开网页？
API 查询只证明 Mihomo 内置 DNS 完成了查询，不证明系统代理、TUN、路由规则或节点连接正常。应继续检查代理模式、节点域名解析和网页加载。
配置了 fallback 就一定更快吗？
不一定。fallback 是备用解析路径，结果取决于上游可达性、筛选条件和缓存。应记录 DNS 返回、代理连接和页面加载，不能只凭一次解析结果判断速度。
改完配置无法启动怎么办？
先停止继续修改，恢复备份并重新加载；然后每次只加入一个字段。重点检查 YAML 缩进、重复节点、端口冲突，以及客户端是否实际加载了另一份配置。
如何避免把 DNS 服务暴露到公网？
起步时使用 127.0.0.1:1053 等回环地址。只有确实需要局域网设备访问时，才改为明确的局域网地址，并同时配置防火墙、允许网段和路由范围，不要直接开放 0.0.0.0:53。
常见问题
Mihomo DNS 配置应该写在哪里？
写在当前运行实例实际加载的 YAML 的 dns: 段。图形客户端可能存在订阅生成、Merge 或 Script，应通过运行配置或 API 的 GET /configs 确认最终内容。
dns-mode 应该写在 dns: 还是 tun: 下面？
当前官方 TUN 文档将 dns-mode、dns-hijack 和 strict-route 放在 tun: 下；dns: 段负责内置 DNS 模块。
Mihomo 应该使用 Fake-IP 还是 redir-host？
首次排错可先使用 redir-host；需要更完整接管 DNS 和流量时，再切换 Fake-IP，并逐步增加必要的过滤项。
为什么 API 能查询 DNS，但网页仍然打不开？
API 查询只代表内置 DNS 完成了一次查询，还需继续检查系统代理、TUN、路由规则、节点解析、代理连接和页面加载。
改完配置无法启动怎么办？
恢复备份后重新加载，再一次只加入一个字段。重点检查 YAML 缩进、重复的 dns: 或 tun: 节点、端口冲突和实际加载文件。
如何避免 DNS 服务暴露到公网？
起步时使用 127.0.0.1:1053 等回环地址；需要局域网访问时再明确指定局域网地址，并配置防火墙和允许网段。