Clashの7890番ポートが使用中：Windowsで使用プロセスを特定し、mixed-portを変更する方法

まずエラーを確認：ポート競合か、リッスン権限の問題か

Clashの画面が開いていても、プロキシのコアが正常にリッスンしているとは限りません。ログに listen tcp 127.0.0.1:7890: bind と表示され、「通常、各ソケットアドレスに対して使用できるのは1回だけです」または Only one usage of each socket address というエラーが出る場合、同じアドレスとポートを別のプロセスが使用している可能性があります。この場合、システムプロキシを何度切り替えてもポートは解放されません。

7890 はよく使われるローカルプロキシポートですが、すべてのクライアントで固定されているわけではありません。実際のポートは、有効な設定とコアのログで確認してください。HTTPポート、SOCKSポート、混合ポート、コントローラーのポートは用途が異なるため、番号が近いからといって置き換えないでください。

ログや症状	まず確認すること
アドレスは既に使用されています、Only one usage	リッスン中のプロセスを調べ、コアが二重起動していないか確認します。
アクセスが許可されていません、forbidden by its access permissions	Windowsの除外ポート範囲、システムポリシー、セキュリティソフトの制限を確認します。
コアは正常にリッスンしているのに、ブラウザーから接続できない	ブラウザーまたはシステムプロキシが古いポートを参照していないか確認します。
ログに9090など別のポートのエラーが出る	ログに記録された実際のポートを調べます。mixed-portだけを変更しないでください。

netstatで7890番ポートを使用中のプロセスを調べる

手順1：TCPのリッスン状態を確認する

Windows ターミナルでPowerShellまたはコマンドプロンプトを開き、次のコマンドを実行します。通常は標準権限で確認できます。権限エラーが出る場合は、管理者としてターミナルを開いてください。

netstat -ano -p tcp | findstr LISTENING | findstr ":7890 "

-a は接続とリッスン中のポート、-n はアドレスの数値表示、-o はPIDの表示を指定します。検索文字列では7890の後にスペースを入れ、78900など別のポートが一致しないようにしています。次は出力形式の例です。最後の列の 12480 は説明用の数字です。

  TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    12480

127.0.0.1:7890 はIPv4のループバックアドレスだけでリッスンしていることを示します。
0.0.0.0:7890 はすべてのローカルIPv4アドレスでリッスンしていることを示します。ループバックアドレスでのリッスンと競合する場合があります。
[::]:7890 はIPv6のワイルドカードアドレスでリッスンしている状態です。競合の有無は、実際のソケット設定を確認してください。
同じPIDが複数行に表示されても、複数のプログラムが動作しているとは限りません。同じプロセスが複数のアドレスでリッスンしている場合があります。

手順2：PIDからプロセスを特定する

Ctrl + Shift + Esc を押してタスクマネージャーを開き、「詳細」タブでPIDから該当プロセスを探します。PID列が表示されていない場合は、列見出しを右クリックして表示を有効にしてください。対象プロセスを右クリックし、「ファイルの場所を開く」を選んで、どのクライアントやサービスに属するか確認します。

tasklist /FI "PID eq 12480"

コマンドを実行するときは、例の数字を先ほど確認した実際のPIDに置き換えてください。よくある原因は、古いクライアントが通知領域に残っている、別のクライアントを起動している、またはサービスとして動作するコアが終了していないことです。プロセス名にClashやmihomoが含まれているだけで終了せず、先に実行ファイルのパスと所属クライアントを確認してください。

PowerShellで確認する方法

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

出力の OwningProcess がPIDです。リッスン中の記録が返らない場合は、その時点のログも確認してください。起動直後に終了したコアは、確認する前にポートを解放していることがあります。

競合を解消する：重複したクライアントを終了するか、空きポートに変更する

使用していない別のクライアントがポートを使用している場合は、まず通知領域のメニューから正常に終了してください。独立したサービスが有効になっていると、ウィンドウを閉じても画面が隠れるだけで、コアは停止しないことがあります。その場合はクライアントのサービス管理画面から該当サービスを停止し、ポートを再確認してください。

現在のシステムプロキシのアドレスとポートを控え、調査中はシステムプロキシを一時的にオフにします。これにより、アプリが使えないプロキシへ接続し続けるのを防げます。
重複しているクライアントを正常に終了します。必要に応じて services.msc で関連サービスを確認してください。
netstatを再実行し、古いリッスン状態が消えたことを確認します。
使用するクライアントを起動し、ログで7890番ポートのリッスンに成功したか確認します。

ポートを使用しているのが停止できないプログラムなら、無理に終了する必要はありません。Clashのポートを空きポートに変えるほうが簡単です。この記事では例として 7897 を使いますが、どのPCでも空いているとは限らないため、変更前に確認してください。

netstat -ano -p tcp | findstr LISTENING | findstr ":7897 "

mixed-portを変更する：ローカルプロキシの接続口を変更

mixed-port は、同じローカルポートでHTTPとSOCKSのプロキシ接続を受け付けます。ノードサーバーのポートでも、サブスクリプションURLのポートでもありません。設定内のプロキシノードにある port はリモート接続用の値であり、PC上の7890番ポートの競合解消には使えません。

クライアントが実際に使っている設定ファイルを確認する

ポート設定の場所や保存方法はクライアントによって異なります。設定画面で「ポート」「混合ポート」または mixed-port を探し、GUIで変更できる場合はそちらを使ってください。mihomoコアを使うクライアントでは、オーバーライド、設定のマージ、実行時の設定管理によってポートが決まることもあります。サブスクリプションのキャッシュファイルを直接編集すると、次回の更新で上書きされる場合があります。

YAMLを編集する場合は、まず元ファイルをバックアップし、有効な設定にある mixed-port の値を変更してください。以下は変更するフィールドだけを示した例です。完全な設定ファイルではないため、サブスクリプション全体を置き換える用途には使えません。

mixed-port: 7897

このフィールドはYAMLのトップレベルに記述し、proxies、proxy-groups、rules のリスト内には置かないでください。
最終的に使用する設定内で mixed-port キーを重複させないでください。
port: 7890 や socks-port: 7890 も有効になっている場合、旧ポートとの競合が続くことがあります。それぞれ独立したリッスン設定を確認してください。
external-controller はクライアントがコアを管理するためのコントロール用インターフェースです。ブラウザー用のプロキシポートとして使わないでください。

再読み込み後、リッスン状態で変更を確認する

保存後、クライアントの設定再読み込みまたはコア再起動機能を使ってください。ファイルを保存しただけでは、古いプロセスが元のポートを使い続けることがあります。続いてログを確認し、7897番ポートを再度調べます。対象コアのPIDがリッスン中であることを確認してください。画面には7897と表示されるのにログが7890のままなら、設定が上書きされていないか、変更したファイルが現在有効な設定かを確認してください。

Windowsのシステムプロキシとアプリごとのプロキシ設定を同期する

ポートを変更しても、すべてのクライアントでシステムプロキシが自動的に同期されるわけではありません。コアが7897番ポートでリッスンしていても、Windowsの設定が 127.0.0.1:7890 のままなら、ブラウザーでプロキシ接続エラーが発生することがあります。新しいポートでリッスンできたら、クライアントのシステムプロキシ機能を再度有効にし、Windowsに保存されたアドレスを確認してください。

Windows 11：「設定」→「ネットワークとインターネット」→「プロキシ」→「プロキシサーバーを使う」→「セットアップ」の順に開きます。
Windows 10：「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシの設定を確認します。
アドレスは 127.0.0.1、ポートは現在の混合ポートに合わせます。この例では 7897 です。プロキシスクリプトを使っている場合は、スクリプトが実際に返す接続先も確認してください。

Firefox、開発ツール、Git、ターミナルの環境変数には個別のプロキシ設定がある場合があり、Windowsの設定には連動しません。まずターミナルで現在のセッションのプロキシ変数を確認できます。

Get-ChildItem Env: | Where-Object Name -Match 'proxy'

結果が7890を指している場合は、該当するアプリまたは環境変数も変更してください。現在のPowerShellセッションだけ変更するには、次の2行を実行します。すでに開いている別のターミナルや、すべてのアプリの設定には反映されません。

$env:HTTP_PROXY = 'http://127.0.0.1:7897'
$env:HTTPS_PROXY = 'http://127.0.0.1:7897'

HTTPS_PROXY の http:// は、ローカルのHTTPプロキシ経由でトンネル接続することを示します。接続先のHTTPSサイトをHTTPにダウングレードする意味ではありません。調査中にWinHTTPのリセットコマンドを安易に実行しないでください。WinHTTPのプロキシと、ブラウザーが一般に使うWindowsユーザーのプロキシ設定は別の設定項目です。

ポートを使用中のプロセスが見つからないのにバインドできない

netstatで使用プロセスが見つからず、ログに「アクセスが許可されていません」と表示される場合は、管理者として開いたターミナルでWindowsのTCP除外ポート範囲を確認してください。Hyper-V、WSL、コンテナー、その他のネットワークコンポーネントが予約範囲に影響することがありますが、機能をインストールしたことだけを根拠に原因と決めつけないでください。

netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp

7890番または使用予定の7897番が、出力された開始ポートから終了ポートまでの範囲内に含まれるか確認します。該当する場合は、その範囲外で、かつリッスンされていないポートを選んでください。プロキシのポートを1つ空けるためにシステム予約範囲を直接削除しないでください。仮想ネットワークサービスに影響するおそれがあります。

ログに記録されたプロトコルとアドレスを確認する

この記事では主にTCPプロキシのリッスンを調べます。エラーにUDPと明記されている場合は、TCPの LISTENING だけでなく、該当するUDPエンドポイントを確認してください。UDPの出力には同じリッスン状態の列がありません。次のコマンドで確認できます。

netstat -ano -p udp | findstr ":7890 "

ログに、現在存在しないLANアドレスへのバインドが表示される場合は、bind-address も確認してください。PC内だけで使う場合、エラーを回避するためにLANからのアクセスを安易に許可しないでください。allow-lan を有効にするとアクセス可能な範囲が変わります。ローカルポートの競合解消とは別の設定です。

復旧を確認する：リッスン、入口、出口をそれぞれチェック

Webページが再び開けても、すべての設定が同期されたとは限りません。次の3段階で確認すると、ポート、プロキシルール、ノード接続のどこに問題があるかを切り分けやすくなります。

リッスンを確認：7897番ポートを調べ、PIDが対象クライアントのコアに属していること、ログにバインド失敗がないことを確認します。
入口を確認：プロキシを明示的に指定したリクエストでシステムプロキシ設定を介さず、ローカルの接続口をテストします。
出口を確認：クライアントの接続ログで、そのリクエストに適用されたルール、プロキシグループ、実際の接続先を調べ、意図した動作か確認します。

curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7897 https://www.microsoft.com/

上のコマンドはローカルのHTTPプロキシに明示的に接続します。すぐに 127.0.0.1:7897 に接続できないと表示された場合は、リッスン状態とポートを再確認してください。プロキシ接続は確立したのに接続先へのリクエストがタイムアウトする場合は、ノードの稼働状況、DNS、ルール、リモートネットワークを調べます。HTTPレスポンスが返っても、必ずプロキシノードを経由したとは限りません。Ruleモードでは接続先が直接接続されることもあるため、接続ログで確認してください。

最後にブラウザーとプロキシを使うアプリを開き直し、クライアントも再起動してポート設定が保持されることを確認します。再起動やサブスクリプション更新のたびに7890へ戻る場合は、一時ファイルを何度も手動編集するのではなく、クライアントの保存設定またはオーバーライド設定を修正してください。TUNモードはポートを解放する機能ではありません。一部の通信が仮想ネットワークアダプター経由になっていても、使えないローカルHTTPプロキシの接続口は別途修復が必要です。