Mihomo TUN 无法使用怎么办？先恢复网络，再按 4 种症状排查

更新于 2026-11-10 · ofonet.online

简答：Mihomo TUN 无法使用时，先关闭 TUN，用 Mixed、HTTP 或 SOCKS 端口确认核心和节点是否正常；普通代理可用后，再按“无法创建、启动后全断网、只有域名打不开、只有部分应用失败”分支排查。Windows 先看管理员权限或服务模式，Linux 看 root/CAP_NET_ADMIN 与 /dev/net/tun，macOS 看网络扩展授权，Android 看 VPN 权限和其他 VPN 冲突。成功判据是普通代理可用、TUN 能创建，且关闭系统代理后至少一个未单独设置代理的应用可以联网。

定义：Mihomo TUN 模式是通过虚拟网络接口接管系统或指定应用流量，再交给 Mihomo 的路由、DNS 和代理规则处理的透明接入方式，不等同于只监听 HTTP、SOCKS 或 Mixed 端口。

30 秒决策树：先判断故障在哪一层

本页为第三方使用指南，不代表任何客户端或核心项目的官方网站。先不要同时修改 DNS、MTU、协议栈和路由；每次只改一个变量，并保留原配置。

现象	优先判断	立即动作	成功判据
普通代理也无法连接	核心、配置、代理组或节点层	保持 TUN 关闭，检查核心日志和节点连接	Mixed、HTTP 或 SOCKS 端口能够访问测试目标
普通代理可用，但 TUN 无法创建	权限、服务模式、虚拟网卡或字段兼容性	检查管理员/root/VPN 权限和当前客户端服务状态	日志不再出现 permission denied 或 TUN interface error
TUN 显示启动但全局断网	出口网卡、自动路由、严格路由或防火墙	先关闭 TUN 恢复网络，再检查 auto-route 与出口接口	开启 TUN 后默认路由和普通网页均可用
只有域名打不开	DNS、dns-mode、dns-hijack、Private DNS 或 fake-ip	使用 nslookup、dig 或系统 DNS 测试，不用浏览器直接访问 HTTPS IP 判断	域名查询有响应，且解析结果能建立连接
只有部分应用失败	UDP、IPv6、应用自带代理或排除规则	对比浏览器、命令行和目标应用，并检查 include/exclude 设置	失败应用与其他应用的差异已定位

最快回滚：关闭 TUN，退出当前客户端和其他 VPN，恢复配置备份，再只启用普通代理端口。系统网络恢复后，才重新开启 TUN。

第一步：关闭 TUN，验证核心和节点是否正常

在客户端中关闭 TUN，并关闭系统代理以外的重复代理功能；Clash Verge Rev 的设置资源中将 TUN Mode 与 System Proxy 分开列出，TUN 用于接管系统流量，不能把两个开关的结果混为一谈。具体菜单名称随版本可能变化，可在设置页搜索 TUN、System Proxy 或 Service。
保留一个 Mixed、HTTP 或 SOCKS 端口，使用同一节点、同一目标进行测试。Mihomo 官方文档将这些端口作为不同类型的入站，Mixed 可同时处理 HTTP(S) 与 SOCKS5 请求，适合先验证核心是否监听和节点是否能建立连接。参考Mihomo 入站端口文档。
如果普通代理失败，先不要改 TUN。检查配置是否加载、代理组是否选中节点、核心是否持续运行以及日志中是否有节点连接错误。
如果普通代理成功，说明节点和核心至少具备基本工作条件，故障范围缩小到 TUN 创建、路由接管、DNS 或应用兼容性。

不要用浏览器直接访问 HTTPS IP 判断 DNS：HTTPS 站点可能因证书或 Host/SNI 不匹配而失败。Windows 可使用 nslookup example.com，macOS 或 Linux 可使用 dig example.com；只观察“是否返回 DNS 结果”和“查询是否超时”，不要把网页打开结果单独当作 DNS 结论。

第二步：只用基础 TUN 字段，先验证创建和路由

改动前复制配置文件，并记录客户端版本、Mihomo 核心版本、系统版本、CPU 架构和启动日志。若能直接运行核心，可先执行：

mihomo -t -f config.yaml

MetaCubeX Dashboard 的配置流程说明，配置激活前会使用 mihomo -t 做最终校验，校验通过后才重启核心，参考MetaCubeX Dashboard 官方仓库。如果客户端没有命令行入口，使用其配置编辑器或配置检查功能；菜单名称以当前版本为准。

第一阶段只保留 TUN 创建和基础路由相关字段，不要先加入 dns-hijack、fake-ip 或复杂 DNS：

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

以上字段及可用协议栈以当前官方文档为准。Mihomo 当前文档列出 system、gvisor、mixed、mips 四种 stack，并说明默认与推荐值可能随核心版本变化；不要把某个客户端的默认值当作所有客户端的默认值。参考Mihomo 官方 TUN 配置文档。

基础 TUN 能创建、默认路由正常、至少一个应用可以联网后，再单独加入 DNS 配置和 dns-hijack。这样可以避免把“权限问题”和“DNS 配置问题”混成一次故障。

第三步：按系统核查权限、服务模式和虚拟网卡

Windows：优先核查管理员权限和 Service Mode

先完全退出其他代理客户端、VPN 和网络过滤软件，再重新打开当前客户端。
如果客户端提示 TUN 需要服务模式或管理员权限，优先使用客户端设置中的 Install Service、Service Mode 或以管理员身份运行。Clash Verge Rev 的设置资源明确包含 TUN Mode、Install Service 和 Switch to Service Mode 等项目，并提示 TUN 需要服务模式或管理员权限，参考Clash Verge Rev 设置字段。
打开 PowerShell，执行 Get-NetAdapter 查看网络适配器，执行 Get-NetRoute -DestinationPrefix '0.0.0.0/0' 查看 IPv4 默认路由。Microsoft 文档说明 Get-NetRoute 用于读取路由表，0.0.0.0/0 表示 IPv4 默认路由，参考Microsoft Get-NetRoute 文档。
正常情况下应能看到正在使用的 Wi-Fi 或以太网接口，以及一条有效默认路由。若 TUN 开启后默认路由消失、接口状态异常或所有流量都无下一跳，先关闭 TUN，再检查自动检测接口和防火墙放行。

Windows 防火墙放行核心程序是后置检查，不应替代管理员权限或服务模式核验。Mihomo 文档还指出，使用 system 或 mixed 协议栈时，防火墙可能需要允许核心程序通过。

macOS：核查网络扩展授权与 utun 接口

先确认客户端是否请求并获得网络扩展、VPN 或辅助服务授权；如果系统弹窗被拒绝，重新打开客户端设置中的 TUN 或网络扩展相关开关，具体名称需以当前客户端为准。
终端执行 ifconfig 查看是否出现以 utun 开头的接口，再执行 route -n get default 查看默认路由。
Mihomo 官方文档要求 macOS 的 TUN 设备名以 utun 开头。若没有 utun 接口，优先处理授权或客户端辅助组件，不要先改 DNS。
如果存在多个 VPN、网络扩展或安全软件，逐个退出后只保留一个客户端复测。

Linux：核查 root、CAP_NET_ADMIN 和 /dev/net/tun

执行 id 确认当前用户；以服务方式运行时，确认服务具备创建和配置网络接口所需的权限。
执行 ls -l /dev/net/tun。文件不存在或服务无权访问时，TUN 通常无法创建；容器环境还需确认设备映射和 NET_ADMIN 能力。MetaCubeX 的容器说明将 NET_ADMIN、/dev/net/tun 和 host networking 列为 TUN 条件，参考官方容器说明。
执行 ip link 查看 TUN 接口，执行 ip route 查看路由表。ip link 用于查看和管理网络接口，参考Linux ip-link 手册。
若开启防火墙后 TUN 无法出站，可按当前防火墙工具检查 TUN 接口出站规则。Mihomo 文档给出的 iptables 示例假定网卡名为 Mihomo，实际接口名必须先通过 ip link 确认，不要直接照抄接口名。

Android：核查 VPN 授权、Private DNS 和应用范围

确认系统已向当前客户端授予 VPN 权限，并检查是否有其他 VPN、广告拦截器或网络过滤应用正在占用 VPN。Android 官方说明同一时刻只有一个应用可以成为当前准备好的 VPN 服务，权限可能被其他应用接管，参考Android VPN 官方文档。
如果配置了 include-package 或 exclude-package，确认失败应用没有被排除。
如果 Android 开启 Private DNS，Mihomo 官方文档说明相关 DNS 请求不能被自动劫持；可暂时关闭 Private DNS 做对照，测试后再根据网络环境决定是否恢复。

第四步：区分 TUN 启动失败、全局断网和 DNS 故障

日志出现 permission denied

这表示核心尝试创建或配置 TUN 时权限不足，优先检查 Windows 管理员/服务模式、macOS 网络扩展授权、Linux root 或 CAP_NET_ADMIN 与 /dev/net/tun，Android 则检查 VPN 授权。防火墙只能作为后续对照项，不能替代系统权限。公开 Issue 只能证明曾出现过类似报错，不能单独证明你的设备原因相同。

日志出现 interface timeout、device is not ready 或 Start TUN listening error

先退出其他代理客户端和残留核心，确认虚拟网卡没有被禁用，再重启当前客户端。若仍失败，使用基础 TUN 配置逐项恢复，并记录每次改变的字段。Mihomo 官方文档将 TUN 设备、协议栈、自动路由和自动检测出口接口分别定义，不能把“设备未就绪”直接归因于 DNS 或节点。

日志出现 address already in use

先检查是否有重复运行的核心、重复端口或两个客户端同时启用 TUN。关闭重复进程后再启动；不要为了绕开报错直接随机改多个端口或配置。

TUN 启动后全局断网

立即关闭 TUN，确认系统网络恢复。
执行 Windows 的 Get-NetRoute -DestinationPrefix '0.0.0.0/0'、macOS 的 route -n get default 或 Linux 的 ip route，观察默认路由是否仍指向实际 Wi-Fi、有线或移动网络接口。
检查 auto-route、auto-detect-interface 和 strict-route。多网卡、虚拟机网卡或 Wi-Fi/有线并存时，官方文档建议考虑手动指定出站接口。
如果只在开启 strict-route 后出现异常，先关闭它进行对照。官方文档说明该选项可强化路由和 DNS 防泄漏，但在特定场景可能影响 VirtualBox 等应用。

只有域名打不开

不要用 HTTPS IP 访问结果直接判断 DNS。使用 nslookup example.com 或 dig example.com 观察查询是否超时、是否返回地址，再对比 TUN 开启前后的结果。

先确认顶层 dns.enable、listen、enhanced-mode 和 nameserver 配置没有被覆盖。
如果使用 fake-ip，Mihomo 文档列出 fake-ip-range: 198.18.0.1/16 示例；看到 198.18.x.x 不能单独证明节点失效，应结合 DNS 映射和实际连接判断。
确认 dns-hijack 或 dns-mode 与平台匹配。Windows、macOS 不能自动劫持发往本地网络的 DNS；Android 开启 Private DNS 时也不能自动劫持相关请求。
公司内网、局域网设备和打印机域名异常时，先检查 fake-ip-filter 或局域网规则，不要直接把全部域名改为 real-ip。

DNS 字段的取值、fake-ip 范围和过滤器语法以Mihomo 官方 DNS 文档为准。

只有部分应用失败

先比较浏览器、命令行工具和目标应用。若只有一个应用失败，检查其自带代理、独立 DNS、UDP 依赖、IPv6 依赖，以及 Android 的 include-package、exclude-package。Hysteria2 等 UDP 场景应单独验证 UDP，不能用普通网页结果代表所有协议都正常。

客户端界面怎么找：只写已确认入口，未知菜单不要硬套

Clash Verge Rev：其公开设置字段包含 System Proxy、TUN Mode、Install Service、Uninstall Service、Switch to Service Mode、Open Logs Dir 和 Open Core Dir。Windows 上 TUN 创建失败时，先在客户端设置中寻找 TUN、Service 或管理员相关操作，再查看日志目录；不同版本的中文翻译和页面布局需以当前安装版本为准。

Mihomo Party：公开资料可确认其基于 Mihomo 核心并提供 TUN 功能，但当前检索资料不足以核实所有版本的固定菜单路径。因此建议在客户端设置中搜索 TUN、核心、服务、日志或网络扩展关键词，不把某篇旧教程的路径当作固定入口。

Clash Nyanpasu：当前资料不足以核实统一的 TUN、服务模式和日志菜单名称。遇到启动失败时，先使用核心配置文件和系统层命令完成判断，再回到客户端查找 TUN、Service、Core、Logs 等同义入口。

无论使用哪一个 GUI，先确认实际运行的核心版本和配置文件，再判断字段是否被客户端覆盖。客户端版本、核心版本、默认 stack 和菜单名称可能不同；无法从当前资料确认的内容，应以当前客户端页面和 Mihomo 文档为准。

回滚、复测与提交问题的最小清单

回滚：关闭 TUN，关闭系统代理和其他 VPN，退出客户端，恢复原配置备份，再启动客户端。
复测：只启用普通 Mixed、HTTP 或 SOCKS 端口，确认节点可用后，再启用基础 TUN。
逐项恢复：依次恢复 DNS、dns-hijack、strict-route、IPv6、应用包含/排除规则和 MTU，每次只改一个字段。
保留记录：记录系统版本、客户端版本、核心版本、CPU 架构、TUN 配置、复现时间、完整日志、普通代理是否可用、TUN 是否创建以及失败应用范围。
脱敏：提交日志前删除订阅链接、UUID、密码、访问令牌、服务器地址和完整节点配置。

如果问题发生在升级之后，记录升级前后的客户端和核心版本，并用同一份最小配置复测。Issue 或公开案例只能作为现象参考，不能替代本机权限、路由、DNS 和应用范围的逐项验证。

常见问题

Mihomo TUN 一打开就断网，第一步做什么？

立即关闭 TUN，确认系统网络恢复；再用 Mixed、HTTP 或 SOCKS 端口测试同一节点。如果普通代理可用，重点检查 auto-route、auto-detect-interface、strict-route、默认路由和出口网卡，不要先反复修改 DNS。

Mihomo 日志出现 permission denied 怎么办？

优先检查系统授权而不是防火墙：Windows 看管理员权限或 Service Mode，macOS 看网络扩展授权，Linux 看 root、CAP_NET_ADMIN 和 /dev/net/tun，Android 看 VPN 授权及其他 VPN 冲突。

看到 198.18.x.x 就代表节点失效了吗？

不一定。该地址范围可用于 Mihomo fake-ip。应同时检查 DNS 查询、规则命中和实际连接，不能仅凭 198.18.x.x 判断节点或线路故障。

Mihomo TUN 的 stack 应该选哪个？

先保留当前配置中能正常工作的值。当前官方文档列出 system、gvisor、mixed、mips，但不同核心或客户端的默认值可能不同；更换时一次只改一个字段，并在普通代理可用的前提下复测。

如何确认是 TUN 问题，而不是节点问题？

关闭 TUN，用同一节点和同一目标测试 Mixed、HTTP 或 SOCKS 端口。普通代理成功而 TUN 失败，故障更集中在权限、虚拟网卡、路由或 DNS 接管；普通代理也失败，则先排查核心、配置和节点。

Mihomo Party 或 Clash Nyanpasu 的 TUN 菜单找不到怎么办？

不要直接套用其他客户端的路径。先在当前客户端设置中搜索 TUN、核心、服务、日志或网络扩展关键词；若仍找不到，使用配置文件和系统命令判断故障阶段，具体菜单名称以当前版本为准。