v2rayNのローカルポートが使用中：プロセスの特定と10808の待ち受けポート変更

1. 10808のバインド失敗：待ち受けポートとノードのポートを区別する

v2rayNはクライアントの画面を提供し、ローカルプロキシの待ち受けは通常、起動したプロキシコアが担当します。アプリはまず 127.0.0.1:10808 などのローカルアドレスに接続し、コアが設定に従って外部への接続を処理します。ログに記録されたローカルのバインド失敗は、この入口で起きています。最初にサブスクリプションのリモートサーバーポートを変更しないでください。

10808はよく使われるローカル待ち受けポートですが、バージョンを問わず受信方式が同じとは限りません。画面上でSOCKSとHTTPを個別に設定するものもあれば、古い設定ではHTTPに10809を使う例もあります。また、1つのポートで両方のプロキシプロトコルを受け付ける混合待ち受け方式もあります。「設定」→「パラメーター設定」の実際の項目と起動ログを確認してください。

TCPとUDPは別々の待ち受けリソースであり、IPv4とIPv6でバインドの挙動が異なる場合もあります。0.0.0.0:10808 や [::]:10808 が表示された場合、ワイルドカードアドレスでの待ち受けがループバックアドレスでの待ち受けと競合することがあります。127.0.0.1と記載された行だけを検索しないでください。

2. エラーメッセージからポート競合・権限・接続拒否を見分ける

まずクライアントのログを開き、失敗の前後数行を保存します。listen、bind、アドレス、ポートを重点的に確認してください。コアによってログの接頭辞は異なります。以下はOSのエラーでよく使われる文言であり、ログの一行全体が完全に一致する必要はありません。

3. Windows：PIDから10808を使用中のプロセスを特定する

PowerShellでTCPの待ち受けを調べてから、プロセス情報を取得します。以下のコマンドは情報を表示するだけで、プログラムを終了しません。結果が空の場合は、検索時点でそのポートのTCP待ち受けが見つからなかったことを示します。すべてのプロトコルやシステムの予約状況が確認できたわけではありません。

$listeners = Get-NetTCPConnection -LocalPort 10808 -State Listen -ErrorAction SilentlyContinue
$listeners | Select-Object LocalAddress, LocalPort, State, OwningProcess
$listeners.OwningProcess | Sort-Object -Unique | ForEach-Object {
    Get-Process -Id $_ | Select-Object Id, ProcessName, Path
}

コマンドプロンプトで以下のコマンドを実行する方法もあります。2行目の1234は例示用のPIDです。1行目に表示された実際のPIDに置き換えてください。ポート番号の10808をプロセスIDとして使わないでください。結果を絞り込む際はローカルアドレスの列も確認し、リモート接続の記録と取り違えないようにします。

netstat -ano -p tcp | findstr ":10808"
tasklist /FI "PID eq 1234"

1. 待ち受け状態を確認：LISTENINGを確認してください。TIME_WAITだけでは、プログラムが待ち受け中である証拠になりません。
2. パスと実行元を確認：タスクマネージャーの「詳細」タブでPIDを照合し、必要に応じてファイルの場所を確認します。プロセスによっては、確認に管理者権限が必要です。
3. まず通常の方法で終了：別のv2rayNが動作している場合は、そのトレイメニューから終了します。ウィンドウを閉じても、トレイに最小化されるだけの場合があります。
4. 必要なサービスは残す：ポートを使用しているプログラムを引き続き使う必要がある場合は、v2rayN側のポートを変更してください。プロセス名だけを見てシステムサービスを強制終了しないでください。

TCPの検索結果が空でも、エラーがUDPに関するものなら、Get-NetUDPEndpoint -LocalPort 10808 -ErrorAction SilentlyContinueで追加確認できます。重複インスタンスを終了した後、もう一度検索してから使用するクライアントを起動してください。複数のインスタンスが交互にポートを確保する事態を防げます。

4. macOSとWindowsの予約ポート：使用中のプロセスが見つからない場合

macOS：待ち受けプロセスと完全なコマンドを確認

ターミナルで以下のコマンドを実行します。-nPはアドレスとポートを数値のまま表示し、名前解決による読み取りの妨げを防ぎます。権限が足りない場合は、sudo lsofで再確認してください。2行目の例示用PIDも、実際の値に置き換える必要があります。

lsof -nP -iTCP:10808 -sTCP:LISTEN
ps -p 1234 -o pid=,ppid=,command=

該当するアプリのメニューから終了し、待ち受けの記録が消えたことを確認してください。クライアントを閉じた後もコアのプロセスが残っている場合は、完全なコマンドと親プロセスを確認し、終了済みのインスタンスだと確かめてから対処します。プロセス名を指定してまとめて終了する方法は避けてください。同じコアが別の設定で動作し、使用中の可能性があります。

Windows：ポートの除外範囲を確認

アクセス拒否のエラーが出て、待ち受けプロセスも見つからない場合は、ターミナルでTCPの除外範囲を確認します。10808が表示された開始・終了範囲に含まれている場合、システムの予約ルールを変更するより、範囲外の空きポートを選ぶのが一般的です。

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

5. SOCKS・HTTP・混合待ち受けのポートを変更する

ここでは11808と11809への変更例を紹介しますが、これらが必ず空いている特別なポートというわけではありません。まず、前述の検索コマンドで10808を変更先のポートに置き換えて確認してください。システムの除外範囲が関係する場合は、変更先がその範囲に含まれていないことも確認します。

1. 元のポート、待ち受けアドレス、現在のシステムプロキシ方式を記録しておくと、設定を戻す際に役立ちます。
2. v2rayNの「設定」→「パラメーター設定」を開き、ローカル待ち受け、SOCKS、HTTP、混合ポートの項目を探します。項目が配置されたグループ名は、画面によって異なる場合があります。
3. SOCKSとHTTPの項目が独立している場合は、それぞれ 11808 と 11809 に設定できます。混合待ち受けの項目しかない場合は、その項目だけを 11808 に変更してください。11809も使えると決めつけないでください。
4. 設定を保存し、画面の案内に従ってコアまたはクライアントを再起動します。その後、ログにバインド失敗が出ていないか確認してください。
5. 変更後のポートを再検索し、表示されたPIDが今回起動したコアのものだと確認してから、アプリ側のプロキシ設定を更新します。

ローカル端末だけで使う場合は、ループバックアドレスでの待ち受けを維持してください。待ち受けアドレスを 0.0.0.0 に変更しても、ポート競合の一般的な解決にはなりません。アクセス可能な範囲が広がるおそれもあります。独自のJSON設定を使う場合は、実際に適用されている inbounds を確認してください。画面上の設定が、インポートした設定の固定ポートを上書きするとは限りません。各項目の意味はJSON設定ガイドを参照してください。

6. システムプロキシ・ブラウザー・コマンドラインの設定を更新する

コアを新しいポートで起動しても、すべてのアプリで古いプロキシ入口が自動的に無効化・更新されるわけではありません。システムプロキシ、ブラウザーの手動設定、ターミナルの環境変数はそれぞれ別の設定元です。各アプリが実際に使う接続先を個別に確認してください。

• v2rayNのシステムプロキシ：トレイメニューの「システムプロキシ」からいったんシステムプロキシを解除し、「システムプロキシを自動設定」を選びます。現在の設定でクライアントが再設定します。完了後、システム側に反映されたポートも確認してください。
• Windows：「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシまたはセットアップスクリプトを確認します。スクリプト方式を使っている場合は、手動プロキシのスイッチだけでなく、スクリプトが返すプロキシポートを確認してください。
• macOS：「システム設定」→「ネットワーク」→現在のネットワーク接続→「詳細」→「プロキシ」を開きます。Webプロキシ、安全なWebプロキシ、SOCKSプロキシを手動で設定している場合は、それぞれ対応する新しいポートに変更してください。
• ブラウザー：システムプロキシを使うブラウザーは、通常システム設定に従います。独自のプロキシ設定や拡張機能を使う場合は、該当する設定でポートを変更し、HTTPとSOCKS5のどちらが選択されているか確認してください。
• コマンドライン：現在のターミナルで HTTP_PROXY、HTTPS_PROXY、ALL_PROXY と、それぞれ小文字の同名変数を確認します。起動スクリプトを変更しても、既存のターミナルセッションには古い値が残っている場合があります。

HTTPSサイトへローカルのHTTPプロキシ経由で接続する場合、プロキシアドレスは通常 http://127.0.0.1:11809 と指定します。接続先のサイトがHTTPSでも、ローカルプロキシの入口に https:// が必要とは限りません。また、通常のシステムHTTPプロキシから、SOCKS専用の待ち受けポートには接続できません。

7. ポート変更後の検証手順と元に戻す際の確認事項

まずローカルの待ち受けを確認し、次にプロキシプロトコルを検証してから、最後にリモート接続を調べます。以下の2つのコマンドは、独立したHTTP受信とSOCKS受信の例です。混合ポートを使う場合は、1つ目の11809を11808に置き換えてください。リクエスト先はこのサイトのトップページです。応答時間やステータスコードは固定されていません。

curl --proxy http://127.0.0.1:11809 --connect-timeout 5 --max-time 20 -I https://v2rayindex.com/
curl --proxy socks5h://127.0.0.1:11808 --connect-timeout 5 --max-time 20 -I https://v2rayindex.com/

WindowsのPowerShellでは、環境によって同名のエイリアスが引数に影響するのを避けるため、curlをcurl.exeに置き換えられます。socks5hは、接続先ドメインの名前解決をプロキシ側で行う指定です。ローカルで名前解決するsocks5とは異なるため、テスト時には使用した方式を記録してください。

• 新しいポートで待ち受けていない：クライアントのログに戻り、設定が保存されているか、コアが起動しているか、独自設定で画面上の値が上書きされていないか確認してください。
• 接続直後に拒否される：まずポートとアドレスを確認します。IPv4ループバックアドレスだけで待ち受けている場合、localhostではIPv6への名前解決による違いが生じることがあります。テスト時は127.0.0.1を明示してください。
• プロキシには接続できるが、リモートへのリクエストが失敗する：ローカルのポート競合は解消している可能性が高いため、プロキシプロトコル、ルーティング、名前解決、リモート接続のログを確認してください。
• コマンドラインでは成功するが、ブラウザーでは失敗する：ブラウザーの接続先が10808のままではないか、独自のプロキシ拡張機能を使用していないか、古いシステムプロキシ設定が残っていないか確認してください。
• クライアントを一時的に使わない：まずシステムプロキシを解除してからクライアントを終了してください。停止済みのローカルポートにアプリが接続し続けるのを防げます。