Clash Verge Rev でカーネル通信エラーが出てプロキシ画面が空になる場合の修正方法

ホーム画面に「カーネル通信エラー」と表示され、現在のノードが空になっていると、プロキシが完全に停止したように見えます。まずサブスクリプションを削除せず、DNS もすぐには変更しないでください。「ログ」と「接続」ページを開き、ブラウザで新しい Web ページへアクセスして、直前のドメインと送信記録が表示されるか確認します。

Web ページを引き続き開くことができ、ログにも TCP または UDP 接続が増え続ける場合、Mihomo は転送を続けているものの、デスクトップ画面がプロキシグループと現在のノードを読み取れていない可能性があります。最近の公式 issue にも、システムプロキシが参照するローカルポートは機能し、実行時設定にもノードが含まれる一方、ホーム画面とプロキシページでは制御情報を読み取れない状態が記録されています。

Clash Verge Rev v2.5.2 の公式リリースノートには、「ホーム画面のプロキシカードが通信異常を誤表示する場合がある問題を修正」「ホーム画面の現在のプロキシ状態がまれに同期されない問題を修正」「Clash の設定を再読み込みした後、ルールページのデータがすぐに更新されない問題を修正」と記載されています。問題が v2.5.1 以前で発生している場合、コントローラーポートを変更するよりも、安定版への更新が直接的です。

プロジェクトの公式 Release または入手元が明記された当サイトのダウンロードページから、Windows のアーキテクチャに適合するインストーラーを選択します。更新前にログをエクスポートして現在のサブスクリプション名を記録し、インストール完了後にクライアントを一度完全に終了してから開き直してください。サブスクリプション、TUN、DNS、サービスモードを同時に変更すると、どの手順が有効だったか判断できません。

更新後もエラーが続く場合は、まずタスクマネージャーの「詳細」を開きます。通常のサービスモードでは、デスクトップアプリケーション、サービスプロセス、Mihomo カーネル一つが表示されます。verge-mihomo.exe が同時に二つ存在する場合、以前のプロセスが mixed-port または名前付きパイプを占有し、新しいカーネルが完全には起動できない可能性があります。

Clash の名前を含むプロセスが複数あるというだけで、すべてを強制終了しないでください。まずシステムトレイからクライアントを終了し、数秒後に verge-mihomo.exe がまだ二つあるか確認します。ログに bind、Only one usage、Access is denied、pipe listen error のいずれかが表示された場合に限って、残存プロセス、ポートの占有、サービス状態を重点的に調べてください。

このコマンドはリスナーを確認するためだけに使い、プロセスを終了しません。Mixed ポートが 7897 とは限らないため、クライアントの設定またはログにある実際の値へ置き換えてください。一つの verge-mihomo.exe が正常にリッスンし、ログにもすでにプロキシリクエストが表示されている場合は、ポート競合としての調査を続けないでください。

サービスモードで起動する際、クライアントはまず実行時設定を生成して検証し、次にサービスからカーネルを起動し、最後に制御インターフェースを通じてプロキシグループを読み取ります。末尾の「通信エラー」だけを見ていると、実際の失敗箇所を見落とします。一度再起動し、ログの先頭から最初の error を探してください。

Clash Verge Rev の公式 Windows FAQ では、「プロキシメニューが空白になる」原因をカーネル通信の失敗とし、Windows ファイアウォールを無効にしてから再び有効にするよう案内しています。ここでの目的はファイアウォールルールを再読み込みすることであり、保護を長期間無効にすることではありません。

まず Windows セキュリティの「ファイアウォールとネットワーク保護」を開き、現在のネットワークの種類を記録します。該当するネットワークの Microsoft Defender ファイアウォールを短時間だけ無効にし、すぐに有効へ戻してから、Clash Verge Rev を終了して再起動してください。会社のコンピューターが管理者ポリシーで制御されている場合は、ポリシーを回避せず、ログを管理者へ渡して、アプリケーションとローカル通信のルールを確認してもらってください。

サブスクリプションのダウンロード、実行時設定、プロキシページの表示は、三つの異なる段階です。サブスクリプションページに更新時刻が表示されても、アドレスが保存され、一度処理されたことしか証明できません。実行時 YAML に proxies と proxy-groups があれば、カーネルがノードを取得したことを示します。プロキシページでは、さらに制御インターフェースを通じてこれらのグループを読み取る必要があります。

最近の公式診断記録には、実行時設定にプロキシとポリシーグループが含まれ、Mixed ポートも転送している一方、external-controller が空で、デスクトップ画面で読み取るための名前付きパイプしか残っていないケースがあります。この状態で HTTP コントローラーを独自に公開する方法は第一候補の修正ではなく、管理インターフェースの露出を広げるおそれもあります。まず安定版への更新、サービスの再起動、ファイアウォールの更新を完了してください。

ログにサービス、パイプの権限、重複したカーネルのいずれかが明示され、更新とファイアウォールの再読み込みでも改善しない場合に限って、サービスモードを処理します。まずシステムプロキシと TUN を無効にし、通常のネットワークが復旧したことを確認してから、クライアント設定のサービスモード画面からサービスをアンインストールします。Windows を再起動した後に再インストールしてください。

サービスの再インストールでは、無効なサブスクリプションは修正できません。また、プロキシページが空白になるたびに実行する定型手順でもありません。再起動後に管理者権限がない、ボタンがポリシーで無効になっている、セキュリティソフトウェアがサービスのインストールを遮断している、といった場合は再試行を中止し、エクスポートしたアプリケーションログとサービスログを残してください。

プロキシページが再表示されても、問題が完全に解決したとは限りません。最後に、同じ Profile と同じノードを使い、画面から実際のアクセスまでを一度通して検証してください。これにより、サービス、制御経路、転送がすべて復旧したことを確認できます。