エラーログを確認：競合している待受ポートを特定

ClashのGUIクライアントは起動するのにコアの起動に失敗し、ログに address already in use と表示される場合、待受対象のアドレスとポートがほかのプロセスに使用されている可能性があります。ログに記録されたプロトコル、アドレス、ポートを控えてからプロセスを調べましょう。「起動失敗」と表示されても、サブスクリプションを再インポートする必要はありません。

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

これはエラーの例であり、実機での検証結果ではありません。このメッセージはローカルのTCPポート7890を示しており、ノードの無効を意味するものではありません。Windowsでは「通常、各ソケット アドレスは 1 回だけ使用できます」といったメッセージが表示されることもあります。ログに access denied や「アクセスが拒否されました」とある場合は、ポートの予約範囲やセキュリティポリシーも確認してください。通常のポート競合として扱わないようにしましょう。

設定項目用途確認ポイント
mixed-port同じポートでHTTPとSOCKSのプロキシリクエストを受け付ける例：7890。システムプロキシと手動設定のプロキシアプリも確認
port / socks-portHTTPとSOCKSのプロキシ入口を個別に提供する有効なほかの待受設定と、同じアドレス・ポートを共有できない
external-controllerコアの制御APIを提供する例：127.0.0.1:9090。ブラウザー用のプロキシポートではない
dns.listenコアのDNS待受口を提供する例：127.0.0.1:1053。ログにあるTCPまたはUDPを確認

Windows：待受PIDを調べてプロセスのパスを確認

PowerShellでTCPの待受状態を確認

スタートメニューを右クリックし、「ターミナル」または「Windows PowerShell」を開きます。まず以下のコマンドを実行してください。検索が制限される場合や、ほかのユーザーのプロセス情報を確認する必要がある場合は、管理者としてターミナルを開きます。

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

OwningProcess はプロセスIDです。結果が 1234 だった場合は、続けてプロセス名、パス、起動引数を確認します。ここでの1234は説明用の値なので、実際に取得した値に置き換えてください。

Get-Process -Id 1234 | Select-Object Id, ProcessName, Path

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

プロセス名よりもパスや起動引数のほうが特定に役立ちます。別々のクライアントが、どちらも mihomo.exe という名前のコアを起動している場合があります。コマンドラインに表示される設定ファイルのパスから、どのクライアントのプロセスかを判断できます。名前にClashやmihomoが含まれているだけで、強制終了しないでください。

コマンドプロンプトで調べる方法

netstat -ano -p tcp | findstr ":7890"
tasklist /FI "PID eq 1234"

netstat を使う場合は、「ローカル アドレス」列のポート番号と LISTENING の状態を確認します。findstr は単純な文字列検索のため、リモートアドレスや桁数の多いポート番号にも一致することがあります。また、TIME_WAIT の記録は、プロセスが現在待ち受けていることを示しません。

待受プロセスが見つからないのにバインドエラーが出る場合

クライアントがコアを繰り返し再起動していて、検索時には待受状態が消えていないか確認してください。アクセス権限に関するエラーの場合は、管理者ターミナルでWindowsのTCP除外ポート範囲を確認できます。

netsh interface ipv4 show excludedportrange protocol=tcp

対象ポートが除外範囲に含まれている場合は、範囲外の空きポートに変更してください。システムの予約設定を安易に削除しないでください。Hyper-V、コンテナー、ほかのネットワークコンポーネントが使用している可能性があります。エラーにIPv6アドレスが明示されている場合は、IPv6側の状態も確認してください。

macOS・Linux：通常のプロセスとバックグラウンドサービスを見分ける

macOS：lsofで待受プロセスを調べる

「ターミナル」を開き、TCPポート7890を待ち受けているプロセスを調べます。-nP を付けるとアドレスやポートが名前に変換されないため、ログと照らし合わせやすくなります。

sudo lsof -nP -iTCP:7890 -sTCP:LISTEN
ps -p 1234 -o pid,ppid,user,command

1つ目のコマンドで返されたPIDを、2つ目のコマンドに指定してください。別のプロキシクライアントがメニューバーに常駐している場合は、そのメニューから正常に終了してから再度調べます。ウィンドウを閉じても動作し続けるクライアントもあるため、ウィンドウが消えただけではコアが停止したとは限りません。

Linux：ssでソケットを確認

sudo ss -ltnp 'sport = :7890'
ps -p 1234 -o pid,ppid,user,args

-l は待受、-t はTCP、-n は数値表示、-p はプロセス情報を示します。ディストリビューションに ss がインストールされていない場合は、lsof が利用できる環境で、macOSの項目にあるコマンドを使えます。

systemdが管理するプロセスを直接終了すると、自動的に再起動されることがあります。systemctl status 1234 で関連するサービスを確認し、実際のサービスユニットを特定してから停止してください。ユーザー単位のサービスは systemctl --user で確認します。サービス名を推測してまとめて無効化しないでください。

DNSの競合はUDPで確認

ここまでのコマンドで確認したのはTCPのみです。ログにUDPポート1053が示されている場合は、以下のコマンドで調べてください。別のポートを確認するときは番号を置き換えます。同じポート番号でもTCPとUDPは別のプロトコルです。TCPの検索結果が空でも、UDPが空いているとは限りません。

# macOS、またはlsofをインストール済みのLinux
sudo lsof -nP -iUDP:1053

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

競合元を特定：重複したコア、別のソフト、設定の重複

プロセスのパスを確認してから対処方法を選びましょう。ポート競合の解消に、通常はソフトのアンインストールやノードのプロトコル、ルールモード、サブスクリプションURLの変更は必要ありません。

  1. 以前使っていたクライアントがバックグラウンドで動作している。たとえば、あるクライアントがポート7890を使っている状態で、別のクライアントもポート7890を要求している場合です。使用するクライアントを決め、もう一方を正常に終了し、スタートアップ設定も確認してください。
  2. GUIとは別にサービスが起動している。手動で起動したコア、システムサービス、スケジュールタスクが別の設定を読み込んでいる可能性があります。プロセスの所属先を特定してから該当するインスタンスを停止してください。サービス管理ツールによってすぐに再起動されないよう注意します。
  3. ポートを別の必要なプログラムが使用している。用途が明確なプロセスはそのままにして、Clashの待受ポートを変更してください。ポートを空けるためにシステムプロセスや不明なサービスを終了しないでください。
  4. 同じ設定で待受ポートが重複している。port、socks-port、mixed-port に同じアドレスとポートを指定していないか確認してください。混合ポートはHTTPとSOCKSの両方を受け付けるため、同じポートに個別の入口を追加する必要はありません。

バインドするアドレスも確認してください。127.0.0.1:7890 はローカルのループバックインターフェースのみを対象とし、0.0.0.0:7890 はすべてのIPv4インターフェースを対象とするため、競合することがあります。IPv6の [::]:7890 がIPv4も同時に対象とするかどうかは、システムやソケットの設定によって異なります。全インターフェースでの待受は一般的な解決策ではありません。プロキシに接続できる範囲も広がります。

待受ポートを変更：実際に反映される設定元を編集

ポート7897の空きを確認してからmixed-portを変更

前述のコマンドで7890を7897に置き換え、競合がないことを確認してください。クライアントを2つ同時に使う場合は、それぞれ異なるプロキシポートを割り当てます。制御APIなど、ほかの待受ポートも個別に確認してください。

# 確認が必要な項目のみ表示。設定全体ではありません
mixed-port: 7897
allow-lan: false
mode: rule

この例は、ローカルでのみ使用する混合プロキシポートを想定しています。既存のYAMLに反映するときは、すでにある項目を編集してください。ファイルの末尾に2つ目の mixed-port を追加しないでください。既存の port や socks-port を使っている場合は、用途に応じて無効化するか、別のポートを割り当てます。この3行だけでサブスクリプション全体を置き換えないでください。ノード、プロキシグループ、ルールはそのまま残す必要があります。

GUIクライアントの設定とサブスクリプションファイル、どちらが優先される？

Clashはコアと設定エコシステムの総称で、GUIクライアントによってメニューや設定の上書き方法が異なります。まず使用中のクライアントの「設定」で「ポート」「混合ポート」「Mixed Port」などの項目を探し、変更前の値を控えてから編集してください。特定のクライアントのメニュー手順がすべてのバージョンに共通するものとしては案内していません。

  • クライアントにポート設定がある：その設定から変更し、画面の案内に従ってコアを再起動してください。サブスクリプション内の同じ項目が上書きされる場合があります。
  • コアを直接起動している：起動引数で指定された設定ファイルを編集してください。ダウンロードした別のコピーではなく、実際に読み込まれているファイルかを確認します。
  • サブスクリプションが自動更新される：クライアントの永続的な上書き設定やマージ機能を使ってください。ダウンロードしたサブスクリプションファイルを直接編集すると、更新時に変更が上書きされることがあります。

保存後にコアを再起動し、起動ログと実際の待受状態を確認してください。設定エディターに7897と表示されても、実行中のコアに反映されたとは限りません。変更後も7890のエラーが続く場合は、ポートの競合だけでなく、設定の優先順位、設定ファイルのパス、正しいインスタンスを再起動したかも確認します。

競合しているのが external-controller の場合は、該当する制御アドレスだけを変更します。たとえば 127.0.0.1:9090 を空きが確認できた 127.0.0.1:9097 に変更し、パネル側の接続設定も合わせて更新してください。制御APIを通常のプロキシポートとして設定したり、トラブル対応のためにインターネットへ公開したりしないでください。

ポート変更後に更新が必要な設定

コアが7897で正常に待ち受けていても、ブラウザーが7890に接続したままだと、「ポートエラーは消えたのにWebページが開けない」という状態になります。この場合はノードを変更せず、プロキシを使用するアプリの設定を確認してください。

利用箇所確認・変更する項目
システムプロキシポートが7897になっているか確認。クライアントからシステムプロキシを一度オフにして再度オンにし、システム設定も確認
ブラウザーのプロキシ拡張機能手動設定したHTTPまたはSOCKSのポートを変更。アドレスは通常127.0.0.1のまま
ターミナルの環境変数HTTP_PROXY、HTTPS_PROXY、ALL_PROXYと、それぞれの小文字の変数を確認
Git、ダウンロードツール、開発ツール各ツールに個別保存されたプロキシアドレスを更新。システムプロキシだけの変更では不十分
LAN内のデバイスパソコンのプロキシを使っていたスマートフォンやテレビでは、パソコンのLANアドレスと新しいポートを設定
外部のコントロールパネル制御APIのポートを変更した場合のみ接続先を更新。プロキシの入口とは別に管理

Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」でアドレスとポートを確認できます。macOSでは「システム設定」→「ネットワーク」→現在の接続先の「詳細」→「プロキシ」を確認してください。OSのバージョンによってメニュー名は異なります。また、クライアントが管理する設定は起動時に書き戻されることがあります。

ターミナルの HTTPS_PROXY=http://127.0.0.1:7897 は、HTTPプロキシ経由でHTTPSの接続先にアクセスする設定です。ローカルのプロキシ入口自体にTLSが必要という意味ではありません。アプリがSOCKSを使う場合は対応するプロトコルを選びます。たとえば socks5h は通常、接続先のドメイン名をプロキシ側で名前解決することを示します。対応状況はアプリごとに確認してください。

TUNモードは仮想ネットワークアダプターを使い、ルーティング条件に一致する通信を処理します。すべてのアプリがmixed-portを使用するわけではありません。ただし、アプリに古い手動プロキシ設定が残っていると、旧ポートにリクエストが送信されることがあります。TUNの起動、ルーティング、プロキシ待受ポートの競合は、それぞれ別に確認してください。

修正後の確認：待受状態と実際の通信を検証

  1. ログを再確認し、元のバインドエラーが繰り返し発生していないことと、制御APIやDNSのポート競合が新たに起きていないことを確認します。
  2. 新しいポートを調べ、待受プロセスが古い別のコアではなく、現在使用しているクライアントのものか確認します。
  3. プロキシを明示したリクエストで接続をテストし、システムプロキシの設定が未反映であることによる影響を切り分けます。
  4. 次にブラウザーで接続先のWebサイトを開き、クライアントの接続ログとルールの適用状況を確認します。
# macOS / Linux
curl -I --proxy http://127.0.0.1:7897 --connect-timeout 5 --max-time 15 https://example.com

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

ここでの example.com はテスト用のアドレスです。確認したいWebサイトに置き換えられます。接続先からレスポンスヘッダーが返れば、そのリクエストの通信が完了しています。Connection refused が表示される場合は、アドレス、ポート、待受状態を優先して確認してください。ローカルプロキシへの接続後にタイムアウト、認証失敗、上流接続エラーが発生する場合は、ノード、DNS、ネットワーク接続、ルールを調べます。すべてをポート競合として扱わないでください。

ポート修正の完了条件は、対象のコアが安定して待ち受け、システムとアプリが新しいポートを使い、クライアントの再起動やサブスクリプションの更新後も設定が維持されることです。「ログ確認 → プロセス特定 → 所属先の判断 → 有効な設定元を変更 → アプリ側を同期 → 通信を検証」の順に進めると、ポート競合とほかのネットワーク障害を切り分けやすくなります。設定方法はClashの設定ガイド、接続時のよくある症状はよくある質問もご覧ください。