まず待ち受けに失敗しているか確認し、ポート変更を判断する

Clashで7890ポートが使用中と表示されたら、まず待ち受けているプロセスを特定し、重複したインスタンスを終了するか、待ち受けポートを変更します。システムプロキシのポート番号だけ変えても、コアの実際の待ち受け先は変わりません。設定ファイルだけ変更してシステムプロキシを更新しない場合も、ブラウザーは古いポートに接続し続けます。

この記事では、ローカルプロキシのアドレス 127.0.0.1:7890 を起点に、変更例として 17890 を使用します。17890が必ず空いているとは限らないため、使用前に確認してください。Clash、Clash Meta（現mihomo）、各GUIクライアントでは既定のポートが異なる場合があります。現在有効な設定と起動ログを確認してください。

ログに出るエラーは種類ごとに対処する

ログや症状まず確認すること
address already in useすでに待ち受けているプロセス、重複起動したコア、または同じアドレスとポートを使う複数のインバウンド設定。
Only one usage of each socket addressWindowsでよく見られるアドレス使用中のエラーです。まずローカルの待ち受けポートとPIDを確認してください。
permission denied または access permissionsアクセス権限、セキュリティソフト、またはシステムの予約済みポート範囲が原因の可能性があります。別のソフトによるポート使用と決めつけないでください。
ブラウザーでプロキシへの接続に失敗するプロキシのアドレスが正しいか、コアが起動しているかを確認してください。この症状だけではポート競合とは判断できません。

クライアントのログを開き、エラーが発生したアドレス、ポート、プロトコルを確認します。ログに 9090 とあれば、7890ではなくコントローラーの設定を確認してください。mixed-port が有効でない場合は、実際に使用している port または socks-port を調べます。

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

まずターミナルでTCPの待ち受け状態を確認します。PowerShellまたはコマンドプロンプトを開き、次のコマンドを実行してください。プロセス情報が十分に表示されない場合は、管理者として再実行します。

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

「ローカル アドレス」が :7890 で終わり、状態が LISTENING の行を探してください。「外部アドレス」にある7890や、TIME_WAIT の接続を待ち受け中のサービスと誤認しないようにします。以下は出力形式の例で、現在の端末での実際の結果ではありません。

  TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    6420

最後の列の 6420 はプロセスIDの例です。実際のPIDに置き換えて、プロセス名を確認してください。

tasklist /FI "PID eq 6420"

PowerShellでローカルポートを絞り込む

文字列による検索で結果が多すぎる場合は、次のコマンドを使ってください。結果が表示されなければ、通常は検索時点で該当するTCP待ち受けが見つからなかったことを示します。権限エラーなどが出た場合は、エラーを解消してから判断してください。

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

Get-Process -Id 6420 |
  Select-Object Id, ProcessName, Path
  1. 別のClashクライアントが原因なら、まず通知領域のメニューから正常に終了し、バックグラウンドのコアも停止したことを確認します。
  2. 同じクライアントの古いコアが原因なら、クライアントを終了してからサービスモードが動作し続けていないか確認します。クライアントのサービス管理機能から停止し、再起動を繰り返してインスタンスを増やさないようにしてください。
  3. 開発用サービスや別のプロキシを停止できない場合は、そのプログラムに元のポートを使わせ、Clashには別の空きポートを割り当てます。

macOS・Linux：lsofで待ち受け状態を調べる

macOSでは「ターミナル」で lsof を実行します。Linuxでこのツールが入っていない場合は、ss を使えます。以下のコマンドはTCPの待ち受けだけを表示するため、ブラウザーがHTTPプロキシに接続する入口を先に調べるのに便利です。

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

-nP はアドレスやポートを名前に変換しないオプションです。出力の COMMAND はプロセス名、PID はプロセスID、NAME は待ち受けアドレスを示します。デスクトップクライアントが起動したコアと手動起動したサービスを見分けるには、起動コマンド全体も確認してください。

ps -p 6420 -o pid,ppid,command

Linuxでは次のコマンドも使えます。

sudo ss -ltnp 'sport = :7890'

127.0.0.1:7890 はIPv4ループバックでの待ち受け、0.0.0.0:7890 はすべてのIPv4アドレスでの待ち受けを示します。ワイルドカードアドレスでの待ち受けは、同じポートのループバック待ち受けと競合する場合があります。[::]:7890 が表示された場合は、システムのIPv6デュアルスタック動作も考慮してください。IPv4アドレスではないという理由だけで競合の可能性を除外できません。

必要に応じてUDPも確認する

TCPとUDPではポート番号の管理が独立しています。UDPの7890が使用中でも、TCPの7890が必ず起動できないとは限りません。ただし、関連するUDPインバウンド機能を有効にしている場合は、ログに沿って調査してください。

# macOS / lsofをインストール済みのLinux
sudo lsof -nP -iUDP:7890

# Linux
sudo ss -lunp 'sport = :7890'

プロセスがどのサービスに属するか確認したら、アプリの画面またはサービス管理ツールから停止するのが基本です。サービスが自動再起動の管理下にある場合、子プロセスだけを終了しても再起動され、すぐにポートが再び使用中になることがあります。

方法1：クライアントの設定画面でポートを変更する

GUIクライアントは通常、起動時に実行用の設定を生成します。その場合は設定画面からポートを変更し、一時的に生成されたファイルを直接編集するのは避けてください。メニュー名はクライアントやバージョンによって異なります。「設定」にある「ポート」「プロキシポート」「混合ポート」などから探します。

  1. まず前述のコマンドで17890を確認します。検索対象の 7890 を 17890 に置き換えてください。
  2. 現在のポートとシステムプロキシの有効・無効を記録します。クライアントの起動に繰り返し失敗する場合は、接続できない入口にアプリがアクセスし続けないよう、一時的にシステムプロキシを無効にしてください。
  3. クライアントの「設定」を開き、「混合ポート」または mixed-port と表示された項目を探して、17890 を入力します。「外部コントローラー」「API」「コントローラーポート」は変更しないでください。
  4. 設定を保存し、画面の案内に従って設定を再読み込みするか、コアを再起動します。設定画面を閉じるだけでは変更が反映されない場合があります。
  5. ログとシステムの待ち受け状態を確認し、目的のコアが17890で待ち受けていることを確かめてから、システムプロキシを再び有効にします。

クライアントに「HTTPポート」と「SOCKSポート」が別々に表示される場合は、混合ポートが有効か先に確認してください。3つすべてを17890に変更しないでください。これらは同じ項目の別名ではありません。項目の意味が分からない場合は、設定リファレンスを確認してください。

方法2：config.yamlのmixed-portを変更する

コアを直接実行している場合や、ローカル設定を明示的に使っている場合は、実際に読み込まれるYAMLファイルを編集できます。起動引数またはクライアントに表示される設定ファイルのパスを確認し、有効なファイルを編集してください。ファイル名が config.yaml だからといって、必ず使用中とは限りません。

以下はローカル環境向けのトップレベル項目の例です。既存の設定に追加し、ノード、プロキシグループ、ルールはそのまま残してください。サブスクリプション全体を置き換えるための設定ファイルではありません。

mixed-port: 17890
allow-lan: false
mode: rule
log-level: info
  • mixed-port：同じ待ち受け口でHTTPプロキシとSOCKSプロキシの接続を受け付けます。アプリ側では適切なプロキシプロトコルを選択してください。
  • allow-lan: false：ローカル端末だけで使う場合の設定です。ローカルのポート競合を解決するために、安易にLANアクセスを有効にしないでください。
  • mode: rule：ルールによる振り分けモードを維持します。インバウンドポートを変更するために、振り分けモードまで変更する必要はありません。
  • log-level: info：起動情報を確認しやすくする設定です。トラブルシューティングが終わったら、元のログレベルに戻せます。

重複キーとほかのインバウンド設定を確認する

項目はYAMLのトップレベルに配置し、インデントにはスペースを使います。proxies や proxy-groups の中には置かないでください。同じ階層に mixed-port を重複して記述しないでください。パーサーによって重複キーの扱いは異なるため、「後に書いた値が前の値を上書きする」と決めつけないでください。

既存の port、socks-port、その他のインバウンド待ち受け設定も検索してください。port: 17890 と mixed-port: 17890 で同じTCPアドレスを同時に使用しないようにします。独立したインバウンド設定を残すかどうかは、アプリの実際の要件に応じて判断してください。

設定を検証してから再読み込みする

mihomoを直接使用している場合は、コアの設定テスト用オプションで構文を確認できます。以下の例は、現在のディレクトリにある設定ファイルを実行時に使用している前提です。実際の場所が異なる場合は、正しいパスを指定してください。

mihomo -t -f ./config.yaml

設定テストに通っても、待ち受けが成功したとは限りません。保存後にコアを再読み込みまたは再起動し、起動ログを確認してください。サブスクリプション管理下のファイルは更新時に手動変更が上書きされる場合があります。クライアントが対応する永続的な上書き方法を使うか、ポート管理をクライアントの全般設定に任せてください。

システムプロキシとアプリのプロキシ設定を更新する

コアを17890に変更したら、7890を参照し続けているプロキシ設定もすべて確認してください。システムプロキシ、ブラウザー拡張機能、ターミナルの環境変数、開発ツールは設定を個別に保存しているため、通常は一括で更新されません。

設定箇所確認する値
Windows 11「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」→「プロキシ サーバーを使う」を開き、アドレスを127.0.0.1、ポートを17890にします。
macOS「システム設定」→「ネットワーク」→現在のネットワーク接続→「詳細」→「プロキシ」を開き、Webプロキシ、安全なWebプロキシ、有効になっているSOCKSプロキシを確認します。
ブラウザーのプロキシ拡張機能現在のプロファイルでサーバーのポートを更新し、7890が残っていないことを確認します。
ターミナルと開発ツールHTTP_PROXY、HTTPS_PROXY、ALL_PROXYのほか、Git、パッケージマネージャー、IDEそれぞれのプロキシ設定を確認します。

クライアントの「システムプロキシ」スイッチを使っている場合は、新しいポートが有効になった後に一度オフにしてからオンにし、OSの設定画面でも確認してください。macOSの「安全なWebプロキシ」はHTTPSサイトへのプロキシ接続を指す名称であり、ローカルのプロキシ入口自体でTLSを有効にする必要があるという意味ではありません。

ターミナルで環境変数を使っている場合は、現在のmacOSまたはLinuxのシェルで次のように更新します。

export HTTP_PROXY=http://127.0.0.1:17890
export HTTPS_PROXY=http://127.0.0.1:17890
export ALL_PROXY=socks5h://127.0.0.1:17890

ここで HTTPS_PROXY も http:// を使っています。これはローカルのHTTPプロキシ経由で接続することを表します。対応ツールでは、socks5h は接続先ドメインの名前解決をプロキシ側で行う指定です。これらのコマンドが影響するのは現在のシェルと、その後に起動する子プロセスです。設定は永続化されず、すべてのツールがこれらの環境変数を参照するわけでもありません。

修復結果と競合が続く原因を確認する

修復後は、新しいポートで実際に待ち受けていること、待ち受けているのが想定したコアであること、アプリからその入口経由でリクエストを送れることの3点を確認します。まず前述のコマンドで17890を調べ、システムプロキシや環境変数の影響を避けるため、プロキシを明示してリクエストを実行してください。

# macOS / Linux
curl -I --proxy http://127.0.0.1:17890 --connect-timeout 5 --max-time 15 https://example.com/

# Windows PowerShell：curl.exeを明示して実行
curl.exe -I --proxy http://127.0.0.1:17890 --connect-timeout 5 --max-time 15 https://example.com/

5秒は接続タイムアウトの上限、15秒はリクエスト全体の制限時間であり、速度テストの結果ではありません。Connection refused が表示された場合は、待ち受けアドレスとコアの状態を確認してください。プロキシが接続を受け付けた後にタイムアウトする場合は、ルールの適用先、出力ノード、DNSのログを調べます。HTTPレスポンスが返っても、そのリクエストが入口を経由したことを示すだけで、すべての通信が想定どおりプロキシされたとは限りません。

ポートが空いているのに起動できない場合

  • Windowsの予約済みポート：ログにアクセス許可エラーがあり、待ち受け中のプロセスも見つからない場合は、次のコマンドで除外範囲を確認してください。新しいポートは表示された範囲を避け、システムの予約設定を安易に削除しないでください。
  • 古いプロセスが自動で再起動する：システムサービス、ログイン時のスタートアップ項目、GUIクライアントの二重起動を確認してください。
  • 編集した設定ファイルが違う：実際に読み込まれるパス、起動引数、クライアントの上書き設定を確認し、再読み込み後のログと照らし合わせてください。
  • 仮想化環境ごとにネットワークが異なる：Docker、WSL、ホストOSではネットワーク名前空間が異なる場合があります。実際にポートをバインドしている側で確認してください。コンテナ内で待ち受けに成功しても、ホスト側のポートマッピングが成功したとは限りません。
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp

TUNを有効にした場合もシステムプロキシを変更する必要がありますか？

TUNは仮想ネットワークアダプターとルーティングで通信を処理するため、アプリが7890に接続する仕組みとは異なります。TUNが引き続き動作していても、設定で有効にした混合ポートだけがバインドに失敗することがあります。逆に、混合ポートが待ち受けを再開しても、TUNのルーティングやDNSが正常とは限りません。トラブルシューティングでは、2つの通信経路を分けて検証してください。ブラウザーでWebページが開けることを、待ち受けの確認の代わりにしないでください。

最後にクライアントを再起動し、ポート設定が17890のままか確認してから、必要に応じてサブスクリプション更新後の設定もテストします。7890に戻す必要がある場合は、元の使用プロセスが終了したことを確認し、システムプロキシとアプリのプロキシ設定を両方戻してください。トラブルシューティング前後のポートを記録しておくと、次回クライアントを移行するときの確認作業を減らせます。