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、権限付与の状態、保存できた最も早い時点の短いエラー記録、再起動前後と変更前後の違いを伝えてください。設定の再読み込み、スリープからの復帰、ネットワークの切り替えについては実際に観察したことだけを記録し、時刻が近いという理由で原因と判断しないでください。共有前に、サブスクリプションのトークン、パスワード、プライベートドメイン、端末の識別情報を削除します。