Clashのポートが使用中？プロセスの特定と待受ポートの変更

Clashは起動時に、ローカル環境で1つ以上の待受ポートを開きます。ブラウザーやOS、ほかのアプリはこれらのポートへプロキシリクエストを送り、Clashが設定ファイルのルールやプロキシグループに従って通信を処理します。対象ポートを別のプロセスがすでに使用している場合、OSは2回目のバインドを拒否します。コアは通常、アドレスが使用中、待受に失敗、またはポートが使用中であることを示します。

よくある原因は、以前のClashプロセスが完全に終了していない、クライアントを2つ同時に起動している、別のプロキシツールが同じポートを使っている、設定内の複数の待受先に同じポートを指定している、あるいはコントロールAPIやDNSサービスがローカル開発サービスと競合していることです。起動ボタンを何度も押すのではなく、まずどのアドレスとポートで競合しているかを確認し、該当プロセスを特定してから、使用中のプロセスを終了するかClashの設定を変更するか判断します。

1. エラーメッセージからポート競合を見分ける

クライアントによってコアログの整形方法は異なりますが、基盤となるエラーには通常、bind、listen、address already in use、「ポートが使用中」といったキーワードが含まれます。ログで特に重要なのは、プロトコル、待受アドレス、ポート番号です。たとえば 127.0.0.1:7890 はローカルのループバックアドレスだけで7890を待ち受けることを示し、0.0.0.0:7890 はすべてのIPv4ネットワークインターフェースでそのポートを待ち受けようとしていることを示します。

listen tcp 127.0.0.1:7890: bind: address already in use
listen tcp 0.0.0.0:9090: bind: address already in use

1つ目は通常、HTTP、SOCKS、mixedプロキシの入口に対応し、2つ目は外部コントロールAPIに対応している可能性が高いです。ただし、ポート番号だけで設定項目を断定することはできません。デフォルト値は変更できるため、ログの前後関係と現在有効な設定をあわせて確認してください。

ログにバインド失敗がなく、TUNデバイスの作成失敗、権限不足、ルート設定の失敗、ネットワークインターフェースが存在しないといった内容が表示される場合、問題はプロキシポートとは限りません。この場合、7890のようなポートを変更しても解決しないことが多く、管理者権限、仮想ネットワークアダプター、TUNドライバー、システムルートを確認する必要があります。

2. Clashが使用中の待受ポートを確認する

Clashとmihomoの設定には、複数のローカル待受先を指定できます。実際の項目はクライアントの機能と現在の設定によって異なりますが、代表的なものは次のとおりです。

設定項目	用途	競合時の影響
`mixed-port`	同じポートでHTTPとSOCKS5プロキシ接続を受け付ける	システムプロキシと手動プロキシの両方が使えなくなる可能性がある
`port`	HTTPプロキシの待受ポート	HTTPプロキシを使うアプリが接続できない
`socks-port`	SOCKS5プロキシの待受ポート	SOCKS5を使うアプリが接続できない
`redir-port`	リダイレクトされた通信を受け付け、特定のシステムネットワーク構成で使用する	透過プロキシの経路を確立できない
`tproxy-port`	TPROXY通信を受け付ける。Linuxのルーター環境でよく使われる	透過プロキシのルールが通信をコアへ渡せない
`external-controller`	クライアント画面や外部パネル向けにコントロールAPIを提供する	画面でコアの状態を読み取れない、またはポリシーを変更できない
`dns.listen`	ローカルDNSサービスを提供する	ドメイン解決リクエストがClashのDNSモジュールに届かない

mixed-port はHTTPとSOCKS5のリクエストを同時に処理できます。mixedモードを使う場合、通常は port や socks-port に同じ値を設定する必要はありません。同じアドレス上で、同一の通信プロトコルとポートの組み合わせを複数の待受先が占有することはできません。

「サブスクリプション設定」と「クライアントの実行設定」は区別してください。デスクトップクライアントの中には、実行時に最終設定を生成し、画面で指定したポート、コントロールAPI、TUN設定をサブスクリプション内容へ統合するものがあります。この場合、サブスクリプションファイルを直接編集しても、更新やクライアントの再起動で上書きされる可能性があります。まずクライアントの一般設定、ポート設定、またはオーバーライド設定から変更してください。YAMLを直接読み込むことが確認できる場合に限り、該当項目を編集します。

3. Windows・macOS・Linuxで使用中のプロセスを特定する

Windows：PIDとプロセス名を確認する

ポート7890を例に、コマンドプロンプトで次を実行します。

netstat -ano | findstr :7890

結果の LISTENING は、プロセスがポートを待ち受けていることを示します。最後の列がPIDです。続けて、そのPIDに対応するプログラムを確認します。

tasklist /FI "PID eq 1234"

PowerShellでは、構造化されたコマンドも使用できます。

Get-NetTCPConnection -LocalPort 7890 -State Listen
Get-Process -Id 1234

コマンドで権限不足と表示された場合は、管理者権限のターミナルで再度確認してください。タスクマネージャーの「詳細」タブでもPIDからプロセスを検索できます。別のClashクライアントや古いコアが見つかった場合は、まず該当画面から正常に終了し、タスクトレイのプロセスも終了したことを確認してから、プロセスの強制終了を検討します。

macOS：lsofで待受プログラムを確認する

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

出力にはプロセス名、PID、ユーザー、待受アドレスが表示されます。DNSサービスを確認する場合は、ローカルDNSの待受がUDPとTCPの両方に関係する可能性があるため、UDPも検索してください。

sudo lsof -nP -iUDP:1053
sudo lsof -nP -iTCP:1053 -sTCP:LISTEN

Linux：ssまたはlsofを使う

sudo ss -lntp 'sport = :7890'
sudo lsof -nP -iTCP:7890 -sTCP:LISTEN

ss の -l は待受ソケットだけを表示し、-n はポートをサービス名へ変換しないようにします。-t はTCP、-p はプロセスの表示です。UDPの待受を確認する場合は、次を使用できます。

sudo ss -lnup 'sport = :1053'

4. 使用中のプロセスを終了するか、Clashのポートを変更するか

使用中のプロセスを特定したら、その用途に応じて対処します。以前のClashコアが残っている場合は、古いクライアントを正常終了するのが最適です。2つのクライアントを両方使う必要がある場合は、プロキシポート、コントロールポート、DNS待受ポートをそれぞれ別の値にする必要があります。mixed-portだけを変更して external-controller を同じままにすると、2つ目のコアが起動できないことがあります。

長時間動作する開発サービス、コンテナのポートマッピング、LANサービスがポートを使用している場合は、Clashのポートを変更するほうが安定します。新しいポートを選ぶ前に、システムコマンドで使用中でないことを確認してください。ポート番号は1～65535の範囲にし、HTTP、SOCKS、コントロールAPI、DNSサービスを同じアドレスとポートに重複設定しないようにします。

使用中のプロセスを終了したのに、ポート検索でまだ待受中と表示される場合は、次の可能性があります。

クライアント画面を閉じてもシステムトレイに残り、コアプロセスが終了していない。
サービスマネージャーがプロセスを自動再起動している。システムサービスやコンテナの再起動ポリシーが該当する。
複数のクライアントがインストールされ、そのうち1つがOS起動時に自動起動する設定になっている。
別のネットワークプロトコルを調べている。TCPだけを確認していて、実際の競合はUDPのDNS待受で発生している。
設定がIPv4とIPv6の両方で待受している。ログにある具体的なアドレスと照合して確認する必要がある。

プロセスの強制終了は、身元を確認した後の手段にしてください。Windowsではタスクマネージャーからタスクを終了し、macOSとLinuxではまず通常の終了シグナルを送り、状態を保存する時間を与えます。プロセスが繰り返し起動する場合は、PIDを何度も終了するのではなく、自動起動、バックグラウンドサービス、コンテナの再起動設定を無効にしてください。

5. mixed-port・HTTP・SOCKSの待受設定を変更する

統一されたプロキシ入口だけが必要な場合は、mixed-port を残し、重複するHTTPとSOCKSの個別待受項目を削除できます。次の例では、統一入口を7893に変更し、コントロールAPIを9091に設定しています。

mixed-port: 7893
external-controller: 127.0.0.1:9091
allow-lan: false
mode: rule

アプリごとにHTTPとSOCKS5を使い分ける場合は、異なる2つのポートを設定します。

port: 7893
socks-port: 7894
external-controller: 127.0.0.1:9091
allow-lan: false
mode: rule

mixed-port: 7893、port: 7893、socks-port: 7893 の組み合わせにはしないでください。一部のクライアントが設定生成時に一部の項目を無視するとしても、不明確な動作に依存すべきではありません。実際に有効にする各個別待受先には、明確で重複しないポートを割り当てます。

YAMLを変更するときは、インデントとデータ型も正しく保ってください。ポートは通常、整数で記述します。保存後はクライアントで設定を再読み込みするかコアを再起動し、新しいポートが待受状態になったことをログで確認します。クライアントに「混合ポート」「HTTPポート」「SOCKSポート」などの画面項目がある場合は、実行設定と画面表示が食い違わないよう、画面から変更するのが安全です。

ポート変更後にシステムプロキシも更新する

コアが新しいポートで正常に待受を開始しても、アプリが自動的にそのポートへ切り替わるとは限りません。システムプロキシが古い 127.0.0.1:7890 を参照したままの場合があります。クライアントでシステムプロキシをいったん無効にしてから再有効化すると、現在のポートが再設定されることが多いです。ブラウザー、コマンドラインツール、ダウンロードツール、開発環境で手動プロキシを使っている場合も、それぞれ更新してください。

たとえば、アプリが以前HTTPプロキシ 127.0.0.1:7890 を使っていて、新しいmixed-portが7893の場合は、127.0.0.1:7893 に変更します。SOCKS5を使うアプリもmixed-portへ接続できますが、アプリ側のプロキシ種類はSOCKS5に設定する必要があります。ポートだけ変更してプロトコルを間違えると、接続失敗や認証形式エラーが発生することがあります。

6. TUNモード・DNS待受・LANアドレスに関する特殊なケース

TUNモードは仮想ネットワークインターフェースを通じて通信を取り込みます。そのため、アプリがmixed-portへ直接接続しない場合もあります。ただし、設定でmixed、HTTP、SOCKS、コントロールAPIのいずれかを有効にしていれば、コアは起動時に対応する待受先を作成しようとします。TUNが有効だからといって、通常のプロキシポート競合を無視できるわけではありません。

TUNを確認するときは、まずエラーがどの段階で発生したかを見ます。ログが 127.0.0.1:7890 や 0.0.0.0:9090 のバインド失敗を明確に示している場合は、ポート競合として対処します。仮想ネットワークアダプター、ルーティングテーブル、権限、ファイアウォールが示されている場合は、TUN環境を確認してください。両方の問題が同時に起きることもあるため、ログに従って1つずつ解決します。

DNSモジュールも、見落としやすい競合原因です。設定例には次のような項目が含まれることがあります。

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

1053がローカルDNSフォワーダーに使用されている場合、ClashのDNSサービスは起動に失敗します。TCPとUDPの両方について使用状況を検索し、Clashの dns.listen を変更するか、別のサービスを変更するか判断してください。DNS待受ポートを変更した後は、OS、ルーティングスクリプト、ほかの転送プログラムがまだ古いポートへリクエストを送っていないかも確認します。

LANアクセスを有効にすると、待受範囲がループバックアドレスからネットワークインターフェースへ広がることがあります。あるプログラムが 127.0.0.1:7890 だけを待ち受け、別のプログラムが 0.0.0.0:7890 で待ち受けようとする場合も、後者がすべてのIPv4インターフェースを対象にするため競合する可能性があります。判断するときはポート番号だけでなく、アドレスも必ず確認してください。

7. ポート修正が完了したか確認する

修正後は決まった順番で確認し、システムプロキシの残存設定、設定の切り替え漏れ、ノード障害をポート問題と取り違えないようにします。

コアを再起動し、ログに bind や address already in use が表示されなくなったことを確認します。
netstat、Get-NetTCPConnection、lsof、または ss で新しいポートを確認し、待受プロセスが現在のClashコアであることを確かめます。
クライアントで現在のProfileが選択され、ルールモード、グローバルモード、ダイレクトモードがテスト目的に合っていることを確認します。
システムプロキシを再有効化し、プロキシアドレスと変更後のポートが一致していることを確認します。
コントロール画面でノード、プロキシグループ、接続情報を読み取れるか確認し、コントロールポートの競合が残っていないことを確認します。
ブラウザー、または指定したプロキシを使うコマンドラインリクエストでテストし、接続ログに該当リクエストが表示されるか確認します。
TUNを使っている場合は、仮想ネットワークアダプター、DNS解決、ルーティングも追加で確認します。

ポートが待受状態なのにWebページへアクセスできない場合、問題は通常「待受競合」以外の層へ移っています。設定が正常に読み込まれたか、ノードが利用可能か、ルールが正しいプロキシグループへ通信を渡しているか、DNSが有効な結果を返しているか、アプリが実際に新しいプロキシアドレスを使っているかを確認してください。ポートの待受成功はローカル入口が確立したことを示すだけで、上流のプロキシ経路が利用できることを保証するものではありません。

一時的に判断しやすいテスト用モードへ切り替え、接続ログにリクエストが表示されるか確認する方法もあります。テスト後は通常のルールモードへ戻してください。新しい接続がまったく表示されない場合は、システムプロキシとアプリのプロキシ設定を重点的に確認します。接続は表示されるものの失敗する場合は、ノード、DNS、ルール、ネットワーク接続を確認します。

8. ポート使用中に関するよくある質問

7890が使用中の場合、任意の番号に変更できますか？

1～65535の範囲で、まだ使われていないポートを選べます。ただし、システムサービスや既存アプリが使うポートは避けてください。変更前に待受状況を確認し、変更後はシステムプロキシ、ブラウザー、その他の手動プロキシ設定も更新します。

Clashのウィンドウを閉じてもポートが使用中なのはなぜですか？

一部のデスクトップクライアントは、ウィンドウを閉じてもトレイで動作を続け、コアプロセスも残ります。トレイメニューから完全に終了し、PIDを検索してプロセスが終了したことを確認してください。プロセスが自動的に復活する場合は、自動起動やバックグラウンドサービスも確認します。

mixed-portとsocks-portに同じポートを使えますか？

この設定は避けてください。mixed-port自体がHTTPとSOCKS5のリクエストを受け付けます。独立したsocks-portも必要な場合は、別のポートを割り当ててください。そうしないと、2つの待受先が同じアドレスとポートを奪い合います。

ポート変更後、Clashは動作中なのにシステムがネットワークへ接続できない場合は？

まずシステムプロキシが古いポートを参照していないか確認します。クライアントのシステムプロキシをいったん無効にしてから再有効化し、現在のProfile、動作モード、接続ログを確認してください。固定プロキシアドレスを使うアプリも個別に変更する必要があります。

9090の競合はプロキシ通信に影響しますか？

9090は外部コントロールAPIによく使われます。競合するとコアを起動できない、またはクライアント画面がコアへ接続できず、プロキシグループや接続記録を読み取れないことがあります。mixed-portに競合がなくても、コントロールAPIには独立した利用可能なポートを割り当ててください。

TUNモードを使う場合もmixed-portは必要ですか？

利用方法によって異なります。TUNはシステム通信を取り込めますが、ブラウザーのデバッグ、コマンドラインツール、ほかのデバイスでは明示的なプロキシ入口が必要になることがあります。mixed-portを残す場合は、正常に待受できなければなりません。不要であれば、クライアントが対応する設定から無効にしてください。

ポート競合の判断基準は明確です。ある待受アドレスとポートをプロセスがすでに使用しており、Clashが同じ組み合わせへバインドしようとしている状態です。ログを記録し、PIDを検索し、プロセスの用途を確認し、設定を変更してシステムプロキシも同期すれば、問題を具体的な箇所に切り分けられます。対処後にProfile、ルール、DNS、TUNを確認すれば、その後のネットワーク障害をポートの問題と誤認せずに済みます。