Mihomo TUN模式无法启动：按阶段和报错逐项排查
简答：Mihomo TUN模式无法启动，先关闭TUN，用同一节点测试Mixed、HTTP或SOCKS普通代理；普通代理正常后，再查看客户端日志或核心输出，依次检查YAML配置、系统权限、虚拟网卡、端口和其他网络接管软件。本文覆盖Windows、macOS和Linux桌面环境，不覆盖Android或iOS的具体VPN授权流程。
定义：Mihomo TUN模式是通过虚拟网络接口接管系统流量的运行方式，启动时同时依赖有效配置、系统网络权限、可用的TUN接口以及与客户端封装相匹配的系统组件。
先用一轮测试判断故障阶段
本文是第三方使用指南，不是Mihomo或具体客户端的官方页面。不要一开始就反复修改stack、DNS或MTU，先把问题分成“普通代理不可用”“TUN创建失败”和“TUN已启动但无法联网”三类。
| 步骤 | 操作 | 结果说明 |
|---|---|---|
| 1 | 关闭TUN，使用同一节点开启Mixed、HTTP或SOCKS普通代理 | 普通代理也失败：先查订阅、节点、代理端口或基础配置 |
| 2 | 普通代理正常后重新开启TUN，立即查看完整日志 | 开关立即关闭：优先查配置、权限、虚拟网卡和端口 |
| 3 | TUN显示启动但应用断网 | 优先查auto-route、出口网卡、DNS接管和其他网络工具冲突 |
| 4 | 每次只恢复一个高级字段 | 避免同时修改路由、DNS、协议栈和MTU，便于回滚定位 |
Mihomo官方文档将顶层tun配置用于系统流量接管，并分别说明了auto-route、auto-detect-interface、dns-hijack和strict-route的作用与系统差异，可先查看Mihomo TUN配置文档。
前置条件：备份、核对版本并先校验YAML
- 备份配置。复制当前正在使用的YAML文件，记录客户端名称、操作系统、核心版本、TUN原状态和最近一次修改。不要直接覆盖唯一配置。
- 核对核心版本。客户端可能内置与独立下载不同的核心，字段行为应以实际运行版本和当前文档为准。版本号不要直接套用旧教程；截至2026年10月30日，版本列表应以Mihomo官方发布页当前显示内容为准。
- 先测试配置文件。如果可以直接运行核心，可使用
mihomo -t -f config.yaml。使用配置目录启动的部署，也可按实际目录使用mihomo -t -d /path/to/mihomo。部分带内核管理功能的客户端会在激活配置前调用mihomo -t，但不同客户端的验证和回滚流程并不完全相同，可参考MetaCubeX面板说明。 - 先做解析测试，再做TUN测试。下面的配置只用于检查YAML结构，不会创建TUN接口，也不代表节点可用：
mode: direct
allow-lan: false
tun:
enable: false
proxies: []
proxy-groups: []
rules:
- MATCH,DIRECT
如果解析测试通过，再回到原配置中只把tun.enable改为true，不要把整份订阅替换成这个测试片段。校验通过只能说明配置可解析，不能证明系统允许创建TUN或节点已经可用。
按日志关键词分流，不要把启动失败归因于节点
日志入口取决于客户端封装：Mihomo Party、Clash Verge Rev等客户端应优先使用其内置的日志或内核输出页面；独立核心则查看启动终端、服务日志或重定向的日志文件。不要只看“已停止”或“启动失败”这一行，尽量保留报错前后的完整片段。
| 关键词 | 优先方向 | 处理方法 | 不要先做的事 |
|---|---|---|---|
permission denied | 系统权限或Linux能力不足 | 按系统确认授权、TUN设备和运行用户 | 不要先改DNS或stack |
cannot create TUN | 虚拟接口、网络扩展或其他软件冲突 | 退出其他VPN、WireGuard、Tailscale类网络接管工具后重试 | 不要直接删除未知适配器 |
device or resource busy | 残留进程、后台服务或重复实例 | 完全退出客户端，确认进程结束后再启动 | 不要同时启动多个内核实例 |
address already in use | 代理、DNS或控制端口冲突 | 查占用进程，改一个端口或关闭冲突程序 | 不要随机修改所有端口 |
unknown field、yaml、not found | 字段版本、缩进或引用错误 | 先运行mihomo -t，再核对当前文档 | 不要照抄旧版字段 |
Windows：只把管理员启动当作权限验证
- 先验证权限。完全退出客户端后，以管理员身份启动一次并重新接受系统授权。这个动作只用于判断是否存在权限问题，验证结束后应恢复普通启动；是否需要特权服务、助手或驱动，取决于具体客户端的打包方式，不能推断所有客户端都相同。
- 检查端口。在命令提示符运行
netstat -ano，对照配置中的mixed-port、port、socks-port、DNS监听端口和控制端口。Microsoft文档说明，-o参数会显示连接对应的进程ID，可在任务管理器中按PID确认程序，参考Microsoft netstat文档。 - 查看网卡而不是删除网卡。在PowerShell运行
Get-NetAdapter -Name * -IncludeHidden，记录物理网卡和虚拟网卡的状态。该命令用于查看可见与隐藏适配器，参考Microsoft Get-NetAdapter文档。名称不熟悉时不要直接卸载。 - 排除单一冲突。暂时退出其他VPN、虚拟机网络、WireGuard、Tailscale或安全软件的网络过滤功能，只保留一个Mihomo实例。测试完成后逐个恢复，以确认具体冲突项。
macOS：核对网络扩展、utun和后台实例
- 查看系统扩展。macOS中可进入“系统设置→通用→登录项与扩展”，查看Network Extensions。Apple说明该区域用于管理网络扩展；如果客户端首次启用TUN后出现授权提示，应按提示完成授权，具体名称以客户端实际显示为准，参考Apple网络扩展说明。
- 确认没有重复后台服务。退出客户端后，检查同一核心是否仍由后台服务、登录项或另一个客户端运行。出现
device or resource busy时，先完全退出并重新启动客户端，必要时再重启系统。 - 查看接口和路由。终端运行
ifconfig和netstat -rn，记录开启TUN前后的变化。出现utun只能说明系统出现了相关接口，不能单独证明流量已正确转发。 - 按字段逐项恢复。先使用基础TUN，再考虑
dns-hijack、strict-route、自定义设备名和MTU。Mihomo文档明确指出macOS、Windows和Linux的DNS接管默认行为存在差异，不要把一个系统的配置直接套到另一个系统。
Linux：检查TUN设备、运行用户和服务能力
- 检查设备。运行
ls -l /dev/net/tun；设备不存在时，再运行lsmod | grep tun。Linux内核文档说明，用户态程序需要访问TUN设备，创建或连接网络设备还需要CAP_NET_ADMIN能力，参考Linux内核TUN/TAP文档。 - 确认服务用户。如果通过systemd运行，使用
systemctl status mihomo查看服务状态，使用journalctl -u mihomo -o cat -e查看最后日志。官方服务示例包含能力配置，但这只是该部署方式的示例，不代表所有Linux安装方式都必须完全照抄，可参考Mihomo systemd服务说明。 - 检查容器限制。如果核心运行在容器中，仅映射代理端口并不会自动获得TUN权限。需要核对容器是否映射
/dev/net/tun以及是否具备网络管理能力；修改前先保存原容器配置。 - 先读首条错误再重启。服务反复重启时，先查看日志中最早出现的权限、设备或配置错误，再执行
sudo systemctl restart mihomo，避免只观察到“服务又启动了”而错过真正原因。
TUN已启动但断网：按路由、DNS和网卡顺序恢复
- 只有域名打不开：暂时关闭
dns-hijack或将DNS接管恢复为基础模式，重新测试域名和已知IP。Mihomo文档说明，macOS和Windows不能自动接管所有发往本地网络的DNS请求，因此不能仅凭字段存在就判断DNS一定被接管。 - 所有应用都断网：先检查
auto-route、auto-detect-interface和其他VPN是否同时生效。多网卡设备可在确认自动选择错误后，再指定实际出口接口。 - 只有虚拟机或局域网软件异常：暂时关闭
strict-route做对照。官方文档提示，严格路由在特定场景下可能影响虚拟化软件；确认结果后再决定是否恢复。 - 只有IPv6、UDP或特定应用失败：记录具体协议和应用，不要立即修改MTU。
mtu、gso和协议栈属于后置变量，应在基础TUN和DNS路径确认后逐项测试。 - 最后再判断节点：用同一节点分别测试普通代理和TUN。普通代理正常而TUN失败，优先回到系统路由、DNS和虚拟接口；两种模式都失败，才继续检查订阅、节点或代理端口。
安全回滚与反馈清单
- 关闭TUN，切回已经验证过的Mixed、HTTP或SOCKS普通代理。
- 退出其他可能接管网络的客户端和后台服务，只保留一个Mihomo实例。
- 恢复YAML备份，重新运行
mihomo -t或客户端提供的配置校验。 - 普通代理恢复后，只启用基础TUN，再逐个恢复DNS接管、严格路由、网卡指定和MTU。
- 如果系统网络仍异常，先关闭客户端并恢复系统网络设置；不要直接清空路由表、删除未知虚拟网卡或重置防火墙。
- 向客户端维护者反馈时，附上操作系统、客户端名称、核心版本、完整日志中的关键片段、普通代理与TUN的对照结果，以及最后一次改动。
当TUN已经能够稳定启动，且你确认普通代理与TUN的结果不一致时，再继续查看站内的延迟、速度和丢包对照方法，用于判断问题是否已经转移到线路或节点质量。
参考资料
本文仅采用可直接核对的官方文档和项目资料；客户端菜单、权限助手、内核版本与字段支持可能随实际打包版本变化，操作前请以当前客户端界面和核心文档为准。
- Mihomo TUN配置文档
- Mihomo官方发布页
- MetaCubeX面板说明
- Microsoft netstat文档
- Microsoft Get-NetAdapter文档
- Linux内核TUN/TAP文档
- Apple网络扩展说明
- Mihomo systemd服务说明
常见问题
Mihomo TUN模式开关一打开就关闭，先检查什么？
先关闭TUN，用同一节点测试Mixed、HTTP或SOCKS普通代理；如果普通代理正常，再查看客户端日志或核心输出，运行<code>mihomo -t -f config.yaml</code>，然后按权限、虚拟网卡、端口和其他网络接管软件分流。
配置校验通过，为什么TUN仍然启动失败？
<code>mihomo -t</code>主要说明配置文件能够解析和初始化，不能证明系统一定允许创建虚拟接口。还要检查运行权限、TUN设备、后台重复实例、端口占用、网络扩展和其他VPN冲突。
Windows一定要以管理员身份运行Mihomo吗？
不一定。管理员启动只适合作为一次权限验证，验证后应恢复普通启动；是否需要特权助手、服务或驱动取决于具体客户端的封装方式，不能把它当成所有TUN失败的通用修复。
Mihomo TUN已启动但网页打不开，先改DNS还是路由？
只有域名打不开时，先对照关闭<code>dns-hijack</code>后的结果；所有应用都断网时，先查<code>auto-route</code>、<code>auto-detect-interface</code>和其他VPN。每次只改一个字段，并保留回滚配置。
Linux找不到<code>/dev/net/tun</code>怎么办？
先运行<code>ls -l /dev/net/tun</code>和<code>lsmod | grep tun</code>，再按发行版方式检查TUN模块。若通过systemd或容器运行，还要确认运行用户、<code>CAP_NET_ADMIN</code>以及设备映射；不要只修改YAML字段。
macOS出现utun接口，是否代表TUN已经正常？
不代表。<code>utun</code>只说明系统出现了相关接口，还需要结合客户端日志、路由变化和实际应用访问结果判断。若启用TUN时出现授权提示，应在系统设置的Network Extensions区域核对对应扩展。
能不能直接删除Windows虚拟网卡或清空路由表？
不建议。先退出客户端、确认残留进程、查看端口和适配器状态，并恢复配置备份；只有明确知道对象归属且具备回滚方案时，才考虑进一步处理。