Clashのポート競合を解決する方法：競合プロセスの特定と待受ポート変更の完全ガイド

まず競合している待受ポートを確認する

Clash、Clash Meta（mihomo）、またはGUIクライアントの起動に失敗したとき、ログには bind: address already in use、listen tcp 127.0.0.1:7890、Only one usage of each socket address is normally permitted などの重要なメッセージが表示されます。いずれも、カーネルがローカルポートで待ち受けようとしたものの、そのアドレスとポートの組み合わせを別のプロセスがすでに使用していることを示します。

7890と表示されたからといって、すぐに設定を変更してはいけません。完全なログを確認し、HTTP、SOCKS、混合プロキシ、コントローラー、DNSのどの待受に失敗したのかを特定します。ポートごとに役割が異なるため、変更後にクライアント側で更新すべき設定も変わります。

設定項目	代表的なポート	用途	競合時の直接的な影響
`port`	`7890`	HTTPプロキシの待受	ブラウザーやシステムのHTTPプロキシが接続できない
`socks-port`	`7891`	SOCKS5プロキシの待受	SOCKS5を使用するアプリが接続に失敗する
`mixed-port`	`7890`	同じポートでHTTPとSOCKS5を受け付ける	2種類のプロキシ入口が同時に使用できない
`external-controller`	`9090`	コントロールパネルやクライアントがカーネルAPIを呼び出す	画面にカーネル切断と表示されたり、プロキシグループを読み込めなかったりする
`dns.listen`	`1053`	ローカルDNSサービス	ドメイン解決モジュールの起動に失敗する
`redir-port`	`7892`	Linux透過プロキシのリダイレクト入口	ファイアウォールのリダイレクト経由の通信がカーネルに届かない
`tproxy-port`	`7893`	Linux TProxy透過プロキシ入口	透過プロキシのルール適用後に接続できない

ログに表示されたアドレスも確認する

127.0.0.1:7890：ローカルのIPv4ループバックアドレスのみで待ち受けるため、LAN内の端末から直接アクセスできません。
0.0.0.0:7890：すべてのIPv4ネットワークインターフェースで待ち受けます。通常、クライアントの「LAN内接続を許可」に関係します。
[::]:7890：IPv6のすべてのインターフェースで待ち受けます。一部のシステムでは、同じポートのIPv4待受にも影響することがあります。
127.0.0.1:9090：通常は外部コントローラー用で、ブラウザーに入力するプロキシポートではありません。

ポート番号が同じでも待受アドレスが異なれば、必ずしも競合するとは限りません。共存できるかどうかは、OS、IPv6デュアルスタックの挙動、プログラムの設定によって決まります。調査時は数字だけでなく、プロトコル、待受アドレス、ポート、プロセスIDを記録してください。

Windowsでnetstatを使ってポート使用中のプロセスを特定する

Windows 10とWindows 11では、標準搭載の netstat をそのまま使用できます。まずClashクライアントを完全に終了し、通常権限でPowerShellまたはコマンドプロンプトを開いて、7890番ポートの待受が残っているか確認します。

手順1：7890番ポートの待受記録を探す

netstat -ano | findstr :7890

出力は複数行になることがあります。状態が LISTENING のTCP記録を探してください。最後の列がPIDです。次の例ではPIDは14672です。

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    14672

findstr :7890 は、リモートの7890番ポートへ接続中の記録も拾うため、ポート番号だけを見てはいけません。7890が「ローカルアドレス」列にあり、状態が LISTENING であることを必ず確認します。

手順2：PIDからプログラムを特定する

tasklist /FI "PID eq 14672"

mihomo.exe、clash.exe、または別のプロキシクライアントのカーネルファイルが返る場合、通常は古いインスタンスが終了していません。開発サーバー、コンテナのポート転送ツール、その他のローカルネットワークプログラムが返った場合は、どのプログラムのポートを変更するのが適切か判断します。

「タスクマネージャー」→「詳細」を開き、PID列をクリックして並べ替え、14672を探す方法もあります。PIDが表示されていない場合は、見出しを右クリックして「列の選択」→「PID（プロセス識別子）」を選びます。

手順3：PowerShellでTCPとUDPを分けて確認する

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

Get-Process -Id 14672

DNS、TProxy、一部の転送入口ではUDPを使用することもあります。UDPエンドポイントを確認するには、次を実行します。

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

UDPには LISTENING 状態がないため、TCPと同じ条件で絞り込むことはできません。Clashのログに listen udp と明記されている場合は、Get-NetUDPEndpoint または netstat -ano -p udp を使用します。

手順4：まず通常終了し、強制終了は避ける

使用中のプロセスが別のプロキシクライアントなら、トレイメニューから終了します。
Windowsサービスとして動作している場合は、services.msc を開き、該当するサービスを停止します。
ダウンロード、コンテナ転送、開発作業などを担っていないことを確認してから、プロセスの終了を検討してください。
netstat -ano | findstr :7890 をもう一度実行し、待受記録が消えたことを確認します。

プロセスを強制終了して解除できるのは、その時点の占有だけです。自動起動、サービスの自動復旧、クラッシュ後の再起動が設定されている場合、数秒後にポートが再び使用されます。その場合は起動項目を変更するか、どちらか一方に固定の新しいポートを割り当ててください。

macOSとLinuxでlsof、ssを使って競合を探す

macOSでは標準搭載の lsof で待受プロセスを確認できます。ClashのGUIクライアントを終了してから「ターミナル」を開き、次のコマンドを実行します。

lsof -nP -iTCP:7890 -sTCP:LISTEN

-nP はアドレスとポートを数値のまま表示し、ホスト名の名前解決による遅延を防ぎます。出力の COMMAND はプログラム名、PID はプロセスIDです。完全な起動引数を確認する場合は、続けて次を実行します。

ps -p 14672 -o pid,ppid,user,command

UDPの待受は次のコマンドで確認できます。

lsof -nP -iUDP:1053

古いカーネルがクライアントから起動されている場合は、まずmacOSのメニューバーからクライアントを終了します。kill 14672 を直接実行すると、クライアントの監視処理がカーネルをすぐ再起動することがあり、PIDだけが変わって7890番ポートは使われ続ける状態になります。

Linuxではssを優先する

最新のLinuxディストリビューションには通常 ss がプリインストールされています。次のコマンドで7890番ポートを待ち受けるTCPプロセスを表示できます。

sudo ss -ltnp 'sport = :7890'

DNSの待受やその他のUDPポートを確認するには、次を実行します。

sudo ss -lunp 'sport = :1053'

mihomoをsystemdで管理している場合は、サービスの状態も確認します。サービス名はインストール方法によって異なりますが、よく使うコマンドは次のとおりです。

systemctl --type=service | grep -Ei 'clash|mihomo'
sudo systemctl status mihomo

重複サービスだと確認できたら、該当するサービス名で古いインスタンスを停止し、自動起動を無効にするか判断します。用途が分からないままサービスファイルを削除しないでください。TUNの権限、ルート初期化、ファイアウォールの後処理などがサービス設定に含まれている場合があります。

mixed-port、port、コントローラーのポートを変更する

競合しているプログラムを元のポートで使い続ける必要がある場合は、Clashに未使用のポートを割り当てます。1024以上で、現在待受記録のないポートを選ぶのがおすすめです。たとえば7890を17890に変更します。ポート番号の範囲は1～65535ですが、macOSとLinuxでは1024未満のポートに通常追加権限が必要なため、一般的なデスクトップクライアントのプロキシ入口には適しません。

mixed-portだけを使用する設定

mixed-port を使うと、同じポートでHTTPプロキシとSOCKS5プロキシを受け付けられます。ローカルの入口を1つにしたいデスクトップ環境では、次のように設定すると簡単です。

mixed-port: 17890
allow-lan: false
bind-address: 127.0.0.1
external-controller: 127.0.0.1:19090

変更後は、システムプロキシのHTTPとHTTPSのアドレスをどちらも 127.0.0.1:17890 にします。SOCKS5を使うアプリも 127.0.0.1:17890 を入力しますが、プロトコルはSOCKS5を選択してください。

HTTPとSOCKS5を分けて待ち受ける

port: 17890
socks-port: 17891
allow-lan: false
external-controller: 127.0.0.1:19090

この設定は、プロトコルを明確に分けたい環境に適しています。ブラウザーの手動プロキシやシステムHTTPプロキシには17890、SOCKS5に対応するターミナルツールには17891を使用します。mixed-port と port を同じポートに設定しないでください。重複バインドにより、カーネルの起動に失敗します。

DNS待受ポートの変更方法

dns:
  enable: true
  listen: 127.0.0.1:11053
  enhanced-mode: fake-ip

DNSを1053から11053に変更したら、その待受アドレスを利用する転送側も合わせて変更します。たとえば、ローカルのdnsmasq、ルーティングルール、クライアントのDNSハイジャック設定が1053を指したままだと、ドメインリクエストは自動的に新しいポートへ転送されません。

GUIクライアントで変更する際は設定の取得元に注意する

クライアントによってメニュー名は異なります。よくある入口は「設定」→「パラメーター設定」→「ポート設定」、または「設定」→「Clash設定」→「混合ポート」です。保存後は設定画面を閉じるだけでなく、「カーネルを再起動」を実行してください。

ポートがサブスクリプション設定に含まれている場合、現在のYAMLを直接編集すると、サブスクリプション更新時に上書きされることがあります。より確実なのは、クライアントの上書き機能を使い、「設定」→「上書き」→「ポート」のようにして、ローカルのポート値を永続設定として保存する方法です。上書き機能がない場合は変更項目を記録し、更新後にポートが元に戻っていないか確認してください。

変更後にポート、システムプロキシ、実際の接続を確認する

設定の保存に成功しても、問題が解決したとは限りません。完全な確認は、古いポートの解放、新しいポートの待受開始、システムプロキシの更新、実際のプロキシリクエストの実行という4段階で行います。

1. 新しいポートが待受中であることを確認する

Windowsでは次を実行します。

netstat -ano | findstr :17890
Test-NetConnection 127.0.0.1 -Port 17890

Test-NetConnection の結果で、TcpTestSucceeded が True になっている必要があります。macOSまたはLinuxでは次を実行します。

lsof -nP -iTCP:17890 -sTCP:LISTEN

同時に7890番ポートも再確認してください。古いポートを別のプログラムが待ち受けていても、Clashに影響するとは限りません。ただし、最初の競合元が残っており、現在は新旧のプログラムが別々のポートで共存していることを確認できます。

2. システムプロキシが古いポートを指していないか確認する

Windows 11：「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシサーバーのポートを確認します。
macOS：「システム設定」→「ネットワーク」→現在のネットワーク→「詳細」→「プロキシ」を開き、WebプロキシとセキュアWebプロキシを確認します。
ブラウザー拡張機能：プロキシプロファイルのHTTP、HTTPS、SOCKS5ポートを確認します。
ターミナルの環境変数：HTTP_PROXY、HTTPS_PROXY、ALL_PROXY に7890が残っていないか確認します。

多くのClash GUIクライアントは「システムプロキシ」を有効にすると新しいポートを自動設定しますが、手動設定のブラウザー、開発ツール、コマンドライン環境は自動更新されません。ポート変更後に「クライアントは動作中なのにブラウザーだけ接続できない」場合、呼び出し側が古いポートへ接続していることがほとんどです。

3. curlで明示的なプロキシリクエストを送る

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

独立したSOCKS5ポート17891を使う場合は、次を実行します。

curl -I --socks5-hostname 127.0.0.1:17891 https://example.com

コマンドがHTTPレスポンスヘッダーを返せば、ローカルポートが接続を受け付け、プロキシプロトコルが一致し、リクエストが完了したことを確認できます。Connection refused が表示される場合は、新しいポートで待受が始まっていません。長時間タイムアウトする場合は、ノード、プロキシグループ、DNS、ネットワーク接続を確認してください。プロトコルエラーの場合は、HTTPクライアントをSOCKS5専用ポートへ接続している可能性があります。

4. カーネルログと接続一覧を確認する

クライアントの「ログ」画面を開き、レベルを info に設定します。テストリクエストを送ると、対象ドメイン、適用ルール、最終的なポリシーが表示されるはずです。たとえばドメインが DOMAIN-SUFFIX に一致し、特定のプロキシグループへ転送されます。続いて「接続」画面を開き、送信元アドレスが 127.0.0.1 であること、アップロードとダウンロードのバイト数が変化することを確認します。

ポート競合が繰り返し起きる場合の確認順序

ポートを変更してしばらくすると再び競合する場合、通常は自動起動または設定の上書きが原因です。何度もポートを変えるより、次の順番で確認したほうが根本原因を見つけやすくなります。

2つのClashクライアントが同時に自動起動していないか確認する。たとえば古いクライアントがログイン項目に残り、新しいクライアントも自動起動に設定されていると、両方が7890番ポートで待ち受けようとします。
GUIと独立したカーネルサービスが重複していないか確認する。GUIクライアントがすでにmihomoを管理している場合、systemd、launchd、Windowsサービスで同じ設定の別インスタンスを起動しないでください。
サブスクリプション更新後の上書き結果を確認する。更新前は17890だったのに、更新後に7890へ戻るなら、ローカルの変更が永続的な上書き設定に保存されていません。
external-controllerを確認する。プロキシポートは正常なのに画面で接続エラーが表示され続ける場合、競合しているのは7890ではなく9090かもしれません。
DNSのTCPとUDPを確認する。DNSサービスによっては両方のプロトコルで待ち受けるため、TCPだけを確認するとUDP 1053の使用中を見落とすことがあります。
「LAN内接続を許可」による待受範囲の変化を確認する。127.0.0.1 から 0.0.0.0 に切り替えると、より多くのインターフェースで待ち受けるため、既存サービスと競合する可能性があります。

長期運用しやすいポート構成例

サービス	ポート例	利用元
混合プロキシ	`17890`	システムプロキシ、ブラウザー、コマンドラインツール
外部コントローラー	`19090`	Clash GUIまたはWebコントロールパネル
ローカルDNS	`11053`	TUN DNSハイジャック、ローカル転送ツール
独立したSOCKS5	`17891`	個別のSOCKS5入口が必要なアプリ

ポート番号そのものは、ルールのマッチング、ノードの遅延、プロキシ速度に影響しません。重要なのは、各待受アドレスを想定したプロセスだけが使用し、システムプロキシ、ブラウザー、DNS転送ツール、コントロールパネルで同じ新しい設定を使うことです。変更後はポート構成を記録しておけば、クライアントのアップグレード、カーネルの切り替え、サブスクリプション更新時にもすぐ照合できます。