macOS TUN 导致 CPU 升高，异常 UDP 连接怎么处理

Mac 开启 TUN 后持续发热，活动监视器中 verge-mihomo 的 CPU 占用很高，可以先检查是否有一条 UDP 连接持续累计下载、上传却几乎不变。不要仅凭客户端的接收计数认定电脑正在从外网下载同样大小的数据。

哪些表现值得进一步检查

该反馈为 macOS 27.1、Apple M4、Clash Verge Rev 2.5.2、规则模式与 TUN 开启。用户记录一条 Tun(udp)、DIRECT、命中直连规则集的连接长时间累积接收流量，进程字段为空；关闭该连接后，其内核 CPU 从超过 120% 降到约 1.8%。

相关 Mihomo 记录也出现过类似的 DIRECT UDP 会话，以及较新内核版本上的现场观察。它们提供了本地 UDP 回环的排查线索，但不能直接证明每次高 CPU 都属于同一问题，也不能据此认定切换某个 TUN 协议栈就能根治。

第一步：确认是内核占用高

1. 打开「活动监视器」的 CPU 页面，确认高占用进程是 verge-mihomo，还是 Clash Verge 界面。
2. 暂停测速、批量下载和其他明确的大流量任务，记录内核 CPU 是否仍持续偏高。
3. 打开客户端「连接」页，按流量与持续时间定位异常会话，记录协议、入站、策略链及命中规则。
4. 间隔数秒比较同一连接的上传与下载增量，而不是只记录累计总量。

优先关注 TUN + UDP + DIRECT 且接收计数不停增加、上传几乎不变的会话。进程字段为空本身不能证明恶意行为；也不要把某一个目标 IP 或端口当成固定判断标准。

第二步：只关闭已经确认的异常连接

保存连接信息与日志后，如果可以中断该会话，在「连接」页对该条目执行关闭连接操作。会议、语音等 UDP 会话可能受影响，先结束正在进行的任务；不要直接关闭全部连接或重启所有网络服务。

关闭后保持 TUN、节点和配置不变，比较：

• 该条目是否消失，是否立即出现相同特征的新会话；
• 接下来十几秒内核 CPU 是否明显回落；
• 其他连接及实际使用的软件是否仍正常。

如果当前界面没有单条连接关闭入口，不要照搬陌生的控制器地址与密钥。先保留记录，待可以中断工作时正常重启客户端，再验证状态。单次恢复只说明当时的连接与占用有关，不能证明已经永久修复。

第三步：区分计数异常与外网流量

相关内核反馈中，虚拟 TUN 接口的包量远高于物理网卡，接收计数可能包含本地重复处理的数据。客户端显示数十 GB，不等于已经独立测得同等 WAN 下载或同等订阅流量扣除。

若需要确认实际流量，应比较同一时间窗内的物理网卡收发、客户端会话增量，以及服务商的流量记录。不同统计层的累计数不能直接相减，也不能用一次短采样推断全天用量。

恢复后仍需保留什么

记录 Rev 和 Mihomo 的准确版本、TUN 协议栈、异常持续时间，以及关闭单连接前后的 CPU 与流量变化。不要为了收集数据长期保留造成发热的连接，也不要公开订阅、节点地址或认证信息。

如果没有这种异常 UDP 会话，但长时间运行仍高 CPU，可继续按macOS 内核 CPU 高占用排查 区分客户端与独立内核场景；若主要问题是内存持续增加，则参考macOS 长时间运行内存占用 。

当前进展

该问题与相关 Mihomo 记录均仍开放，尚无可以确认适用于上述全部场景的修复版本。建议先备份配置，再使用下载页 中的稳定版；升级后仍需按相同条件验证，不承诺升级一定消除复发。

参考：Rev 问题记录 、Mihomo UDP 回环记录 3302 、相关记录 3349 。