配置里已经写了 tun.enable: true，界面上却没有可用的虚拟网卡，或者网卡出现后仍然无法联网。这时继续修改DNS服务器往往没有帮助。Mihomo TUN模式的启动涉及核心进程、系统权限和路由安装，先确定失败发生在哪个状态，后续检查才有方向。

把五个状态拆开观察

配置文件启用了TUN，只能说明一项配置意图；核心实际读取这份配置并启动，才进入第二步。随后还需要成功创建虚拟接口、让目标流量进入接口，最后才是远端连接成功。五个状态之间都有可能中断，不能用一个“已开启”替代全部检查。

先记录当前使用的配置文件位置、运行方式和错误出现时间。桌面客户端可能覆盖核心配置，编辑磁盘上的文件并不一定改变活动配置。对照TUN模式设置指南，确认实际生效的入站方式，再判断是否需要检查虚拟接口。

权限与接口，先查最靠近系统的一层

Windows下创建接口和安装路由通常需要管理员权限，服务运行与普通用户启动也可能使用不同权限。Linux需要检查TUN设备是否可用以及进程具有的网络管理权限；容器环境还受设备映射和能力限制。macOS应核对运行权限与接口命名，官方文档要求接口名称以 utun 开头。

从核心启动日志里找第一条与设备创建、权限或路由安装相关的错误，不要只看最后一条连接超时。若其他VPN仍在运行，记录其接口和默认路由；优先暂停自己明确知道用途的连接做单变量对照，保留恢复路径。不要删除全部虚拟网卡，也不要结束未知系统进程。

自动路由与出站接口分别检查

auto-route 负责自动设置通往TUN的系统路由，auto-detect-interface 负责识别出站网络接口。前者回答“流量怎样进入”，后者回答“核心从哪里出去”。同时连接有线、Wi-Fi和其他VPN时，自动检测结果尤其需要核对，不能用两个开关互相替代。

strict-route 的行为存在系统差异，可能影响其他网络软件。不要为追求“接管完整”直接打开所有选项；先确认当前系统支持的字段、原有路由以及IPv4、IPv6的使用情况。DNS接管还需要单独检查 dns-hijack 与DNS模块，网卡存在并不能证明查询已经进入核心。

用只读信息验证流量入口

Windows可先查看 Get-NetAdapter 和 Get-NetRoute；Linux查看 ip address、ip route 与 ip -6 route；macOS查看 ifconfig 和 netstat -rn。这些命令用于读取状态，不会替你修复路由。将实际接口名称、默认出口和故障前后的变化对应起来，避免凭空套用别人的网卡名称。

然后发起一次已知目标请求，观察核心是否出现对应连接。完全没有入站记录时，优先检查应用路径和系统路由；已经出现连接时，再参考请求入站与规则匹配定位后续阶段。单纯看到接口收发计数增长，也不能直接证明特定应用已被正确处理。

恢复时保留证据

每次只改一个参数，保存原配置与改动时间，再用同一个目标复测。若接口已经建立、请求也进入核心，就停止反复重建网卡，转到分层连接排障检查DNS、策略和远端服务。把问题缩小到具体一层，比一次清空路由或重置整个网络更容易恢复。