Mihomo TUN 模式启动失败怎么办？按日志排查权限、网卡与路由
简答：Mihomo TUN 启动失败时，先关闭 TUN，确认 Mixed、HTTP 或 SOCKS 代理本身能正常工作；再读取完整日志区分“无法创建 TUN”与“已启动但无法联网”。优先检查管理员或系统权限、旧的 Mihomo 进程、其他 VPN 或虚拟网卡冲突，最后再调整 DNS、路由和 TUN 参数。
定义：Mihomo TUN 模式是通过虚拟网卡和系统路由接管流量的工作方式，权限、虚拟网卡、出口网卡、DNS 或路由任一环节异常，都可能导致启动失败或启动后断网。
先做对照：判断是 TUN 失败，还是核心和节点也有问题
如果你反复点击 TUN 开关却没有结果，不要一开始就批量修改配置。先在客户端中关闭 TUN，保留同一个配置和节点，使用 Mixed、HTTP 或 SOCKS 代理进行一次普通连接测试。普通代理能访问而 TUN 不能，问题通常集中在权限、虚拟网卡、系统路由或 DNS 接管；普通代理也不能访问，则应先检查配置是否加载、节点是否可用以及核心是否正常运行。
| 观察结果 | 优先判断 | 下一步 |
|---|---|---|
| 日志没有出现 TUN listening | 权限、网卡、驱动、旧进程或参数创建失败 | 检查权限、冲突进程和虚拟网卡 |
| 出现 TUN listening，但所有应用断网 | 路由、DNS、出口网卡或规则接管异常 | 关闭 DNS 劫持和严格路由做单变量复测 |
| 普通代理和 TUN 都不能访问 | 配置、节点、核心或基础网络问题 | 先恢复普通代理，再处理 TUN |
| 第一次失败，重启核心后成功 | 旧进程、旧网卡或系统网络初始化时序冲突 | 退出其他实例，重新启动客户端并记录日志 |
官方文档将 tun.enable、auto-route、auto-detect-interface、dns-hijack 和 strict-route列为相互关联的 TUN 选项；不要把整份复杂配置一次改完，否则无法判断是哪一项产生影响。可先参考Mihomo TUN 官方配置说明核对当前字段名称和平台边界。
按日志关键词分流处理
打开 Mihomo 或客户端的完整日志，保留从启动核心到报错结束的连续内容。不要只截取最后一行，因为前面的配置加载、代理端口和默认出口网卡信息有助于判断故障层级。
| 日志关键词 | 可能所在环节 | 安全处理顺序 |
|---|---|---|
permission denied | 当前进程没有创建虚拟网卡或写入路由的权限 | 退出核心，使用客户端提供的管理员授权或系统权限流程；不要直接关闭系统安全防护 |
cannot create TUN、device is not ready | 虚拟网卡未创建、不可用或被其他程序占用 | 关闭其他代理、VPN、虚拟机网络工具和重复的 Mihomo 实例，再检查系统网卡列表 |
Cannot create a file when that file already exists | 已有同名适配器、旧进程或旧的 TUN 状态残留 | 先完整退出客户端和核心，确认没有残留进程后重启；不要直接删除未知驱动 |
add route ... file exists | 路由已经存在，或另一套工具正在管理同一条路由 | 关闭其他接管网络的工具，关闭再开启 TUN；必要时重启系统后复测 |
Start Tun interface timeout | 创建或初始化 TUN 超时，不能单凭这行确定原因 | 结合后面的具体错误继续判断，不要只重复点击开关 |
出现 Tun adapter listening 后断网 | TUN 已创建，问题转向 DNS、路由、规则或出口接口 | 先关闭 dns-hijack 和 strict-route 做一次对照，再逐项恢复 |
官方仓库的公开问题记录中，确实可以看到“路由已存在”“设备未准备好”“适配器已存在”等不同错误文本；这些记录只能作为日志匹配线索，不能替代对本机环境的确认。可对照路由已存在的官方仓库问题、设备未准备好的官方仓库问题和Windows TUN 超时讨论。
Windows：先查权限、进程和虚拟网卡
- 关闭接管：先关闭 TUN 和系统代理，退出客户端；任务管理器中确认没有重复的 Mihomo 核心或其他代理实例。
- 重新授权：重新打开客户端，按客户端提示完成管理员授权。TUN 属于系统级路由操作，官方面板说明也提示桌面 TUN 首次启用通常需要管理员授权或特权辅助程序。可参考官方 Mihomo 面板仓库中的 TUN 说明。
- 检查网卡：打开系统的网络适配器列表，确认启用 TUN 后是否出现对应虚拟适配器。如果适配器出现后立即消失，重点看日志中的驱动、创建失败或设备未准备好信息。
- 排除冲突：暂时退出其他 VPN、虚拟机、容器网络、网络加速器和重复代理程序，再只启动一个 Mihomo 实例。不要直接删除驱动、清空路由表或关闭防火墙。
- 复测：先只保留
enable、auto-route和auto-detect-interface等必要设置，确认能出现 TUN listening 后，再逐项恢复 DNS 劫持和严格路由。
如果 Windows 日志出现“适配器已存在”或“系统找不到文件”，先记录完整错误、客户端版本、核心版本和系统版本，再重启客户端或系统复测。当前核心发布页显示的版本和资源会变化，下载或升级前应以Mihomo 官方 Releases 页面当前实际内容为准；本文不替你判断某个安装包是否适合你的客户端。
macOS、Linux、Android：按平台边界检查
- macOS：检查客户端是否获得创建网络扩展或系统网络配置所需的权限。若 TUN 能启动但域名打不开，先分别测试 IP 访问和域名解析，再核对 DNS 接管设置。官方文档说明 macOS 默认不一定启用 DNS 接管，不能把“已出现 TUN”直接等同于“DNS 已被接管”。
- Linux：检查运行用户是否有创建 TUN、修改路由和使用网络设备的权限。若启用了自动重定向或严格路由，先记录当前配置，再一次只调整一个字段；不要用批量删除路由的命令作为第一步。
- Android：确认系统 VPN 权限已经授予，并检查系统是否启用了 Private DNS。官方 TUN 文档指出，Android 开启 Private DNS 时，DNS 请求可能无法被自动劫持；这类情况应先关闭 DNS 劫持做对照，或按系统 DNS 设置重新设计配置。
- 所有平台：若设备上同时运行其他系统级 VPN、代理或安全软件，先关闭其他接管程序。TUN 解决的是流量接管，不会自动修复错误节点、错误规则或失效 DNS。
TUN 已启动但无法联网：DNS、路由与出口网卡复测
- 看出口接口：日志中应能看到默认出口网卡或自动识别接口。若出现接口为空、接口丢失或 interface not found，先恢复系统网络连接，关闭虚拟机和其他网络适配器后复测。
- 拆分 DNS：临时关闭
dns-hijack，保留 TUN 进行测试。如果关闭后网页恢复，问题集中在 DNS 监听地址、系统 Private DNS、53 端口或 DNS 规则，而不是虚拟网卡本身。 - 拆分严格路由：临时关闭
strict-route做对照。官方说明指出，Windows 的严格路由会增加阻止 DNS 泄漏的防火墙规则，Linux 上则会影响不支持网络的可达性；同时它也可能让某些虚拟化应用出现异常，因此应根据现象复测。 - 检查规则：如果只有部分域名或应用失败，优先检查规则、分流和 DNS 返回结果，不要立即更换核心或删除全部配置。
- 回滚：记录原配置，关闭 TUN，恢复原来的系统代理和 DNS 设置，确认普通网络恢复后，再从最小配置重新启用。
官方 API 文档提供了读取当前运行配置、查看版本和重新加载配置的接口；如果客户端提供面板，可在修改前记录当前 tun对象和版本信息，避免凭记忆恢复。涉及 API 时不要公开真实密钥，也不要把控制接口暴露到公网，具体字段以Mihomo API 官方文档为准。
最小配置、单变量恢复与求助信息模板
安全恢复的核心是“先备份、后改单项”。先复制当前配置文件，保留原文件不覆盖；然后只确认 TUN 开关和自动路由是否能启动。成功后再依次测试自动识别出口网卡、DNS 接管、严格路由以及其他高级字段。每次只改一项，并在日志中记录结果。
提交求助时可按以下格式整理，先脱敏再发送：
- 操作系统和架构；
- 客户端名称与版本；
- Mihomo 核心版本；
- 是否管理员、root 或已授予系统 VPN 权限；
- 关闭 TUN 时普通代理是否正常；
- TUN 配置中与
enable、auto-route、auto-detect-interface、dns-hijack、strict-route有关的片段； - 从启动核心到最终错误的完整日志；
- 已安装的其他 VPN、虚拟机或网络管理工具。
不要提交订阅地址、节点密码、访问令牌、外部控制器密钥或完整个人配置。若问题只在某个客户端出现，应优先核对该客户端实际使用的核心版本和权限方式，而不是直接套用其他客户端的菜单名称。
补充说明：资料核验日期与版本边界
资料核验日期：2026年11月2日。本文只引用 Mihomo 官方文档、官方仓库发布页、官方仓库问题记录和官方面板仓库中能够核验的内容。Mihomo 的发布版本、客户端菜单、系统权限提示和适配器名称可能随版本或平台变化；未在当前资料中明确写出的版本兼容性、驱动状态、修复时间和性能结论，均需以当前客户端和系统实测为准。
常见问题
Mihomo TUN 一打开就自动关闭，先查什么？
先关闭 TUN，确认普通 Mixed、HTTP 或 SOCKS 代理是否正常；然后查看完整日志。如果没有出现 TUN listening，优先检查管理员或系统权限、重复核心进程、其他 VPN 和虚拟网卡；如果已经出现 TUN listening，则转查 DNS、路由和出口网卡。
日志里的 Start Tun interface timeout 一定是驱动坏了吗？
不一定。这只是创建或初始化 TUN 超时的提示，具体原因可能是权限、适配器已存在、设备未准备好、路由冲突或出口接口异常。应继续查看同一段日志中的具体错误，不要仅凭 timeout 判断驱动故障。
TUN 已启动但浏览器打不开网页，怎么办？
先确认普通代理是否正常，再临时关闭 dns-hijack 做对照。如果关闭后恢复，重点检查 DNS 监听、系统 Private DNS、53 端口和 DNS 规则；如果仍然失败，再测试 strict-route、出口网卡和分流规则。每次只改一个字段。
Windows 上是否可以直接删除旧的虚拟网卡或驱动？
不建议作为第一步。先退出所有相关客户端和核心，记录日志，确认是否存在重复实例或其他网络工具占用；只有明确知道某适配器属于哪个软件并有可回滚方案时，才考虑系统级清理。
如何判断是 Mihomo 配置问题还是客户端问题？
用同一份配置先关闭 TUN测试普通代理，再在客户端中重新加载或启动核心，并记录核心版本。若普通代理正常而 TUN失败，问题更可能在系统权限、虚拟网卡或路由接管；若两者都失败，应先排查配置、节点和核心加载。