Mihomo DNS配置后无法上网怎么办？按系统恢复与分层排查

更新于 2026-10-28 · jinx.mom

简答：先备份配置并关闭 Mihomo 的 TUN、系统代理和 DNS 覆写，确认设备本身能直连上网；如果恢复正常，再只加回 dns.enable、nameserver，最后测试 Fake-IP、nameserver-policy 和节点解析。Windows、macOS、Linux、Android 的恢复入口不同，不能只靠更换 DNS 地址解决。

定义：Mihomo DNS配置后无法上网，通常是 DNS 上游不可达、节点域名解析失败、TUN 劫持或客户端覆写配置之间出现不匹配，而不一定是某个 DNS 地址本身失效。

先试这一步：关闭接管，恢复一条可验证的直连基线

本文按 2026-10-28 检索到的 Mihomo 文档整理，菜单名称可能随客户端外壳和版本变化；涉及字段时请以当前客户端和 Mihomo DNS 配置文档为准。先复制一份原配置，尤其保存订阅地址、节点信息和当前 YAML 文件，不要直接覆盖唯一配置。

在 Mihomo 客户端中暂时关闭 TUN、DNS 覆写或 DNS 劫持，并关闭系统代理；如果客户端只有一个“系统代理”开关，先关闭它。
保留设备原有网络连接，打开浏览器访问一个平时能访问的普通网站。此时不要同时修改 DNS、规则、节点和 MTU。
如果直连恢复，说明故障范围缩小到 Mihomo 的 DNS、代理、规则或 TUN 接管；如果直连仍无法上网，先排查 Wi-Fi、网线、路由器、系统网络和运营商 DNS，不要继续改 Mihomo。
在日志级别允许的情况下观察是否出现 dns resolve failed、no such host、timeout、connection refused 或监听端口占用等关键词。日志分享前应隐藏订阅链接、UUID、密码、节点域名和访问令牌。

现象	优先检查	不要先做什么
关闭 Mihomo 后仍打不开网页	设备网络、系统 DNS、路由器	不要继续堆叠 nameserver 和 fallback
直连正常，开启代理后失败	节点域名、代理组、出口和规则	不要把 ping 通当作节点可用证明
关闭 TUN 正常，开启 TUN 断网	权限、auto-route、strict-route、dns-hijack、防火墙	不要同时更换 MTU 和 DNS
只有局域网设备或内网域名失败	fake-ip-filter、局域网 DNS、系统路由	不要把所有域名都强制走公网 DNS

按系统恢复网络：Windows、macOS、Linux、Android 分开操作

Windows

在 Mihomo 客户端关闭 TUN、系统代理和 DNS 覆写；若客户端要求管理员权限，使用管理员权限重新启动客户端后再操作。
打开“设置 → 网络和 Internet → 代理”，确认手动代理暂时关闭；再到当前网络适配器的 IPv4 DNS 设置，将手动 DNS 暂时改回“自动获取”。菜单名称以 Windows 当前版本为准。
以普通命令提示符执行 ipconfig /flushdns，再执行 nslookup example.com。需要指定上游时，可用 nslookup example.com DNS服务器地址；Microsoft 文档说明 nslookup 可用于诊断 DNS 基础设施。
重新启用 Mihomo 时，先只开系统代理或普通混合端口，不要马上开启 TUN。Mihomo 文档说明 Windows 的 DNS 劫持和严格路由存在特定依赖，启用 TUN 后应重点检查 strict-route、防火墙和 dns-mode。

macOS

在客户端关闭 TUN、系统代理和 DNS 覆写。
打开“系统设置 → 网络 → 当前网络 → 详细信息 → DNS”，删除刚添加的自定义 DNS，或暂时恢复为自动状态。Apple 的菜单路径可参考 Apple 官方 DNS 设置说明。
终端执行 scutil --dns 查看当前解析器，使用 dig example.com 检查解析结果；如果只是客户端内置 DNS 失败而系统 DNS 正常，优先回到 Mihomo 的 nameserver、监听端口和覆写配置检查。
确认直连正常后，只启用普通代理，再单独启用 TUN。macOS 的 TUN 配置和系统代理不是同一层，不能用浏览器能打开网页证明 TUN 路由一定正确。

Linux

先停止客户端的 TUN、DNS 劫持和自动路由，避免手动删除不了解来源的路由规则。
执行 resolvectl status 查看当前 DNS，执行 resolvectl query example.com 测试解析；使用 NetworkManager 的系统也可查看当前连接配置，命令名称会因发行版不同而变化。
如果客户端退出后仍断网，检查是否遗留 TUN 网卡、策略路由或防火墙规则；优先用客户端的“停止 TUN/恢复网络”功能，只有确认规则来源后再清理。
Linux 开启 TUN 时，Mihomo 文档将 auto-redirect 与 Linux 的透明转发关联，并说明部分协议栈受防火墙影响；因此要把路由、iptables/nftables、防火墙和 DNS 劫持分开验证。

Android

在 Mihomo 客户端停止 VPN/TUN，关闭 Android 系统的“私人 DNS”或暂时改为“自动”，再用浏览器测试普通网络。
如果关闭 TUN 后恢复，重新启用时先不要开启复杂规则和 Fake-IP。Android 的系统 VPN、私人 DNS 与 Mihomo 的 DNS 劫持可能互相影响；官方文档明确指出，开启私人 DNS 时不能自动劫持 DNS 请求。
检查客户端是否被系统省电策略限制，确认 VPN 权限仍存在；不同厂商的入口可能不同，不能按某一品牌菜单硬套。
如果只有某个应用打不开，检查 Mihomo 的应用包含/排除规则，而不是立即改全局 DNS。

不同系统恢复成功后，都应先保留这条最小基线，再逐项加回 TUN、Fake-IP、策略组和分流规则。这样才能知道是哪一个变量重新触发故障。

最小 DNS 排查：先分清是哪一种解析失败

不要把“DNS 配置”理解成一个字段。Mihomo 文档将不同字段用于不同解析任务：

字段或对象	作用	故障时看什么
`nameserver`	普通域名的默认解析服务器	普通网站域名是否能返回地址
`default-nameserver`	用于解析 DNS 服务器自身的域名	DoH/DoT 地址写成域名时，上游域名是否先能解析；它必须是 IP 或可用的加密 DNS 地址
`proxy-server-nameserver`	仅用于解析代理节点域名	普通网站可解析、但节点域名无法解析时再检查
`nameserver-policy`	按域名或规则集选择解析服务器	某些域名失败、解析结果与预期出口不一致
`fake-ip-filter`	控制哪些域名不接收 Fake-IP 映射	局域网、设备发现、内网域名或特定应用异常

其中，default-nameserver 不是普通网站查询的“首选 DNS”，而是帮助解析 DoH/DoT 上游域名。proxy-server-nameserver 也不是所有用户都必须填写；只有当代理节点域名需要独立解析，或 DNS 请求按规则经代理时，才有必要单独设置。Mihomo 文档同时提示，如果 DNS 查询本身需要通过代理，应配置用于节点解析的服务器以避免特定拓扑下的相互等待；这不是“缺少字段就一定循环”的普遍结论。

测试 DNS 上游时不要照抄某个公共地址。223.5.5.5、1.1.1.1 等示例并不代表在所有网络环境都可达，应替换为所在网络实际可访问的 DNS，并分别确认 UDP、TCP 或 DoH/DoT 上游是否能建立连接。浏览器的 Secure DNS 只可能影响浏览器自身，不等于系统 DNS，也不等于 Mihomo 内部 DNS。

建议按以下顺序对照：

系统命令查询普通域名：Windows 使用 nslookup example.com，macOS/Linux 使用 dig example.com 或系统自带解析命令。
查看 Mihomo 日志，确认失败对象是普通网站、代理节点域名、DNS 上游域名，还是目标 IP 连接。
如果普通域名可解析、节点域名失败，检查 proxy-server-nameserver 和节点域名本身；如果节点已连接但网页失败，再检查规则、代理组和出口。
如果局域网域名失败，检查 fake-ip-filter、direct-nameserver 和局域网 DNS，不要直接把所有内网域名交给公网解析。

配置逐项加回：YAML、监听端口、Fake-IP 和 TUN

恢复直连后，建议使用“配置骨架”思路，而不是把网上示例当作可直接运行成品。下面只列字段关系，属于检查清单，不是可直接粘贴的完整配置：

dns.enable: true：确认 DNS 模块启用；关闭时会使用系统 DNS。
dns.listen：确认监听地址和端口没有被其他程序占用；端口占用会让 DNS 模块无法按预期接收请求。
dns.nameserver：先只保留一到两个已验证可达的上游，确认普通域名解析后再增加策略。
dns.enhanced-mode：先使用客户端和当前版本明确支持的模式；Fake-IP 出问题时，可临时改为 redir-host 做对照，但要记录改动并在测试后恢复原值。
dns.fake-ip-filter：只加入确实需要真实地址的局域网或设备域名，避免使用不理解含义的全量通配。
tun.dns-hijack、tun.auto-route、tun.strict-route：一次只恢复一个变量。官方 TUN 文档说明不同系统对 DNS 劫持、严格路由和自动转发有不同要求。

每次改动后执行三项校验：一是客户端能否加载配置；二是日志是否显示 DNS 监听和 TUN 启动成功；三是用一个普通域名、一个代理节点域名和一个局域网域名分别测试。配置加载成功只代表语法或加载层通过，不代表上游可达、节点可用、规则正确或 TUN 流量已经接管。

如果客户端支持控制 API，可在确认 API 地址和认证方式后使用 Mihomo 文档中的 DNS 缓存清理接口；不要把外部控制端口暴露到公网。Mihomo API 文档列出了清理 DNS 缓存和 Fake-IP 缓存的接口，但具体客户端是否开放 API、路径是否可访问，以客户端设置为准。

仍然无法上网时：按日志对象分流

日志或现象	下一步	恢复方式
`yaml`、缩进、字段类型错误	检查重复的 `dns:` 区块、冒号、列表缩进和字符串引号；只保留一个生效配置来源	回滚到备份，再逐段加回
`listen udp ... address already in use`	检查 DNS 或混合端口是否被其他程序占用	换用未占用端口或关闭冲突进程，避免盲目改端口后忘记同步客户端
`dns resolve failed` 或 `timeout`	测试上游可达性，确认 DoH/DoT 域名能由 `default-nameserver` 解析	暂时回到已验证的系统 DNS 或可达上游
节点域名失败，普通域名正常	检查 `proxy-server-nameserver`、节点域名、代理解析策略	先关闭复杂策略，验证节点域名的独立解析
DNS 正常，网页仍打不开	检查代理组选择、规则命中、出口连接、TLS、系统时间和浏览器 Secure DNS	切换到已知可用的代理组或暂时使用普通代理模式对照
关闭 TUN 正常，开启 TUN 断网	检查权限、`auto-route`、`strict-route`、`dns-hijack`、防火墙和残留路由	关闭 TUN，确认普通代理恢复后再逐项启用

不要用单次 ping、单个测速结果或“DNS 查询成功”直接证明整条连接可用。DNS 只解决名称到地址的解析，后续仍可能在节点认证、TCP/TLS、规则选择、代理出口或应用自身的 Secure DNS 阶段失败。

回滚与安全检查清单

保留原始配置和修改后的配置，使用带日期的文件名，避免无法比较。
恢复时按“关闭 TUN → 关闭系统代理 → 恢复系统 DNS → 清理缓存 → 测试直连”的顺序执行。
重新启用功能时按“普通代理 → DNS 模块 → Fake-IP 或 redir-host → 规则策略 → TUN”的顺序，每次只改一项。
不要把订阅链接、UUID、密码、节点域名、API 密钥和完整日志公开；分享日志前先脱敏。
如果客户端外壳提供“一键恢复网络”或“重置 DNS”功能，优先使用它；手动改路由和防火墙前，先记录当前状态。

本文是客户端使用与网络排查指南，不代表任何客户端项目的官方页面。客户端功能、字段支持和菜单路径可能变化，最终以当前项目文档和实际版本为准。

常见问题

Mihomo DNS配置后完全没网，第一步应该做什么？

先备份配置，然后关闭 TUN、系统代理和 DNS 覆写，恢复系统自动 DNS，确认设备直连是否正常。直连恢复后，再逐项启用 Mihomo 功能。

default-nameserver 和 nameserver 有什么区别？

nameserver 用于普通域名解析；default-nameserver 主要用于解析 DNS 服务器自身的域名，尤其是 DoH 或 DoT 上游使用域名时。它们不是完全相同的用途。

proxy-server-nameserver 必须配置吗？

不一定。它专门用于代理节点域名解析；只有节点域名解析失败、DNS 请求按规则经代理，或当前拓扑确实需要独立节点解析时才考虑配置。具体行为以当前 Mihomo 文档和版本为准。

浏览器能打开网页，是否代表 Mihomo DNS已经正常？

不代表。浏览器可能使用自身的 Secure DNS，绕过系统 DNS 或 Mihomo DNS。应同时对照系统的 nslookup/dig、Mihomo 日志、节点连接和实际代理出口。

Fake-IP 和 redir-host 应该选哪个？

不要先追求固定答案。遇到局域网、设备发现或特定应用异常时，可在备份后临时切换到另一种模式做对照；每次只改一个变量，并检查 fake-ip-filter 与当前 TUN 配置。

Mihomo 配置测试通过后，为什么还是不能上网？

配置加载或语法校验通过，只能说明文件能被读取，不能证明 DNS 上游、监听端口、节点、规则、TLS 或 TUN 路由都正常。还需要观察启动日志并按域名解析、节点连接、网页访问三层分别测试。