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

7897番ポートの競合を解消する方法｜使用中のプロセスを特定して待受ポートを変更

Windows、macOS、Linuxでポートを使用中のプロセスを特定し、クライアント設定で混合ポートを変更してシステムプロキシを再設定する方法を解説します。

まず7897番ポートの待受失敗か接続失敗かを確認

Clash Verge Revの混合ポートは、mihomoの設定にあるmixed-portに対応します。このポートはHTTPプロキシとSOCKS5プロキシの両方の接続を受け付けます。この記事では、確認対象のポートを7897、変更先の例を7898とします。実際の値はクライアントの設定とコアのログで確認してください。例示したポートがすべての環境で使われているとは限りません。

ポート競合は、ローカルで待ち受けを開始する段階で発生します。クライアント画面は開けても、コアのログにbind、address already in use、またはWindowsの「通常、各ソケット アドレスに対して使用できるのは 1 つだけです」というエラーが表示されることがあります。この場合、サブスクリプションの更新に成功し、ノードの遅延が正常でも、ローカルのプロキシ接続口が使えるとは限りません。

listen tcp 127.0.0.1:7897: bind: address already in use

上記はよくあるエラーの例です。実際のログでは先頭部分が異なる場合があります。まず「ログ」ページで7897とbindを検索し、下の表を参考に問題を切り分けましょう。あらゆるネットワークエラーをポート競合と決めつけないことが大切です。

ログまたは症状優先して確認する項目
address already in use同じアドレス・ポートで待ち受けているプロセス、およびワイルドカードアドレスでの待受
connection refusedアプリが接続しているアドレスとポートで、サービスが実際に待ち受けているか
access permissions / permission deniedシステム予約済みポート、権限の制限、セキュリティソフトの設定
接続後にタイムアウトするノード、ルール、DNS、接続先サイト。ローカルポート以外も確認

Windows：PowerShellで待受プロセスを特定する

手順1：ローカルの待受ポートだけを確認

PowerShellを開き、次のコマンドを実行します。通常のターミナルで情報をすべて取得できない場合は、管理者として開き直してください。ここではローカルポートとListen状態で絞り込むため、接続先のポートがたまたま7897である通信を競合と誤認しません。

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

OwningProcess列はプロセスID（PID）です。実際の出力に表示された番号を控え、プロセス名とパスを確認してください。次のコマンドでは待受プロセスのPIDを取得します。変数には$ownerPidを使い、PowerShellの組み込み変数$PIDには代入しないでください。

$owners = Get-NetTCPConnection -LocalPort 7897 -State Listen -ErrorAction SilentlyContinue |
  Select-Object -ExpandProperty OwningProcess -Unique

foreach ($ownerPid in $owners) {
  Get-Process -Id $ownerPid |
    Select-Object Id, ProcessName, Path
}

手順2：別のクライアントのプロセスか確認

mihomoや別のプロキシクライアントが見つかった場合は、まずタスクトレイとタスクマネージャーを確認してください。ウィンドウを閉じてもプログラムが終了せず、バックグラウンドで動き続けることがあります。サービスモードでは、コアがシステムサービスとして管理されている場合もあります。プロセス名だけで強制終了せず、該当クライアントの「終了」操作やサービス管理画面から停止してください。

プロセス終了後すぐに別のPIDで再び現れる場合は、バックグラウンドサービスやランチャーが再起動している可能性があります。プロセスを何度終了しても競合は解消しません。該当サービスを停止するか、2つのプログラムで異なるポートを使ってください。proxy、clash、mihomoを含む名前のプロセスをまとめて終了するのは避けてください。

待受プロセスが見つからないのにバインドできない場合

まず、エラーに表示されたアドレスとプロトコルを確認します。IPv4の0.0.0.0:7897は、ループバックアドレスだけでなく、すべてのIPv4インターフェースで待ち受けることを示します。ループバックアドレスでの待受と競合する場合もあります。ログにアクセス権限エラーが明記されている場合は、WindowsのTCP除外ポート範囲も確認してください。

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

7897が除外範囲に含まれている場合は、範囲外で、ほかのプロセスも待ち受けていないポートに変更してください。プロキシのポート問題を解決するために、システムの除外設定を削除するのは避けましょう。仮想化ソフト、コンテナ、ネットワークコンポーネントがこれらの設定を利用している可能性があります。

macOS・Linux：PIDからプロセスの実体を確認

macOS：lsofでTCPの待受を確認

「ターミナル」を開き、次のコマンドを実行します。-nPはアドレスとポートを数値で表示し、-sTCP:LISTENは待受ソケットだけに絞り込みます。sudoを使うと、権限不足によって別ユーザーのプロセスを見落としにくくなります。

sudo lsof -nP -iTCP:7897 -sTCP:LISTEN

出力のCOMMANDはプログラム名、PIDはプロセスID、NAMEは待受アドレスです。起動コマンド全体を確認する場合は、見つかったPIDを指定して次のコマンドを実行します。

read -r owner_pid
ps -p "$owner_pid" -o pid=,user=,command=

旧クライアントのプロセスだと確認できたら、メニューバーから該当アプリを終了します。バックグラウンドサービスによって起動されている場合は、サービスの所属を確認してから停止してください。システムプロセスや出所の分からないプログラムは安易に終了せず、Clash Verge Revのポートを空いている番号に変更する方法もあります。

Linux：ssで待受とプロセスを確認

ターミナルで次のコマンドを実行します。-lは待受、-tはTCP、-nは数値表示、-pは関連プロセスの表示を指定します。プロセスの詳細を確認するには、通常、管理者権限が必要です。

sudo ss -ltnp 'sport = :7897'

systemdが管理するプロキシサービスが表示された場合は、そのサービスに適した方法で停止してください。コアのプロセスだけを終了すると、自動的に再起動する可能性があります。ログにUDPのバインド競合が明記されている場合に限り、UDPも個別に確認しましょう。異なるプロトコルで同じ番号のポートを使っていても、すべて同じ競合とは限りません。

sudo ss -lunp 'sport = :7897'
  • 出力なし：今回の検索では該当する待受が見つからなかったという意味です。今後もポートを使える保証ではなく、起動時に別のプログラムが先にバインドする可能性があります。
  • 127.0.0.1で待受：通常はこの端末内からの利用に限られます。競合の解消を目的に、外部からアクセスできる設定へ変更する必要はありません。
  • 0.0.0.0または[::]で待受：ワイルドカードアドレスでの待受です。IPv6デュアルスタックの動作は、システムやソケットのオプションによって異なるため、実際のログと合わせて判断してください。

混合ポートを7897から7898に変更する

対処方法は2つあります。使わなくなったプログラムを停止して7897を使い続けるか、既存のプログラムはそのままにしてClash Verge Revを別の空きポートに変更します。2つのクライアントを同時に使う必要がある場合は、後者が手軽です。ただし、両方のクライアントがシステムプロキシを繰り返し書き換えないようにしてください。

  1. 先ほどのOS別コマンドで7898を確認し、該当ポートを使用中のプロセスがないことを確かめます。Windowsでは、除外ポート範囲に含まれていないかも確認してください。
  2. Clash Verge Revを開き、「設定」から「Clash設定」にある「混合ポート」欄を探します。バージョンによって関連項目が設定ダイアログ内やポート設定のセクションにある場合があります。画面上の「混合ポート」という項目名を目印にしてください。
  3. 値を7897から7898に変更して保存します。コアの再起動を求められた場合は、画面の指示に従ってください。その後、「ログ」ページで新しいアドレスの待受を確認します。
  4. 7898の待受プロセスをもう一度確認し、別のプロセスではなく、現在のクライアントが使っているコアかどうかを確かめます。

mihomoのYAMLでは、該当するフィールドは次のとおりです。これはフィールドの意味を示す例であり、サブスクリプションのファイルを同時に編集する必要はありません。

mixed-port: 7898

Clash Verge Revでは、クライアント設定がサブスクリプション内の共通フィールドより優先されることがあります。そのため、ダウンロードしたYAMLを直接編集しても最終的な待受ポートに反映されるとは限らず、サブスクリプションの更新で手動変更が上書きされる場合もあります。クライアントの設定画面を優先して使い、起動ログとOSの待受情報で反映された値を確認してください。設定の上書きを管理する方法は応用設定をご覧ください。

システムプロキシ、ターミナル変数、アプリの設定を同期

コアの待受ポートを7898に変更したのに、アプリが7897へ接続し続けるのは、ポート変更後によくある見落としです。ポートを移行するときは「待ち受ける側」と「接続する側」の両方を確認しましょう。クライアントが管理するシステムプロキシを更新しても、ブラウザー拡張、ターミナルの環境変数、プロキシを手動設定した開発ツールまで自動で変わるとは限りません。

システムプロキシを設定し直す

新しいポートを保存したら、「設定」で「システムプロキシ」をいったんオフにしてからオンにし、クライアントにプロキシアドレスを再設定させます。続いてOSの設定を確認してください。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」、macOSでは「システム設定」→「ネットワーク」→使用中のネットワーク接続→「詳細」→「プロキシ」です。Linuxの設定場所はデスクトップ環境によって異なり、デスクトップのプロキシ設定を参照しないアプリもあります。

ローカルプロキシのアドレスには通常127.0.0.1を使い、ポートには新しい待受ポートを指定します。HTTPやHTTPS宛ての通信は、同じHTTPプロキシ経由で転送できます。これは、ローカルプロキシのアドレスをhttps://で指定する必要があるという意味ではありません。別のクライアントもシステムプロキシを有効にしている場合は、設定が交互に上書きされないよう、そちらの機能をオフにしてください。

ターミナルと開発ツールの設定も個別に確認

開いたままのターミナルには、古いHTTP_PROXY、HTTPS_PROXY、ALL_PROXYが残っている場合があります。次のコマンドで変更されるのは現在のターミナルセッションだけで、システム設定は永続的には変更されません。

# macOS / Linux：現在のシェルセッション
export HTTP_PROXY=http://127.0.0.1:7898
export HTTPS_PROXY=http://127.0.0.1:7898
export ALL_PROXY=socks5h://127.0.0.1:7898
# Windows PowerShell：現在のセッション
$env:HTTP_PROXY = "http://127.0.0.1:7898"
$env:HTTPS_PROXY = "http://127.0.0.1:7898"
$env:ALL_PROXY = "socks5h://127.0.0.1:7898"

これらの環境変数を参照するかどうかは、アプリの実装によって異なります。ブラウザーのプロキシ拡張、Gitのプロキシ設定、エディターのネットワーク設定、コンテナ内の環境変数には、それぞれ独立した値が保存されていることがあります。ブラウザーを再起動するだけでなく、7897を使い続けている設定を一つずつ確認してください。

TUNモードと混合ポートは別の機能

TUNモードは仮想ネットワークインターフェースを通じて通信を取り込みます。一方、混合ポートはアプリが接続するローカルのプロキシ接続口です。mixed-portを変更しても、TUNのルーティングやDNS設定は自動で変わりません。アプリに古いプロキシポートが明示されている場合は、TUNを有効にしていても接続エラーが続くことがあります。ポート競合の対処としてTUNを有効にするのは避けてください。

新しいポートを確認：待受を確認してからリクエストをテスト

確認は段階的に行います。まず正しいコアがポートを待ち受けていることを確かめ、その後、プロキシを明示してリクエストを送信してください。Webページが開けただけでは修復完了と判断できません。キャッシュが表示されたり、プロキシを使わず直接接続したり、別のネットワーク経路を通ったりする可能性があります。

  1. OSに応じた待受確認コマンドを再実行し、ポートを7898に変更して、プロセスと待受アドレスを確認します。
  2. 「ログ」ページを開き、再読み込み後に新たなbindエラーが発生していないことを確認します。
  3. 次のHTTPプロキシテストを実行し、「接続」ページで宛先とルールの適用結果を確認します。
# macOS / Linux
curl --noproxy "" --proxy http://127.0.0.1:7898 --connect-timeout 5 --max-time 15 -I https://example.com

# Windows PowerShell
curl.exe --noproxy "" --proxy http://127.0.0.1:7898 --connect-timeout 5 --max-time 15 -I https://example.com

接続タイムアウトは5秒、全体のタイムアウトは15秒です。これらはテスト用の設定であり、実測の遅延ではありません。--noproxy ""は、既存のプロキシ除外リストの影響を避けるための指定です。HTTPレスポンスが返れば、ローカルプロキシ経由でリクエストが処理されたことは分かりますが、ステータスコードが必ず200になるとは限りません。また、ルールによって接続先がDIRECTに振り分けられることもあるため、接続の詳細も確認してください。

127.0.0.1:7898にすぐ接続できない場合は、待受の確認に戻ってください。ローカルプロキシへの接続後にTLS、DNS、上流接続のタイムアウトが発生する場合は、ノード、名前解決、ルールを確認します。この段階では、ローカルポートを何度も変更しても通常は解決しません。

よくある疑問：ポート変更後もエラーが続く場合

7897の記録が複数行ある場合、複数のプログラムが競合していますか？

必ずしもそうとは限りません。同じPIDがIPv4とIPv6の両方で待ち受けていたり、確立済みの接続が複数表示されたりすることがあります。出力行数だけでなく、待受状態、アドレス、プロトコル、PIDを確認してください。TCPのTIME_WAITレコードは、現在も待ち受けているプロセスとして扱わないでください。

画面を閉じてから、もう一度起動するだけでよいですか？

手順としては問題ありませんが、結果の確認に代わるものではありません。トレイに常駐していたり、サービスモードが動いていたり、別のクライアントが起動していたりすると、コアが動作し続けることがあります。終了後にポートを再確認して、待受が本当に解放されたか確かめてください。再起動後も、新しい待受プロセスを確認しましょう。

「LANからの接続を許可」を有効にすれば競合を解消できますか？

一般的な解決方法として使うことはできません。この設定は待受範囲に関わり、ループバックアドレスだけでなく複数のインターフェースで待ち受けるようになると、既存の待受と競合する可能性もあります。端末内だけで使う場合はローカルアクセスのままにしてください。LANで共有する場合は、ファイアウォールとアクセス制御も確認する必要があります。

クライアントの再インストールやサブスクリプションの削除は必要ですか？

通常は必要ありません。サブスクリプションにはノードやルールが含まれますが、ポート競合はローカルのソケットをバインドする段階で発生します。まず待受プロセスを特定し、空きポートを選び、プロキシを使うすべてのアプリの設定を同期してから、リクエストを検証してください。インストールやサービス自体に問題があると確認できた場合に限り、該当コンポーネントを調査しましょう。最初からすべての設定を消去する必要はありません。

Clashクライアントをダウンロード