この記事の要点

v2rayNの起動失敗、10808ポートの競合、ブラウザーのプロキシ無応答、カーネルの繰り返し終了に悩む方向けの記事です。まず待受アドレスを確認し、Windows・macOS・Linuxのシステムツールで占有プロセスを特定します。状況に応じて古いプロセスを終了するかポートを変更し、システムプロキシ、ブラウザー、アプリの設定も同期して更新します。

本当にポート競合が起きているか確認する

V2RayやXrayなどのカーネルは、ローカルにインバウンドの待受を作成します。ブラウザーやほかのアプリは、その待受ポートにリクエストを渡します。一般的な設定では 127.0.0.1:10808 をSOCKSプロキシ、127.0.0.1:10809 をHTTPプロキシとして使用します。実際のポートはクライアント設定によって異なり、すべてのバージョンで固定されているわけではありません。

ポート競合とは、2つのプロセスが同じアドレス、同じトランスポートプロトコル、同じポートを待ち受けようとする状態です。たとえば、古いv2rayNのカーネルが終了していないまま新しいカーネルが 127.0.0.1:10808 に再度バインドしようとすると、システムは2回目の待受を拒否します。この場合、サブスクリプション、VMess、VLESS、ルーティングルールは最初に確認すべき対象ではありません。

アプリがリクエストを開始ローカルポートに接続カーネルがインバウンドを受信ルールで振り分けプロキシ経由で出力
10808
一般的なSOCKS待受ポート
10809
一般的なHTTP待受ポート
127.0.0.1
ローカルホストからのみアクセス可能な待受アドレス
0.0.0.0
すべてのIPv4インターフェースを対象

エラー:listen tcp 127.0.0.1:10808: bind: address already in use

原因と対処:TCP 10808をすでに別のプロセスが使用しています。まず該当するPIDを調べ、プログラムを確認して古いプロセスを正常終了するか、新しいクライアントを未使用のポートに変更します。

エラー:Only one usage of each socket address is normally permitted

原因と対処:Windowsが同じソケットアドレスへの重複バインドを拒否しています。v2rayNを二重起動していないか、終了せずに残ったカーネルや別のローカルプロキシが動作していないか確認します。

現象:カーネルは実行中なのに、ブラウザーにプロキシサーバーが応答しないと表示される

原因と対処:必ずしもポート競合とは限りません。ブラウザーが古いポートを参照している可能性があります。クライアントの現在の待受ポートと照合し、HTTPとSOCKSの種類が正しく選択されているか確認します。

Windowsで10808の占有プロセスを特定する

Windows 11とWindows 10では、標準搭載の netstat で待受プロセスを確認できます。起動予定のv2rayNを完全に終了してからターミナルを開いて調べると、新しく起動したプロセスを競合プロセスと誤認しにくくなります。

  1. 待受レコードを確認する

    PowerShellまたはコマンドプロンプトを開き、netstat -ano | findstr :10808 を実行します。状態が LISTENING の行を確認し、右端のPIDを控えてください。

  2. プロセス名を確認する

    tasklist /FI "PID eq プロセス番号" を実行し、コマンド内のプロセス番号を実際のPIDに置き換えます。タスクマネージャーの「詳細」タブでPIDを検索することもできます。

  3. 終了してよいプロセスか判断する

    以前のv2rayNまたはそのカーネルプロセスが残っている場合は、まずトレイメニューから正常終了してください。ほかの使用中のプログラムであれば、直接終了せず、どちらか一方のクライアントのポートを変更するのが安全です。

  4. ポートを再確認する

    もう一度検索コマンドを実行します。LISTENING の記録がなくなったらv2rayNを起動し、ログに待受開始の成功メッセージが出ているか確認します。

netstat -ano | findstr :10808
tasklist /FI "PID eq 6420"

PowerShell:
Get-NetTCPConnection -LocalPort 10808 -State Listen
Get-Process -Id 6420

検索結果に複数の接続状態が表示されても、ESTABLISHEDTIME_WAIT を待受プロセスと見なさないでください。確認すべきなのは LISTENING、またはPowerShell出力の Listen です。接続状態の行は既存の接続を示しますが、右端のPIDから実際の使用者を特定できます。

結論:まずPIDを特定し、その後でプロセスを処理する

プロセスの終了は必須の手順ではありません。PIDが古いカーネルに対応するなら正常終了して構いませんが、開発サーバー、リモート接続ツール、稼働中のプロキシなら、v2rayNのローカルポートを変更する方が安全です。

macOSとLinuxで待受プロセスを確認する

macOSとLinuxでは lsof でポートを確認できます。Linuxのディストリビューションには通常 ss も用意されています。Debian、Ubuntu、Fedoraなどでは、一般ユーザーが別アカウントで起動したプロセスの詳細を確認できない場合があります。権限の範囲を確認したうえで sudo を使用してください。

macOS:
lsof -nP -iTCP:10808 -sTCP:LISTEN

Linux:
ss -ltnp | grep ':10808'
sudo lsof -nP -iTCP:10808 -sTCP:LISTEN

エラー:listen tcp 0.0.0.0:10808: bind: address already in use

原因と対処:すでに別のプログラムがすべてのIPv4インターフェースで10808を待ち受けています。ss -ltnp または lsof でPIDを特定し、該当するユーザーサービスを停止するか、クライアントのポートを変更します。

現象:lsofに出力がないのに、クライアントでは10808が使用中と表示される

原因と対処:実際のエラーがUDP、IPv6、または別のポートに関するものではないか確認します。次に [::]:10808、UDPの待受項目、ログに記録された完全なアドレスを個別に調べてください。

古いプロセスを終了するか、待受ポートを変更するか

対処方法は、ポートを使用しているプロセスにまだ用途があるかどうかで決まります。古いカーネルの残留、クライアントの二重起動、異常終了で孤立したプロセスは、正体を確認してから終了できます。別の継続稼働サービスがポートを使用している場合は、そのサービスを残し、v2rayNに新しいローカルポートを設定してください。

変更時は1項目だけを書き換えないでください。SOCKS、HTTP、LAN待受、APIのポートはそれぞれ別に設定されている場合があります。そのうち2つが誤って同じアドレスとポートを使うと、カーネルの起動に失敗することがあります。新しいポートを選んだら、システムプロキシとアプリのプロキシも更新されているか確認します。

  1. 現在の設定を記録する

    v2rayNのメイン画面で「設定」→「パラメータ設定」を開き、ローカルSOCKS、HTTP、LAN接続許可に関する値を記録します。バージョンによってグループ名が多少異なる場合があるため、ポート欄を基準にしてください。

  2. 空いているポートを選ぶ

    まず10810や10811など候補のポートをシステムコマンドで確認します。待受レコードがないことを確認してからクライアントに設定し、見慣れない番号だからという理由だけで使用しないでください。

  3. 保存してカーネルを再起動する

    設定を保存したらカーネルを再起動するか、v2rayNを終了して再度起動します。その後、新しいポートを調べ、該当するPIDが待受状態になっていることを確認してください。

  4. プロキシの接続先を変更する

    システムプロキシをv2rayNが自動で管理していない場合は、従来の 127.0.0.1:10808 を新しいポートに変更します。ブラウザー拡張機能や個別アプリも1つずつ同期してください。

  5. アドレスの公開範囲を維持する

    ローカルでのみ使用する場合は、待受アドレスを 127.0.0.1 のままにします。LAN内の端末から接続する明確な必要がある場合だけ、対応するLAN待受オプションを有効にしてください。

状況 推奨される対処 その後の確認
古いv2rayNカーネルが残っている 古いプロセスを正常終了してから、現在のクライアントを起動する 10808を新しいPIDが待ち受けているか
別のローカルサービスが長期間ポートを使用している 既存サービスを維持し、プロキシを10810など空いているポートに変更する システムプロキシとブラウザーのポート
v2rayNのインスタンスを2つ同時に実行している 必要なインスタンスだけ残すか、2つに異なるポートを設定する トレイアイコンと起動項目
LAN待受がローカルアドレスまで対象にしている すべてのインターフェースで待ち受ける必要が本当にあるか確認する 0.0.0.0と127.0.0.1のバインド範囲

結論:継続稼働するサービスにはポートを譲り、残留プロセスは終了する

競合プロセスがまだ必要な処理を担っているならローカルプロキシのポートを変更します。二重起動や古いカーネルが原因なら、ポートを何度も変更するより自動起動元を整理する方が効果的です。

システムプロキシとブラウザーの設定を同期する

ポート競合を解決してもアクセスできない場合、最も多い原因は通信が古いポートへ送られ続けていることです。クライアントに新しいポート10810が表示されても、ブラウザー、コマンドラインツール、システムプロキシが自動で10810に変わったとは限りません。手動設定したプロキシの接続先はすべて個別に確認してください。

新しいポートを確認システムプロキシを更新ブラウザーを更新個別アプリを確認接続テストを実行
使用場所 確認する内容 よくあるミス
Windowsのシステムプロキシ アドレスが127.0.0.1で、ポートが現在のHTTPインバウンドと一致している SOCKSポートをHTTP専用の欄に入力している
ブラウザー個別のプロキシ プロキシの種類、ホスト、ポートの3項目が一致している 拡張機能に古い10808が残っている
コマンドラインの環境変数 HTTP_PROXYHTTPS_PROXYALL_PROXY ターミナルセッションで変数が再読み込みされていない
LAN内のほかの端末 クライアントを実行しているPCのLANアドレスと新しいポートを入力する 127.0.0.1を入力しており、実際には接続元端末自身を指している

現象:10810に切り替えるとカーネルは正常に動作するのに、Webページがすぐ接続を拒否する

原因と対処:アプリが古い10808へ接続しているか、SOCKSをHTTPとして使用しています。プロキシの種類を選び直し、手動設定したすべての接続先を現在の待受ポートに統一してください。

現象:ブラウザーは使えるのに、ターミナルのコマンドだけ接続できない

原因と対処:ブラウザーとターミナルが異なるプロキシ設定元を使用しています。現在のターミナルセッションのプロキシ環境変数を確認し、変更後にターミナルを開き直してテストしてください。

v2rayNGとv2flyNGはAndroid上で通常、ローカルプロキシとVPNの接続処理をアプリ自身が管理します。同じサブスクリプションをインポートして接続できない場合でも、デスクトップのPIDコマンドをそのまま使わないでください。まず別のVPN接続が同時に有効になっていないか確認し、次にクライアント設定のローカルポートと実行状態を確認します。

修復後の確認手順

確認はノードが無効かどうかを直接判断せず、ローカル待受から始めます。ローカルポートが確立していなければ、その後のプロトコルハンドシェイク、トランスポート接続、ルーティングも発生しません。まずアプリがローカルプロキシへ接続できることを確認し、その後でノード設定とリモートネットワークを確認してください。

  1. 待受が1つだけか確認する

    netstatlsof、または ss を再度実行します。対象ポートは想定したカーネルのPIDが待ち受けている必要があり、説明できない別サービスが同時に存在してはいけません。

  2. クライアントログを確認する

    起動後30秒間ログを観察し、新たな address already in use、繰り返しの再起動、インバウンド作成失敗が発生していないか確認します。

  3. ローカルプロキシをテストする

    ブラウザーまたはコマンドラインから現在のポートへ明示的に接続します。すぐに接続拒否となる場合は、問題がまだローカル待受にあります。接続確立後にタイムアウトする場合は、ノードとネットワークを確認してください。

  4. ルーティング結果を確認する

    ルーティングルールによってテスト対象が誤って直接接続またはブロック対象へ送られていないか確認します。ポートを修正しても、geosite、geoip、domainなどのルールは自動的に変わりません。

  5. 自動起動を再確認する

    システムを再起動するか再ログインした後、もう一度確認します。古いポートが再び使用中になる場合は、ログイン時の起動項目またはユーザーサービスがバックグラウンドで古いインスタンスを起動しています。

PID 1つ
対象ポートで想定される待受プロセス
30秒
起動後にログを観察する時間
2回の確認
変更後と再ログイン後の再確認

ポートが正常に待ち受けているのにすべてのノードがタイムアウトする場合は、ネットワークと設定の確認に切り替えます。システム時刻、ノードアドレス、プロトコルパラメータ、トランスポート設定、サブスクリプションの有効性を確認してください。ポート競合はローカルインバウンドの段階で発生するため、カーネルへの接続確立後に起きるすべての通信障害を説明するものではありません。