← 返回 GitHub Proxy 最新地址发布 - GitHub 文件 , Releases 首页

Clash Verge Rev Mac TUN 模式虚拟网卡设置教程

更新于 2026-10-30 · ghproxy.cyou

简答:在 Mac 上开启 Clash Verge Rev TUN,建议先确认配置和系统代理可用,再安装 Service 并完成管理员授权,最后关闭系统代理,用连接日志、utun 接口和 DNS 状态交叉验证。看到 utun 只能说明虚拟接口出现,不能单独证明流量已经正确转发。

定义:Clash Verge Rev 的 TUN 模式,是通过 macOS 的 utun 虚拟网卡在网络层接收系统流量,再交给 mihomo 核心按配置和规则处理的方式。

先试这一步:Mac 开启 TUN 的最短路径

本文是第三方使用指南,不代表 Clash Verge Rev 官方。适用范围是已经安装 Clash Verge Rev、拥有可用配置或订阅,并希望在 macOS 上使用 TUN 虚拟网卡的用户。不同版本的页面布局和中文翻译可能略有差异,入口通常位于设置中的系统代理、TUN Mode 或 Tunnel 相关区域;应用源码中的设置文案明确包含 System Proxy、Tun Mode、Install Service 和 Switch to service mode 等字段。查看项目设置字段

  1. 记录环境。先记下 macOS 版本、Clash Verge Rev 版本、Apple 芯片或 Intel 架构、当前核心名称和配置来源。版本不要凭文章猜测,直接从应用设置或官方 Releases 页面查看;截至 2026 年 10 月 30 日,页面上的版本列表仍可能继续变化。查看官方 Releases 页面
  2. 先验证系统代理。导入配置,选择策略组或节点,打开 System Proxy。使用一个平时需要经过代理的明确测试目标,并同时观察 Clash 连接日志是否出现对应请求。普通网页能打开,只能证明该网页连通,不能单独证明代理或 TUN 生效。
  3. 安装 Service。在设置中找到 TUN Mode。如果界面显示需要 Service 或 Admin Mode,点击 Install Service 或 Switch to service mode。macOS 弹出管理员授权时,确认应用来源和安装位置后再输入密码。安装完成的预期结果是服务状态正常,TUN 开关不再提示服务不可用。
  4. 只开启 TUN 做对照。先关闭 System Proxy,再打开 TUN Mode。项目设置文案说明,TUN 模式用于捕获系统流量,启用后不需要同时打开系统代理;但这是功能层面的说明,不代表所有应用、规则和 DNS 配置都能在任何环境下正常工作。查看 TUN 与系统代理说明
  5. 交叉验证。打开终端,执行 ifconfig | grep -E 'utun[0-9]+'。出现 utun 接口只能证明接口被创建。随后查看 Clash 连接日志,确认测试请求出现,并用 scutil --dns 查看当前 DNS 状态。最后可执行 curl -I https://www.apple.com 做 HTTPS 连通性测试,但该命令不能证明请求一定经过 TUN。

最快成功标准:Service 正常、TUN 开关保持开启、至少出现一个 utun 接口、关闭系统代理后测试请求出现在 Clash 日志中,并且 DNS 没有明显解析失败。任何一项不满足,都不要继续同时修改规则、DNS 和路由。

TUN、系统代理、规则模式和全局模式怎么区分?

项目作用层级适合先做什么不能单独证明什么
系统代理修改 macOS 的 HTTP、HTTPS 或 SOCKS 代理设置确认配置、节点和策略组是否基本可用不能覆盖所有不读取系统代理的应用
TUN 虚拟网卡在网络层接收更广泛的系统流量处理不读取系统代理的应用,并验证透明接管utun 出现不等于 DNS、规则和上游连接都正常
规则模式决定请求直连、代理或拒绝日常分流使用不能替代 TUN Service 或系统网络权限
全局模式改变符合条件流量的统一策略作为临时对照,判断节点或规则是否导致失败不能解决 Service、DNS 或物理网卡冲突

TUN 是流量入口,规则模式和全局模式是流量决策方式,不能把三者当成同一个开关。建议固定采用“系统代理验证配置—关闭系统代理—开启 TUN—观察日志”的顺序。这样如果 TUN 失败,可以把问题缩小到 Service、虚拟接口、DNS、路由、规则或上游链路,而不是同时面对两个代理入口。

mihomo 的 TUN 文档说明,auto-route 用于自动设置全局路由,macOS 的 TUN 设备名称只能使用以 utun 开头的接口名;文档还说明 macOS 默认 DNS 行为与 Windows、Linux 不同。因此,不建议直接照搬其他系统的 TUN 配置字段。查看 mihomo TUN 官方字段说明

怎么确认虚拟网卡真的在工作?

第一层:看接口。在终端运行 ifconfig,搜索 utun。如果输出中出现 utun0、utun1 或其他编号,只能说明 macOS 当前存在 utun 接口。编号会受到其他 VPN、网络扩展和系统状态影响,不要把固定编号当成成功条件。

第二层:看 TUN 日志。在 Clash Verge Rev 的连接或内核日志中查找 TUN 启动信息、测试域名、策略组和错误原因。如果能看到 TUN 接口创建,但测试请求没有进入日志,说明“接口存在”和“流量被正确处理”之间仍有问题。官方仓库中也有 TUN 接口已经创建,但后续代理服务器域名解析失败的个案记录。查看 TUN 已启动但 DNS 解析失败的 Issue

第三层:看 DNS。执行 scutil --dns,保存输出,不要一开始就替换多个 DNS。重点观察是否出现解析器为空、请求超时、代理服务器域名无法解析或唤醒后 DNS 未恢复等迹象。

第四层:做前后对照。分别记录以下三组结果:关闭 TUN 与系统代理时是否能访问普通网页;只开系统代理时测试请求是否出现在日志;关闭系统代理、只开 TUN 时同一个请求是否仍出现在日志。测试目标、网络环境和节点尽量保持不变。这样比单独执行 curl -I 更容易判断请求究竟经过了哪一层。

第五层:查看路由但不要误判。可以执行 route -n get default 和 netstat -rn 记录默认路由及路由表。macOS 的默认路由不一定直接显示为 utun,因此路由表只能作为辅助证据,不能把“默认路由没有指向 utun”直接判定为 TUN 失败。

按症状排查:TUN 开关灰色、断网、DNS 失败和反复授权

现象先检查下一步处理停止边界
TUN 开关灰色或提示服务不可用Service 状态、应用是否位于“应用程序”目录、是否有管理员授权退出应用后重新打开,只执行一次 Install Service 或修复操作不要连续安装、卸载,也不要手动删除系统服务
utun 出现但所有请求失败连接日志、代理服务器域名解析、DNS 状态和其他 VPN关闭其他 VPN 或网络扩展,保持一个变量不变后重测不要仅因 utun 存在就继续修改 IPv4、IPv6 和多个 DNS 字段
只有域名打不开scutil --dns、日志中的 DNS 错误、代理服务器域名先确认是解析失败还是 TCP/HTTPS 连接失败,再处理 DNS不要把普通 HTTPS 失败直接归因于 TUN
睡眠唤醒后 TUN 失效唤醒前后日志、utun 状态、物理网卡和 DNS先重启 Clash Verge Rev,再重复同一组测试不要立即固定网卡或改多个配置项
重启后反复弹出安装或卸载提示开机自启、Service 状态、应用版本和弹窗文字暂时关闭开机自启,手动启动应用并观察是否仍复现不要把单个 Issue 当成所有版本的普遍缺陷

官方仓库曾记录 Service IPC 无法连接、TUN 已创建但代理服务器 DNS 失败、开机自启后重复授权等 macOS 个案。这些记录只能说明特定环境中曾出现相似现象,不能直接证明你的版本一定存在同一问题;排查时应记录 macOS 版本、芯片架构、Clash Verge Rev 版本、核心版本、网络类型、是否有其他 VPN,以及完整日志。Service IPC 个案、重启后重复授权个案

开启 TUN 后完全断网:安全回滚顺序

  1. 在 Clash Verge Rev 中关闭 TUN。
  2. 关闭 System Proxy,等待几秒后测试普通网页。
  3. 如果仍无法联网,完全退出 Clash Verge Rev,再重新打开 macOS 的 Wi-Fi 或有线网络连接。
  4. 执行 scutil --dns 和 netstat -rn,只读记录 DNS 与路由状态。
  5. 暂时退出其他 VPN、网络过滤器和网络扩展,再用同一目标重新测试。
  6. 如果系统代理可用而 TUN 不可用,保留系统代理作为临时对照,不要继续反复安装 Service。

如果日志出现 dns resolve failed、代理服务器域名无法解析或 IPv6 无路由,优先处理日志明确指出的层级。mihomo 文档中说明,TUN 的协议栈、自动路由、DNS 模式和 IPv6 会共同影响行为;不同系统不能直接套用同一组字段。查看 TUN 字段和平台边界

macOS TUN 相关 Issue 也曾出现接口已创建但后续流量失败、睡眠唤醒后 TUN 与本地代理同时失效等个案。遇到相同症状时,先保存日志和版本信息,再对照官方仓库当前 Issue;不要直接删除网络配置、手动清理系统服务或修改多个 DNS 参数。查看唤醒后连接失效个案

问题反馈前,按这个模板记录信息

如果仍无法定位,建议一次性记录以下内容:macOS 版本;Apple Silicon 或 Intel;Clash Verge Rev 版本;mihomo 或 verge-mihomo 核心版本;TUN 是否要求 Service;System Proxy 单独测试结果;TUN 单独测试结果;是否存在其他 VPN 或网络扩展;网络是 Wi-Fi、网线、热点还是扩展坞;ifconfig 中的 utun 状态;scutil --dns 输出;Clash 连接日志中的第一条错误。

反馈时可以隐藏订阅地址、节点域名、用户名、密钥和公网 IP。保留错误类型、时间点和可复现步骤即可。这样比只说“Mac TUN 不能用”更容易判断是权限、核心、DNS、路由、接口切换还是上游连接问题。

常见问题

Clash Verge Rev for Mac 开启 TUN 后还要打开系统代理吗?

验证 TUN 时建议先用系统代理确认配置可用,再关闭系统代理单独测试 TUN。TUN 的功能说明是不需要同时开启系统代理,但日常是否需要仍取决于具体应用、规则、DNS 和网络扩展,不能保证所有应用都只靠 TUN 正常工作。

Mac 上看到 utun 接口,就代表 TUN 已经成功了吗?

不代表。utun 只能证明虚拟接口出现,还需要结合 Clash 连接日志、DNS 状态和同一测试请求的前后对照。默认路由也不一定直接显示为 utun,因此不能用单一命令下结论。

TUN Service 安装时反复要求输入管理员密码怎么办?

先确认应用位于“应用程序”目录,退出其他 VPN 和网络扩展,再重新打开应用。只执行一次 Install Service 或修复操作并记录完整错误;若出现 IPC path not ready,应优先查看 Service 状态和日志,不要连续安装、卸载或手动删除系统文件。

开启 TUN 后浏览器完全打不开网页怎么办?

先关闭 TUN,测试系统代理或直连是否恢复。如果系统代理可用,重点检查 utun、连接日志、DNS、路由、物理网卡自动识别和其他 VPN 冲突。日志明确出现代理服务器 DNS 解析失败时,先处理 DNS 或上游连接,不要只重装虚拟网卡。

Mac 睡眠唤醒后 TUN 失效怎么办?

先重启 Clash Verge Rev,再用同一网络和同一测试目标复测,同时记录唤醒前后的 utun、DNS 和日志状态。如果只在热点、扩展坞或 Wi-Fi 切换后出现,应把触发动作和接口变化一并记录,再对照官方 Issue。

关闭 TUN 后仍然无法上网怎么办?

先关闭 System Proxy 并退出 Clash Verge Rev,重新连接当前 Wi-Fi 或网线,再执行 <code>scutil --dns</code> 和 <code>netstat -rn</code> 做只读检查。不要直接删除网络配置或手动清理系统 Service;如果问题持续,应保留日志并按版本、核心和网络环境反馈。

相关阅读

参考资料

  1. mihomo 官方 TUN 配置字段与 macOS 平台说明
  2. Clash Verge Rev 官方 Releases 页面