Mihomo macOS TUN：ENOTSOCK 與 CPU 飆高

在 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、授權狀態、最早可用的短錯誤片段、重新啟動前後與修改前後差異。重新載入設定、睡眠喚醒或網路切換僅按實際觀察記錄，不憑相鄰時間認定原因；分享前刪除訂閱令牌、密碼、私有網域和本機身分資訊。