トラブル対処 読了時間：約11分

Clashのポート7890が使用中：プロセスの特定と混合ポートの変更

Clashの起動時にポート使用中と表示されたら、netstatやlsofでプロセスを特定し、mixed-portと外部コントローラーポートを変更してシステムプロキシも更新します。

まずログに記録された待ち受けアドレスとポートを確認

Clashでポート使用中と表示されるのは、通常、指定したアドレスでカーネルが待ち受けを開始できないことを意味します。複数のプロキシクライアントを同時に起動している、以前のカーネルが正常に終了していない、バックグラウンドサービスが同じポートを使用している、といったケースがよくあります。この場合、サブスクリプションの更新やノードの切り替え、ルールの変更では、ローカルの待ち受け競合は解消できません。

クライアントの「ログ」画面を開き、bind、listen、address already in useを含むログ全体を探します。WindowsではOnly one usage of each socket addressと表示されることもあります。以下はエラーの種類を見分けるための例であり、実機で取得した出力ではありません。

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

1行目はローカルプロキシの接続口、2行目はコントロールインターフェースに関するエラーです。実際にエラーが出たポートを調べてください。Clashの起動に失敗したからといって、7890だけを確認するのは避けましょう。ログにpermission deniedやソケットへのアクセス禁止とある場合は、権限、システムの予約ポート範囲、セキュリティポリシーも考慮します。別のプロセスによる占有と決めつけないでください。

設定項目用途と例変更後に必要な対応
mixed-portHTTPとSOCKSで共用する接続口。例：7890システムプロキシや手動でプロキシを指定しているアプリも更新が必要
port / socks-portHTTPとSOCKSの接続口を個別に設定。値は設定ファイルを確認該当するプロトコルを使用するアプリも更新が必要
external-controllerコントロールインターフェース。例：127.0.0.1:9090パネルやクライアントからカーネルへの接続設定も更新が必要な場合あり

Windows：netstatでPIDを調べ、プログラムのパスを確認

PowerShellで待ち受けプロセスを特定

「スタート」を右クリックして「ターミナル」を選び、PowerShellタブで次のコマンドを実行します。通常、確認に管理者権限は不要です。プロセス情報が表示されない場合は、管理者としてターミナルを開いてください。

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

ローカルアドレスが:7890で終わっているか、状態がLISTENINGかを確認します。リモートアドレスに7890が含まれているだけの場合や、状態がTIME_WAITの場合は、その情報だけでプログラムがローカルの7890を待ち受けているとは判断できません。各行の右端に表示される数字がPIDです。

対象ポートの待ち受けだけを表示する場合は、PowerShellで次のコマンドを実行します。

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

PIDが1234だった場合は、続けてプロセス名とパスを確認します。1234は例です。実行時は先ほど調べた数字に置き換えてください。

tasklist /FI "PID eq 1234"
Get-Process -Id 1234 | Select-Object Id, ProcessName, Path

実行元を確認してからプログラムを終了

  1. 別のプロキシクライアントが使用している場合は、そのクライアントのトレイメニューから「終了」を選びます。メインウィンドウを閉じるだけでは不十分です。
  2. 現在使用中のクライアントの古いカーネルが該当する場合は、まずクライアントを正常に終了します。その後、もう一度PIDを調べ、バックグラウンドプロセスが残っていないか確認してください。
  3. ほかの業務用ソフトが使用している場合は、そのプログラムを終了せず、空いているプロキシポートを使います。
  4. PIDがサービスまたはシステムプロセスに対応している場合は、「タスク マネージャー」→「詳細」と「サービス」を確認してください。いきなり強制終了しないでください。

プロセス名にmihomoやclashが含まれていても、残存プロセスとは限りません。サービスモードを有効にしたクライアントでは、カーネルがバックグラウンドで動き続けることがあります。プロセスだけ終了してトレイアプリやサービスを停止しないと、カーネルがすぐに再起動される場合があります。

macOS・Linux：lsofやssで待ち受け元を調べる

macOS：メインウィンドウとメニューバーのプロセスを確認

「アプリケーション」→「ユーティリティ」→「ターミナル」を開き、TCP 7890の待ち受けプロセスを調べます。

lsof -nP -iTCP:7890 -sTCP:LISTEN

-nPを付けると、名前解決を行わず、アドレスとポートを数字で表示できます。出力のCOMMAND、PID、NAMEから、それぞれプロセス名、プロセスID、待ち受けアドレスを確認できます。通常の確認で結果が表示されないのにエラーが続く場合は、sudo lsof -nP -iTCP:7890 -sTCP:LISTENを実行し、ほかのユーザーが所有するプロセスも調べてください。

実行元を確認したら、メニューバーのアイコンから該当するクライアントを終了します。macOSでは、ウィンドウを閉じてもアプリが終了するとは限りません。PIDの起動コマンドを詳しく調べるには、次のコマンドを実行します。

ps -p 1234 -o pid=,ppid=,command=

Linux：デスクトップクライアントとサービスの両方を確認

多くのLinuxディストリビューションでは、ssで確認できます。プロセス情報をすべて表示するには、通常、管理者権限が必要です。

sudo ss -ltnp 'sport = :7890'

見つかったカーネルがsystemdサービスから起動されている場合、デスクトップのウィンドウを閉じてもサービスは停止しません。出力にあるプロセスのパスから実行元を確認し、該当するサービス管理画面で重複インスタンスを停止してください。サービス名はインストール方法によって異なるため、ネット上で見つけた名前をそのままこの端末のサービス名だと考えないでください。

  • 127.0.0.1:7890は、IPv4のループバックアドレスで待ち受けていることを示します。
  • 0.0.0.0:7890は、すべてのIPv4インターフェースで待ち受けていることを示します。ループバックアドレスだけにバインドしたインスタンスとも競合する場合があります。
  • [::]:7890はIPv6のワイルドカードアドレスです。IPv4接続も受け付けるかどうかは、システムとソケットの設定によって異なります。

そのため、調査時に127.0.0.1:7890と完全に一致する行だけを探してはいけません。ワイルドカードアドレス、IPv6の待ち受け、ほかのユーザーが実行するサービスも確認してください。

mixed-portを変更：実際に適用される設定を確認

使用中のプロセスを特定したら、対応方法は2つあります。不要な重複インスタンスを終了して7890を使い続けるか、既存のプログラムを残して現在のクライアントを空きポートに変更します。変更前に、上記のコマンドで17890が空いていることを確認してください。以下は、これらの項目に対応したClashカーネルおよびClash Meta（mihomo）向けの設定例であり、サブスクリプションファイル全体ではありません。

まずクライアント側のポート設定を変更

  1. 現在のmixed-port、HTTPポート、SOCKSポート、コントロールインターフェースのアドレスを控え、現在の設定のコピーを保存します。
  2. クライアントの「設定」を開き、「ポート」または「混合ポート」を探します。クライアントによっては「Clash設定」や「カーネル設定」にあります。メニュー名はクライアントごとに異なります。
  3. mixed-portを17890に変更して保存し、クライアントの再起動機能からカーネルを再起動します。
  4. ログを再度開き、新しいポートで待ち受けが開始されたことを確認します。次に、システムのコマンドで17890を使用しているプロセスが想定したカーネルか確認してください。

クライアントがYAMLでこれらの値を管理している場合は、実際に読み込まれるローカル設定または上書き設定を編集します。

# 既存の設定に追加してください。この部分だけで設定全体を置き換えないでください。
mixed-port: 17890
allow-lan: false

allow-lan: falseはLANからの接続を制限する設定であり、ポート競合を解消するスイッチではありません。端末内だけで使う場合、トラブルシューティングのために待ち受けアドレスを0.0.0.0に変更したり、LANアクセスを安易に有効にしたりしないでください。

以前の接続口と設定の上書き元を確認

設定にはport、socks-port、mixed-portが同時に定義されている場合があります。mixed-portを変更しても、ほかの2つの接続口は自動で無効になりません。別の待ち受け項目でエラーが発生している場合は、それぞれ個別に対処してください。同じYAMLマッピング内にmixed-portキーを複数追加しないでください。

サブスクリプションファイルの値が、クライアントの全体設定、マージ設定、上書きルールによって変更されることもあります。ダウンロードしたサブスクリプションを直接編集しても、次回の更新で元の値に戻る場合があります。クライアントが提供する永続設定を使い、起動ログとシステムの待ち受け結果で最終的な値を確認してください。エディターに保存された内容だけで判断しないでください。

9090の競合：外部コントロールポートを個別に対処

ログに9090と明記されている場合は、mixed-portを何度も変更するのではなく、9090を使用しているプロセスを調べてください。コントロールインターフェースは、クライアントやパネルからカーネルを管理するためのものです。ブラウザーでWebページを閲覧するためのHTTPプロキシ接続口ではありません。

# クライアントでコントロールインターフェースをカスタマイズできる場合のみ追加してください。
external-controller: 127.0.0.1:19090

デスクトップクライアントによっては、コントロールアドレスや認証情報を自動管理します。まずクライアントの設定画面から変更してください。自動生成された設定を無理に変更すると、メイン画面からカーネルに接続できなくなる場合があります。外部パネルを手動で接続している場合は、接続先を127.0.0.1:19090に更新し、認証キーも一致させてください。

システムプロキシ、ターミナル変数、アプリ内プロキシを更新

新しいポートで待ち受けが始まった後も、アプリが古いポートを使い続けるのはよくある問題です。この場合、バインドエラーは解消していても、ブラウザーにはプロキシ接続エラーが表示され、ターミナルにはconnection refusedが出ることがあります。プロキシを使う場所を1つずつ確認してください。

システムプロキシ：17890が設定されているか確認

  • Windows 11：「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」→「編集」を開き、アドレスとポートを確認します。クライアントに設定を任せている場合は、通常、クライアントの「システムプロキシ」をいったんオフにしてからオンにすると、設定が再適用されます。
  • macOS：「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」を開き、Webプロキシ、安全なWebプロキシ、SOCKSプロキシのうち、実際に有効な項目を確認します。
  • アプリ内プロキシ：ブラウザーのプロキシ拡張機能、開発ツール、ダウンロードツールには独自の設定がある場合があります。手動で設定した127.0.0.1:7890を127.0.0.1:17890に変更してください。

自動プロキシ構成スクリプト（PAC）を使用している場合、プロキシの接続先は手動プロキシ欄ではなく、スクリプトから返されることがあります。現在のプロキシ設定元を確認してください。拡張機能とシステムプロキシを同時に有効にして、一方だけ変更することのないよう注意しましょう。

ターミナル：環境変数はクライアントの変更に自動追従しない

PowerShellでは、次のコマンドで現在のウィンドウのHTTP・HTTPSプロキシを一時的に更新できます。HTTPS用の変数にもhttp://を指定します。HTTPSリクエストはローカルのHTTPプロキシ経由でCONNECT転送されるためです。

$env:HTTP_PROXY = "http://127.0.0.1:17890"
$env:HTTPS_PROXY = "http://127.0.0.1:17890"

macOSまたはLinuxのsh、bash、zshでは、現在のターミナルで次のコマンドを実行します。

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

大文字・小文字の異なるプロキシ変数に加えて、ALL_PROXYやall_proxyも確認してください。どの設定が優先されるかはツールによって異なります。シェルの起動ファイル、システム環境変数、ツール独自の設定に登録されている場合は、永続化されている箇所も更新してください。一時的なコマンドが反映されるのは現在のプロセスと、その後に起動する子プロセスです。すでに開いている別のターミナルには反映されません。

TUNモードが処理するのは、別のトラフィック経路です。TUNを有効にしても7890は解放されず、バインドに失敗したmixed-portが再び待ち受けを始めるわけでもありません。ローカルポートの調査で、TUNのオン・オフを代替手段にしないでください。

修正を確認：待ち受け、プロキシ経由のリクエスト、再起動後の設定

ノードへの接続失敗をポート競合と取り違えないよう、3段階で確認します。以下は確認用のコマンドであり、応答状態や所要時間を前提としていません。

  1. 待ち受けを確認。上記の確認コマンドで7890を17890に置き換え、PIDとプロセスのパスが現在のクライアントに属していることを確認します。
  2. プロキシを明示してテスト。システムプロキシの自動設定を使わず、新しいローカルポートに直接接続します。
  3. 再起動後に確認。クライアントを正常に終了してから再起動し、サブスクリプションや上書き設定によってポートが元に戻っていないことを確認します。その後、ブラウザーと普段使うターミナルツールでテストしてください。

Windowsではcurl.exeを使い、一部のPowerShell環境でcurlに別名が割り当てられていることによる引数の違いを避けます。

curl.exe --noproxy "" --proxy http://127.0.0.1:17890 --connect-timeout 5 --max-time 20 -I https://clash15.com/

macOSとLinuxでは、次のコマンドを使います。

curl --noproxy "" --proxy http://127.0.0.1:17890 --connect-timeout 5 --max-time 20 -I https://clash15.com/

--noproxy ""を指定すると、既存のプロキシ除外リストを無視して今回のテストを直接実行できます。接続先から応答があれば、今回のリクエスト経路を確認できますが、すべてのノードやルールが正常とは限りません。ローカル接続が拒否される場合は、まず待ち受けを再確認してください。リクエストがカーネルのログに記録された後でDNSエラーや接続先のタイムアウトが発生する場合は、名前解決、ルール、ノードを調べます。

待ち受けプロセスが見つからないのにポートをバインドできない場合

まずエラーの発生中にもう一度確認し、バックグラウンドのインスタンスが一時的に再起動していないか調べます。Windowsでアクセス権に関するエラーが表示される場合は、システムが除外しているTCPポート範囲を確認してください。

netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp

対象ポートが除外範囲内にある場合は、システムの予約項目を削除せず、範囲外の空きポートを使ってください。仮想化機能やネットワークコンポーネントが、これらの範囲を使用している場合があります。最終的に、次の4点を満たしていることを確認してください。想定したインスタンスだけが対象ポートで待ち受けている、起動ログにバインドエラーが出ない、アプリが新しいポートを使用している、クライアントを再起動しても設定が維持されている。

システムプロキシやモードの選択を続けて確認する場合は、システムプロキシの設定手順をご覧ください。リクエストがカーネルに届いた後で接続先がタイムアウトする場合は、接続タイムアウトのトラブル対処をご覧ください。ポートの問題はまずローカル端末で解決してから、サブスクリプションや接続先を確認してください。

Clash インストーラー ダウンロード