Clash Verge Revでポートが使用中の場合の対処方法

この記事は、ログに address already in use、Bind failed、または Start Mixed(http+socks) server error が明確に出ている場合だけを対象とします。問題報告にある 7890 と 1053 は例にすぎません。確認には、自分のログに表示された mixed-port、DNS、または external-controller のポートを使ってください。

Mihomo のドキュメントでは、mixed-port は HTTP(S) と SOCKS の両方のリクエストを受け付けるローカルの入口です。新しいコアがこのポートをバインドできない場合、システムプロキシが引き続き同じポートを指していても、新しい接続は利用できません。

Clash Verge Rev の issue #7861 では、macOS のサービスモードで GUI が異常終了した後も、root ユーザーで動作する verge-mihomo が mixed-port と DNS ポートを占有し続ける事例が報告されています。Issue #6741 では、Linux への再ログイン時に新旧のコアが mixed-port を取り合う事例が記録されています。

どちらも現在 open issue であり、原因分析は報告者によるものです。メンテナーが一般的な原因として確認済みであるかのように書くことはできません。

まず TUN とシステムプロキシを無効にし、Clash Verge Rev に依存しなくてもデバイスがインターネットへ直接接続できることを確認してから、トレイからクライアントを完全に終了します。現在の Profile、ポート設定、障害ログを保存し、切り分け中にサブスクリプションを同期したりルールを変更したりしないでください。

終了後は数秒待ってから、ポートをもう一度確認します。リスナーが消えていれば、まずクライアントを一度だけ起動して様子を見ます。ポートが引き続き使用中の場合だけ、使用しているプロセスをさらに調べてください。

ポート競合はプロセス名の当て物ではありません。まず PID を特定し、プロセス名、所有者、起動時刻、実行ファイルのパスを確認して初めて、現在動作中のコア、終了後に残った古いコア、無関係なプログラムを区別できます。

下記の 7890、1053、12345 はすべて例です。実行前にログのポートと、確認した PID に置き換えてください。読み取り専用の照会で結果が出なくても、結果を得るためにむやみにプロセスを終了しないでください。

PID がクライアント終了後に残った verge-mihomo であると確認できた場合だけ、単一プロセスを終了します。まず通常の終了を使い、その後ポートをもう一度確認してください。広範囲の pkill や強制シグナルから始めないでください。

Issue #6947 の Windows の報告では、ポートを変更してシステムプロキシを再起動すると利用できるようになりました。プロジェクトのコラボレーターは、まず Mihomo ログの Bind failed を確認し、Windows または Hyper-V の予約済みポートも調べるよう案内しています。この分岐が当てはまるのは、リッスンしているプロセスが見つからない一方で、ログには明確なバインド失敗が残る場合だけです。

現在の mixed-port が予約範囲に含まれる場合は、Clash Verge Rev のポート設定で、リッスンしておらず予約範囲にも含まれない新しいポートを選び、ホームへ戻ってシステムプロキシを再度有効にします。使用しているプロセスを確認せずにポートだけを変えても、動作中の残存コアには対処できません。

Clash Verge Rev v2.5.2 のソースコードには、サービスのインストール、アンインストール、再インストール、repair コマンドが用意されています。repair は強制再インストールを実行し、サービスの IPC が復旧するまで待機します。システムやビルドによってボタン名が異なる場合があるため、現在のクライアント設定にあるサービスモードの入口を使い、サービスファイルを手動で削除しないでください。

v2.5.2 のリリースノートには、より堅牢なサービスライフサイクル管理が記されていますが、後から報告された残存コアやポート切り替え競合が安定版で完全に修正された証拠にはなりません。この記事は障害からの復旧手順であり、バージョンの修正告知ではありません。

まず起動前に対象ポートが空いていることを確認してから Clash Verge Rev を起動し、想定したコア一つだけがリッスンしていることを確認します。続いてサンプルのポートを現在の mixed-port に置き換え、ローカルプロキシ経由で実際の HTTPS リクエストを行い、Connections で記録を確認します。

システムプロキシ経由の検証に成功した後で TUN を有効にします。TUN を有効にしたときだけ通信できなくなり、ログにバインドエラーがない場合は、TUN、DNS、ルーティングの調査へ移り、mixed-port の変更を続けないでください。

ポート変更やサービス再インストールで問題が悪化した場合は、まずシステムプロキシと TUN を無効にして、デバイスを直接接続できる状態に戻します。古いポートが解放されている場合だけ元のポートへ戻してください。サービスの再インストールに失敗した場合は、サービスモードを無効のままにし、システムファイルを手動で削除しないでください。

公式へ報告するときは、ローカルで分かったことを観察結果として書き、メンテナーに代わって原因を断定しないでください。完全な設定、サブスクリプション URL、ノードのパスワード、コントローラーの secret、未編集のログをアップロードしないでください。