Clashのポートが使用中のときの対処法：プロセスの特定とポート変更

まずエラーがポート競合かどうかを確認する

Clashがコアを起動するときは、ローカルアドレス上に1つ以上のリッスンポートを開きます。ブラウザー、システムプロキシ、その他のアプリがこれらのポートへリクエストを送り、コアがプロキシグループとルールに従って通信を処理します。同じネットワークプロトコル、同じリッスンアドレス、同じポートを別のプロセスがすでに使用している場合、新しいリッスンは通常失敗します。

よくある症状は、クライアント画面は開くもののコアがすぐ停止する、システムプロキシを切り替えられるのにウェブページへアクセスできない、ログに address already in use、bind、listen tcp、「ポートはすでに使用されています」などの情報が出る、といったものです。一部のGUIクライアントはコアの起動を繰り返し試みるため、ログに同じエラーが連続して記録されることもあります。

「インターネットに接続できない」だけを理由に、すぐポートを変更しないでください。設定の解析エラー、無効なサブスクリプション、使用できないプロキシノード、システムプロキシが有効になっていないこと、ファイアウォールの制限などでも似た症状が起こります。ポート競合を判断するには、まずログにある具体的なアドレス、たとえば 127.0.0.1:7890、0.0.0.0:7890、:9090 を確認します。コロンの後の数字が確認すべきポートです。

ポート競合と権限エラーの違い

「アドレスはすでに使用中です」は通常、既存のリッスンプロセスがあることを示します。一方、permission denied の「権限がありません」は、必ずしもポートが使用中という意味ではありません。1024未満のポート、システム予約ポート、セキュリティソフトのポリシー、OSによるポート除外範囲などがバインドを妨げることもあります。通常の設定では、使用されていない高い番号のポートを選び、一般的なサービス用ポートの安易な利用は避けてください。

mixed-port、port、socks-portを区別する

競合に対処する前に、エラーがどの設定項目に対応しているかを確認します。項目ごとに対象プロトコルが異なり、変更後に同期が必要なアプリも変わります。Clashとmihomoでよく使われるリッスン項目は次のとおりです。

デスクトップクライアントで最もよくある競合は mixed-port です。たとえばクライアントAがバックグラウンドで 7890 を使用中なのに、クライアントBも 7890 を使おうとすると、後から起動したコアはリッスンを開始できません。見落としやすいのが、プロキシポートは正常でも、external-controller が使う 9090 が占有されているケースです。この場合、GUIがコアに接続できない、または実行状態を読み取れないといった症状になります。

用途が重複し、同じポート番号を持つ項目を同時に設定しないでください。たとえば mixed-port と port をどちらも 7890 にすると、同じコア内部でバインド競合が起こります。一般的なデスクトップ環境のシステムプロキシを使うなら、mixed-port を1つだけ残すほうが管理しやすいでしょう。HTTPとSOCKS5の入口を明確に分ける必要がある場合に限り、port と socks-port を個別に設定します。

Windows、macOS、Linuxでリッスン中のプロセスを特定する

ログでポートを確認したら、次は誰が待ち受けているかを調べます。確認前に現在のClashクライアントを完全に終了し、数秒待ってからコマンドを実行してください。それでもポートがリッスン中なら、別のプロキシクライアント、残存したコアプロセス、開発サーバー、コンテナのポートマッピング、システムサービスなどが使用している可能性があります。

Windows：ポートからPIDを特定する

コマンドプロンプトでTCPポート 7890 を確認します：

netstat -ano | findstr :7890

結果の最後の列がPIDです。状態が LISTENING になっている記録を重点的に確認し、PIDからプログラム名を調べます：

tasklist /FI "PID eq 1234"

PowerShellなら、そのリッスンポートを所有するプロセスを直接一覧表示することもできます：

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 1234

コマンドプロンプトで権限不足と表示された場合は、必要な権限を持つターミナルで再試行してください。複数の記録がある場合はローカルアドレスを比較します。IPv4とIPv6を別々にリッスンするプログラムもあり、タスクマネージャーでは1つのプロセスに見えても、コマンド結果では2つのリッスン記録が表示されることがあります。

macOS：lsofでリッスン中のプロセスを確認する

lsof -nP -iTCP:7890 -sTCP:LISTEN

出力の COMMAND はプロセス名、PID はプロセス番号です。通常の権限で詳細情報を表示できない場合は、コマンド内容を確認したうえで次を実行します：

sudo lsof -nP -iTCP:7890 -sTCP:LISTEN

macOSではウィンドウを閉じただけでは、クライアントを終了したことにならない場合があります。メニューバーの状態項目を確認し、クライアントの終了コマンドでメインプログラムを終了してください。メインプログラムの終了後もコアプロセスが残っている場合は、PIDとプログラムのパスから、どのクライアントに属するかを判断します。

Linux：TCPとUDPを両方確認する

sudo ss -ltnp | grep ':7890 '
sudo ss -lunp | grep ':7890 '

1つ目はTCP、2つ目はUDPを確認します。通常のHTTP、SOCKS5、コントロールインターフェースでは主にTCPを確認しますが、DNSのリッスンや一部の透過プロキシ環境ではUDPも確認してください。システムに lsof があれば、macOSに近いコマンドも利用できます。

古いプロセスを終了するかClashのポートを変更するか決める

使用者を特定したら、対応方法は2つあります。判断基準は「どちらが早いか」ではなく、今後どのプロセスがそのポートを使うべきかです。

古いプロセスの終了が適しているケース

• 現在使っていない別のClashまたはプロキシクライアントがポートを使用している。
• 同じクライアントが異常終了し、古いコアだけが独立して動き続けている。
• クライアントが起動時に自動起動する設定で、これから別のクライアントを使う予定である。
• テストプログラムが一時的にプロキシポートを使用しており、終了してもほかの作業に影響しないことを確認できている。

まずはアプリ本来の終了機能やサービス停止コマンドを使い、状態の保存とネットワーク設定の復元を完了させます。画面から操作できない残存プロセスだと確認できた場合に限り、PID指定での終了を検討してください。終了後、ポート確認コマンドをもう一度実行してリッスン記録が消えたことを確認し、その後Clashを起動します。

Clashのポート変更が適しているケース

• 元のポートが継続稼働の必要なサービスに割り当てられている。
• 2つのプロキシコアを同時に起動し、それぞれ別のテストを実行する必要がある。
• 組織やデバイスのポリシーによって、特定のポート範囲が固定的に確保されている。
• クライアントを起動するたびに、コンテナのポートマッピング、開発ツール、仮想マシンサービスと競合する。

新しいポートには3つの条件があります。現在リッスン中のプロセスがなく、設定内のほかの項目と重複せず、利用元の設定を同期して変更できることです。まず 7891 や 17890 のような高い番号のポートを選び、システムコマンドで空いていることを確認してください。ポート番号の上限は 65535 です。負数、文字列、範囲外の値は指定できません。

YAML設定を変更し、サブスクリプションによる上書きを防ぐ

クライアントの設定画面でポートを変更できる場合は、まず画面のポート設定を使ってください。クライアントがそれに基づいて実行用設定を同期生成する場合があるためです。YAMLを直接編集する前に、そのファイルが実際の実行設定なのか、サブスクリプションの元設定なのか、クライアントが生成した一時コピーなのかを確認します。

単一の混合ポートを使う場合は、次のように設定できます：

mixed-port: 7891
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9091

HTTPとSOCKS5の入口を分ける場合は、2つの項目に異なるポートを割り当てます：

port: 7891
socks-port: 7892
external-controller: 127.0.0.1:9091

変更後はまず設定を検証し、それからコアを再起動します。YAMLはスペースで階層を表すため、Tab、インデントのずれ、項目の重複によって新たな解析エラーが起こることがあります。ポート値は整数で記述してください。同じ項目が統合設定、上書きスクリプト、サブスクリプション内容に複数回登場する場合、最終的な有効値はクライアントの設定統合フローによって決まり、1つのファイルだけを見ても判断できません。

2つのコアを同時に実行する場合、プロキシポートだけでなく、コントロールポート、DNSリッスンポート、透過プロキシポートも項目ごとに確認します。2つのインスタンスでそれぞれ mixed-port: 7890 と mixed-port: 7891 を使うだけでは不十分です。両方が external-controller: 127.0.0.1:9090 にバインドされていれば、2つ目のインスタンスは起動に失敗する可能性があります。

ポート変更後にシステムプロキシとアプリ設定を同期する

ポート競合を解消しても接続できない場合、最も多い原因は「リッスンポートは変わったのに、リクエストが古いポートへ送られている」ことです。たとえばClashを mixed-port: 7891 に変更しても、WindowsやmacOSのシステムプロキシが 127.0.0.1:7890 を指したままなら、ブラウザーは新しい入口に接続できません。

システムプロキシ

Clashクライアントがシステムプロキシを自動管理している場合は、いったんシステムプロキシをオフにしてから再度オンにし、クライアントに新しいアドレスを書き込ませます。その後、OSのネットワーク設定でHTTPとHTTPSのプロキシが 127.0.0.1 と新しいポートを指しているか確認します。mixed-port を使う場合、HTTPプロキシにはそのポートをそのまま指定できます。

ブラウザーと個別アプリ

一部のブラウザー拡張機能、ダウンロードツール、コードエディター、チャットアプリ、リモート接続ツールはシステムプロキシに従わず、独自のプロキシアドレスを保存しています。各アプリのHTTPまたはSOCKS5ポートを個別に確認してください。アプリがSOCKS5に設定されているのに、現在 port しか残っていない場合はプロトコルが一致しません。mixed-port を使うか、アプリに専用の socks-port を指定します。

ターミナルの環境変数

コマンドラインツールは HTTP_PROXY、HTTPS_PROXY、ALL_PROXY を読み取ることがあります。既存セッションの環境変数は、Clashの設定を変更しても自動更新されません。一時的な環境変数を使う場合も、ポートを実際のリッスン値と一致させる必要があります：

HTTP_PROXY=http://127.0.0.1:7891
HTTPS_PROXY=http://127.0.0.1:7891
ALL_PROXY=socks5://127.0.0.1:7891

環境変数を設定する構文はターミナルごとに異なります。上記はアドレスの構造を示す例です。起動スクリプトやシステム全体の環境変数を変更する前に、ほかのツールが古いポートに依存していないことを確認してください。

LAN内のデバイス

スマートフォンやほかのデバイスがパソコン上のClashプロキシを使う場合、allow-lan: true にするだけでなく、パソコンのLAN内アドレスと新しいポートを指定する必要があります。この場合、リッスンアドレス、ファイアウォールの受信規則、ネットワーク分離設定が接続に影響します。スマートフォン側に 127.0.0.1 を入力しないでください。スマートフォン自身を指してしまいます。

TUNモードでもDNSとコントロールポートを確認する

TUNモードを有効にすると、多くのアプリはシステムのHTTPプロキシを直接参照しなくなるため、mixed-port は問題と無関係だと思いがちです。実際には、コアが混合プロキシポート、コントロールインターフェース、DNSサービスを同時に起動することがあります。必須のリッスン項目のいずれかが競合すると、コアの起動が中断されたり、一部機能に異常が生じたりします。

ログが dns.listen を示している場合は、次のようにDNS設定を確認します：

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip

1053 が別のDNSフォワーダーに使用されている場合は、空いている別のポートに変更できます。ただし、そのリッスンアドレスに依存する設定も更新が必要です。DNSがTUNによって自動的に引き継がれている場合は、例だけを見て変更せず、クライアントが生成した実際の設定とログを基準にしてください。

コントロールインターフェースの競合では、コア自体は動作しているのに、GUIに「接続に失敗しました」「設定を取得できません」「読み込み中のまま」と表示されることがあります。この場合は external-controller のポートを確認し、クライアントがコアへの接続に使うアドレスが同じであることを確認します。コントロールポートを変更したら、外部パネルのブックマークやクライアント内のコントローラーアドレスも同期してください。

透過プロキシ環境では、redir-port、tproxy-port、ファイアウォールルールも関係することがあります。YAMLだけ変更してリダイレクト先を更新しないと、通信は古いポートへ流れ続けます。Linuxではポリシールーティング、ファイアウォールルール、サービスの起動パラメーターも確認し、独立したスクリプトに固定ポートが記述されていないか確認してください。

手順に沿ってポート競合を再確認する

変更後は、「クライアント画面が緑になった」ことだけを判断材料にしないでください。リッスン、プロキシ入口、ルール処理、実際のアクセスという4つの層に分けて確認すると、ポートの問題とノードの問題を切り分けやすくなります。

1. クライアントを完全に終了して再起動します。古いコアが終了していることを確認し、残存プロセスによる誤った検証結果を避けます。
2. 起動ログを確認します。以前の bind または address already in use エラーが再び表示されていないことを確認します。
3. 新しいポートを調べます。netstat、lsof、ss を使い、現在のClashまたはmihomoコアがリッスンしていることを確認します。
4. システムプロキシを確認します。アドレスは通常 127.0.0.1 で、ポートは mixed-port または port と一致している必要があります。
5. 個別アプリの設定を確認します。特にブラウザー拡張機能、ターミナル変数、ダウンロードツール、SOCKS5を使うプログラムを確認してください。
6. ローカル接続テストを実行します。まずリクエストがローカルプロキシに届くことを確認し、次にログに対応する接続記録があるか確認します。
7. ノード障害と切り分けます。ログにリクエストが記録され、ルールのマッチングも完了しているのに接続先がタイムアウトする場合は、ローカルポートを再度変更するのではなく、プロキシノード、プロキシグループ、ネットワーク環境を確認してください。
8. サブスクリプションを1回更新します。更新後にポート値を再確認し、ローカル設定がサブスクリプション内容で上書きされていないことを確認します。

ポート競合への対処は、ログからポートを読み取り、実際にリッスンしているプロセスを調べ、ポートの所有者を判断し、競合している項目だけを変更して、すべてのリクエスト入口を同期する、という流れにまとめられます。この手順を順番に実行するほうが、クライアントを何度も再インストールしたり、複数のポートを無作為に変更したりするより、保守しやすい設定を残せます。