Mihomo DNS 设置与连接排查：Fake-IP、TUN 与解析失败处理

更新于 2026-11-10 · viewturbo.store

简答：如果 Mihomo 显示已连接但网页打不开，先确认当前生效配置确实启用了 DNS，再用一个最小 DNS 配置测试普通域名；随后查看节点域名是否能解析、TUN 是否接管流量，以及规则是否把请求判为 DIRECT 或 REJECT。成功标准是 Mihomo 日志不再出现 DNS 超时或解析失败，连接列表能看到浏览器请求，且关闭 TUN 或切换到 redir-host 后能明确判断故障层级。

定义：Mihomo DNS 设置是通过 dns 区块定义本地监听、上游解析、Fake-IP 或 redir-host 模式，以及节点域名和直连域名的解析路径；连接排查则是按内核、DNS、规则、节点和 TUN 接管顺序逐层验证。

先试这一步：用最小配置判断是不是 DNS 配置本身

本文是面向 Mihomo 用户的第三方使用指南，不代表任何客户端或服务的官方页面。先备份当前配置，再只修改 DNS 相关部分；不要同时更换节点、规则、TUN 和多个 DNS 上游，否则无法判断是哪一项产生了变化。

Mihomo 官方文档说明，enable 为 false 时会使用系统 DNS；enhanced-mode 支持 fake-ip 和 redir-host，而 listen 用于提供本地 DNS 服务。字段名称和默认行为应以当前配置文档为准，参见 Mihomo DNS 配置文档。

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

上面只是排查用的最小示例，不代表所有网络环境都适合这些上游地址。若保存后内核无法启动，立即恢复备份；若内核能启动但浏览器仍无请求，先不要继续增加 fallback、nameserver-policy 或 respect-rules。

先分清 5 个 DNS 字段：普通域名、节点域名不是一条链路

nameserver 是普通域名的默认解析服务器；default-nameserver 用于解析 DNS 服务器自身的域名；proxy-server-nameserver 专门用于解析代理节点的域名。假如订阅里的节点地址是域名，普通网页能解析但节点始终连接失败，应优先检查后者，而不是继续更换网页 DNS。

nameserver-policy 可以按域名或规则集指定解析路径；direct-nameserver 用于直连出口的域名解析；respect-rules 会让 DNS 连接遵循路由规则，官方文档同时提示这类配置需要配合 proxy-server-nameserver，否则可能形成“解析节点需要代理、代理又需要先解析节点”的循环。详细字段定义见 Mihomo DNS 配置文档 和 Mihomo DNS 解析流程。

dns:
  enable: true
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - 1.1.1.1
  direct-nameserver:
    - system
  nameserver-policy:
    '+.lan': system

这段配置中的 system 只是示例写法。局域网域名、公司内网域名和节点域名是否应走系统 DNS，要结合实际网络；不要把所有域名都强行套用同一条策略。

Fake-IP、redir-host 与 fake-ip-filter 怎么选

先用 redir-host 定位问题。它更适合做基线测试，因为返回的是实际解析结果；如果 redir-host 下普通网页和节点都正常，再切换到 fake-ip，可以判断是否是 Fake-IP 映射、局域网域名或应用兼容性导致故障。

fake-ip 适合需要由 Mihomo 接管域名流量的场景。官方文档说明，fake-ip-filter 支持域名通配符；匹配到过滤规则的域名不会获得 Fake-IP 映射。局域网域名、路由器管理地址和部分需要真实地址的应用，可以作为排查对象加入过滤列表，但应一项一项添加。

dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - router.local

切换模式后要清理 DNS 和 Fake-IP 缓存，再重启或重新加载当前生效配置。Mihomo API 提供 /cache/dns/flush 和 /cache/fakeip/flush 接口，也可以在所用前端的 DNS 或缓存页面执行同等操作；接口定义见 Mihomo API 文档。

TUN、DNS 劫持、系统代理和浏览器加密 DNS 的关系

系统代理与 TUN 是两条不同的流量入口。系统代理只影响遵循系统代理设置的应用；TUN 通过虚拟网络接口接管更广范围的流量。Mihomo 官方文档将 dns-mode 分为 disabled、native 和 hijack：其中 hijack 会在设置 TUN DNS 的基础上拦截发往其他接口的 53 端口请求，但 Windows 需要配合 strict-route，Linux 需要配合 auto-redirect。参见 Mihomo TUN 配置文档。

浏览器的 Secure DNS、Android 的 Private DNS、路由器 DNS 转发和 Mihomo 内置 DNS 可能同时存在。排查时一次只保留一个接管层：先关闭浏览器 Secure DNS 或系统 Private DNS 做对照，再恢复并确认是否需要该功能。不要仅凭某个 DNS 检测页面显示的地址就断定存在泄露，必须结合 Mihomo 日志、连接列表和实际请求路径判断。

按日志关键词定位：从内核启动到节点连接

先把日志级别调到能看到错误的程度，并在复现问题时只打开一个网页或执行一次 DNS 查询。Mihomo API 的 /logs 可获取实时日志，/connections 可查看活动连接、目标地址、规则匹配结果和代理链；相关接口见 Mihomo API 文档。

Windows、macOS、Linux、Android 的实际验证步骤

Windows

1. 打开命令提示符，执行 nslookup example.com，确认普通域名能得到回答。Microsoft 文档建议使用 nslookup 测试外部名称，并在缓存异常时执行 ipconfig /flushdns；参见 Microsoft DNS 客户端排查文档。
2. 执行 ipconfig /all，记录当前网卡、默认网关和系统 DNS；执行 ipconfig /flushdns 清理 Windows DNS 客户端缓存。命令说明见 Microsoft ipconfig 文档。
3. 在 Mihomo 前端确认当前激活 Profile、DNS 覆写、系统代理端口和 TUN 开关；若 TUN 无法工作，检查 Windows 防火墙是否放行核心程序。Mihomo 文档明确列出 Windows 防火墙与 strict-route 的相关注意事项。

macOS

1. 先在前端关闭 TUN，只启用系统代理，观察连接列表是否出现浏览器请求。
2. 需要查看系统 DNS 时，进入“系统设置→网络→当前网络服务→详细信息→DNS”；这是 Apple 支持文档给出的设置路径，参见 Apple macOS DNS 设置说明。
3. 若切换 Fake-IP 后局域网失效，优先把局域网域名加入 fake-ip-filter，清理缓存后再测试，不要立即修改 MTU。

Linux

1. 如果 Mihomo 以 systemd 服务运行，使用 systemctl status mihomo 查看状态，使用 journalctl -u mihomo -o cat -f 跟踪日志；这些命令见 Mihomo systemd 服务文档。
2. 检查 TUN 是否创建、系统路由是否变化，以及防火墙是否允许 TUN 出站流量。Linux 的 auto-redirect 依赖 auto-route，不能只打开其中一项就假定所有流量都会被接管。
3. 用 dig example.com 测试系统解析；再通过 Mihomo 前端或 API 查询同一域名，比较两者是否都能返回结果。

Android 与 iOS

1. Android 先检查系统“私人 DNS”是否开启。Mihomo 文档指出，Android 开启 Private DNS 时，DNS 请求可能无法被自动劫持；排查时可暂时关闭后复测。
2. Android 使用 TUN 时，确认 VPN 权限已授予，查看前端日志和连接列表；不要同时改变 Private DNS、Fake-IP 和节点。
3. iOS 不同前端的菜单名称和能力可能不同，本文不写未核实的固定路径。可执行的通用顺序是：确认 VPN 配置已启用→关闭其他 DNS/VPN 配置做对照→查看前端日志→切换 redir-host→清理缓存→重新测试一个普通域名。

配置未生效、订阅异常和缓存清理

如果你改了 YAML 但行为完全不变，优先怀疑“改的不是当前运行配置”，而不是先怀疑 DNS 上游。按以下顺序检查：

1. 确认当前前端激活的是哪一个 Profile，避免修改了备用文件。
2. 检查是否存在多个 dns: 区块、Merge 覆写、Script 动态修改或面板生成配置；YAML 中重复的顶层区块可能导致后写内容覆盖前写内容，具体行为要以所用前端和解析器为准。
3. 保存后执行前端提供的“应用配置”“重新加载”或“重启内核”操作；仅保存文件不一定等于运行中的配置已经改变。
4. 通过 Mihomo API 的 /configs 查看当前运行配置，通过 /cache/dns/flush 和 /cache/fakeip/flush 清理缓存，再复测。
5. 如果问题出现在订阅更新阶段，先分别测试订阅地址是否能访问、订阅中的节点域名是否能解析、节点连接是否成功；不要把“订阅更新失败”和“目标网页打不开”当成同一类 DNS 故障。

回滚路径很简单：恢复备份配置，关闭 TUN，删除本次新增的 nameserver-policy、respect-rules 和 Fake-IP 过滤项，只保留最小 DNS 配置，然后重新启动内核。

一套可照做的最终排查顺序

1. 确认内核启动：日志没有 YAML 解析错误、端口绑定失败或 TUN 创建失败。
2. 确认 DNS 监听：检查 listen 地址和端口没有冲突，普通域名能得到回答。
3. 分别测两个域名：一个普通目标域名，一个订阅或节点服务器域名；前者看 nameserver，后者看 proxy-server-nameserver。
4. 检查规则：在连接列表查看请求是否进入 Mihomo，以及命中的规则是 PROXY、DIRECT 还是 REJECT。
5. 单独测试 TUN：先关闭 TUN验证系统代理，再开启 TUN验证虚拟网卡、路由、DNS 模式和防火墙。
6. 清理缓存并复测：清理 DNS/Fake-IP 缓存，只打开一个网页或执行一次查询。
7. 最后才改高级项：包括 respect-rules、DoH HTTP/3、nameserver-policy、MTU 和 IPv6；一次只改一项。

如果完成上述步骤后仍然失败，保留一份脱敏日志，记录系统、前端、当前配置模式、是否启用 TUN、普通域名结果、节点域名结果和连接列表中的规则命中情况。不要公开订阅链接、访问令牌、节点密码或完整配置中的隐私字段。

常见问题

Mihomo 的 nameserver 和 proxy-server-nameserver 有什么区别？

nameserver 主要处理普通域名解析；proxy-server-nameserver 专门用于代理节点域名解析。节点服务器使用域名时，普通网页能打开但节点连接失败，应优先检查 proxy-server-nameserver。

Mihomo 应该使用 Fake-IP 还是 redir-host？

排查故障时建议先用 redir-host 建立基线，再切换 Fake-IP。若 redir-host 正常而 Fake-IP 异常，应检查 fake-ip-filter、局域网域名、应用兼容性以及 Fake-IP 缓存。

Mihomo 已连接但网页打不开，第一步做什么？

先查看连接列表是否出现浏览器请求。如果没有请求，检查系统代理端口或 TUN 接管；如果有请求，再看 DNS 查询、规则命中结果和节点连接日志。

为什么打开 TUN 后局域网设备无法访问？

常见排查方向是 Fake-IP 没有过滤局域网域名、DNS 请求没有走局域网解析、路由范围发生变化。先关闭 TUN做对照，再逐项检查 fake-ip-filter、dns-mode 和局域网 DNS。

改了 Mihomo DNS 配置但完全没有变化怎么办？

确认修改的是当前激活 Profile，检查是否存在 Merge、Script 或重复 dns 区块，保存后重新应用或重启内核，并清理 DNS/Fake-IP 缓存。还可以通过 Mihomo API 的 /configs 查看运行中的配置。

Android 开启 Private DNS 会影响 Mihomo 吗？

可能会。Mihomo TUN 文档说明，Android 开启 Private DNS 时，DNS 请求无法自动被劫持。排查时可暂时关闭 Private DNS，完成对照后再决定是否恢复。

相关阅读

• 连接问题排查总清单
• 订阅导入失败与节点解析排查
• Windows 客户端订阅与连接验证
• 不同设备的客户端配置指南

参考资料

1. Mihomo DNS configuration
2. Mihomo DNS resolution flow
3. Mihomo TUN configuration
4. Mihomo API documentation
5. Microsoft DNS client troubleshooting
6. Microsoft ipconfig command
7. Mihomo systemd service