Mihomo TUN模式无法启动怎么办？按报错定位权限与网卡
简答：Mihomo TUN模式无法启动时，先关闭TUN，用Mixed、HTTP或SOCKS代理确认节点和配置本身是否可用；普通代理正常而TUN失败，优先检查权限、虚拟网卡和TUN字段。不要先清空系统路由，先备份配置，再根据日志中的具体关键词处理，最后用同一网址复测。本文是第三方使用指南，不代表任何品牌的官方网站。
定义：Mihomo TUN模式是通过虚拟网卡接管系统流量，并结合自动路由、DNS劫持或分应用规则进行转发的网络接管方式。
先做对照：30秒判断是TUN问题还是节点问题
第一步不要继续反复点击TUN开关。先在客户端中关闭TUN，保留同一份配置和同一个节点，开启客户端提供的Mixed、HTTP或SOCKS代理入口，再让浏览器或测试应用明确使用该代理。
| 现象 | 优先判断 | 下一步 |
|---|---|---|
| 普通代理也无法连接 | 节点、订阅、配置或DNS本身异常 | 先排查节点和配置，不要继续改TUN路由 |
| 普通代理正常，TUN立即关闭 | 权限、虚拟网卡、字段兼容或端口冲突 | 查看启动日志，按下方报错分流 |
| TUN显示已启动但全网断开 | 自动路由、DNS、出口网卡或规则接管异常 | 先关闭strict-route和DNS劫持做对照，逐项恢复 |
| 只有部分应用无法联网 | 规则、应用绕过、IPv6或客户端差异 | 用浏览器和命令行分别复测，记录受影响应用 |
Mihomo官方文档将TUN定义为可接管系统流量的入站方式，并提供auto-route、auto-detect-interface、dns-hijack和strict-route等字段；不同客户端可能只暴露其中一部分选项，字段是否可用应以当前内核文档和客户端配置编辑器为准。Mihomo TUN配置文档
先校验配置，再改系统设置
复制当前配置文件，另存为带日期的备份，例如config-before-tun.yaml。不要把订阅链接、节点密码、外部控制器密钥和完整日志公开到论坛或截图中。
如果客户端提供“校验配置”“测试配置”或“重新加载前检查”，先使用该功能。官方面板项目的说明显示，配置激活前可使用mihomo -t进行最终校验；但不同GUI是否内置该命令需要核实。命令行环境中请先运行mihomo -h确认当前构建支持的参数，再执行对应的配置测试。MetaCubeX官方面板配置说明
检查日志时只保留三类信息：Mihomo版本、操作系统与架构、从启动到失败的完整错误行。重点看permission denied、cannot create TUN、device or resource busy、address already in use、unknown field和Start TUN listening error。不要只截取最后一行，因为前面的配置解析错误可能才是真正原因。
最小化复测时，暂时保留一个已知可用节点、一个代理端口和最少的TUN字段。以下只是结构示例，不能直接覆盖现有配置；字段名称和默认值必须按当前版本文档核对。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
先不要同时加入自定义MTU、IPv6路由、复杂DNS劫持、多个出口网卡和大量排除规则。基础TUN能启动后，再一次只恢复一个字段。
按日志关键词分流处理
permission denied 或 cannot create TUN
这类信息通常说明当前客户端或进程没有创建虚拟网卡所需的系统权限，也可能是客户端没有完成系统VPN授权。Windows先完全退出其他代理和VPN客户端，再用管理员权限启动当前客户端；如果客户端有“服务模式”或“安装服务”选项，先确认服务已安装且正在运行。不要同时打开两个客户端的TUN。
Linux需要确认运行用户能访问TUN设备，并确认系统存在/dev/net/tun。可先执行ls -l /dev/net/tun和ip link记录结果；如果设备不存在，先修复系统TUN设备或容器权限，不要直接修改路由表。以systemd运行时，官方服务示例使用了CAP_NET_ADMIN等能力，实际服务文件应按当前发行版和部署方式核对。Mihomo官方服务部署说明
macOS检查系统弹出的网络扩展、VPN或网络过滤授权，并退出其他会创建utun接口的工具后重启客户端。Mihomo文档说明，macOS指定TUN设备时名称需要以utun开头，因此不要照搬Windows或Linux的网卡名称。Mihomo官方TUN字段说明
Android先确认客户端的VPN权限仍然有效，并检查系统是否已有其他VPN、始终开启VPN或阻止无VPN连接的设置。Android启用“私人DNS”时，Mihomo官方文档提示DNS请求可能无法被自动劫持；遇到TUN启动后域名打不开，可暂时关闭私人DNS做一次对照。
device or resource busy
先关闭TUN，完全退出客户端，再等待虚拟网卡释放后重新启动。Linux可用ip link查看是否还残留同名接口；如果残留，优先重启客户端或系统服务，不要直接删除不确定归属的网卡。项目问题记录中曾出现关闭TUN后接口未及时释放、再次启用时报该错误的情况，但这属于特定版本、系统和复现条件，不能推断所有设备都存在同一问题。Mihomo项目问题记录：device or resource busy
address already in use
这通常先检查端口冲突，而不是修改TUN路由。确认客户端的Mixed、HTTP、SOCKS、DNS监听端口没有被其他进程占用。Windows可用netstat -ano查看占用进程，Linux或macOS可用lsof -i :端口号；命令输出只用于定位，不要结束不认识的系统进程。关闭重复运行的客户端后，再启动一次。
unknown field、parse config error 或 YAML错误
检查字段拼写、缩进和版本差异。YAML使用空格缩进且区分大小写，不能把不同项目或旧版示例中的字段直接混用。官方语法文档说明，Mihomo配置使用YAML，层级必须通过一致缩进表达。Mihomo官方配置语法
如果报错发生在升级内核之后，先恢复上一份可用配置或关闭最近新增的字段，再逐项加入。版本号和字段兼容性没有在当前资料中统一核实，不能仅凭客户端名称判断支持范围。
TUN已启动但全网断开：按安全顺序恢复
- 先关闭TUN并恢复普通代理。确认节点和订阅仍可用，避免在断网状态下连续修改多项设置。
- 检查出口网卡。设备同时使用Wi-Fi、有线、虚拟机或其他VPN时，先关闭不需要的虚拟网络适配器；如果客户端支持手动选择出口网卡，再按当前系统实际联网接口选择。
- 暂时降低接管范围。把
auto-route、dns-hijack、strict-route等选项逐项做对照，而不是一次全部关闭或全部开启。Mihomo文档说明，Windows的strict-route会加入防止DNS泄漏的防火墙规则，但也可能影响VirtualBox等特定应用；Linux下它会让连接按严格规则进入TUN。Mihomo官方strict-route说明 - 检查DNS。先确认浏览器能否访问已知可用的IP，再测试域名解析。Mihomo的DNS配置包含
enhanced-mode、fake-ip、nameserver和proxy-server-nameserver等独立部分，改动时一次只调整一项。Mihomo官方DNS配置文档 - 最后处理IPv6、MTU和局域网排除。如果只有部分网站、公司内网或局域网设备异常，记录是否依赖IPv6、局域网地址或特定协议，再针对性测试。不要一开始就把MTU改成任意数值，也不要直接清空系统路由。
每次修改后，用同一个浏览器、同一个节点和同一个测试网址复测，并记录“能否启动、能否解析域名、能否建立连接、哪些应用受影响”。单次成功只能说明当前条件下恢复，不能证明长期稳定。
按系统执行最短检查清单
| 系统 | 先查什么 | 复测与回滚 |
|---|---|---|
| Windows | 管理员权限、服务模式、虚拟网卡、端口占用、其他VPN和安全软件 | 关闭TUN恢复系统代理；确认无重复客户端后重新启用 |
| Linux | /dev/net/tun、用户权限、ip link、ip route、ip rule | 保存路由输出；不要执行清空路由表的命令，优先停止服务并恢复备份 |
| macOS | 网络扩展授权、utun接口、其他VPN、系统防火墙和客户端重启 | 关闭TUN并退出客户端，确认普通代理可用后再启用 |
| Android | VPN权限、私人DNS、其他VPN、应用分流和客户端内核差异 | 关闭私人DNS做对照；只在当前客户端支持的字段范围内修改 |
如果客户端界面没有日志、配置校验或内核版本信息，先在客户端帮助页确认其内置内核和配置路径，再决定是否使用命令行复测。不要把某个GUI的菜单名称当成所有Mihomo客户端都存在。
什么时候应停止继续修改
出现以下情况时，建议停止扩大修改范围：配置尚未备份、系统已经完全断网、路由表中出现不认识的批量变化、多个VPN和虚拟机同时运行，或日志显示核心反复崩溃。此时按回滚顺序处理：关闭TUN、退出客户端、恢复备份配置、重新启用系统原有网络，再只启动普通代理验证。若普通代理正常而TUN仍失败，整理系统、客户端、内核版本、最小配置和完整启动日志，向客户端项目或内核项目提交可复现信息。
本文不核实任何具体订阅、节点或服务的可用性；如果问题只在某一订阅或某一节点发生，应把它与“核心能否创建TUN”分开记录。
常见问题
为什么普通代理能用，TUN却启动不了？
普通代理只需要客户端监听端口并让应用主动连接；TUN还需要创建虚拟网卡、应用系统路由或DNS接管，因此权限、网卡、服务模式和系统网络冲突都可能只影响TUN。先做普通代理对照，可以缩小排查范围。
TUN开关一打开就自动关闭，应该先改哪个字段？
不要先改字段。先看完整启动日志，确认是权限、字段解析、网卡占用还是端口冲突。备份后用最小TUN结构复测，再一次恢复stack、auto-route、DNS劫持和严格路由。
Linux报device or resource busy可以直接删除网卡吗？
不建议直接删除不确定归属的网卡。先停止Mihomo和相关服务，确认残留接口名称与进程归属；优先重启客户端或服务，只有明确知道接口由当前实例创建时，才按系统和客户端文档处理。
Windows开启strict-route后虚拟机不能联网怎么办？
先关闭strict-route做对照，并记录虚拟机软件、局域网访问和DNS是否恢复。官方文档提示该选项可能影响部分应用，因此恢复时要在“防止DNS泄漏”和“虚拟机或局域网兼容”之间按实际需求选择，而不是盲目长期开启。
Android开启私人DNS后TUN无法解析域名怎么办？
先暂时关闭私人DNS并重启当前客户端进行对照。Mihomo文档说明，Android启用私人DNS时，DNS请求可能无法被自动劫持；如果关闭后仍异常，再检查客户端的DNS模式、规则和应用分流。
需要把完整配置和订阅链接发出来求助吗？
不需要。先隐藏订阅链接、节点密码、外部控制器地址和密钥，只提供系统、客户端、内核版本、最小配置片段、错误关键词和必要的命令输出。
常见问题
为什么普通代理能用，TUN却启动不了？
因为TUN除了代理端口，还需要创建虚拟网卡并接管系统路由或DNS；权限、网卡和服务模式问题可能只影响TUN。
TUN开关一打开就关闭，先改哪个字段？
先看完整启动日志并备份配置，不要盲改字段；用最小TUN配置复测，再逐项恢复高级选项。
Linux出现device or resource busy能直接删除网卡吗？
不建议。先停止客户端和服务，确认接口归属，优先通过重启实例释放资源，避免误删系统或其他工具创建的网卡。
Windows开启strict-route后虚拟机不能联网怎么办？
关闭strict-route做对照并记录变化。官方文档提示它可能影响部分应用，恢复时需兼顾DNS接管、虚拟机和局域网访问。
Android私人DNS会影响TUN吗？
可能会。官方文档说明私人DNS启用时DNS请求无法被自动劫持，可暂时关闭私人DNS进行复测。