Clashのポート競合で起動できないときの対処法：使用中のプロセスを特定して混合ポートを変更

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

ClashやClash Meta（mihomo）のコアを起動すると、ローカルマシンで1つ以上のポートをリッスンする必要があります。一般的な設定では mixed-port に 7890 を指定し、同じポートでHTTPとSOCKS5のプロキシ接続を受け付けます。このポートを別のプロセスがすでにリッスンしていると、新しく起動したコアは再びバインドできません。クライアントが「起動中」のまま止まったり、コアの起動失敗と表示されたりする場合があります。

ログに次のようなメッセージが表示されたら、まずポートを確認しましょう。コアのバージョンやOSによって表現は多少異なりますが、通常は bind、address already in use、Only one usage、または具体的なポート番号が含まれます。

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

listen tcp 0.0.0.0:7890:
bind: Only one usage of each socket address is normally permitted

7890だけを確認してはいけません。設定には、HTTPポート、SOCKSポート、透過プロキシ用ポート、外部コントロール用ポートが個別に指定されている場合もあります。たとえば、port: 7890、socks-port: 7891、external-controller: 127.0.0.1:9090 を同時に使用する設定もあります。ログでバインドに失敗したアドレスを確認し、該当するポートを調べてください。

ポート競合と接続失敗は別の問題

ポート競合：コアを起動できず、ログにリッスンまたはバインドの失敗が表示されます。
ノードへの接続失敗：コアは起動していますが、プロキシノードがタイムアウトします。ログは通常、リモートアドレスを示します。
システムプロキシが更新されていない：コアは正常にリッスンしていますが、ブラウザが古いポートに接続し続けるため、Webページを開けません。
コントロールポートの競合：プロキシポートは利用できますが、GUIからコアに接続できません。external-controller の9090や、別途指定したコントロールポートが原因になることがあります。

まずクライアントのログで完全なエラーメッセージを確認し、該当するポートを調べてください。これにより、ノード障害をローカルポートの問題と誤認せずに済みます。YAMLのインデントやフィールド型など、設定の解析エラーが表示されている場合は、7890を変更しても起動失敗は解消しません。

Windows：netstatで使用中のプロセスを特定する

Windows 10とWindows 11には netstat が標準搭載されています。Clash Nyanpasuを完全に終了してから、通常権限で「ターミナル」または「コマンドプロンプト」を開き、次のコマンドを実行します。

netstat -ano | findstr :7890

ポートがリッスン中の場合、次のような結果が表示されます。最後の列にある 18432 はプロセスのPIDであり、ポート番号ではありません。

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    18432
TCP    [::1]:7890        [::]:0       LISTENING    18432

次に、確認したPIDを tasklist に渡してプロセス名を確認します。

tasklist /FI "PID eq 18432"

別のプロキシクライアント、古いClashコア、またはバックグラウンドで動作中のデスクトップクライアントが表示された場合は、まずそのプログラムの終了メニューから正常に終了してください。異常終了した残存プロセスであれば、名前とPIDを確認したうえで終了できます。

taskkill /PID 18432 /F

PowerShellで結果をわかりやすく確認する

PowerShellなら、そのリッスンポートを所有しているプロセスIDを直接取得できます。Windows 11の「ターミナル」は通常、PowerShellが既定のシェルです。

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

OwningProcess の値を取得したら、続けてプロセスを確認します。

Get-Process -Id 18432

Clashの設定でUDPリッスンも有効にしている場合、TCPの検索結果が空でも競合を完全には否定できません。UDPも追加で確認してください。

Get-NetUDPEndpoint -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

リッスンアドレスから影響範囲を判断する

リッスン結果	意味	確認するポイント
`127.0.0.1:7890`	ローカルIPv4ループバックアドレスのみ	ローカルのプロキシプログラムと古いコアを確認
`[::1]:7890`	ローカルIPv6ループバックアドレスのみ	同じプロセスがIPv4とIPv6の両方でリッスンしている可能性がある
`0.0.0.0:7890`	すべてのIPv4ネットワークインターフェースでリッスン	LANアクセスを有効にしたプロキシや開発ツールを確認
`[::]:7890`	すべてのIPv6ネットワークインターフェースでリッスン	デュアルスタックのリッスンとポート共有を確認

同じPIDが2行に表示されても、通常は2つの競合プログラムがあるという意味ではありません。そのプログラムがIPv4とIPv6で個別にリッスンしている可能性があります。確認すべきなのは、そのポートを所有するプロセスが今回起動するコアかどうか、そしてシステムに別のインスタンスが残っていないかです。

macOSとLinux：lsof、ssでポートを確認する

macOSでは「アプリケーション」→「ユーティリティ」→「ターミナル」から lsof を実行できます。次のコマンドはTCP 7890だけを確認し、リッスン状態に絞り込みます。

lsof -nP -iTCP:7890 -sTCP:LISTEN

出力の COMMAND はプロセス名、PID はプロセス番号です。例：

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
mihomo   4217 user   11u  IPv4  0x01      0t0  TCP 127.0.0.1:7890 (LISTEN)

まずメニューバーにClashクライアントが残っていないか確認します。すでにGUIから操作できない残存プロセスだと確認できたら、まず正常終了シグナルを送ります。

kill 4217

2秒待ってから lsof をもう一度実行します。プロセスが終了せず、身元を確認できている場合に限り、強制終了を検討してください。

kill -9 4217

Linuxではssを優先する

最新のLinuxディストリビューションの多くには ss が標準で用意されています。TCP 7890のリッスン中プロセスを確認するには、次を実行します。

sudo ss -lptn 'sport = :7890'

UDPを確認する場合は次を使用します。

sudo ss -lpun 'sport = :7890'

システムに lsof がインストールされている場合は、次のクロスプラットフォームな方法も使えます。

sudo lsof -nP -i :7890

Linuxではsystemdサービスにも注意が必要です。手動で起動したGUIクライアントを終了しても、システムサービスのmihomoがバックグラウンドでリッスンし続けることがあります。まずサービスの状態を確認し、停止するか判断してください。

systemctl status mihomo
sudo systemctl stop mihomo

サービス名はインストール方法によって異なり、clash や独自のユニット名の場合もあります。用途を確認せずに無効化しないでください。このサービスが普段使用しているプロキシコアなら、停止せずに残し、GUIクライアントには別のポートを使わせる方が適切です。

Clash Nyanpasuで混合ポートを変更する

7890を使用しているプログラムを動かし続ける必要がある場合は、Clash Nyanpasuに未使用の別ポートを割り当てます。一般的な操作手順は「設定」→「Clash設定」→「一般」→「混合ポート（Mixed Port）」です。項目名はバージョンによって異なりますが、コア設定またはClashパラメータの中から mixed-port を探してください。

まずnetstat、lsof、またはssで、使用予定の新しいポート（例：7893）が空いているか確認します。
混合ポートを 7890 から 7893 に変更します。
設定を保存し、コアを再起動するか、クライアントを完全に終了してから再度開きます。
ログに 127.0.0.1:7893 でリッスンしている記録があることを確認します。
システムプロキシをいったん再度有効にし、OSのプロキシアドレスを新しいポートに同期します。

1024より大きく、現在リッスンされていないポートを優先してください。ポート番号の上限は65535です。競合を避けるために80や443などの低いポートへ変更するのはやめましょう。追加の権限が必要になり、Webサービスとも競合しやすくなります。

ポートを変更してもWebページを開けない理由

ポート変更が成功したということは、コアがリッスンできるようになっただけです。ブラウザ、ターミナル、その他のアプリも新しいポートへ接続する必要があります。システムプロキシが 127.0.0.1:7890 のままなら、リクエストは古いアドレスへ送られ続けます。最も簡単な対処は「システムプロキシ」を一度オフにしてから再度オンにし、クライアントに 127.0.0.1:7893 を設定させることです。

ターミナルの環境変数は、システムプロキシに合わせて必ずしも自動更新されません。以前にプロキシを手動設定している場合は、次の値も変更してください。

export HTTP_PROXY=http://127.0.0.1:7893
export HTTPS_PROXY=http://127.0.0.1:7893
export ALL_PROXY=socks5://127.0.0.1:7893

混合ポートを使う場合、同じ7893でHTTPプロキシとSOCKS5プロキシの接続を受け付けられるため、上記の設定で共用できます。port と socks-port を分けている場合は、それぞれ対応するポートを入力し、すべてを7893に置き換えないでください。

設定ファイルのmixed-portを直接変更する

mihomoのコマンドライン版、コンテナ、または設定ファイルを自分で管理している場合は、YAMLを直接編集できます。最小限の記述は次のとおりです。

mixed-port: 7893
allow-lan: false
mode: rule
log-level: info

mixed-port はHTTPとSOCKS5で共用する受信ポートです。この項目を使用している場合、通常は同じ値の port と socks-port を同時に設定する必要はありません。重複または重なり合うリッスン設定は、再びバインドエラーを起こし、原因の切り分けも難しくします。

HTTPとSOCKS5のポートを分けて提供する必要がある場合は、異なる値を指定します。

port: 7893
socks-port: 7894
allow-lan: false
mode: rule
log-level: info

外部コントロールインターフェースにも専用のポートが必要です。例：

mixed-port: 7893
external-controller: 127.0.0.1:9091
secret: "change-this-controller-secret"

ここではプロキシの入口を7893、コントロールインターフェースを9091に設定しています。用途は異なり、7893はアプリのプロキシ通信を受け付け、9091はGUIや管理パネルからコアのAPIを呼び出すために使います。ログに9090の競合が明記されている場合、mixed-port だけを変更しても解決しません。external-controller を変更し、クライアントのコントローラー接続設定も更新してください。

変更後は設定を検証してからコアを再起動する

コマンドラインでmihomoを実行する場合は、まずコアに用意されている設定検証オプションを使えます。実行ファイル名はインストール方法によって異なります。

mihomo -t -f config.yaml

検証に通ったら、元の方法で起動します。それでも失敗する場合は完全なログを確認し、エラーに示されたポートが7893になっているか確認してください。ログが7890のままなら、編集した設定ファイルとは別のファイルで起動しているか、GUIクライアントが起動時に実行用設定を再生成している可能性があります。

ポート変更後も起動できない場合の5項目チェック

1. 新しいポートも使用中

7891や7892を感覚だけで選ばないでください。これらもプロキシツールでよく使われるポートです。変更前に確認コマンドを実行しましょう。Windowsでは netstat -ano | findstr :7893、macOSでは lsof -nP -iTCP:7893 -sTCP:LISTEN を実行します。出力がなければ通常、TCPをリッスンしているプロセスはありません。ただしUDPの受信を有効にしている場合は、UDPも確認してください。

2. クライアントが2つのコアを同時に起動している

自動起動、サービスモード、手動起動が重複し、複数のインスタンスが作られることがあります。まずクライアントを完全に終了し、7890、7893、コントロールポートがすべて解放されたことを確認してから、1回だけ起動してください。クライアント終了直後にポートが再び使用中になる場合は、システムのスタートアップ項目、タスクスケジューラ、ログイン項目、systemdサービスを確認します。

3. 設定のオーバーライドが反映されていない

サブスクリプションの mixed-port: 7890 がクライアントのグローバル設定で上書きされることもあれば、起動オプションが設定ファイルを上書きすることもあります。判断材料にするのはエディター上のYAMLだけではなく、実行ログと実際のリッスン結果です。起動後にもう一度ポートを確認し、コアが実際にどのアドレスでリッスンしているかを確かめてください。

4. 外部コントロールポートが競合している

プロキシポートが空いていても、すべてのリッスンを確立できるとは限りません。ログが 127.0.0.1:9090、9091、または別のコントロールポートを示していないか確認してください。コントロールポートを変更した場合は、GUIの接続先も更新する必要があります。そうしないとコアは動作していても、パネルには「未接続」と表示されます。

5. リッスンアドレスまたは権限が適切でない

allow-lan を有効にすると、設定が 0.0.0.0 または指定したLANアドレスでリッスンすることがあります。そのアドレスがすでに無効だと、ログに「cannot assign requested address」と表示される場合があります。これは通常のポート競合ではありません。有効なインターフェースに戻すか、127.0.0.1 のみでリッスンする設定にして再試行してください。1024未満のポートでは権限不足になることもあるため、より大きなポートを使いましょう。

7890の再発競合を防ぐ設定のコツ

自動起動の入口は1つだけにする：GUIクライアント、バックグラウンドサービス、タスクスケジューラで同時にコアを起動しないでください。
クライアントごとに別のポートを割り当てる：たとえばメインクライアントは7890、テスト用インスタンスは7893、コンテナのインスタンスは7895を使用します。
コントロールポートを記録する：プロキシポートと external-controller を分けて記録し、トラブル時はログに沿って1つずつ確認します。
終了後にトレイを確認する：ウィンドウを閉じただけではプロセスが終了しないことがあります。アップデートやクライアントの切り替え前には、完全終了を実行してください。
システムプロキシはクライアントに管理させる：混合ポートを変更したらシステムプロキシをいったん切り替え、古いポートの設定が残るのを防ぎます。
ローカルポートは永続化設定で管理する：サブスクリプションはノードとルールを担当し、ローカルのリッスンポートはクライアントのオーバーライドまたはグローバル設定で管理します。

同じデバイスで複数のmihomoインスタンスを同時に動かす場合は、各インスタンスに異なる混合ポート、コントロールポート、実行ディレクトリも割り当てる必要があります。7890だけを変更しても、すべてのリソースを分離できるとは限りません。キャッシュ、データベース、Unixソケット、名前付きパイプにも個別のパスが必要になる場合があり、詳細は起動方法とクライアントの実装によって異なります。

すぐに確認する手順

クライアントのログを開き、バインドに失敗した完全なアドレスとポートを控えます。
Clash Nyanpasuを完全に終了し、それに伴ってポートが解放されるか確認します。
WindowsではnetstatまたはPowerShell、macOSではlsof、Linuxではssを使ってPIDを確認します。
プロセス名を確認し、重複しているクライアントを正常終了するか、重複サービスを停止します。
使用中のプログラムを残す必要がある場合は、mixed-port を7893など、空いていることを確認済みのポートに変更します。
external-controller も同時に確認し、プロキシポートの競合だけを解決して終わらせないようにします。
コアを再起動し、ログとリッスン結果で新しい設定が反映されたことを確認します。
システムプロキシを再度有効にし、ターミナルの環境変数とポートを手動指定しているアプリも更新します。

ポートの使用中エラーの本質は、ローカルでリッスンするリソースの競合です。何度もクライアントを再インストールするのではなく、ログからポートを特定し、システムコマンドでPIDを調べて、使用中のプロセスを終了するか設定を変更するか判断することが重要です。変更後はシステムプロキシとターミナルの環境変数も忘れずに同期してください。コアが復旧しても、アプリが古いポートへ接続し続けることがあります。