Clash がポート使用中エラーを出す場合の対処法:7890 ポート競合プロセスの特定とミックスポート変更

エラーメッセージが示す問題

Clash コアは起動時に設定ファイルのポート設定に従ってローカルポートを待ち受けます。デフォルトのミックスポート(mixed-port)は 7890 で、HTTP と SOCKS5 の両プロトコルに対応しています。起動ログに次のような行が出た場合、コアが 7890 ポートへのバインドに失敗したことを意味します。

level=fatal msg="Start Http Server error: listen tcp 127.0.0.1:7890: bind: address already in use"

このエラーはネットワークの接続状況とは無関係で、純粋にOSレベルのポート競合です。すでに別のプロセスが 7890 ポートを監視しているため、新しく起動した Clash コアがそのポートを確保できず、そのまま終了したり、プロキシページに「未起動」と表示されたりします。よくある原因としては、前回の Clash プロセスが完全に終了していない、同じマシンに Clash 系クライアントを二つインストールしている、あるいは他のプロキシソフト(一部のダウンローダーや開発用デバッグプロキシなど)がたまたまデフォルトポートを 7890 に設定している、といったケースが挙げられます。

対処の流れはシンプルです。まずどのプロセスがそのポートを占有しているかを確認し、そのプロセスを終了するか、Clash のポートを別の番号に変更するかを判断します。以下、プラットフォームごとに具体的なコマンドを示します。

Windows:netstat で占有プロセスを特定する

コマンドプロンプトまたは PowerShell を開き、次を実行します:

netstat -ano | findstr 7890

出力の最後の列がプロセス PID です。例:

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    8824

PID を確認したら、タスクマネージャーでその PID に対応するプロセス名を検索するか、コマンドラインで続けて確認します:

tasklist /FI "PID eq 8824"

残留した古い Clash プロセスや、残しておく必要のないプログラムだと確認できたら、そのまま終了させます:

taskkill /PID 8824 /F

占有していたのが Clash 自身の残留プロセス(強制終了後にプロセスが完全に消えていない場合によく見られます)であれば、終了後にクライアントを再起動すれば正常に戻ります。占有していたのが長期間動かしておく必要のある別のプログラムであれば、毎回手動でプロセスを終了させるのではなく、後述のポート変更方法を使うことをおすすめします。

macOS と Linux:lsof または ss で占有プロセスを特定する

macOS と大半の Linux ディストリビューションには lsof コマンドが標準で入っているため、ポート番号で直接調べられます:

lsof -i:7890

出力の COMMAND 列がプロセス名、PID 列がプロセス番号です。例:

COMMAND     PID   USER   FD   TYPE   NODE NAME
clash-core 3021   dev    3u  IPv4        TCP *:7890 (LISTEN)

確認できたら kill でそのプロセスを終了させます:

kill -9 3021

一部の軽量な Linux システム(コンテナイメージやルーター用の OpenWrt など)には lsof がプリインストールされていないことがあります。その場合は ss コマンドを使えば同じ結果が得られます:

ss -tulnp | grep 7890

ss の出力は最後の列にプロセス名と PID がそのまま表示され、形式は users:(("clash",pid=3021,fd=3)) のようになります。同様に kill -9 で終了できます。ss すら入っていない古いシステムでは、netstat -tulnp | grep 7890 で代用でき、原理は同じです。

クライアントで mixed-port を変更する

7890 ポートを使っているプログラムを終了させにくい場合や、このような競合が繰り返し発生する場合は、Clash の待ち受けポートを別の番号に変更して競合そのものを避けるほうが手間がかかりません。変更方法はクライアントによって異なりますが、内部で変更している設定項目は同じです。

方法一:クライアントの設定画面から直接変更する

Clash Verge、Clash Nyanpasu、FlClash などの主要クライアントは「設定」や「一般」のページにポート入力欄を用意しています。「ミックスポート」「Mixed Port」または「ローカルポート」といった項目を探し、使われていない番号に直接変更しましょう。推奨は 10000 以上の高位ポートで、例えば 17890 や 27890 のようにシステムがよく使うポート帯を避けます。保存すると、クライアントが自動的にコアを再起動して反映されます。

方法二:設定ファイルを直接編集する

クライアントに該当する設定項目がない場合や、コマンドラインでコアを実行している場合は、設定ファイルを手動で編集します:

mixed-port: 17890
allow-lan: false
mode: rule
log-level: info

設定ファイルが統合された mixed-port ではなく、従来型の分離ポート方式(port が HTTP、socks-port が SOCKS5)を使っている場合も、競合しているポート番号を同様に変更する必要があります:

port: 17891
socks-port: 17892

ポート変更後に合わせて確認すべき箇所

ポートを変更して設定を保存しただけでは終わりではありません。連動して確認すべき箇所がいくつかあり、見落とすと「プロキシは起動しているのに反映されていない」ように見えることがあります:

• システムプロキシ設定:クライアントで「システムプロキシとして設定」のようなスイッチをオンにしている場合、システム側に記録されているポート番号は古い値のままです。一度スイッチをオフにしてから再度オンにし、システムプロキシ設定を新しいポートに更新してください。
• ブラウザ拡張機能:一部のブラウザ拡張(SwitchyOmega のようなプロキシ切り替え系拡張)は、独自にポート設定を保存しており、クライアントの設定とは別のデータです。拡張機能の設定画面から手動で新しいポートに変更する必要があります。
• コマンドラインツールのプロキシ環境変数:export https_proxy=http://127.0.0.1:7890 のようなコマンドでターミナルにプロキシを設定している場合は、ポート番号も一緒に変更してください。変更を忘れるとターミナルからのリクエストは古いポートを指したままになり、接続に失敗します。
• LAN内の他デバイス:このパソコンのLANプロキシ経由でインターネットに接続している他のデバイスがある場合、そちら側に保存されているアドレスのポート番号も更新が必要です。

よくあるポート占有の原因

Clash 自身の残留プロセス以外にも、7890 ポートの競合は次のようなプログラムが原因になることが多く、優先的に疑ってみるとよいでしょう:

1. Clash 系クライアントを二つ同時にインストールしている:例えば同じパソコンに Clash Verge と ClashX Meta を両方入れている場合、どちらもデフォルトポートは 7890 なので、一方が先に起動すればもう一方は必ず競合します。常用するクライアントは一つに絞ることをおすすめします。
2. コマンドラインでコアを実行した後**正しく終了させていない:ターミナルから手動でコア本体を実行してデバッグしている際、Ctrl+C 以外の方法でターミナルウィンドウを強制的に閉じると、コアプロセスが孤立プロセスとなってポートを占有し続けることがあります。前述のコマンドで手動で見つけて終了させる必要があります。
3. 他のプロキシ・パケットキャプチャツール:一部のネットワークデバッグツールやダウンロードマネージャーに内蔵されたプロキシモジュールが、たまたま 7890 というよく使われるポート番号を使用していることがあり、Clash と競合する可能性は低くありません。
4. 仮想マシンやコンテナのポートマッピング:ローカルで仮想マシンや Docker コンテナを動かしていて、コンテナ内のサービスをホストマシンの 7890 ポートにマッピングしている場合も占有の原因になります。この場合は Clash 側ではなく、コンテナのマッピングポートを変更することをおすすめします。

競合の原因を特定したあとは、占有プロセスを終了させるか Clash のポートを変更するかを、どちらのプログラムをデフォルトポートに固定しておく必要があるかで判断します。日常的な利用シーンの大半では、Clash の mixed-port を使われていない高位ポートに変更しておくのが最も手間のかからない解決策で、変更後は同様の競合にほぼ遭遇しなくなります。