こんなログ・症状のとき読む記事
Clash for Windows や Clash Verge Rev、その他 Mihomo コアを同梱する GUI を、初回導入・アップデート直後に起動しようとすると、画面は開かない／すぐ終了する、ログに bind: Only one usage of each socket address や日本語環境では「アドレスは既に使用中」に相当する文言、英語メッセージでよく出る address already in use が並ぶ、といったパターンがあります。更新で再起動したつもりでも旧プロセスがタスクバックグラウンドに残ったままになっていると、同じ番号のポート（特に REST API の待ち受け口）を二度目が奪えずに失敗します。
一方で、原因が常に Clash 本体とは限りません。開発用 Web サーバー、別のプロキシ／VPN ツール、遠隔管理ソフト、あるいは誤って二重起動した同系アプリが、偶然としても同じ TCP ポート を LISTEN しているケースもあります。ここでは Windows 標準の手段として netstat で「誰がどのポートを掴んでいるか」を数字で突き止め、必要なら設定側の external-controller（外部から API を叩く 制御ポート）を空き番へ逃がす流れを、コピー＆ペーストしやすい形に整理します。関連トピックは ブログ一覧 からも辿れます。
external-controller は、ブラウザ拡張や GUI が http://127.0.0.1:番号 経由でコア設定や接続状態を操作するための待ち受け口です。既定値が 9090 付近であることが多く、ここが衝突すると「プロキシそのものより先に」起動段階で止まりがちです。mixed-port（例：7890）や port も別問題で塞がれることがありますが、まずはログに出た番号を優先してください。
準備：管理者権限のコマンドプロンプト／PowerShell
ポートを掴んでいるプロセスを強制終了する場合、権限不足で拒否されることがあります。手順の後半で taskkill を使う予定があるときは、開始メニューから「コマンド プロンプト」または「Windows PowerShell」を管理者として実行しておくと安全です。単に netstat で番号と PID を眺めるだけなら、通常権限でも問題ないことが多いですが、トラブルが続くときは管理者コンソールに切り替えて再試行してください。
ステップ 1：netstat で LISTENING と PID を拾う
まず、衝突が疑われるポート番号を一つ決めます。ログに listen tcp 127.0.0.1:9090 のように出ていれば 9090 です。不明なときは、よく使われる 9090（制御）、7890（mixed／HTTP 兼用）、7891（SOCKS）あたりを順に当たります。
管理者でなくてよいコマンド例は次のとおりです（ポートを 9090 にした例。必要に応じて置き換えてください）。
netstat -ano | findstr :9090netstat の -a は全接続、-n は番号表示、-o は PID 表示です。出力のうち LISTENING の行に注目し、右端の数字がプロセス ID です。複数行あれば、そのいずれもが「そのポートに触れている候補」です。別のポートを見るときは findstr の後ろだけ差し替えれば足ります。
より絞り込みたい場合は、PowerShell で Get-NetTCPConnection -LocalPort 9090 のようにローカルポート指定で調べる方法もありますが、環境によってはモジュールの表示形式が異なるため、本記事では互換性の広い netstat を主に据えます。
ステップ 2：PID からプロセス名を特定する
PID だけでは何のアプリか分からないので、同じコンソールで実行名を引き当てます（12345 は例です）。
tasklist /FI "PID eq 12345"表示された イメージ名 が clash.exe、clash-windows.exe、verge-mihomo.exe のような Clash 系であれば、二重起動かアンインストール残りが有力です。node.exe や java.exe、製品付きのバックグラウンドサービスであれば、別アプリがポートを消費している可能性を疑ってください。
GUI 中心で進めたい場合は、タスク マネージャーの「詳細」タブで PID 列を表示し、該当行を右クリックして「ファイルの場所を開く」と、どのフォルダの実行ファイルかまで辿れます。第三者の「怪しい」実行ファイルの場合は、安易に kill せず提供元を確認するのが安全です。
ステップ 3：安全にプロセスを止める（二重起動の解消）
Clash 本体の残プロセスであれば、タスクトレイのアイコンから「終了」「Quit」が選べる場合はそれが最優先です。反応しないときに限り、対象 PID を指定して終了を試みます（管理者コンソール推奨）。
taskkill /PID 12345 /F終了後、もう一度 netstat -ano | findstr :9090 を流し、LISTENING が消えたかを確認してください。そのうえで Clash を起動し直します。毎回これが必要なら、スタートアップへの二重登録や、常駐型アップデータと手動起動の競合を疑い、起動経路を一つにそろえると再発を抑えやすくなります。
taskkill /F は保存されていない作業中データのあるアプリにも効いてしまいます。PID がシステムや不明な商用ソフトの場合は、終了前にサービス／製品ドキュメントを確認してください。
ステップ 4：設定で external-controller（制御ポート）を変える
どうしても同じ番号が必要な別プロセスと同居させる必要がある、あるいは将来の衝突を避けたい、という場合は Clash 側の待ち受け番号を変更します。コアが読む config.yaml（または GUI が生成する同等の項目）に、だいたい次のような行があります。
external-controller: 127.0.0.1:9090ここを例えば空いていそうな 127.0.0.1:9191 や 127.0.0.1:59090 へ変更し、保存したうえで GUI を再起動します。併せて secret を設定している場合は、ダッシュボードや拡張側の認証情報も揃えないと API が 401 になる点に留意してください（ポートだけ変えて本体が無断で外部公開にならないよう、基本的にループバック拘束のままが無難です）。
GUI（例：Clash Verge Rev）では「コア設定」「設定ファイル」「API ポート」などの名称で同一項目が並ぶことがあり、YAML 直編集と画面上書きが二重になる場合は、最後にどちらが効いているかログで確認すると混乱が減ります。また mixed-port を同時に変える必要は、ログのエラー行がそちらを指しているときだけで構いません。
その他のよくある衝突相手
開発サーバー（例：localhost の特定ポートで待ち受けるツール）を常時立ち上げている環境では、たまたま Clash の既定ポートと一致することがあります。仮想化ソフトや別ブランドの VPN が同じ帯域を掴むケースもあるため、問題が続くときは一時的に競合候補を終了させ、差分で切り分けると確実です。
一方で、プロキシが効いているかどうかの話題としては、ポート競合とは別軸で システムプロキシ とアプリ特性の問題が出ることがあります。Windows 11 環境でブラウザやストアアプリだけ挙動が崩れる場合は、システムプロキシ関連の記事 をあわせて参照してください。レイヤを一段下に取り込むなら TUN モード解説 が補助線になります。
まとめ：Clash のポート占有は「番号・PID・設定」の三点セット
ポートが占有されているせいで Clash が起動に失敗するときの実務的な筋道は、ログの番号を読む → Windows netstat で LISTENING と PID を拾う → 安全にプロセスを終了するか、external-controller を空いているポートへ移す、の三点に集約できます。制御ポートは機能追加で重要性が増した一方、衝突時のエラーもここに出やすい点を押さえておくと、原因当たりが速くなります。
入手元が揃っていれば、アップデートや再インストール後の挙動説明もブレにくいです。初回セットアップから ダウンロードページ でパッケージを選び、バージョンと設定ファイルの場所を固定しておくと、同種のトラブルでもログと設定を突き合わせやすくなります。安定運用の前提は分流ルールだけでなく、まず通信の土台となるポートとプロセスが一本化されているかです。その確認の仕方として、本記事の netstat 手順をブックマークしておいてください。