Mihomo macOS TUN 高 CPU：ENOTSOCK 修复

在 macOS 的 Mixed TUN 日志中核对 socket operation on non-socket 是否持续重复，同时确认 Mihomo 是否持续占用 CPU。一次启动报错、正常流量负载或仅界面内存增长，不足以认定这条读包错误循环。

Issue #3310 记录的是 Apple Silicon 的 Clash Party 2.0.3、Mihomo v1.19.31 与 mixed 协议栈故障。没有确定的触发步骤，睡眠唤醒、网络切换和配置重载是否有关也未确认；不要据此断言所有 Mac 或所有 TUN 高 CPU 都是同一问题。

这次要核对的是 Mihomo 内核，不只是客户端版本。记下 Clash Party 内核卡片的实际版本和通道，以及 TUN 开关和 stack 值，再把订阅、本地配置、覆写与应用设置独立备份。客户端换了新版，但内核仍是旧版，就还没有加载这份修复。

v1.19.32 调整了 macOS 读包报错的处理，把 ENOTSOCK、EBADF 视为关闭状态，让 Mixed TUN 结束读取，避免同一错误反复刷屏。它修复的是错误循环；连接最初为什么失效、网络是否恢复，仍要分别检查。

保存少量带时间的错误、实际内核版本和 CPU 观察，再关闭 TUN，确认重复错误是否停止。需要临时联网时，只在原配置已支持系统代理的情况下使用系统代理；它只覆盖遵循该代理的应用，不等于继续接管整台设备。不要长期保持刷屏来收集完整日志。

以下入口按 Clash Party v2.0.3 的固定源码与中文标签核对；其他客户端使用各自的官方内核更新方式，不照搬菜单。先确认备份可读、当前配置仍可用，并安排能短暂停网的时段。

本节面向普通 Mihomo 配置。当前使用 Smart 或其他内核分支、且依赖该分支功能时，先查原维护者的兼容说明，不直接切换普通特定版本；内核名称不同，不能只按数字较新来替换。

普通更新按钮与选择特定版本是不同操作；这里用特定版本固定复核目标。后续版本须另查发布说明，不把所有未来版本预先写成已验证。下载、校验、授权或启动任一步失败，都先停在该步骤，不连续叠加内核、订阅和 DNS 修改。

优先完成已确认的内核修复。确需临时对照时，可在自己管理的本地覆写中只把 tun.stack 从 mixed 改为 gvisor，保留原值与备份；原配置不是 mixed，或客户端没有受支持的覆写入口时，不直接复制这一步。

下面只表示要调整的字段，不是一份完整配置。保持原 DNS、路由、设备名、订阅和其他 TUN 项，应用后检查最终运行配置确实为 gvisor，再正常重启内核。不要改远程订阅，也不要同时修改 strict-route 来混淆结果。

#3310 的一次恢复同时包含重启与配置变化，不能单独归功于 gVisor，也不能证明长期不复发。官方文档区分 system、gvisor 与 mixed 的实现；它们不是按“越新越好”排序。记录相同业务的变化，无改善就还原原 stack，不把新设置直接当永久答案。

在相同配置和相近负载下观察内核与客户端两个进程，再重复原来失败的网站或应用请求。不能用别人的 CPU 数字作合格线；应比较自己修改前后的持续占用与日志增长，避免把一次瞬时下降当作长期结论。

日志停止重复，还不能说明 TUN 已能联网。若仍访问失败，保持 TUN 关闭，逐项确认内核已启动、授权已完成、当前配置已生效，再正常重启并重测原请求。不要继续提高日志等级，也不要同时修改 DNS 来试错。

临时改过 stack 时，先恢复记录的原值并重启内核；保持 TUN 关闭直到基本联网恢复。必要时使用此前可用且受支持的系统代理方式，不假定它能覆盖所有应用，也不删除整个客户端数据目录。

新内核无法启动时，按备份恢复原通道、具体内核和配置，再按客户端提示重新授权。旧内核仍可能包含这次错误循环，不应在已知触发条件下当作长期方案；回退若又刷屏，关闭 TUN、保留可用联网方式并停止重试。不要把程序降级与配置恢复当成同一操作。

仍复发时提供 macOS 与架构、客户端和实际内核版本、stack、授权状态、最早可用的短错误片段、重启前后与修改前后差异。配置重载、睡眠唤醒或网络切换仅按实际观察记录，不凭相邻时间认定原因；分享前删除订阅令牌、密码、私有域名和本机身份信息。