Clashのポート競合を解消する方法：7890の使用プロセス特定とmixed-portの変更

まずログを確認：リッスン競合かどうかを見極める

対処は、エラーが出たポートを確認し、リッスン中のプロセスを特定して、停止するかポートを変更するかを決め、最後に接続元の設定を更新する順で進めます。7890はClashの設定でよく使われるプロキシポートですが、必須の固定値ではありません。空いている7893に変更すれば競合を解消できますが、クライアントに新しい設定を適用し、ブラウザー・システムプロキシ・ターミナルも新しいポートに切り替える必要があります。

クライアントのログ画面でbind、listen、address already in useを探します。エラーメッセージの全文はカーネルやOSによって異なるため、記載されているアドレス・ポート・プロトコルを確認してください。たとえば、次のログはTCPの7890番ポートでリッスンできなかったことを示しています。プロキシサーバーが利用できるかどうかまでは判断できません。

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

• 127.0.0.1:7890：ローカルループバックアドレスの7890番ポートでリッスンします。
• 0.0.0.0:7890：すべてのIPv4インターフェースでリッスンしようとします。すでにループバックアドレスでリッスンしている場合、競合することがあります。
• [::]:7890：IPv6のワイルドカードアドレスです。IPv4にも影響するかどうかは、OSやソケットの設定によって異なります。
• connection refused：接続先がリッスンしていないか、接続を明示的に拒否した状態を示すことが多く、ポート競合とは異なります。

mixed-portとコントロールポートを区別する

Clashクライアントは管理画面で、実際のリッスン処理は通常カーネルプロセスが担います。Clash Meta（現mihomo）を使うクライアントも同じ仕組みです。画面上の「ポート」は複数の接続先を指す場合があるため、ログに記載された番号を手がかりに調べてください。7890という数字だけを見て、すべての項目を一律に変更しないようにしましょう。

たとえば、mixed-port: 7890はHTTPとSOCKS5の両方から利用できるため、portとsocks-portも7890に設定する必要はありません。独立したリッスン項目に同じアドレスとポートを設定すると、設定内で競合する場合があります。混合ポートだけでよい場合は、クライアントが対応していることを確認したうえで、混合ポートを残し、使わない個別の接続先を削除できます。

external-controller: 127.0.0.1:9090は別のサービスです。システムプロキシに9090を設定してはいけません。また、ここを変更しても7890のプロキシリッスンエラーは解消しません。コントロールポートは管理権限に関わるため、ローカルへのバインドと既存の認証設定を維持し、競合調査のために安易にLANへ公開しないでください。

Windows：netstatでプロセスを特定する

手順1：リッスン状態とPIDを確認

PowerShellまたはコマンドプロンプトを開き、次のコマンドを実行します。1つ目は7890を含む行を抽出し、2つ目はPowerShellでローカルのリッスンポートを正確に検索します。

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

powershell -NoProfile -Command "Get-NetTCPConnection -LocalPort 7890 -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess"

netstatの出力では、まず「ローカル アドレス」のポートが7890であることを確認し、状態がLISTENINGの行を探します。数字を含む行をそのまま見ると、リモート側のポートや17890を誤って対象にすることがあります。最後の列がPIDです。たとえばPIDが6240と表示されたら、次のコマンドでプロセス名を確認します。

tasklist /FI "PID eq 6240"

6240はコマンドの例です。実際に調べた結果のPIDに置き換えてください。実行ファイルのパスや起動引数も確認する場合は、PowerShellでさらに調べられます。他のユーザーのプロセス情報を取得するには、管理者権限が必要なことがあります。

Get-CimInstance Win32_Process -Filter "ProcessId = 6240" |
  Select-Object ProcessId, Name, ExecutablePath, CommandLine

手順2：プロセスの種類に応じて対処する

• 別のプロキシクライアント：通知領域のメニューから終了し、バックグラウンドのカーネルも停止したことを確認してから、使用するクライアントを起動します。
• 同じクライアントの残存カーネル：まずクライアントを通常の手順で終了し、ポートを再確認します。プロセスのパスと所属を確かめてから、タスクマネージャーで残存プロセスを終了してください。
• 停止できないローカルサービス：無理に終了せず、空いていることを確認した別のプロキシポートを使います。
• 不明なプロセスやシステムサービス：パスとサービスの提供元を確認してください。PIDだけを根拠に強制終了コマンドを実行しないでください。

リッスン記録がないのに「アクセス許可で禁じられた方法でソケットにアクセスしようとしました」と表示される場合は、ポートの予約とアクセス権限の問題を切り分けてください。netsh interface ipv4 show excludedportrange protocol=tcpを実行すると、TCPの除外範囲を確認できます。候補のポートが範囲内にある場合は、範囲外の空きポートに変更してください。システムの予約項目を安易に削除しないでください。

macOS・Linux：lsofやssで確認する

macOS：TCPのリッスン状態だけを確認

ターミナルを開き、次のコマンドを実行します。-nPはアドレスとポートを数字で表示し、-sTCP:LISTENはリッスン状態の項目だけを表示するため、通常の接続を除外できます。他のユーザーのプロセスを確認する場合に限り、sudoを使ってください。

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

出力のCOMMAND、PID、NAMEを確認します。占有しているのが別のクライアントなら、まずメニューバーから終了してください。終了後すぐに再び表示される場合は、ログイン時の自動起動、バックグラウンドサービス、自動再起動の設定を確認します。

Linux：TCPとUDPを分けて確認

sudo ss -ltnp 'sport = :7890'
sudo ss -lunp 'sport = :7890'

# lsofがインストールされている場合はTCPのリッスン状態も確認できます
sudo lsof -nP -iTCP:7890 -sTCP:LISTEN

ssでは、-tがTCP、-uがUDP、-pがプロセス情報を表示します。TCPとUDPではポートが別々に管理されるため、UDPの7890が使用中でも、それだけでTCPのバインド失敗の原因とは判断できません。ログに記載されたプロトコルに合わせて確認してください。

mihomoがsystemdで管理されている場合、デスクトップのウィンドウを閉じてもサービスは停止しないことがあります。サービスユニット名が実際にmihomo.serviceであれば、systemctl status mihomo.serviceで状態を確認し、停止が必要と判断した場合にsudo systemctl stop mihomo.serviceを実行できます。ユニット名が異なる場合は、導入時の名前を確認してください。名前を誤ると、カーネルが停止したと勘違いするおそれがあります。

mixed-portを7893に変更する

まず、前述の検索コマンドで7890を7893に置き換え、変更先のポートが競合していないことを確認します。7893がすべての環境で使えるとは限りません。ここでは設定例として使用しています。ポートを変更する際は、未適用のYAMLファイルを編集するだけでなく、クライアントが実際に読み込む設定を変更してください。

1. クライアントの現在の設定または実行時設定から、「混合ポート」「Mixed Port」「mixed-port」を探します。メニュー名はクライアントによって異なるため、実際の設定項目を確認してください。
2. YAMLで管理している場合は、トップレベルの項目を変更します。インデントにはスペースを使い、proxiesやproxy-groupsの中にポートを記述しないでください。
3. クライアントに別のポート上書き設定がないか確認します。サブスクリプション設定、オーバーライド設定、実行時設定が組み合わさって最終的な値が決まることがあります。
4. 設定を保存して適用します。クライアントからカーネルの再起動を求められた場合は、再起動後にログとリッスン状態を確認してください。

以下はポート関連の設定例であり、サブスクリプション設定全体ではありません。個別のSOCKS接続先が必要なアプリがある場合は、異なるポートを指定できます。

# 既存設定のトップレベルに追加し、他のプロキシ・グループ・ルールはそのまま残す
mixed-port: 7893
socks-port: 7894
allow-lan: false

# コントロールAPIとプロキシの接続先を分け、既存の認証設定は変更しない
external-controller: 127.0.0.1:9090

混合ポートだけを使う場合、例に合わせてsocks-portを追加する必要はありません。元の設定でport: 7890も有効になっていると、mixed-portだけを変更しても独立したHTTP接続先でエラーが続く場合があります。すべてのリッスン項目を個別に確認してください。

システムプロキシ・ブラウザー・ターミナルの設定も更新

ポート変更後によくあるのは、カーネルは7893でリッスンしているのに、アプリが引き続き7890へ接続するケースです。この場合、サブスクリプションを再読み込みしても解決しません。通信の接続元を確認してください。

システムプロキシをクライアントが自動管理している場合は、新しいポートを適用した後、クライアントの「システムプロキシ」設定を一度オフにしてからオンにし、システム設定を確認してください。PACで自動設定している環境では、PACが返すプロキシアドレスを確認します。手動プロキシの設定欄を変更しても、PAC経由の通信には反映されないことがあります。

ターミナルの環境変数設定例

macOSまたはLinuxの現在のシェルでは、HTTPプロキシを次のように設定できます。https_proxyにもhttp://を指定します。これはHTTPプロキシのCONNECTメソッドでHTTPSサイトに接続するという意味で、接続先の通信が平文になるわけではありません。

export http_proxy=http://127.0.0.1:7893
export https_proxy=http://127.0.0.1:7893

# SOCKS5が必要で、ツールが対応している場合は個別に設定：
export all_proxy=socks5h://127.0.0.1:7893

これらのコマンドが反映されるのは、現在のシェルと、その後に起動した子プロセスだけです。すでに起動しているアプリの設定は自動更新されません。HTTPとSOCKSの環境変数を両方設定した場合、どちらが優先されるかはツールによって異なります。切り分け時はプロキシを明示的に指定し、複数の設定が干渉しないようにしてください。HTTP_PROXYやHTTPS_PROXYなどの大文字の変数と、シェルの起動ファイルに残った古い値も確認します。

TUNモードが処理するのは別の通信経路であり、ローカルプロキシのバインド競合が自動的に解消されるわけではありません。アプリがTUN経由で正常に通信できても、7890のリッスンに失敗することがあります。逆に、明示プロキシの設定が誤っていると、通常の転送経路に到達する前に接続が失敗することもあります。両方を分けて確認してください。

修正を確認：リッスン・リクエスト・再起動

1. リッスン状態を確認：7893を再度調べ、PIDが想定したカーネルプロセスのものか確認します。ログに該当する接続先のバインドエラーが出ていないことも確認してください。
2. プロキシリクエストを確認：まずシステムプロキシやブラウザーの設定に頼らず、プロキシを明示するオプションでリクエストを送信します。
3. 普段使うアプリを確認：ブラウザーや実際に使うツールを起動し、古いポートが設定されたままになっていないか確認します。
4. 設定の保持を確認：クライアントを再起動してサブスクリプションを一度更新し、ポート設定が上書きされないこと、別のクライアントが先に自動起動しないことを確認します。

次のコマンドは新しい混合ポートを使ってHTTPプロキシ経由のリクエストを送信します。Windowsではcurl.exeを使うと、一部のPowerShell環境にある同名コマンドのエイリアスによる違いを避けられます。

# macOS / Linux
curl --noproxy "" --proxy http://127.0.0.1:7893 --connect-timeout 5 --max-time 15 -I https://clash03.com/

# Windows
curl.exe --noproxy "" --proxy http://127.0.0.1:7893 --connect-timeout 5 --max-time 15 -I https://clash03.com/

HTTPレスポンスが返れば、今回のリクエストに応答があったことは確認できますが、必ず遠隔のプロキシノードを経由したとは限りません。ルールモードでは、接続先がDIRECTルールに一致する場合があります。Failed to connectが表示されたら、まずローカルのリッスン状態とポートを確認します。ローカルプロキシが接続を受け付けた後に上流のタイムアウトやTLSエラーが発生する場合は、ノード・DNS・ルール・ネットワーク環境を確認してください。むやみにローカルポートを変更し続けないようにしましょう。

よくある追加の問題

• 終了後もポートが使用中：バックグラウンドサービス、別ユーザーのセッション、クライアントの残存カーネルを確認します。
• 変更直後に元の値へ戻る：ポートの上書き機能とサブスクリプションの更新動作を確認し、現在有効な設定を編集しているか確かめます。
• ポートが空いていても起動できない：アクセス権限、システムの除外ポート、無効なバインドアドレス、YAMLの構文エラーを切り分け、最新のログを確認してください。
• 管理画面はオフラインだがWeb閲覧はできる：コントロールAPIのアドレス・ポート・認証設定を個別に確認します。プロキシの接続先を管理画面のAPIとして使わないでください。

調査が終わったら、普段使うプロキシクライアントだけを自動起動するようにし、「混合ポート7893、独立SOCKSポートの有効・無効、コントロールポート9090」など、実際の設定を記録しておくと便利です。再び競合が起きた際は、クライアントの再インストールを繰り返すより、リッスン中のプロセスから確認するほうが原因を特定しやすくなります。各項目の詳しい説明は設定リファレンス、インストールと初期設定の手順はクイックスタートをご覧ください。