まずログを確認：どの待ち受けアドレスで起動に失敗したか
Clashクライアントに「ポートが使用中」と表示される場合、通常はコアが指定されたアドレスで待ち受けを開始できていません。よくある原因は、別のプロキシクライアントがバックグラウンドで動作していること、または同じクライアントのサービスと手動起動したコアが重複していることです。すぐに再インストールしたり、「Clash」を含む名前のプロセスを片っ端から終了したりせず、競合したポートと使用中のプロセスを特定しましょう。
クライアントのログでbind、listen、address already in useなどのキーワードを探します。Windowsでは「通常、各ソケット アドレスに対して使用できるのは1回だけです」と表示されることもあります。以下は問題を特定するためのログ例です。実際のプレフィックスはコアのバージョンによって異なります。
listen tcp 127.0.0.1:7890: bind: address already in useこのメッセージが示しているのは、リモートノードのポートではなく、ローカルのループバックアドレス上にあるTCP 7890です。サブスクリプション内のノードポートを変更しても、ローカルの待ち受けポートの競合は解消しません。ログにpermission deniedや「アクセスが拒否されました」と表示される場合は、システムの予約ポート、権限、セキュリティポリシーも確認してください。プロセスによる占有とは限りません。
| 設定項目 | 用途 | 確認ポイント |
|---|---|---|
mixed-port | 同じ入口でHTTPとSOCKSのプロキシリクエストを受け付ける | 一般的な例は7890。実際の設定を確認 |
port / socks-port | HTTPとSOCKSのプロキシ入口を個別に提供する | 混合ポートと同じ待ち受けアドレス・ポートを重複指定していないか確認 |
external-controller | クライアント画面やパネルから使用するコントロールAPIを提供する | 一般的な例は127.0.0.1:9090。Webアクセス用のプロキシポートではない |
dns.listen | DNSクエリを受け付ける | 53番ポートや独自のDNSポートで競合する場合は、DNSサービスを別途確認 |
ポートの競合は、待ち受けアドレスや通信プロトコルにも左右されます。0.0.0.0:7890はすべてのIPv4インターフェースで待ち受ける設定のため、127.0.0.1:7890と競合することがあります。IPv6のワイルドカード待ち受けがIPv4もカバーするかどうかは、OSやソケットの設定によって異なります。同じ番号でもTCPとUDPは別の待ち受けリソースです。ログに記録されたプロトコルに合わせて確認してください。
Windows：PIDから7890を使用しているプログラムを特定する
待ち受けを調べてからプロセス名を確認
PowerShellで次のコマンドを実行します。1つ目はTCP 7890の待ち受けだけを抽出し、2つ目はプログラムのパスを確認します。出力例のPIDが6248の場合は、その数字を2つ目のコマンドに指定してください。実際には、このPCで取得したPIDを使います。
Get-NetTCPConnection -LocalPort 7890 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Id 6248 | Select-Object Id, ProcessName, Pathコマンドプロンプトを使う場合は、Windows標準のnetstatとtasklistでも確認できます。
netstat -ano -p tcp | findstr ":7890"
tasklist /FI "PID eq 6248"findstrは文字列を検索するため、リモートポートや78900などの数字に一致することもあります。「ローカル アドレス」列が実際に:7890で終わっていることと、状態がLISTENINGであることを確認してください。TIME_WAITの記録だけでは、プログラムが待ち受け中とは判断できません。接続記録をすべて競合の原因とみなさないようにしましょう。
- 別のプロキシクライアントが使用中の場合：まず通知領域のメニューから正常に終了し、もう一度ポートを調べます。
- 現在使っているクライアントのコアが使用中の場合：サービスモードが有効な状態で、コアを手動でも起動していないか確認します。
- 終了してもすぐに新しいPIDで現れる場合：「タスク マネージャー」→「サービス」を開くか、
services.mscを実行して、該当するバックグラウンドサービスが再起動していないか確認します。
待ち受けが見つからないのにバインドに失敗する場合
エラーが7890ではなく、9090や別のアドレスを指していないか確認します。Windowsのログにアクセス権限の問題が示されている場合は、TCPの除外ポート範囲を確認してください。
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcpHyper-V、コンテナー、および関連するネットワーク機能でポートが予約されている場合があります。使用したいポートが除外範囲に含まれているなら、出所のわからないシステム予約を削除するより、利用可能と確認できた別のポートを使うのが安全です。管理者としてクライアントを実行しても、この種の制限が必ず解除されるわけではありません。
macOS・Linux：デスクトップクライアントとバックグラウンドサービスを見分ける
macOSではlsofを使用
「アプリケーション」→「ユーティリティ」→「ターミナル」を開き、TCP 7890の待ち受けプロセスを調べます。-nPを付けるとアドレスとポートが数字のまま表示され、名前解決による表示の変化を避けられます。権限不足で結果が表示されない場合は、sudoを付けて再実行してください。
lsof -nP -iTCP:7890 -sTCP:LISTEN
ps -p 6248 -o pid,ppid,command出力のCOMMANDとPIDを確認し、2つ目のコマンドで起動時のコマンド全体を調べます。ウィンドウを閉じてもメニューバーに常駐するクライアントもあるため、メニューバーから終了してください。ログイン時に自動起動する場合は、「システム設定」→「一般」→「ログイン項目と機能拡張」で確認します。macOSのバージョンによって最後の項目名が多少異なる場合があります。
Linuxではssを使用
Linuxではssで待ち受けアドレスとプロセス情報をまとめて確認できます。次のコマンドはTCPとUDPを個別に調べます。2つ目は、ログや機能でUDPが関係する場合にのみ実行してください。
sudo ss -ltnp 'sport = :7890'
sudo ss -lunp 'sport = :7890'
ps -p 6248 -o pid,ppid,argssystemdがプロセスを管理している場合、プロセスを終了しても自動的に再起動することがあります。まずsystemctl status 6248を実行し、PIDから該当するサービスを特定します。ユーザー単位のサービスはsystemctl --userで確認してください。実際のユニット名を確認してから、対応するstop操作で停止します。インストール方法が違ってもサービス名が同じとは限りません。
Dockerなどのコンテナーを使っている場合は、ホスト側のポートマッピングも確認してください。コンテナー内の7890番ポートと、ホスト側で公開する7890番ポートは別々の設定です。ホスト側で競合している場合、コンテナー内の設定だけを変えても、ホスト側のポート使用状況は変わらないことがあります。
mixed-portの変更：サブスクリプションのコピーではなく、実行時の設定を変更
占有しているプログラムを終了できない場合は、Clashのプロキシ入口を別のポートに変更します。ここでは7890を7893に変更する例を紹介します。7893はあくまで例で、このPCで空いているとは限りません。変更前に同じコマンドで使用状況を確認してください。
クライアントが最終的に読み込む設定ファイルを確認
GUIクライアントでは、「サブスクリプションの内容」「オーバーライド設定」「クライアントのポート設定」から実行時の設定が生成されることがあります。ダウンロードしたYAMLだけを変更すると、サブスクリプション更新時に元に戻ったり、コアに反映されなかったりする場合があります。画面上の項目名はクライアントごとに異なるため、「ポート」「混合ポート」「Mixed Port」を探し、クライアントが提供する永続設定やオーバーライド機能を使ってください。
- GUIクライアント：現在のポートを控え、設定画面で混合ポートを変更します。適用後にコアを再起動し、起動ログで最終的な待ち受けアドレスを確認してください。
- コアを直接起動している場合：起動コマンドの設定ファイルを指定する
-fオプションと、作業ディレクトリを指定する-dオプションを確認し、実際に読み込まれるファイルを編集します。 - サービス・コンテナー：サービスの起動引数、マウント先、ポートマッピングを確認し、同名の別設定ファイルを変更しないようにします。
以下はmihomo用のトップレベル設定例で、サブスクリプション全体の設定ではありません。既存の設定に必要な項目を追加・統合してください。ファイル全体を置き換えず、同名のキーがある場合は値を変更します。キーを重複して追加しないでください。
mixed-port: 7893
allow-lan: false
bind-address: 127.0.0.1mixed-portはHTTPとSOCKSのリクエストを同じポートで受け付けますが、同じアドレスで独立したportやsocks-portと重複して待ち受けることはできません。既存の個別入口を確認し、そちらも7893に設定しないようにしてください。待ち受けアドレスはクライアントの設定生成方法にも左右されるため、最終的にはシステム上の調査結果で確認します。
mihomoの設定を直接管理している場合は、まず構文と設定を確認できます。以下のコマンドは、ターミナルの現在のディレクトリに実際のconfig.yamlがあることを前提としています。
mihomo -t -f ./config.yaml設定チェックに合格しても、ポートの待ち受けが成功するとは限りません。設定の検査と、実行時の待ち受け開始は別の処理です。設定を適用した後も、ログとポートの状態を確認してください。GUIクライアントでは、待ち受けポートの変更を反映するために「コアを再起動」する必要がある場合があります。入力欄に値が保存されたかだけで判断しないでください。
コントロールポート9090の競合：プロキシポートで代用しない
external-controllerは、クライアント画面が接続情報の取得、ルールの切り替え、実行状態の変更などに使うコントロールAPIの待ち受けアドレスです。HTTPプロキシではありません。127.0.0.1:9090で競合している場合、mixed-portだけを変更しても解決しません。逆に、ブラウザーのプロキシに9090を設定しても、Webリクエストは正常に転送されません。
設定とコントロールパネルを自分で管理している場合は、空き状況を確認したうえで、コントロールアドレスを次の例の値に変更できます。
external-controller: 127.0.0.1:9093変更後は、外部パネルの接続先アドレスも更新し、既存のsecretによる認証設定を維持してください。コントロールポートをGUIクライアントが管理している場合は、クライアントの設定画面から変更します。コアの項目だけを上書きし、画面側の接続先を更新しないと、「コアは通信を中継しているのに、画面では未接続」と表示されることがあります。
プロキシポートの変更後に更新が必要な設定
ポートを7890から7893に変更すると、古い接続先を使い続けるアプリは接続に失敗します。クライアントに「コア実行中」と表示されても、確認できるのはコアの起動状態だけです。ブラウザー、ターミナル、その他のツールが新しいアドレスを使っているとは限りません。
| 設定箇所 | 更新が必要な内容 |
|---|---|
| システムプロキシ | クライアントのシステムプロキシ設定を再適用し、アドレスが127.0.0.1:7893になっていることを確認 |
| ブラウザーのプロキシ拡張機能 | 手動設定したHTTPまたはSOCKSのポートを7893に変更。「システム設定に従う」モードも別途確認 |
| ターミナルの環境変数 | HTTP_PROXY、HTTPS_PROXY、ALL_PROXYと、実際に使っている小文字の環境変数を更新 |
| 開発ツール | Git、パッケージマネージャー、IDEにそれぞれ保存されているプロキシアドレスを確認 |
| LAN内のデバイス | LANからの接続を許可していた場合は、ポートも更新してファイアウォールを確認。127.0.0.1を別のデバイスのアドレスとして使わない |
Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」から手動プロキシを確認できます。macOSでは「システム設定」→「ネットワーク」→現在のネットワーク接続の「詳細」→「プロキシ」を確認してください。クライアントでシステムプロキシを再設定した後も、システム設定画面で実際の値を確認すると、ほかのツールによる上書きを見つけやすくなります。
ターミナルで現在のセッションだけを変更する例
# macOS / Linux：現在のシェル
export http_proxy=http://127.0.0.1:7893
export https_proxy=http://127.0.0.1:7893
# PowerShell：現在のセッション
$env:HTTP_PROXY = "http://127.0.0.1:7893"
$env:HTTPS_PROXY = "http://127.0.0.1:7893"HTTPS用の環境変数でもhttp://を使うのは、ローカルのHTTPプロキシのCONNECT方式でHTTPSサイトに接続するためです。接続先サイトがHTTPに変更されるわけではありません。SOCKSを使っていた場合は、対応アプリの接続先をsocks5h://127.0.0.1:7893に変更できます。各アプリが環境変数を読み込むかどうかは、個別に確認してください。
TUNモードは仮想ネットワークインターフェースで通信を取り込みます。アプリが混合ポートに直接接続する経路とは異なります。そのため、TUNモードでアプリがインターネットに接続できても、古い7890のプロキシ設定が解消したとは限りません。プロキシを手動設定したツールは、引き続き古いポートへ接続する場合があります。
3段階で確認：待ち受け、プロキシリクエスト、アプリからの実接続
- 待ち受けプロセスを確認：7893をもう一度調べ、想定したコアが待ち受けており、新たなバインド失敗のログがないことを確認します。
- プロキシプロトコルを確認：システムプロキシの更新に頼らず、新しいポートを明示してリクエストを1回送信します。
- よく使うアプリを確認：ブラウザーや開発ツールを開き、クライアントの接続一覧で該当リクエストとルールの適用状況を確認します。
# macOS / Linux
curl -I --connect-timeout 5 --max-time 15 --noproxy "" --proxy http://127.0.0.1:7893 https://example.com
# Windows PowerShell：curl.exeを明示して実行
curl.exe -I --connect-timeout 5 --max-time 15 --noproxy "" --proxy http://127.0.0.1:7893 https://example.com上記のテストでは、接続タイムアウトを5秒、全体の制限時間を15秒に設定し、そのリクエストに限ってプロキシの除外リストを空にしています。127.0.0.1:7893に接続できない場合は、まず待ち受けが成功しているか確認してください。プロキシ接続が確立した後にTLSエラー、上流への接続タイムアウト、ルール関連のエラーが出る場合は、ローカルポートを変更し続けるのではなく、ノード、DNS、ルールを調べます。
接続先からHTTPレスポンスが返れば、リクエスト経路の確認に役立ちますが、ノードの帯域、すべてのWebサイト、すべてのアプリが正常であることを保証するものではありません。サイトによってはHEADリクエストを拒否するため、レスポンスの内容も確認してください。テストでは一度に変更する項目を1つにし、変更前のポートを記録しておくと、ルール、DNS、TUNを同時に変更するより原因を特定しやすくなります。
よくある質問：再起動、複数クライアント、ポート競合の再発
PCの再起動で直った場合も、調査が必要ですか？
一度だけなら、まず様子を見てもよいでしょう。ログイン後に毎回再発する場合は、自動起動するクライアントやバックグラウンドサービスを確認してください。再起動で起動順が一時的に変わっても、2つのプログラムが同じポートを奪い合う原因は残っています。繰り返し再起動するより、競合時のPID、プログラムのパス、ログを記録しておくほうが役立ちます。
Clashクライアントを2つ同時に実行できますか？
プロキシポートとコントロールポートを別々に割り当てることはできますが、システムプロキシの設定、TUNルート、DNSの取り込みは互いに影響する場合があります。普段の利用では、通信を取り込むクライアントを1つにすると管理しやすくなります。7890だけを変更しても、複数クライアントのシステム設定がすべて分離されるわけではありません。
ポートを変更したのに、サブスクリプション更新後に7890へ戻ります。どうすればよいですか？
設定が再生成されるレイヤーを変更した可能性があります。クライアントのポート設定や永続オーバーライド機能を確認し、サブスクリプションの更新後に、実際に使われている設定と待ち受け状況を確認してください。サブスクリプション編集画面の表示だけでは、コアが現在使用している値は判断できません。
この種のトラブルは、ログでアドレスとプロトコルを確認し、待ち受けプロセスを特定してから、重複したプロセスを終了するかポートを変更し、最後にアプリの設定を更新してテストする手順で進めます。クライアントへの基本的な設定の取り込みと通信の取り込みについては、Clashの使い方ガイドをご覧ください。設定項目を確認するには、プロトコルと設定のリファレンスを参照してください。