Clash が起動できない「ポートが使用中」：Windows で netstat・PID を追い mixed-port を変える実践ガイド

この記事で扱う症状

Clash や Mihomo コアを載せた Windows 向け GUI（Clash Verge 系など）をインストールした直後、アップデート後、あるいは設定を弄ったあとに、起動に失敗してログや画面に次のような文言が出るケースを想定しています。「指定されたポートは既に使用されています」「bind: Only one usage of each socket address」「address already in use」「listen tcp … bind: An attempt was made to access a socket in a way forbidden by its access permissions」など、表現は実装や言語パックで多少違いますが、根っこは同じで、ローカル TCP ポートの二重バインドです。

よく衝突するのは、HTTP 用の port（例：7890）、SOCKS 用の socks-port（例：7891）、HTTP と SOCKS をまとめて受ける mixed-port、ダッシュボード用の external-controller（例：9090）あたりです。どれか一つでも先に別プロセスが LISTENING していると、コアはその段階で止まります。本稿ではファイアウォールを主役にせず、コマンドプロンプトと PowerShell、必要ならリソースモニターを補助的に使い、netstat と プロセス ID（PID） で犯人を特定し、プロセス終了か mixed-port ほかの番号変更のどちらで直すか決める流れを、再現しやすい順に整理します。

なぜポートが埋まるのか

典型原因は次のどれか、あるいは複合です。（1）前回の Clash がトレイに残ったまま、別のショートカットからもう一度起動しようとした。（2）別ブランドのローカルプロキシや開発用プロキシが、同じ 7890 番台を既に掴んでいる。（3）古いサービス登録やタスクスケジューラのエントリが、バックグラウンドで同じ設定を読み込んでいる。（4）Docker Desktop や WSL2 側のポートフォワードとホスト側の期待が食い違っている——などです。Docker 併用時の全体像はDocker Desktop と Clash の併用ガイド、WSL2 経由のルーティング周りはWSL2 ルーティングの記事と役割が分かれますが、「ホスト Windows 上でいま誰がその番号を聞いているか」を押さえるのが第一歩です。

ステップ 1：CMD で netstat し、PID をメモする

スタートメニューで「cmd」と入力し、管理者として実行したコマンドプロンプトを開きます（トレイ常駐のプロキシを落とすときも管理者のほうが手戻りが少ないです）。次のように、問題のログに出ていたポート番号を findstr で絞り込みます。例として HTTP でよく使う 7890 を置いていますが、7891 や 9090、あるいは自分の YAML で指定した mixed-port に読み替えてください。

netstat -ano | findstr :7890

出力のうち、状態が LISTENING の行の末尾に PID（10 進のプロセス ID）が並びます。その数字をメモします。複数行ある場合は、ローカルアドレスが 0.0.0.0:7890 や [::]:7890、あるいは特定 NIC の IP になっているかも確認してください。ループバックのみ 127.0.0.1:7890 で聞いている場合でも、同じ番号は一プロセスしかバインドできないため、新しい Clash が同じ番号を全域バインドしようとすれば衝突します。

ステップ 2：PowerShell でも確認する（任意）

Windows 10／11 では PowerShell から次のように特定ポートの接続と所有者を一覧できます。GUI に慣れている方は、こちらのほうが列が読みやすいことがあります。

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

OwningProcess が PID です。複数バージョンの .NET や権限によってはコマンドが失敗する場合があるので、そのときは前節の netstat に戻れば十分です。

ステップ 3：PID からプロセス名を特定する

PID が分かったら、コマンドプロンプトで次を実行します（12345 を実際の PID に置き換え）。

tasklist /FI "PID eq 12345"

イメージ名が clash.exe、verge-mihomo.exe、別の VPN／プロキシ、あるいは予期しないホストプロセスかを確認します。GUI が好きなら、タスクマネージャーの「詳細」タブで PID 列を表示し、同じ番号を探しても構いません。リソースモニター（resmon）の「ネットワーク」→「リスニング ポート」でも同様に PID とプロセス名の対応が見えます。本稿では主に netstat と tasklist に絞りますが、調査の補助として使ってください。

ステップ 4：終了するか、ポートを変えるか

ここからはリスクの許容度で分岐します。PID が「前回の Clash の残骸」や「もう使っていない別プロキシ」なら、タスクマネージャーから終了するか、コマンドプロンプトで taskkill /PID 12345 /F（管理者）を実行してから Clash を再起動、というのが手早いです。会社支給機や共有 PC では、勝手にプロセスを落とさず IT ポリシーを確認してください。

一方、そのプロセスを止められない・止めたくない場合は、Clash 側のポートを空いている番号に変更します。設定の中心は YAML ですが、多くの GUI は「ポート」画面から mixed-port や HTTP／SOCKS を同期してくれます。変更したら必ず保存してコアを再起動し、同じログに別のポート番号が出ていないかを見ます。

ステップ 5：YAML で揃える項目のチェックリスト

テキストエディタでプロファイルを直接触る場合、次のキーを一巡すると抜け漏れが減ります。

• mixed-port：HTTP と SOCKS を単一ポートで受けるときの番号。ここを変えたら、システムプロキシの「ポート」と一致させるのが最優先です。
• port と socks-port：mixed-port を使わず従来どおり分ける構成なら、両方の空き状況を netstat で確認します。
• external-controller：ダッシュボードや API が 9090 などで衝突しているケースは独立しているので、ログに出た番号をそのまま netstat に渡してください。
• 複数プロファイルを切り替える GUI では、編集中のファイルが本当に起動時に読み込まれているか（ワークスペースディレクトリのミス）も合わせて確認します。

番号の選び方は、IANA の既知ポートと被らないよう 10000 台の空きを選ぶ、といった実務上の慣習に寄せるとトラブルが少ないです。変更後にもう一度 netstat -ano | findstr :新しい番号 を流し、意図したプロセスだけが LISTENING しているか確認すると安心です。

ステップ 6：起動ログとブラウザで確認する

コアが立ち上がったら、ダッシュボードの遅延テストや、単純な HTTPS サイトへの接続でざっくり確認します。トレイアイコンだけ緑でも、実際には別ポートで古いインスタンスが残っている——ということは珍しくないので、占有のあった PID が再出現していないかも合わせて見ます。複数ユーザーセッションがある端末では、他のログオン セッションにプロセスが残っていないかも頭の隅に置いてください。

まとめ

Windows で Clash が「ポートが使用中」で止まるときは、まずログに出ている番号を決め打ちし、netstat -ano と tasklist で PID とプロセス名を突き合わせます。止めてよいプロセスなら終了し、そうでなければ mixed-port ほか関連キーを空き番号へ寄せ、OS やブラウザ側のプロキシ設定まで含めて一貫させる、という順序が再現性が高いです。ファイアウォール以前に「誰がその TCP ポートを聞いているか」を押さえると、原因の八割ほどは地図が描けます。

同種のローカルプロキシの中でも、Clash／Mihomo 系はログにキーワードが出やすく、GUI と YAML の両方から状態を追いやすいのが強みです。別アプリと番号が被ったときも、切り分けの道具立てさえ揃えば復旧は素直です。

安定版ビルドや各クライアントの入手先はダウンロードページにまとめています。ポート設定を直したうえで、用途に合ったパッケージを選ぶと運用が楽になります。→ Clash を無料ダウンロードし、Windows 環境を整える