常见问题

Windows TUN 显示开启却没有虚拟网卡，Clash Verge Rev 怎么排查

区分界面开启意图、内核 tun.enable 与实际网卡路由，避免用系统代理或内置测速代替 TUN 验证。

更新于 2026年11月6日

本页目录

Windows 上 Clash Verge Rev 的 TUN 开关已经亮起，浏览器或内置测速也能联网，但系统没有创建对应虚拟网卡，需要分别核对设置、内核实际状态和系统路由。系统代理仍然可用时，部分网络测试可能绕过 TUN，不能用它证明虚拟网卡已经工作。

涉及版本与表现

原始反馈涉及 Windows 11、Rev 2.5.7 / 2.5.8、Mihomo 1.19.32。后续在 Windows 11、Rev 2.5.10、Mihomo 1.19.33 的服务模式下，也有用户提供界面显示开启而内核 tun.enable 为 false 的记录。

这些电脑的网卡、桌面环境和触发条件不同。已有额外虚拟适配器只是环境信息，不能据此认定 Hyper-V、WSL 或某个无线网卡型号就是原因。

先记录系统代理与 TUN 当前状态，保存正在进行的网络会话。确认需要测试的程序是否有自己单独设置的代理；如果程序已经显式使用本地混合端口，即使 TUN 没有开启，也可能正常连接。

在客户端「日志」中确认当前是 Service 还是 Sidecar，并检查是否出现服务不兼容、内核重启或 TUN 初始化错误。若明确报服务安装失败，先按服务安装与内核匹配排查处理，不要直接删除网卡。

在 Windows PowerShell 中运行以下只读命令：

Get-NetAdapter -IncludeHidden
route print -4

保存关闭和开启 TUN 时的结果，比较是否新增了对应虚拟适配器，以及路由是否发生预期变化。适配器名称可能为 Meta、Mihomo 或其他已配置名称，不应只搜索一个固定名称。

route print 输出包含本机网络信息，公开分享前应隐藏个人接口标识与内部地址。不要为了让列表中出现某个网卡，反复重装所有驱动。

熟悉内核控制接口的用户，可以通过当前客户端已配置的本地接口与认证方式读取 /configs，只核对 tun.enable 等相关字段。不要照抄他人的管道、端口或凭据，也不需要开放公网控制接口。

如果内核明确返回 tun.enable: false，当前首先是开启状态没有落实，不能直接归类为驱动创建失败。
如果内核在尝试创建 TUN，日志却持续出现 Start Tun interface timeout 或创建适配器错误，则应保留这些错误，按创建阶段继续排查。
如果虚拟网卡已经存在，但目标程序仍直连，应进一步检查程序自己的代理设置、路由及规则，不能继续只盯着开关颜色。

后续 2.5.10 的反馈中，用户从界面关闭再开启 TUN 后，内核返回开启、Meta 适配器出现，原本不指定代理的 Git 连接也恢复。但现场还伴随系统代理状态变化，因此不能认定这是单一变量验证过的通用修复。

需要尝试时，先记录原状态，关闭 TUN，等待操作结束，再开启一次。随后同时检查网卡、内核日志和不依赖系统代理的新连接。操作失败就保留错误，不要快速反复点击。

问题仍开放，最初进入失同步状态的稳定复现步骤尚未确定，也没有适用于所有场景的正式修复结论。macOS 有界面与 TUN 内核状态不一致的类似反馈，但目前不能认定两者根因相同。