Clash のポート競合対処法:7890 番ポートの占有調査と待受ポート変更の全手順

起動時に address already in use と出ても、慌てて再インストールしたりクライアントを乗り換えたりする必要はありません。sslsofnetstat を使って 7890 番ポートを占有している具体的なプロセスを見つけ出し、そのプロセスを終了すべきか別のポートに切り替えるべきかを判断してから、mixed-port を変更してシステムプロキシ設定も同期更新すれば、数分で解決できます。

ポート競合はなぜ起こるのか

Clash のコア(オリジナルの Clash でも Mihomo でも)は起動時にプロキシ通信を受け付けるローカルポートをバインドします。よく使われる既定値は 7890 番で、設定ファイル上は mixed-port フィールドに対応します(旧バージョンでは portsocks-port の 2 つに分かれていましたが、現在は多くのクライアントで HTTP と SOCKS5 の両方に対応する mixed-port に統一されています)。すでに別のプロセスがこのポートを使用していると、コアがポートのバインドに失敗し、ログには次のような内容が出力されるのが典型的です。

ERRO[0000] Start HTTP server error: listen tcp 127.0.0.1:7890: bind: address already in use

エラーの原理は単純で、同じポートを同時に独占監視できるのは 1 つのプロセスだけという点にあります。競合が起こる原因は大きく 3 パターンです。1 つ目は多重起動で、前回の Clash プロセスが正常終了しないままもう一つ起動してしまい、旧プロセスがポートを掴んだままになっているケース。2 つ目は他のソフトが先にポートを占有しているケースで、他のプロキシツール(v2ray、trojan、別系統の Clash クライアントなど)や、開発環境上のローカルサービス、コンテナがマッピングしているポートなどが該当します。3 つ目は同じマシン上で Clash 関連サービスが二重に動いているケースで、システムサービスとして動く clash とユーザーが手動で立てたテスト用インスタンスが同時に存在している場合などです。

原因がどれであっても対処の考え方は同じです。まずどのプロセスがポートを占有しているかを特定し、そのプロセスを終了するか Clash のポートを変更するかを決めます。

ss / lsof / netstat でポート占有プロセスを特定する

Linux にはポート占有状況を確認するためのコマンドが 3 つよく使われます。どれか 1 つ使えれば十分ですが、主要ディストリビューションに標準搭載されていて性能も良い ss を優先的に使うのがおすすめです。

方法 1:ss コマンド

sudo ss -tulnp | grep 7890

出力にはローカルアドレス、ポート番号、そのポートを占有しているプロセス名と PID が表示され、次のような形になります。

tcp   LISTEN 0      4096   127.0.0.1:7890   0.0.0.0:*   users:(("mihomo",pid=8123,fd=12))

カッコ内の pid=8123 がポートを占有しているプロセス ID で、"mihomo" がプロセス名です。ここに表示されているのがまさに Clash 自身のコアプロセス(mihomo または clash)であれば、前回のプロセスが正常終了していなかったことが原因なので、その旧プロセスを終了してからクライアントを再起動すれば解決します。

方法 2:lsof コマンド

ss が入っていない環境や lsof を使い慣れている場合は、以下のように確認できます。

sudo lsof -i :7890

出力には COMMAND、PID、USER といった項目が並び、同様に占有プロセスの名前と PID を確認できます。lsof はミニマル構成のディストリビューションでは別途インストールが必要な場合があり、Ubuntu/Debian 系なら sudo apt install lsof、Fedora 系なら sudo dnf install lsof で導入できます。

方法 3:netstat コマンド

netstat は新しいディストリビューションでは ss に置き換わりつつありますが、古いスクリプトや解説記事ではまだよく使われています。確認方法は次の通りです。

sudo netstat -tulnp | grep 7890

3 つのコマンドで得られる情報の本質は同じなので、自分の環境で動くものを 1 つ選べば十分で、すべて入れる必要はありません。

ヒント

grep で何も表示されない場合、実際には 7890 番ポートは占有されていないことになります。この場合は設定ファイル内の別の記述ミス(たとえば bind-address の設定不備)や権限不足によるバインド失敗が原因である可能性が高く、単純なポート競合とは異なるため、ポートの問題にこだわらず起動ログ全体を確認するのが先です。

プロセスを終了すべきか、ポートを変更すべきか

占有しているプロセスを特定できたら、対処方法はそのプロセスの種類によって変わります。

  • Clash/Mihomo 自身の残留プロセスの場合:前回正常終了しなかったことが原因なので、この PID を終了してクライアントを再起動するだけで解決し、設定変更は不要です。
    sudo kill 8123
    # 通常の終了が効かない場合はこちら
    sudo kill -9 8123
  • 他のプロキシツールや常時稼働しているサービスの場合:こうしたプロセスには明確な用途があるため無闇に終了するのは避け、Clash 側で競合しない別のポートに変更するのが安全な方法です。
  • 用途が分からない、判断のつかないプロセスの場合:まず ps -p PID -o comm=,args= で完全な起動コマンドを確認し、システムの重要なサービス(コンテナのネットワークコンポーネントやデータベースのプロキシクライアントなど)かどうかを見極めます。判断がつかない場合はプロセスを終了するよりポートを変更する方を優先し、他で使用中のサービスへの影響を避けましょう。

一般的な判断基準としては、競合相手が Clash 自身の旧プロセスであれば終了するのが最もクリーンな解決策です。無関係な第三者のサービスが競合相手の場合は、プロセスを終了するよりポートを変更する方が安全で、特にサーバーや複数人で共用しているマシンでは、見慣れないプロセスを不用意に kill するリスクが高くなります。

mixed-port を変更してコアを再起動する

ポートを変更することが決まったら、Clash の設定ファイルを探します(GUI クライアントであれば設定画面から設定ファイルのパスを確認できることが多く、コマンドライン構成でよく見られるパスは ~/.config/clash/config.yaml/etc/clash/config.yaml です)。mixed-port を占有されていないポートに変更します。たとえば 7891 番などです。

mixed-port: 7891
allow-lan: false
bind-address: "*"
mode: rule
log-level: info

設定ファイルにまだ古い形式の portsocks-port の分離記述が残っている場合は、これらも合わせて変更し、他の場所に旧ポート番号が残っていないか確認してください。

port: 7891
socks-port: 7892

ポートを変更したら、その新しいポート自体が占有されていないかも先に確認する必要があります。前の手順同じく ss -tulnp | grep ポート番号 で再チェックしておくと、変更したのに別の競合にぶつかるという事態を避けられます。問題なければ、Clash のサービスまたはクライアントを再起動して設定を反映させます。

# systemd で管理している場合
sudo systemctl restart clash

# コアを手動で動かしている場合。まず旧プロセスを終了してから再起動
sudo pkill mihomo
mihomo -d /etc/clash

再起動後にもう一度起動ログを確認し、bind: address already in use のエラーが出ていないこと、待受ポートが新しいポートに切り替わっていることを確認します。

sudo ss -tulnp | grep mihomo

システムプロキシ設定の同期更新

mixed-port を変更しただけでは、コアの待受先が変わったに過ぎません。OS やブラウザ側のプロキシ設定に旧ポート番号がまだ残っていると通信は依然として通らず、この手順はよく見落とされがちで、「ポートを変更したのに反映されていない」という誤解につながります。

GNOME デスクトップ環境の場合

gsettings set org.gnome.system.proxy mode 'manual'
gsettings set org.gnome.system.proxy.http host '127.0.0.1'
gsettings set org.gnome.system.proxy.http port 7891
gsettings set org.gnome.system.proxy.https host '127.0.0.1'
gsettings set org.gnome.system.proxy.https port 7891

「設定 → ネットワーク → ネットワークプロキシ」の GUI から直接ポート番号を新しい値に変更することもできます。

コマンドラインの環境変数の場合

環境変数でプロキシを通す方式に慣れている場合も、同様にポート番号を変更する必要があります。~/.bashrc~/.zshrc に書いておくと恒久的に反映されます。

export http_proxy="http://127.0.0.1:7891"
export https_proxy="http://127.0.0.1:7891"
export all_proxy="socks5://127.0.0.1:7891"

変更後は source ~/.bashrc を実行して現在のターミナルに即時反映させることを忘れずに。そうしないと、すでに開いているターミナルウィンドウは旧ポートを使い続けます。

ブラウザ拡張機能の場合

SwitchyOmega のようなプロキシ切り替え拡張機能でプロキシルールを設定している場合も、拡張機能の設定画面からポート番号を 7890 から新しいポートに変更する必要があります。拡張機能側のポート設定とシステム側のポート設定は独立しており、互いに連動しません。

注意

TUN モードを有効にして全体の通信を横取りしている場合、TUN モード自体は mixed-port の HTTP/SOCKS ポートを経由しないため、理論上は今回のポート競合の影響を受けません。ただし、システムプロキシやブラウザ拡張機能が旧ポートを指すまま残っていると、TUN モードを終了した際にそれらの設定が無効になるため、あわせて確認しておきましょう。

見落としやすいその他の注意点

  • 自動起動スクリプル内の旧ポート番号:systemd などで自動起動を設定している場合、起動スクリプトや環境変数ファイルにポート番号がハードコードされていることがあります。設定ファイル内の mixed-port だけを変更しても不十分で、起動スクリプト側も併せて確認しましょう。
  • 外部コントロールパネルのポート:設定内の external-controller(通常は 9090 番)は Clash の API 管理用ポートで、プロキシ用の mixed-port とは独立したフィールドです。9090 番も占有されるとパネルが開かなくなりますが、対処方法は同様なので個別に調査すれば解決できます。
  • 複数ユーザーが同じマシンを共用する場合:同一サーバー上で複数のユーザーがそれぞれ Clash の設定を動かしている場合は、ユーザーごとに異なるポート範囲を割り当てておくと競合を避けやすくなります。たとえばユーザー A に 7890〜7899、ユーザー B に 7900〜7909 を割り当てる、といった運用です。
  • Docker コンテナ環境の場合:Clash をコンテナ内で動かしている場合、ポート競合はホスト側のポートマッピング層で発生することもあります。この場合はコンテナ内部の mixed-port ではなく、ホスト側の docker ps で確認できるポートマッピング設定をチェックする必要があります。

よくある質問

ポートを変更してもブラウザがプロキシに接続できない場合は? 多くはシステムプロキシ設定やブラウザ拡張機能側のポート番号が同期更新されていないことが原因です。上記の「システムプロキシ設定の同期更新」の各項目を順番に確認してください。

PC を再起動するたびにポート競合が起こるのはなぜ? 自動起動用の Clash サービスを設定しているのに、手動でもアイコンをダブルクリックしてクライアントを起動する習慣があると、2 つのインスタンスが同じポートを取り合う結果になります。起動方法をどちらか一方に統一すれば解決します。

占有プロセスを終了してもまだ起動できない場合は? ss -tulnp | grep ポート番号 でポートが本当に解放されているかもう一度確認してください。プロセス終了後もポートが一時的に TIME_WAIT 状態になることがあるので、数秒待つか別のポートで試してみると原因を絞り込めます。

Clash クライアントを入手する

ダウンロードページでは Linux、Windows、macOS など各プラットフォーム向けのクライアントとコアを選択できます。設定に関する疑問があれば、先に利用ガイドを確認するのもおすすめです。

ダウンロードページへ 利用ガイドを見る
Clash をダウンロード