Clashのポート7890が使用中？競合プロセスの特定とmixed-port変更手順

まず競合しているリスニングポートを確認する

Clash、Clash Meta（mihomo）および各種GUIクライアントの起動時には、ローカル環境に1つ以上のリスニングポートが必要です。よくあるエラーには address already in use、bind: Only one usage of each socket address、listen tcp 127.0.0.1:7890: bind、クライアント画面の「ポートが使用中です」などがあります。これはOSが新しいリスニング要求を拒否したことを示すもので、設定ファイル全体が壊れているとは限りません。

7890はClash設定でよく使われるプロキシポートであり、固定値ではありません。mixed-port: 7890を使うと、同じポートでHTTPとSOCKS5プロキシ接続を受け付けられます。古い設定ではport: 7890とsocks-port: 7891を分けて使う場合があります。mihomoの設定には、透過プロキシ、DNS、コントロールインターフェース用の別ポートが含まれることもあるため、調査前にエラー行全体を確認してください。

よく使われるポートと用途

設定項目	よくある値	用途	競合時の症状
`mixed-port`	`7890`	HTTPとSOCKS5の混合プロキシ	システムプロキシや手動プロキシで接続できない
`port`	`7890`	HTTPプロキシ	ブラウザーのHTTPプロキシが機能しない
`socks-port`	`7891`	SOCKS5プロキシ	SOCKS5を使うアプリが接続できない
`external-controller`	`127.0.0.1:9090`	ダッシュボードとクライアントのコントロールインターフェース	カーネルは動作していてもダッシュボードが切断状態になる
`dns.listen`	`0.0.0.0:1053`	ローカルDNSサービス	DNSモジュールの起動失敗または名前解決異常

Windowsで7890を使用しているプロセスを特定する

現在のClashクライアントを完全に終了してから、もう一度起動します。それでもエラーが出る場合は、バックグラウンドに別のカーネルプロセスが残っているか、別のプロキシソフトがそのポートを使用している可能性があります。ウィンドウを閉じるだけでは不十分です。多くのクライアントは閉じるボタンで通知領域に最小化され、カーネルがバックグラウンドで待ち受け続けます。

方法1：netstatとtasklistを使う

通常権限で「ターミナル」または「コマンドプロンプト」を開き、次を実行します。

netstat -ano | findstr :7890

代表的な結果は次のとおりです。

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    18432

最後の列にある18432はプロセスPIDです。状態がLISTENINGの記録だけが、ポートが待ち受け中であることを直接示します。TIME_WAITが大量に表示されても、通常はリスニングの競合を意味しないため、それを根拠にプロセスを終了しないでください。続けてPIDに対応するプログラムを確認します。

tasklist /FI "PID eq 18432"

結果がmihomo.exe、clash.exe、またはクライアントに付属するカーネルファイルなら、前回の終了時に残ったインスタンスである可能性が高いです。別のプロキシツールが表示された場合は、まずそのツールでサービスを停止するかアプリを終了してから、Clashのポートを変更するか判断します。

方法2：PowerShellを使う

PowerShellでは、待ち受けエンドポイントとプロセス名を直接確認できます。

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

Get-Process -Id 18432

1つ目のコマンドで権限不足と表示された場合は、管理者としてWindowsターミナルを開いて再実行してください。「タスクマネージャー」→「詳細」でもPID順に並べ、プロセスのパスと起動時刻を確認できます。パスが現在のクライアントディレクトリにあり、起動時刻が今回の操作より明らかに前なら、残ったカーネルである可能性が高いです。

残ったインスタンスを安全に停止する

まず通知領域のメニューから「終了」を選び、クライアントにカーネル、システムプロキシ、サービスをまとめて停止させます。画面を操作できない場合は、次を使用します。

taskkill /PID 18432 /T

通常の終了に失敗し、PIDが正しいことを確認できた場合は、強制オプションを追加します。

taskkill /PID 18432 /T /F

macOSとLinuxでポート使用状況を確認する

macOSでlsofを使う

「ターミナル」を開き、TCP 7890を待ち受けているプログラムを確認します。

lsof -nP -iTCP:7890 -sTCP:LISTEN

出力のCOMMANDはプロセス名、PIDはプロセス番号、NAMEは待ち受けアドレスを示します。何も表示されない場合は、エラーログが実際には7891、9090、1053を指していないか確認してください。待ち受け状態の条件を外し、ポートに関連するすべての接続を確認することもできます。

lsof -nP -i :7890

mihomoまたはClashカーネルの残存プロセスだと確認できたら、まず通常の方法で終了します。

kill 18432

約2秒待ってから、もう一度lsofを実行します。プロセスが残っている場合は、GUIクライアントやバックグラウンドサービスが自動的に再起動していないか確認してください。kill -9を直接実行しても現在のインスタンスを終了できるだけで、デーモンが繰り返し起動する問題は解決しません。

Linuxでssまたはlsofを使う

多くの最新ディストリビューションにはssが標準でインストールされています。

sudo ss -ltnp 'sport = :7890'

次のコマンドも使用できます。

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

mihomoがsystemdで動作している場合は、カーネルプロセスだけを終了しないでください。systemdがサービス設定に従って再起動します。まずサービスの状態を確認し、対応するユニットを停止します。

sudo systemctl status mihomo
sudo systemctl stop mihomo

サービス名はインストール方法によって異なり、必ずしもmihomoとは限りません。systemctl list-units --type=service | grep -Ei 'clash|mihomo'を実行して探せます。コンテナ環境ではDockerのポートマッピングも確認してください。ホスト側の127.0.0.1:7890をコンテナ内のカーネルではなく、コンテナのプロキシプロセスが保持している場合があります。

プロセスを終了するかmixed-portを変更するか判断する

使用中のプログラムを特定しても、すぐにポートを変更しないでください。まず、両方のプログラムを継続して動かす必要があるか判断します。使用中のプロセスが同じクライアントの異常終了で残ったカーネルなら、残存インスタンスを終了して再起動するだけで解決します。2つのプロキシツールを同時に使う必要がある場合や、7890をローカル開発サービスが固定で使用している場合は、どちらか一方に新しいポートを割り当てます。

古いプロセスを終了するのが適切なケース

使用中のプロセスが、現在のクライアントと同じカーネルファイルおよび設定ディレクトリを使っている。
タスクマネージャーまたはアクティビティモニタに、mihomoやClashカーネルのインスタンスが2つ表示される。
古いクライアントをアンインストールしたのに、スタートアップ項目、サービス、スケジュールタスクが残っている。
ポート解放後に必要なプロキシクライアントが1つだけである。

ポートを変更するのが適切なケース

7890を、常時稼働させる必要がある別のプロキシやデバッグツールが使用している。
安定版設定とテスト設定を同時に動かす必要があり、2つのカーネルを分離する必要がある。
集中管理された環境で、アプリケーションに固定のポート範囲が割り当てられている。
現在の設定を他のデバイスとも共有しており、使用中のプログラムを停止すると既存の作業に影響する。

新しいポートには、7893、17890、27890など、待ち受けていないローカルポートを選びます。変更前に同じ確認コマンドで候補値を調べてください。ポート範囲は1から65535です。一般的なデスクトップ設定では、1から1023までの代表的なシステムサービス用ポートを避け、設定内のコントロールインターフェース、DNSの待ち受け、透過プロキシ用ポートとも重複させないでください。

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

YAMLを直接編集する場合は、トップレベルのmixed-portを探します。次の設定では、混合プロキシを7890から7893に変更しています。

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

mixed-portは設定のトップレベルに置く必要があり、proxies、proxy-groups、dnsの下にインデントしてはいけません。コロンの後には半角スペースを1つ入れ、ポートは整数で記述します。保存後はカーネルに設定全体を再読み込みさせる必要があります。プロキシグループを切り替えるだけでは、リスニングポートは作り直されません。

重複するリスニング設定を残さない

設定ですでに混合ポートを使っている場合、HTTPとSOCKSに同じ値を個別設定する必要は通常ありません。次の記述では、複数のリスナーが7893を取り合うことになります。

mixed-port: 7893
port: 7893
socks-port: 7893

どちらか一つの方式を選択してください。入口を1つにする場合は、次だけを残します。

mixed-port: 7893

HTTPとSOCKS5を分けて提供する必要がある場合は、異なるポートを使い、mixed-portを削除します。

port: 7893
socks-port: 7894

GUIクライアントでポートを変更する

クライアントによってメニュー名は異なりますが、一般的には「設定」→「詳細設定」→「ポート」、または「設定」→「カーネル設定」→「混合ポート」から開きます。7890を確認済みの空きポート7893に変更し、保存後に「カーネルを再起動」するか、クライアントを完全に終了して再起動します。

画面によってはHTTP、SOCKS、Mixedの3項目が同時に表示されます。Mixedを有効にした場合は、混合ポートを主な入口として使います。クライアントでHTTPやSOCKSの個別リスナーを無効にできるなら、使っていない入口を無効にして設定の重複を減らしてください。ポートが読み取り専用で変更できない場合は、現在の設定ファイルまたは上書きルールによって値が管理されていることが多いため、設定管理画面に戻って変更します。

システムプロキシも更新する

ポートを変更しても、システムプロキシが古い127.0.0.1:7890を参照したままの場合があります。この状態ではカーネルは正常に起動していても、ブラウザーは接続できません。クライアントの「システムプロキシ」スイッチをいったんオフにしてからオンにすると、新しいポートが反映されることが多いです。OS側で手動確認することもできます。

Windows：「設定」→「ネットワークとインターネット」→「プロキシ」を開き、アドレスが127.0.0.1、ポートが7893になっているか確認します。
macOS：「システム設定」→「ネットワーク」→現在のネットワーク→「詳細」→「プロキシ」を開き、Webプロキシと保護されたWebプロキシのポートを確認します。
ブラウザー拡張機能、開発ツール、コマンドラインプログラムが個別にプロキシアドレスを設定している場合は、7890も7893に変更してください。

コマンドラインの環境変数にも古い値が残っている可能性があります。新しい混合ポートを使う例は次のとおりです。

http_proxy=http://127.0.0.1:7893
https_proxy=http://127.0.0.1:7893
all_proxy=socks5://127.0.0.1:7893

環境変数の設定構文はOSとシェルによって異なります。重要なのはクライアント画面のポート番号だけでなく、すべての利用元を確認することです。

TUNモードでもリスニングの競合に対処する必要がある

TUNモードは仮想ネットワークインターフェースでシステム通信を受け取りますが、だからといってmixed-portの競合を無視できるわけではありません。設定にmixed-port: 7890がある限り、通常はカーネルがそのリスナーを作成しようとします。ポートのバインドに失敗すると、カーネルの起動が中断されたり、一部の明示的なプロキシ機能が使えなくなったりします。

TUNだけに依存する場合は、クライアントとカーネルの設定に応じて不要な明示的プロキシリスナーを削除できます。ただし、GUIクライアント、ブラウザー拡張機能、LAN内のデバイスがmixed-portに依存している場合があります。変更前に手動プロキシの利用有無を確認してください。TUNの自動ルーティング、厳格ルーティング、DNSハイジャックは別の設定であり、7890を変更することで正しいTUN設定の代わりにはできません。

allow-lan: trueを有効にすると、クライアントが0.0.0.0:7893で待ち受け、LAN内のデバイスからアクセスできる場合があります。ローカルだけで使う場合はallow-lan: falseを維持するか、ループバックインターフェースに待ち受けアドレスを制限してください。LANアクセスを許可するかどうかにかかわらず、同じアドレスファミリー内ではポートを一意にする必要があります。

新しいポートが実際に有効か確認する

手順1：待ち受け状態を確認する

カーネルを再起動した後、新しいポートをもう一度確認します。Windowsでは次を使います。

netstat -ano | findstr :7893

macOSでは次を使います。

lsof -nP -iTCP:7893 -sTCP:LISTEN

Linuxでは次を使います。

ss -ltnp 'sport = :7893'

mihomoまたはClashカーネルがLISTEN状態になり、古いポート7890がそのインスタンスに使用されていなければ期待どおりです。

手順2：プロキシ入口を直接テストする

curlがインストールされていれば、システムプロキシ設定を介さず新しいポートを直接指定できます。

curl -I -x http://127.0.0.1:7893 https://example.com

HTTPレスポンスヘッダーが返れば、ローカルプロキシ入口がリクエストを受け付けています。Connection refusedと表示される場合は、新しいポートで待ち受けていないか、アドレスが誤っています。接続できてもリクエストがタイムアウトする場合は、ポートを変え続けるのではなく、ノードの可用性、プロキシグループの選択、DNS、ルールを確認してください。

手順3：クライアントログを確認する

「ログ」画面でerror、listen、bindなどのキーワードを絞り込みます。正常起動後は7890や7893のバインドエラーが再び出ないはずです。エラーが127.0.0.1:9090に変わった場合、mixed-portの問題は解決していますが、コントロールインターフェースが別のインスタンスと競合しています。同じ方法でexternal-controllerを確認してください。

7890の競合が繰り返し発生するときのチェックリスト

クライアントのウィンドウを閉じた後、通知領域、メニューバー、タスクマネージャーにカーネルプロセスが残っていないか確認します。
ClashまたはmihomoのGUIクライアントを2つインストールしていないか、両方がスタートアップに登録されていないか確認します。
Windowsでは「タスクマネージャー」→「スタートアップアプリ」とサービス一覧、Linuxではsystemd、macOSではログイン項目とバックグラウンド項目を確認します。
サブスクリプション更新後も、実行用設定のmixed-portが7893から7890に戻っていないことを確認します。
システムプロキシ、ブラウザー拡張機能、ターミナルの環境変数、LAN内のデバイスが現在のポートを使っていることを確認します。
9090、1053、7891など他のリスニングポートも確認し、1つのポートを直した後に別の競合で止まらないようにします。
mixedは7893、コントロールインターフェースは9093、DNSは1053のように、明確なポート設計を1つ決め、複数インスタンスで使い回さないようにします。

ポート使用の問題は、まずログから正確なポートを読み取り、次にシステムツールでPIDを特定し、使用中のプロセスを残す必要があるか判断してから、残ったプロセスを終了するか設定を変更する、という順番で対応します。mixed-portを変更した後は、システムプロキシとすべての手動プロキシ利用元も更新してください。YAMLだけを変更して利用側のポートを更新しないと、「起動失敗」が「カーネルは正常だがアプリがネットワークに接続できない」状態に変わり、後の調査が難しくなります。