Clashの7890番ポートが使用中：占有プロセスの特定とmixed-portの変更方法
システムコマンドで7890などのポートを使用中のプロセスを特定し、プロセス終了とポート変更の判断方法、mixed-port変更後にシステムプロキシやブラウザーの設定を合わせる方法を解説します。
まず確認：リスニングに失敗しているのか、プロキシの接続先が間違っているのか
次の順に確認します：占有プロセスを特定 → 古いプロセスを終了するかポートを変更 → プロキシ設定を更新 → リスニングとリクエストを確認。Webページが開かないからといって、すぐにクライアントを再インストールする必要はありません。ポート競合はローカルでのリスニング時に発生するため、通常、サブスクリプションの期限切れやノードの遅延とは直接関係ありません。
7890はよく使われる設定値ですが、Clashやmihomoで必須のポートではありません。クライアントでは、現在有効なフィールドに応じてHTTPプロキシ用または混合ポート用に設定できます。まずクライアントのログを開き、listen、bind、ポート番号を含むエラーを探してください。
listen tcp 127.0.0.1:7890: bind: address already in use上記は典型的なエラー例で、該当アドレスのTCPポートを再度バインドできないことを示しています。Windowsでは「通常、各ソケット アドレスに対して、プロトコル、ネットワーク アドレス、またはポートの組み合わせは 1 つしか使用できません」と表示される場合もあります。ログにpermission deniedや「アクセスが拒否されました」とある場合は、ポートの予約やシステムポリシーなどの制限も確認してください。別のプロセスによる占有と決めつけることはできません。
- ログにバインド失敗が明記されている：まず以下のシステムコマンドを実行して、リスニング中のプロセスを特定します。
- カーネルは正常にリスニングしているのに、ブラウザーでプロキシ接続エラーが表示される：ブラウザーやシステムプロキシの接続先が古いポートのままになっていないか、優先して確認します。
- 一部のWebサイトだけ開けない：ルール、DNS、ノードを引き続き確認してください。ローカルポートを何度も変更する必要はありません。
Windows：PIDから7890番ポートを使用中のプログラムを特定する
方法1：PowerShellでリスニングポートを正確に検索
Windows 10またはWindows 11でPowerShellを開き、次のコマンドを実行します。結果が空の場合、今回の検索では該当するTCPポートのリスニングプロセスは見つかりませんでした。アクセス許可が不足している場合は、管理者としてターミナルを開いて再試行してください。
Get-NetTCPConnection -LocalPort 7890 -State Listen -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, OwningProcessOwningProcess列のプロセスIDを控えます。結果が6420だった場合は、続けてプロセス名、パス、起動コマンドを確認します。この数値は説明用です。実際の操作では、必ず自分の環境で確認したPIDを使ってください。
Get-Process -Id 6420 | Select-Object Id, ProcessName, Path
Get-CimInstance Win32_Process -Filter "ProcessId = 6420" |
Select-Object ExecutablePath, CommandLine名前にClashが含まれているかどうかだけで判断しないでください。デスクトップ画面とカーネルが別々のプロセスで動いていることはよくあります。同じmihomo.exeでも、トレイアプリ、Windowsサービス、手動コマンドからそれぞれ起動されている場合があります。実行ファイルのパスと起動引数を確認すると、どのインストール環境のプロセスか判断しやすくなります。
方法2：コマンドプロンプトで検索
netstat -ano -p tcp | findstr ":7890"
tasklist /FI "PID eq 6420"netstatの結果は手動で確認してください。「ローカル アドレス」列のポートが7890と完全一致し、状態がLISTENINGの行を探します。リモートアドレスに7890が含まれている場合、状態がESTABLISHEDの場合、ローカルポートが78901の場合は、いずれも該当するリスニングとは異なります。
macOSとLinux：リスニングプロセスとバックグラウンドサービスを確認
macOS：lsofでTCPリスニングを確認
「ターミナル」を開き、7890番ポートをリスニングしているプログラムを検索します。一般ユーザー権限では情報が不足する場合は、sudoを付けて再実行してください。
sudo lsof -nP -iTCP:7890 -sTCP:LISTEN結果のCOMMANDはプログラム名、PIDはプロセスID、NAMEはリスニングアドレスです。トレイアプリを終了した後、もう一度実行してください。引き続きリスニングしている場合は、カーネルが独立して起動しているか、バックグラウンドサービスとして動作している可能性があります。直前の終了操作が無効だったとは限りません。
Linux：ssでポートとプロセスを確認
sudo ss -ltnp 'sport = :7890'-lはリスニングソケットのみ、-tはTCPのみを表示し、-nはポート番号を数値で表示、-pは関連するプロセスを表示します。UDPを確認する場合は、別途次のコマンドを実行してください。TCPとUDPは異なるトランスポートプロトコルです。UDPの検索結果だけから、TCPポートも使用中だと判断することはできません。
sudo ss -lunp 'sport = :7890'プログラムを終了してもすぐに再び起動する場合は、systemd、ユーザーサービス、その他のプロセス管理ツールによる自動起動を確認してください。まず該当するサービスユニットを特定してから、そのサービスを停止します。強制終了を繰り返すのは避けてください。コンテナ環境では、ホスト側のポートマッピングも確認します。コンテナごとに内部の7890番ポートをリスニングすることはできますが、同じホストアドレスの7890番ポートを複数のコンテナに同時に割り当てることはできません。
古いプロセスを終了するか、mixed-portを7891に変更するか
判断基準は、ポートを使用中のプロセスを引き続き動かす必要があるかです。「先に起動したほうが正しい」とは限りません。古いクライアントを重複して起動しているだけなら、まずトレイメニューから正常に終了してください。別のプロキシや開発用サービスを動かし続ける必要がある場合は、現在のClashのポートを変更します。
| 確認できた状況 | 推奨する操作 | 注意点 |
|---|---|---|
| 古いクライアントが重複して起動 | 古いクライアントを正常に終了 | スタートアップ設定の重複を確認 |
| 画面を閉じてもサービスが動作中 | 確認後、該当するクライアントまたはサービス管理ツールから停止 | サービスがカーネルを自動再起動する場合がある |
| 別の必要なプログラムが7890番ポートをリスニング | 現在のmixed-portを7891に変更 | 先に7891番ポートが空いているか確認 |
| リスニングプロセスが見つからないのにアクセス拒否が表示される | ポート予約とアクセス許可の制限を確認 | システムの予約項目をむやみに削除しない |
プロセスの正体を確認し、必要な作業を保存してから終了を検討してください。まずプログラム自体の終了機能を使います。コマンドラインから起動したカーネルは、該当するターミナルでCtrl + Cを押して終了できます。Windowsのtaskkill /PID 6420 /Fは強制終了コマンドです。通常の終了に失敗した場合の手段として使い、例示のPIDをそのままコピーしないでください。
Windowsでリスニングプロセスが見つからないのにアクセス許可エラーが続く場合は、TCPの除外ポート範囲を確認できます。仮想化やコンテナ関連のコンポーネントが使用可能なポートに影響することがあります。予約済みのポートが見つかった場合は、システムの予約範囲を変更するより、空いているポートを使うほうが安全です。
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcpmixed-portを変更する：正しいフィールドを編集し、設定を保持する
mixed-portでは、同じリスニングポートでHTTPプロキシとSOCKSプロキシの接続を受け付けます。サブスクリプションのURLでも、ノードサーバーのポートでも、コントロールパネルのAPIポートでもありません。現在portまたはsocks-portを個別に使用している場合、mixed-portだけを変更しても、従来の接続先が変わらないことがあります。
まず7891番ポートが空いていることを確認し、現在の設定をバックアップします。以下は設定ファイルのトップレベルに追加できる断片であり、ノードやルールを含む完全なサブスクリプション設定ではありません。ローカルでのみ使用するプロキシなら、アクセス範囲はローカルのままにしてください。
config.yaml：トップレベルのリスニング設定
mixed-port: 7891
allow-lan: false
bind-address: 127.0.0.1- トップレベルのインデントを維持：
mixed-portをdns:、tun:、ノード定義の中に入れないでください。 - 既存のキーを置き換える：ファイル末尾に同じフィールドを追加しないでください。キーが重複すると、解析エラーや動作の不整合が発生することがあります。
- 個別のポート設定を確認：
port: 7890が残っていると、従来のHTTPリスニングで競合が続く可能性があります。必要に応じて、既存のリスニング設定を変更または削除してください。 - コントロールポートと区別する：
external-controllerはクライアントやパネルからカーネルを操作するための設定です。ブラウザー用のHTTPプロキシ接続先としては使えません。
保存しても7890に戻るのはなぜ？
GUIクライアントでは、グローバルポート設定、設定の上書き、複数設定の統合などによって最終的なYAMLが生成される場合があります。サブスクリプションファイルに加えたローカル変更も、次回の更新で上書きされることがあります。そのため、クライアントに用意された、設定が保持されるポート設定または上書き機能を優先してください。メニュー名はクライアントのバージョンによって異なります。特定のクライアントの設定手順を、すべてのClashクライアントに当てはめないでください。
変更後、クライアントの設定リロードまたはカーネル再起動を実行し、新しいリスニングアドレスがログに記録されているか確認します。画面の入力欄に7891と表示されていても、設定が保存されたことを示すだけで、カーネルのバインド成功までは確認できません。各フィールドの詳しい意味はYAMLガイドを参照してください。
システムプロキシ、ブラウザー、ターミナルに残る古いポートを更新
ポートを7890から7891に変更しても、新しい接続先を受け付けるのはカーネルだけです。外部のアプリケーションの設定がすべて自動で切り替わるわけではありません。よくあるのは、カーネルは正常に起動しているのに、Windowsのシステムプロキシが127.0.0.1:7890のままになっているケースです。その場合、システムプロキシを使うブラウザーは接続エラーになります。
システムとブラウザーの設定確認場所
- Windows 11：「設定」→「ネットワークとインターネット」→「プロキシ」→「プロキシ サーバーを使う」→「セットアップ」を開き、アドレスとポートを確認します。クライアントがシステムプロキシを管理している場合は、クライアントの「システムプロキシ」をいったんオフにしてからオンにし、ここで反映された設定を確認してください。
- macOS：「システム設定」→「ネットワーク」→現在のネットワーク接続の「詳細」→「プロキシ」を開き、有効になっているWebプロキシ、安全なWebプロキシ、SOCKSプロキシをそれぞれ確認します。ポートは実際のリスニング先と一致させてください。
- Firefox：「設定」→「一般」→「ネットワーク設定」→「設定」を開きます。「システムのプロキシー設定を利用する」を選ぶとシステム設定に従います。「手動でプロキシーを設定する」を選んでいる場合は、ポートを個別に変更してください。
- Chromium系ブラウザー：通常はシステムプロキシを使用しますが、起動オプションやプロキシ拡張機能で上書きされることがあります。特定のブラウザーだけで問題が起きる場合は、こうした個別設定を確認してください。
自動プロキシ設定スクリプト（PAC）を使っている場合は、スクリプトが返すPROXY 127.0.0.1:7890が古い値のままになっていないか確認してください。HTTPプロキシでもHTTPSサイトへのCONNECTトンネルを利用できます。接続先がHTTPSサイトだからといって、ローカルプロキシのアドレスをhttps://127.0.0.1:7891に変更しないでください。
ターミナルの環境変数も別途更新
ターミナルのプログラムは、デスクトップのシステムプロキシではなく、HTTP_PROXY、HTTPS_PROXY、ALL_PROXYを参照することがあります。PowerShellの現在のセッションでHTTPプロキシの接続先を更新するには、次のようにします。
$env:HTTP_PROXY = "http://127.0.0.1:7891"
$env:HTTPS_PROXY = "http://127.0.0.1:7891"macOSまたはLinuxの一般的なシェルでは、次のように設定できます。大文字・小文字の異なるプロキシ変数やALL_PROXY、各ツール独自の設定も使っていた場合は、7890が残っていないか確認してください。設定の優先順位はプログラムによって異なります。
export http_proxy=http://127.0.0.1:7891
export https_proxy=http://127.0.0.1:7891最後に、リスニング・リクエスト・再起動後の3点を確認
- 新しいリスニング先を確認：前述のコマンドで7890を7891に置き換え、リスニングしているプロセスが現在のクライアントか確認します。古いポートでもリスニングが続いている場合は、そのプログラムを残す予定か判断してください。
- プロキシを明示してリクエストを実行：ブラウザーのキャッシュされたページだけで判断せず、次のコマンドで新しい接続先に接続できることを確認します。
- 設定の保持を確認：クライアントを正常に終了して再起動し、ポートをもう一度確認します。サブスクリプションの更新後にも確認し、保持用の上書き設定が消えていないことを確かめてください。
Windowsではcurl.exeを使うと、一部のPowerShell環境で発生するcurlのエイリアスとの違いを避けられます。macOSとLinuxではcurlをそのまま使えます。
curl.exe --noproxy "" --proxy http://127.0.0.1:7891 --connect-timeout 5 --max-time 15 -I https://example.comcurl --noproxy "" --proxy http://127.0.0.1:7891 --connect-timeout 5 --max-time 15 -I https://example.comここでの接続タイムアウト5秒、全体のタイムアウト15秒はテスト上限であり、速度を保証するものではありません。127.0.0.1:7891に接続できない場合は、リスニングと設定の反映状況を引き続き確認してください。プロキシトンネルの確立後にTLS、上流への接続、接続先サイトの応答でエラーが出た場合は、ノード、ルール、接続先サイトを中心に調べます。200 Connection establishedが表示されても、リクエスト全体の成功を意味するわけではありません。後続の出力も確認してください。
プロキシを明示したリクエストが成功したら、コマンドからプロキシ指定を外し、ブラウザーでシステムプロキシ経由の接続を確認します。ローカルの接続先ポートを変更しても、ルールモードの振り分け結果は変わらず、ノードが速くなることもありません。一連の確認によって「ローカルのポート競合は解消した」のか「別のネットワーク障害が残っている」のかを切り分けられ、問題を混同して何度も再インストールするのを防げます。その他の接続問題はトラブルシューティングをご覧ください。