接続トラブルシューティング · Clash 技術ブログ

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

Clash Verge Rev で address already in use が出る場合は、mixed-port を使用するプロセスと予約ポートを調べます。残ったコアや別のアプリに対処し、システムプロキシと終了後の直接接続を確認してください。

本文を読むブログへ戻る
  • Clash Verge Rev
  • address already in use
  • mixed-port
  • ポート競合
  • サービスモード
目次
執筆者
Clash 公式
公開日
更新日時
読了時間の目安
約 10 分

ウィンドウを閉じても、プロキシのコアや別のローカルプログラムが同じポートを使い続けている場合があります。新しいプログラムが起動できないからといって、サブスクリプションが壊れているとは限りません。実際のポートと使用中のプロセスを照合し、動いている接続を残して、確認できた競合だけを処理します。

address already in use：実際にバインドできないポートはどれ？

ログのaddress already in use、Bind failed、Start Mixed(http+socks) server errorを保存し、示されているローカルポートを記録してください。これらのエラーが出た場合、新しいプログラムはポートのバインドを完了していません。

ポートはプログラムがリクエストを受け取る入口の番号です。自分のログにある mixed-port、DNS、external-controller の値を使ってください。報告の 7890 と 1053 は例にすぎません。

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 であり、原因分析は報告者によるものです。メンテナーが一般的な原因として確認済みであるかのように書くことはできません。

最初の bind エラーで実際のポートを記録する
Start Mixed(http+socks) server error: listen tcp :7890: bind: address already in use
Start DNS server(TCP) error: listen tcp 0.0.0.0:1053: bind: address already in use
Start DNS server(UDP) error: listen udp 0.0.0.0:1053: bind: address already in use

最初のエラーに応じて切り分ける

ログまたは症状考えられる原因次の手順
mixed-port だけに address already in use が出る古いクライアント、別のプログラム、残存コア、または Windows の予約済みポート実際のリスナーを確認する
mixed-port と DNS ポートの両方が失敗する別のコアがポート群全体を保持している可能性が高いプロセスの所有者と起動時刻を確認する
external-controller ポートだけが競合するコントロールインターフェースまたは Dashboard が同じポートを使用しているコントロールポートを個別に確認する
ログには connection refused だけがあり、bind エラーはない対象ポートがリッスンしていないため、ポート競合ではないコアの起動と設定を確認する
一つのサイトだけ開けないルール、DNS、またはノードの問題この記事に従ってプロセスを終了しない

クライアント終了後、ポートは解放された？

TUN とシステムプロキシを無効にし、Clash Verge Rev なしで通信できることを確認してトレイから完全終了します。サブスクリプションやルールを更新せず、現在の Profile、ポート設定、最初のエラーログを保存してください。公開する前にサブスクリプションの URL、パスワード、secret を隠します。

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

PID・実行アカウント・パスから、ポートを使用しているプログラムを確認する

プロセス名だけでポートを使用しているプログラムを判断しないでください。まず PID（プロセスの識別番号）を調べ、プロセス名、所有者（実行アカウント）、起動時刻、プログラムのパスを確認します。これにより、現在正常に動作するコア、終了後に残った旧コア、無関係のプログラムを区別できます。

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

Windows PowerShell：TCP と UDP のリスナーを確認する
$Port = 7890
$Tcp = Get-NetTCPConnection -LocalPort $Port -State Listen -ErrorAction SilentlyContinue
$Tcp | Select-Object LocalAddress, LocalPort, OwningProcess
$Tcp | ForEach-Object {
  Get-Process -Id $_.OwningProcess | Select-Object Id, ProcessName, Path
}
Get-NetUDPEndpoint -LocalPort 1053 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess
macOS：リスナーを確認してプロセスを照合する
PORT=7890
sudo lsof -nP -iTCP:${PORT} -sTCP:LISTEN
sudo lsof -nP -iUDP:1053
ps -o user,pid,ppid,lstart,command -p 12345
Linux：リスナーを確認してプロセスを照合する
sudo ss -ltnp 'sport = :7890'
sudo ss -lunp 'sport = :1053'
ps -o user,pid,ppid,lstart,cmd -p 12345

別のプログラムや残ったコアがポートを使用している場合はどうする？

ポートを別の Clash、VPN、開発サーバー、またはローカルプロキシが使用している

そのプログラムの画面から正常に終了するか、両方のプログラムで異なるポートを使います。未知のシステムプロセスは終了しないでください。

Clash Verge Rev を終了しても、ポートを verge-mihomo が使用している

残存コアの特徴に当てはまります。PID と所有者を記録してから、下記の OS 別の方法でその PID だけを終了してください。同じ名前のほかのプロセスは終了しません。

プロセスが root または管理者所有で、終了後すぐに再び現れる

強制終了を繰り返さず、クライアントのサービスモードを修復または再インストールする手順へ進む。

再ログインやクライアントの素早い再起動後に、ときどき競合する

旧コアが終了しきる前に新しいコアが起動した可能性があります。重複した自動起動設定を無効にし、クライアントを一度だけ起動して確認してください。

Windows でリスナーが見つからないのにバインドできない

ポートが Windows excluded port range に含まれていないか確認する。

PID がクライアント終了後に残った verge-mihomo であることを確認してから、そのプロセスを終了し、ポートを再確認します。macOS/Linux では先に TERM を送ります。Windows の Stop-Process はプロセスを直接終了し、-Confirm は確認画面を追加するだけです。広範囲の pkill を使ったり、正常に通信を転送しているコアを終了したりしないでください。

macOS / Linux：確認した単一の PID だけを終了する
# 把 12345 换成刚才确认的 PID
sudo kill -TERM 12345
Windows PowerShell：確認後に単一の PID を終了する
# 把 12345 换成刚才确认的 PID
Stop-Process -Id 12345 -Confirm

Windows でリスナーが見つからない場合は予約済みポートを確認する

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

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

Windows の TCP と UDP の予約済みポートを読み取り専用で確認する
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv4 show excludedportrange protocol=udp
netsh interface ipv6 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=udp
候補ポートを使う前にリスナーがないことを確認する
# 17890 只是示例，不能保证每台电脑都可用
Get-NetTCPConnection -LocalPort 17890 -ErrorAction SilentlyContinue
Get-NetUDPEndpoint -LocalPort 17890 -ErrorAction SilentlyContinue

残存コアが繰り返し現れる場合はサービスモードを修復する

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

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

サービスモードの復旧手順

  1. 直接接続を維持する

    システムプロキシと TUN を無効にし、クライアント停止中もシステムがインターネットに接続できることを確認する。

  2. 診断結果を保存する

    ポート、PID、プロセス所有者、クライアントのバージョン、最初の bind エラーを記録する。

  3. クライアント内の入口を使う

    現在のクライアントのサービスモード設定から、旧サービスを無効化またはアンインストールできます。Windows では、使用するサービスのコンポーネントが公式セキュリティ勧告の修正要件を満たしていることを確認してから、修復・再インストール・有効化を行ってください。確認できない場合は無効のままにします。ほかのシステムではクライアントのアンインストール・修復・再インストール機能を使い、権限確認と操作の完了を待ってください。

  4. 必要ならシステムを再起動する

    管理者権限のコアが引き続きポートを保持している場合は、再起動後にポートが解放されたことを確認してからクライアントを起動する。

  5. 機能を一つだけ戻す

    まず元の Profile とシステムプロキシを起動し、正常動作を確認してから必要に応じて TUN を戻す。

修復後にポート、プロキシ、終了時の解放を検証する

現在の mixed-port で実際のリクエストを確認する
# 把 7890 换成当前 mixed-port
curl -I -x http://127.0.0.1:7890 https://example.com

完了基準

  • 起動前、対象ポートに未知のリスナーがない
  • 起動後、mixed-port を想定した verge-mihomo 一つだけがリッスンしている
  • 新しいログに address already in use または Bind failed が出ない
  • mixed-port を使った curl リクエストで HTTP レスポンスを受信できる
  • システムプロキシが現在の実際のポートを指し、Connections にテストリクエストが表示される
  • クライアントを正常終了するとポートが解放され、システムプロキシも元に戻る
  • 再起動または再ログイン後に、二つ目の残存コアが現れない

システムプロキシで実際の HTTPS リクエストが成功してから、必要な場合だけ TUN を有効にします。TUN を有効にしたときだけ切れ、バインドエラーもなければ、DNS と経路を調べ、mixed-port を変え続けないでください。

ポート変更やサービス再インストールで直らない場合は、直接接続に戻して証拠を保存する

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

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

公式 issue を送信する前に残す情報

  • Clash Verge Rev の完全なバージョンとインストール元
  • OS のバージョンと CPU アーキテクチャ
  • サービスモード、TUN、自動起動を有効にしていたか
  • GUI が正常終了、クラッシュ、強制終了のどれだったか
  • 最初の address already in use ログと実際のポート
  • リスナーの PID、所有者、起動時刻、プログラムのパス
  • クライアント終了後にポートが解放されたか、サービス修復後に再現したか

参考資料