ZeZe

Mihomo TUN 模式无法上网怎么办？按 DNS、路由和防火墙排查

更新于 2026-11-04 · allzezecloud.xyz

简答：如果 Mihomo 开启 TUN 后整机无法上网，先关闭 TUN 或退出 Mihomo，确认普通网络恢复；然后只重新启用 TUN、auto-route 和 auto-detect-interface，最后再检查 DNS 模式、防火墙与 IPv6。多数情况不是节点本身失效，而是虚拟网卡没有正确接管路由，或 DNS 劫持与系统防火墙发生冲突。

定义：Mihomo TUN 模式是通过虚拟网卡接管系统流量的透明代理方式，无法上网时应优先排查虚拟网卡、自动路由、DNS 处理和系统防火墙之间是否配合正常。

先试这 3 步：把网络恢复，再定位 TUN 问题

本文是 ZeZe 的第三方使用指南，不是 Mihomo 官方页面。不同客户端的菜单名称可能不同，以下字段以 Mihomo TUN 配置文档为准。

  1. 关闭 TUN，保留普通代理或直接退出 Mihomo。如果网络立即恢复，问题基本集中在 TUN 的路由、DNS、权限或防火墙，而不是先判断节点失效。
  2. 重新启用时只保留必要选项。优先确认 enable: true、auto-route: true 和 auto-detect-interface: true。先不要同时修改 MTU、IPv6、分流路由和复杂 DNS。
  3. 按现象分流。能打开 IP 但打不开域名，先查 DNS；所有网站和应用都打不开，先查路由、出口网卡、权限和防火墙；只有部分应用失败，再查规则、IPv6 或应用自身的网络限制。

官方文档说明，顶层 TUN 配置适合自动路由、DNS 劫持和系统流量接管；普通用户通常应优先使用顶层 tun 配置，而不是额外创建高级 TUN listener。参考：Mihomo Inbound Configuration。

先用表格判断：到底是路由、DNS 还是防火墙

现象优先检查处理方向
开启 TUN 后所有应用都无法联网auto-route、auto-detect-interface、系统权限、防火墙关闭复杂选项，确认出口网卡和自动路由正常
可以访问已知 IP，但域名打不开dns.enable、dns-mode、dns-hijack、nameserver先确认 Mihomo DNS 是否启动，再检查 DNS 劫持和解析服务器
浏览器能用，部分应用不能用应用是否走系统代理、规则命中、IPv6查看应用请求是否进入 TUN，必要时暂时关闭 IPv6 测试
只有开启防火墙后无法使用系统防火墙是否拦截 Mihomo 核心或 TUN 网卡为 Mihomo 核心程序或 TUN 出站流量添加允许规则
连接一会儿后断网或速度明显异常MTU、GSO、IPv6、路由冲突先恢复默认 MTU，逐项关闭高级选项后复测

这张表的判断依据来自 Mihomo 对 TUN 自动路由、DNS 模式、严格路由和防火墙行为的说明；具体表现仍会受到系统版本、客户端封装方式和当前配置影响。

按最短路径修复 Mihomo TUN 无法上网

第 1 步：备份并回到最小 TUN 配置

先复制当前配置文件或导出配置，避免排查过程中无法回滚。然后暂时移除或注释自定义的 route-address、route-exclude-address、include-interface、exclude-interface、UID 限制、应用包名限制和自定义 IPv6 路由。

初次排查只需要确认类似以下字段存在，字段名和缩进必须以当前 Mihomo 文档及客户端配置格式为准：

tun:
  enable: true
  stack: mips
  auto-route: true
  auto-detect-interface: true

当前文档列出的 TUN 协议栈包括 system、gvisor、mixed 和 mips，并将 mips列为一般无明显问题时的推荐默认栈。不要因为别人的配置使用某个栈，就直接认定它适合你的系统。

第 2 步：确认出口网卡没有选错

电脑同时连接 Wi-Fi、有线网卡、虚拟机网卡、公司 VPN 或手机热点时，自动识别可能无法得到你期望的出口。先断开暂时不用的网络接口，再重新启动 Mihomo；如果恢复，说明问题可能与多出口环境有关。

如果必须同时保留多个接口，再考虑手动指定出口接口。官方文档建议，在同时存在多个出口接口时手动指定 outbound interface，但具体字段和客户端界面需要以当前版本为准。

第 3 步：检查 TUN 权限和系统防火墙

TUN 需要创建虚拟网卡并修改系统路由，因此客户端可能需要管理员权限、系统扩展许可或 VPN 权限。表现为“配置看起来正确但没有请求进入 TUN”时，先完全退出 Mihomo，再以系统允许的权限重新启动。

Mihomo 文档指出，在 Windows 上，system 和 mixed 协议栈在防火墙开启时可能需要放行核心程序；Linux 上如果防火墙阻断 TUN 网卡出站流量，也需要添加允许规则。不要直接复制网上不明来源的防火墙命令，先确认系统、网卡名称和规则管理工具。

第 4 步：只有域名打不开时，再处理 DNS

先区分“没有网络”与“DNS 解析失败”。如果能访问一个已知 IP，但打开域名失败，重点查看 dns.enable、enhanced-mode、nameserver 和 TUN 的 dns-mode。

官方 DNS 文档说明，enhanced-mode可使用 fake-ip 或 redir-host；TUN 的 dns-mode可设置为 disabled、native 或 hijack。Windows 上使用 DNS 劫持时，strict-route与防止 DNS 泄漏有关；Linux 上 DNS 劫持还依赖自动重定向条件。建议先使用客户端默认 DNS 方案，确认网络恢复后再调整 fake-ip、nameserver-policy 或 fallback。

如果配置了 respect-rules: true，还要注意 Mihomo 文档要求同时配置 proxy-server-nameserver，否则解析代理节点域名时可能形成相互依赖。这个字段不要在不了解现有规则的情况下随意添加，先检查节点地址是否为域名、DNS 是否能独立解析节点域名。

第 5 步：暂时关闭 IPv6 和复杂规则进行复测

如果 IPv4 可以连接、IPv6 相关请求失败，或者只有部分应用异常，可以暂时关闭配置中的 IPv6 处理进行对照测试。确认问题后，再根据实际网络逐项恢复 IPv6、IPv6 路由和规则集。

同时暂时使用简单的策略组或明确的节点，减少规则集、脚本和自定义路由对结果的干扰。本文只处理 TUN 无法上网，不把规则策略问题与节点质量混在一起判断。

第 6 步：最后才测试 MTU

MTU 不是开启 TUN 后断网的第一排查项。Mihomo 文档说明，MTU 会影响极端条件下的传输速率，一般用户可以保持默认值。只有在网页部分加载、特定应用连接失败、频繁重传等现象持续存在，并且路由、DNS 和防火墙都正常时，才适合小范围调整并逐次复测。

按系统分流：Windows、macOS、Linux 和 Android 的注意点

Windows

  • 先确认 Mihomo 核心程序已被防火墙允许，尤其是使用 system 或 mixed 协议栈时。
  • 如果使用 DNS 劫持，检查是否启用了与严格路由相关的设置；不确定时先回到客户端默认方案。
  • 虚拟机、公司 VPN、网卡加速软件可能修改路由表，排查时先临时关闭不必要的虚拟网络接口。

macOS

  • 确认系统已允许客户端创建或使用 VPN、网络扩展或 TUN 接口。
  • macOS 的 TUN 接口名称通常需要符合系统要求；自定义设备名时不要直接套用其他系统的接口名。
  • 如果开启系统防火墙后才出现问题，按官方文档检查应用是否被允许，而不是先修改 DNS。

Linux

  • 确认运行用户有创建 TUN 和修改路由的权限。
  • auto-redirect是 Linux 专用选项，并且需要同时启用 auto-route；防火墙、iptables、nftables 规则冲突时，可能出现 TUN 已启动但流量不通。
  • 如果使用基于 nftables 的地址集路由，还要确认相关组件和规则集条件满足，排查时可先移除自定义地址集。

Android

  • 检查系统 VPN 权限是否已授予，并确认没有同时运行另一个 VPN 类应用。
  • Android 开启 Private DNS 时，DNS 请求可能无法被自动劫持；可暂时改为系统自动或关闭 Private DNS 进行对照测试。
  • 如果使用应用包含或排除规则，先取消应用范围限制，确认全局 TUN 能工作后再逐个恢复。

以上系统差异均应以当前 Mihomo TUN 文档和客户端实际界面为准；文档明确说明 Android 的 Private DNS、Linux 的自动重定向以及 Windows 的严格路由对 DNS 处理存在额外条件。

复测与回滚：确认修好了，而不是暂时碰巧能用

  1. 关闭 TUN，确认普通网络可以恢复。
  2. 重新开启 TUN，只保留最小配置，打开一个普通网页并测试一个此前失败的应用。
  3. 确认域名解析、网页连接和应用请求都正常后，再一次只恢复一个高级选项。
  4. 每次改动后重新启动 Mihomo，并记录“改了什么、是否恢复、哪个应用仍失败”。
  5. 如果某个选项导致断网，回退到备份配置，不要继续叠加修改。

如果 TUN 能启动但所有请求仍没有记录，优先查看客户端是否真的使用了当前配置、核心是否正在运行，以及系统是否授予了 TUN 权限。如果只有某个域名失败，再转向 DNS 或规则排查，不要反复重装客户端。

常见问题 FAQ

1. Mihomo TUN 开启后完全断网，应该先改 DNS 吗？

不建议。完全断网时先关闭 TUN 验证普通网络，再检查 auto-route、出口网卡、权限和防火墙。只有“IP 能通、域名不通”时，DNS 才是第一优先级。

2. TUN 的 auto-route 和 auto-redirect 是一回事吗？

不是。auto-route负责自动设置全局路由；auto-redirect是 Linux 相关的 TCP 重定向能力，并且需要启用 auto-route。普通用户不要把 Linux 配置直接照搬到 Windows、macOS 或 Android。

3. 为什么开启 strict-route 后反而有些软件不能用？

strict-route会强化流量经过 TUN 的约束，并可能影响某些虚拟机或特殊网络环境。官方文档也提示它在特定场景下可能导致 VirtualBox 等软件异常。可以先关闭该选项做对照测试；如果关闭后恢复，再针对具体软件配置排除项。

4. MTU 改成 9000 就能解决 TUN 断网吗？

不能这样判断。MTU 主要影响特定传输条件下的数据包处理，一般用户可保持默认值。TUN 一开启就断网时，优先排查路由、DNS、权限和防火墙，最后才测试 MTU。

5. Android 上 TUN 正常启动但域名打不开怎么办？

先检查 Private DNS 是否启用。Mihomo 文档说明，Android 开启 Private DNS 时，DNS 请求可能无法被自动劫持；可以暂时改为自动或关闭后复测。若仍失败，再检查 DNS 配置和应用包含/排除范围。

6. 如何判断是节点问题还是 TUN 问题？

先关闭 TUN，使用同一配置的普通代理入口测试。如果普通代理可用、只有 TUN 失败，优先排查 TUN 路由、DNS、权限和防火墙；如果两种模式都失败，再检查节点、订阅配置或上游网络。

参考资料

本文关键字段和系统差异依据以下 Mihomo 一手文档整理：

  • Mihomo TUN 配置文档：TUN 协议栈、自动路由、DNS 模式、严格路由、MTU 和各系统注意点。
  • Mihomo DNS 配置文档：DNS 启用状态、fake-ip、nameserver、fallback 和 proxy-server-nameserver。
  • Mihomo Inbound Configuration：顶层 TUN 与高级 TUN listener 的定位和使用边界。

资料核验日期：2026 年 11 月 4 日。客户端封装层的菜单名称、权限提示和默认值可能不同，遇到冲突时以当前版本界面与官方文档为准。

常见问题

Mihomo TUN 开启后完全断网，应该先改 DNS 吗？

不建议。先关闭 TUN 验证普通网络，再检查 auto-route、出口网卡、权限和防火墙；只有 IP 能通而域名不通时，才优先查 DNS。

TUN 的 auto-route 和 auto-redirect 是一回事吗？

不是。auto-route 负责自动设置路由，auto-redirect 主要用于 Linux 的 TCP 重定向，并且需要配合 auto-route。

为什么 strict-route 会让部分软件异常？

strict-route 会强化流量经过 TUN 的约束，可能影响虚拟机等特殊网络环境。可以先关闭它做对照测试，再为具体应用配置排除项。

MTU 改成 9000 就能解决 TUN 断网吗？

不能直接判断。MTU 应放在路由、DNS、权限和防火墙之后排查，一般用户可以先保持默认值。

Android 上 TUN 启动但域名打不开怎么办？

先检查 Private DNS。Android 开启 Private DNS 时，DNS 请求可能无法被自动劫持；可暂时改为自动或关闭后复测。

相关阅读

参考资料

  1. Mihomo TUN 配置文档
  2. Mihomo Inbound Configuration