macOS 开启 TUN 后不生效，Clash Verge Rev 开关与内核状态不一致

Clash Verge Rev 的 TUN 开关已经打开，但程序仍然直连、没有预期的虚拟网卡时，需要分别确认界面状态、内核运行状态和系统接口。仅凭开关亮起，不能确认 TUN 已经接管流量。

涉及版本和具体表现

相关反馈环境为 macOS 27.0.1、Apple Silicon，涉及 Rev 2.5.8 稳定版及 2.5.9 AutoBuild 1021。反馈者称，生成的配置文件中包含完整 TUN 段，但核心控制接口返回的 tun.enable 一直为 false；混合代理端口可用，TUN 接口却未按预期创建。

这台电脑同时运行了 Tailscale、EasyTier、aTrust 等网络扩展，已有多个 utun 接口。它们是否造成这次异常，尚无明确结论。反馈者尝试重启、修改 MTU 和切换堆栈后仍未恢复。

第一步：确认是 TUN 未启动还是节点不可用

关闭 TUN，单独使用系统代理，并测试一个此前可用的节点。如果系统代理可用、打开 TUN 后仍无法接管目标程序，应重点检查 TUN 启动阶段。

打开「日志」，保留本次开启 TUN 前后的记录，检查是否有服务启动失败、接口创建失败或配置重载异常。相关反馈中出现过 Unregistered Clash configuration key 与 tun 字段有关的警告，但这条警告本身不能确定根因。

第二步：核对配置和实际接口

在「订阅」页面的「查看运行时订阅」中确认 TUN 字段，记录 enable、device、stack 和 auto-route。生成配置中的值与内核通过控制接口返回的当前值可能需要分别核对，不能只读其中一份就认定启动成功。

打开 macOS「终端」，运行以下只读命令：

ifconfig -l
netstat -rn

分别保存关闭和开启 TUN 时的结果，比较接口与路由的变化。电脑原本就可能存在其他软件创建的 utun；某个接口存在，并不能单独证明它属于 Clash Verge Rev。路由也应结合接口和内核日志判断，不要求默认路由必须呈现某一固定格式。

如需通过核心 API 核对状态，应使用当前客户端实际配置的控制地址和认证方式，不要将控制端口开放到公网，也不要照抄他人的 Unix socket 路径。

第三步：排除名称与网络扩展干扰

Mihomo 要求 macOS 的 TUN 设备名称以 utun 开头。维护者在讨论中询问更换 TUN 名称后是否仍然复现，但后续回复尚未提供明确有效的测试结果。

先记录当前名称和其他 VPN 的状态。如果有条件暂停非必要的 VPN，通过其自身界面正常退出后，再按服务模式与 TUN 教程 测试一个未使用的、以 utun 开头的名称。不要直接删除系统中的全部 utun 接口，也不要反复修改多个参数。测试后恢复原名称，并逐一恢复其他网络软件。

如果服务无法安装或运行，先保留原始服务报错。受管理的电脑应由管理员核对相应权限，而不是直接关闭所有安全软件。

当前进展与临时使用方式

该问题仍在跟进，尚未确认具体根因及修复版本。需要代理的程序支持系统代理时，可以暂时采用系统代理；不支持的程序仍需等 TUN 恢复后再验证。

补充问题时，注明客户端和内核版本、实际 TUN 名称、其他 VPN 状态，以及开启前后的日志和接口变化。相关操作见日志导出教程 。

参考：GitHub Issue #8392 、Mihomo TUN 配置 、macOS 常见问题 。