Clash 起動時のポート競合エラー対処法:占有プロセスの特定と mixed-port の変更

「ポートが使用中」と表示される原因

Clash のコア起動時には、いくつかのポートをローカルで待ち受ける必要があります。混合ポート(mixed-port、デフォルトは 7890 が一般的)は HTTP と SOCKS5 の両方のリクエストを処理し、外部コントローラー(external-controller、デフォルトは 9090 が一般的)はパネルが状態を読み取るために使われ、クライアントによっては HTTP 専用のポートを別途開くものもあります。これらのポートがシステム上の別のプロセスに占有されていると、コアは bind というシステムコールを完了できず、ログには address already in use や bind: アクセスが拒否されました のような表示が出ます。クライアント側では、コアの起動失敗、プロキシスイッチがオンにならない、あるいは起動数秒後に自動で「未起動」状態に戻るといった症状として現れます。

この種の競合を引き起こす典型的な原因は 3 つあります。1 つ目はパソコンに複数のプロキシツール(例えば Clash と別の V2Ray クライアント)を同時に入れている場合、2 つ目は前回の Clash プロセスが正常終了せず、残ったプロセスがポートを握ったままになっている場合、3 つ目はごく一部のシステムサービスやルーター用ソフトが近いポート帯を使っている場合です。切り分けの流れはシンプルで、まずどのプロセスがそのポートを占有しているかを確認し、その上でプロセスを終了するかポートを変更するかを決めます。

手順1:競合しているポート番号を確認する

クライアントのログやバックグラウンドウィンドウには、通常問題のポート番号が表示されます。まずは以下の代表的なデフォルト値を確認しておきましょう。

ログにポート番号が直接出ていない場合は、上表を順に確認していきましょう。まず 7890 を最優先で調べてください。多くのクライアントがデフォルトで使う混合ポートで、最も競合が起きやすい番号です。

Windows:占有プロセスを特定して終了する

コマンドプロンプトまたは PowerShell を開き、netstat にポート番号を渡してリスニング状態を確認します。

netstat -ano | findstr "7890"

出力の最後の列が PID(プロセス番号)です。これを使ってプロセス名を逆引きします。

tasklist | findstr "PID番号"

無関係なプロセスによる占有だと確認できたら、そのプロセスを直接終了できます。

taskkill /PID PID番号 /F

逆引きしたプロセス名が Clash 関連(clash-verge.exe や mihomo.exe など)だった場合は、前回終了しきれずに残ったプロセスです。それを終了してクライアントを再起動すれば、ポート変更は不要です。

macOS:lsof コマンド1つでプロセスを特定する

macOS では lsof が最も手軽です。ポート番号で直接フィルタできます。

lsof -i :7890

出力の COMMAND 列が占有中のプログラム名、PID 列がプロセス番号です。終了させる場合は次のコマンドを使います。

kill -9 PID番号

占有しているのがシステムサービスや、パケットキャプチャツール・開発環境のローカルプロキシなど停止しにくいプログラムの場合は、他のソフトに手を加えるより Clash 側のポートを変更する方が安全です。

Linux:ss / lsof / fuser のいずれかを使う

Linux ではss(旧来の netstat より高速)がおすすめです。コマンドは以下の通りです。

ss -tulnp | grep 7890

ss が入っていない場合は lsof でも構いません。使い方は macOS と同じです。

lsof -i :7890

あるいは fuser で直接特定・終了することもできます。

fuser -k 7890/tcp

systemd で mihomo コアを常駐運用している場合は、自分で mihomo サービスを二重起動していないかも確認しましょう。1つは自動起動、もう1つを手動で起動していて、互いにポートを奪い合っているというのはよくある自作トラブルです。

対処法1:設定ファイルを直接編集する

他のプログラムに手を加えたくない場合は、Clash 側のポートをずらすのが手軽です。設定ファイル(通常 config.yaml)内のポート関連項目を、使われていない番号に変更します。

mixed-port: 7891
external-controller: 127.0.0.1:9091
allow-lan: false

1024~65535 の範囲内で、現在使われていない値であれば任意の番号を選べます。元の値に 1 や 100 を足すと覚えやすくおすすめです。編集後は保存して設定を再読み込みするか、クライアントを再起動すれば反映されます。

対処法2:クライアントの画面上で変更する

主要な GUI クライアント(Clash Verge Rev、Clash for Windows 系の派生版、ClashX Meta など)には、いずれもポート設定画面が用意されています。「設定」や「一般」のセクションに混合ポートやコントロールポートの入力欄があるので、新しい番号を入力して保存するだけです。クライアントが自動で内部の設定を書き換えてコアを再起動してくれるので、yaml ファイルを直接編集する必要はありません。変更後は、システムプロキシの設定やブラウザ拡張機能に入力しているポート番号も忘れずに揃えてください。この3箇所が一致していないことが、「設定は変えたのに反映されていないように見える」原因として最も多いです。

変更後の動作確認方法

先ほどの確認コマンドをもう一度実行し、新しいポートが今度は Clash 自身によって使われていることを確認します(別のプロセスとまた競合していないかも要チェックです)。

lsof -i :7891

コマンドの出力に表示されるプロセス名が clash や mihomo 関連であることを確認したら、実際にブラウザでいくつかのサイトを開いて接続を試すか、パネルでトラフィックの波形が動いているかを見て、プロキシ経路が通っているか確認します。外部コントローラーのポートも変更した場合は、パネルのアドレスバーに入力するポート番号も一緒に更新してください。忘れると「接続できません」と表示されます。

次回また競合させないための2つの習慣

• 現在使っているプロキシクライアントだけをスタートアップ(自動起動)リストに残し、使っていない古いクライアントはアンインストールまたは終了しておきましょう。バックグラウンドに残ったプロセスがポートを奪い合う確率を減らせます。
• 比較検証のために2つのプロキシツールを長期的に同時稼働させる必要がある場合は、事前にどちらか一方のポート番号をずらして固定しておき、メモに残しておくと、毎回勘で対処する必要がなくなります。

ポート競合は本質的にはリソースの奪い合いによる問題で、設定ミスやサブスクリプション失効とは別種のトラブルです。切り分ける際は混同しないようにしましょう。まずログのエラー表示を確認し、次にどのプロセスがポートを占有しているかを調べ、最後にプロセスを終了するかポートを変更するかを決める。この3ステップでたいてい解決します。