v2rayNでコアを起動する際は、まずローカルにインバウンドの待受を作成します。一般的な初期設定では、SOCKSの待受ポートが10808、HTTPの待受ポートが10809で、アドレスは通常127.0.0.1です。同じポートを別のプロセスがすでに使用していると、新しく起動したXrayまたはV2Rayコアはバインドできません。ノード設定が正しくても、利用可能な状態にはなりません。
この種の障害では、すぐにクライアントを再インストールするのではなく、「競合ポートを確認する、プロセスを特定する、用途を判断する、解放または変更する、システムプロキシを同期する、再確認する」の順に対応することが重要です。クライアント側のポートだけを変更してシステムプロキシを更新しないと、「コアは動作しているのにウェブページを開けない」状態になります。両方の設定を必ず確認してください。
10808、10809、またはカスタムしたローカルポートで待受できないv2rayN、v2rayNGユーザー向けです。確認後は、実際にポートを使用しているプロセスを特定し、安全な対処方法を選んだうえで、ブラウザー、システムプロキシ、クライアントコアが同じポートを参照しているか確認できます。
まずポート競合か確認し、ノード障害と混同しない
ポートの使用中エラーは、VMessやVLESSノードへのリモート接続より前に発生する、ローカルのインバウンド段階の問題です。つまり、サーバーアドレス、UUID、通信方式、ルーティングルールが実際の通信に関与する前に、クライアントがローカルポートを待ち受けられず停止しています。この場合、サブスクリプションの更新、ノードの切り替え、通信プロトコルの変更を繰り返しても、通常は結果は変わりません。
v2rayNのログ欄を開き、listen、bind、address already in use、または具体的なポート番号を含む行を確認します。ログが接続タイムアウト、TLSハンドシェイク失敗、リモート側による接続拒否だけを示している場合は、ローカルポートではなくノード経路の調査に切り替えてください。
エラー: listen tcp 127.0.0.1:10808: bind: Only one usage of each socket address is normally permitted
原因と対処:Windows上ですでに別のプロセスが10808を待ち受けています。まずPIDからプロセスを特定し、重複したインスタンスを終了するか、v2rayNを空いているポートへ変更します。
エラー: listen tcp 127.0.0.1:10809: bind: address already in use
原因と対処:10809は別のローカルサービスが使用中です。旧サービスを終了するか、HTTP待受ポートとシステムプロキシのポートを新しい番号にそろえて変更します。
エラー: failed to start app/proxyman/inbound: failed to listen TCP
原因と対処:コアがインバウンドの待受を作成できていません。同じログの末尾にあるアドレスとポートを確認し、上位レベルのエラーだけでノード障害と判断しないでください。
Windowsで10808と10809を使用中のプロセスを特定する
まずv2rayNを完全に終了し、もう一度起動します。それでもエラーが出る場合は、古いコアプロセスが終了していないか、別のプロキシツール、開発サービス、セキュリティソフトがポートを使用している可能性があります。PIDを1つ見つけただけで強制終了せず、実行ファイル名と起動パスを先に確認してください。
「ターミナル」または「コマンドプロンプト」で次のコマンドを実行します。10808と10809は別々に調べることをおすすめします。2つのポートが異なるプロセスによって待ち受けられている場合があるためです。
netstat -ano | findstr :10808
netstat -ano | findstr :10809
結果から状態がLISTENINGになっている行を探します。右端の数字がPIDです。たとえば結果の末尾が6420なら、タスクリストでプロセス名を確認します。
tasklist /FI "PID eq 6420"
PowerShellを使う場合は、待受中の接続と所有プロセスを直接取得できます。2つ目のコマンドにある6420は、実際に確認したPIDへ置き換えてください。
Get-NetTCPConnection -LocalPort 10808 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Id 6420 |
Select-Object Id, ProcessName, Path
- 結果が現在使用中のv2rayNコアプロセスなら、まずクライアントから終了し、タスクマネージャーで残ったコアを終了してからクライアントを再起動します。
- 結果が継続稼働させる必要のある別のローカルサービスなら、そのプロセスは残し、v2rayNのポートを変更します。
- 複数の接続が表示されても
LISTENINGがない場合、それらは通常、ポートを使用しているクライアント接続にすぎず、待受入口を占有しているプロセスとは限りません。 - 検索結果がないのに起動時のエラーが続く場合は、管理者権限のターミナルを開き直して調べ、ログに記録された実際のアドレスがIPv4、IPv6、または別のポートでないか確認します。
| 表示される状態 | 意味 | 次の手順 |
|---|---|---|
| 127.0.0.1:10808 LISTENING | ローカルからのみアクセス可能な待受 | PIDからプロセス名を確認する |
| 0.0.0.0:10808 LISTENING | 全IPv4インターフェースで待受中 | LANからのアクセスが必要か確認する |
| [::]:10808 LISTENING | IPv6インターフェースで待受中 | 同一ポートのデュアルスタックバインドを確認する |
| ESTABLISHED | 接続が確立されデータを転送中 | 対応するLISTENING行を引き続き探す |
結論:PIDの正体で対処を決める
古いコアの残留プロセスならポートを解放し、稼働中の業務プロセスなら残したままポートを変更します。「10808が使用中」という情報だけでは、どちらを終了すべきか判断できません。
古いプロセスを終了するか、クライアントのポートを変更するか
使用中のプロセスが、前回の異常終了後に残ったXrayまたはV2Rayコアなら、まずv2rayNのメニューから「終了」を実行し、約5秒待ってからポートを確認します。クライアントのウィンドウを閉じても、バックグラウンドのコアまで終了するとは限りません。特に、スリープからの復帰後、コア更新の中断後、またはクライアントを何度も起動した後に起こりやすくなります。
残留プロセスだと確認できたら、タスクマネージャーの「詳細」タブでPIDを指定してタスクを終了できます。PowerShellで指定したPIDを終了することもできますが、名前とパスを確認してから実行してください。
Stop-Process -Id 6420
使用中のプロセスが継続稼働の必要なプログラムなら、v2rayNのローカル待受ポートを変更する方が安全です。新しいポートは20000~50000の範囲から、現在待受に使われていない番号を選びます。例として20808、20809が使えます。選択前に必ず検索を実行し、LISTENINGの結果がないことを確認してください。
netstat -ano | findstr :20808
netstat -ano | findstr :20809
- プロセスを終了:クライアントの重複起動、メインウィンドウを失った古いコア、使用していないと確認できる一時サービスに適しています。
- ポートを変更:開発サーバー、別のローカルプロキシ、常時稼働するバックグラウンドサービスが10808、10809を固定使用している場合に適しています。
- 番号を無作為に連続変更しない:変更するたびに先に確認し、10808から別の使用中ポートへ競合が移る可能性を抑えます。
- アドレス範囲を明確に保つ:ローカル専用なら127.0.0.1のままにし、競合回避のために0.0.0.0へ変更しないでください。待受アドレスを変えても、同じポートの競合は解消しません。
v2rayNでポートを変更し、システムプロキシを同期する
v2rayN 7.xでは、画面の文言がマイナーバージョンによって異なる場合がありますが、操作入口は「設定」周辺にまとまっています。「設定」→「パラメータ設定」を開き、Core基本設定またはローカル待受に関する項目で、SOCKS、HTTPポートとローカル待受アドレスを確認します。10808を20808、10809を20809に変更して保存し、コアを再起動します。
使用中のバージョンが1つの基本ポートから後続ポートを自動的に決める場合は、画面の説明に従って基本値を変更します。設定ファイルとグラフィカルインターフェースで、競合する2組の値を別々に設定しないでください。変更後はログに戻り、待受成功のメッセージが表示され、bindエラーが再発していないことを確認します。
- 「設定」→「パラメータ設定」を開き、変更前の待受アドレスとポートを控えます。
- SOCKSポートを20808、HTTPポートを20809に設定します。画面に基本ポートしかない場合は、そのバージョンのポート説明に従って設定してください。
- 設定を保存し、「サービスを再起動」を実行するか、v2rayNを終了して再度開きます。
- メイン画面の「システムプロキシ」メニューから「システムプロキシを自動設定」を選び、現在のHTTP待受ポートを使ってシステム設定をv2rayNに書き直させます。
- Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスが127.0.0.1、ポートが20809に更新されていることを確認します。
症状:コアは動作中と表示されるが、ブラウザーがすぐにプロキシサーバーへ接続できないと表示する
原因と対処:クライアントのポートは20809に変更済みですが、システムプロキシが10809を参照しています。「システムプロキシ」→「システムプロキシを自動設定」を再実行するか、Windowsのプロキシポートを手動で同期します。
症状:SOCKSのテストは成功するが、HTTPプロキシを使うプログラムは失敗する
原因と対処:プログラムが古いHTTPポートへ接続している可能性があります。そのプログラムのプロキシアドレスを127.0.0.1:20809に更新し、20809が待受中であることを確認します。
症状:設定を保存しても、再起動すると10808で待受する
原因と対処:現在使用している設定項目とは別の項目を変更したか、古いインスタンスがバックグラウンドに残っている可能性があります。クライアントを完全に終了し、関連プロセスが終了したことを確認してから、パラメータ設定を開き直して実際の値を確認します。
ブラウザーは通常、Windowsのシステムプロキシを読み取りますが、一部のプログラムは独自のプロキシ設定を使います。プログラムに127.0.0.1:10808を手動入力していた場合、v2rayNの変更後にそのプログラム側も更新してください。サブスクリプションのURL、VMessまたはVLESSノードのポートは、ローカルポートに合わせて変更する必要はありません。
Androidとその他のデスクトッププラットフォームでの違い
v2rayNGがAndroidのVPNサービスで通信を処理している場合、ローカルSOCKS待受を他のアプリに直接入力する必要は通常ありません。ただし、10808がカスタムインバウンド、LAN共有、重複したサービスによって使用されることはあります。まずv2rayNGの接続を停止し、アプリのタスク一覧から古いインスタンスを終了して、再度開いて現在の設定を起動します。
Xrayコアを使うv2rayNGとv2flyコアを使うv2flyNGでは、ポート競合の判断原則は同じです。まずログで具体的な待受アドレスとポートを確認し、LAN接続の許可、カスタムSOCKSインバウンド、追加のHTTPインバウンドが有効になっていないか調べます。ノードのリモートポートをローカルポートと取り違えて変更しないでください。
ポートを20808に変更した後、サブスクリプションを再インポートする必要はありますか?
必要ありません。ローカル待受ポートはクライアントのインバウンド設定です。サブスクリプションにはノードアドレス、認証情報、通信方式、リモートポートが保存され、両者は独立しています。
パソコンを再起動するたびに10808が使用中と表示される場合は?
タスクマネージャーの「スタートアップアプリ」で、クライアントのインスタンスが2つシステム起動時に立ち上がっていないか確認し、v2rayNが自動起動に設定されているかも調べます。起動入口は1つだけ残し、netstat -anoで待受プロセスを確認します。
待受アドレスを0.0.0.0に変更すれば解決できますか?
できません。同じプロセスで待受範囲を広げてもポートは解放されず、LAN上の機器からアクセス可能になるおそれがあります。ローカル専用なら127.0.0.1のままにし、ポートの解放または変更で競合を解決してください。
v2rayNGを起動するとすぐ停止します。まず10808を変更すべきですか?
まずアプリのログを確認します。10808と待受失敗が明記されている場合だけポートを変更してください。VPN権限、ノードのタイムアウト、DNSエラーの場合は、それぞれのログに応じて対処します。
macOSやLinuxで待受プロセスを調べる方法は?
macOSではlsof -nP -iTCP:10808 -sTCP:LISTEN、Linuxではss -lntp 'sport = :10808'を実行します。プロセス名を確認したら、同様に用途を判断してから、プロセスを終了するかクライアントのポートを変更します。
変更後に行う完全な確認手順
ポート調査の完了条件は「エラー画面が消えた」ことではなく、コアの待受、システムプロキシ、実際のリクエストの3層が一致していることです。まず新しいポートを現在のコアが実際に待ち受けているか確認し、次にシステムプロキシが正しく設定されているか確認します。最後にネットワークへアクセスし、ログに新しいインバウンド接続が記録されるか確認します。
- 待受を確認:
netstat -ano | findstr :20808とnetstat -ano | findstr :20809を実行し、状態がLISTENINGであることを確認します。 - PIDを確認:待受PIDを調べ、プロセスが別のバックグラウンドサービスではなく、現在のv2rayNコアに属していることを確認します。
- システムプロキシを確認:アドレスは127.0.0.1、HTTPポートはクライアントの現在の設定と一致している必要があります。例:20809。
- クライアントログを確認:ウェブページへアクセスした後、新しい接続記録が表示されることを確認します。待受失敗や旧ポートへの接続拒否が再び表示されてはいけません。
- ルーティングをテスト:直接接続する対象とプロキシ経由にする対象へそれぞれアクセスし、ポート変更によって既存のルーティングルールの判定結果が変わっていないことを確認します。
- 再起動して再確認:クライアントを完全に終了して一度再起動し、古いインスタンスが再びポートを奪わないことを確認します。
netstat -ano | findstr :20808
netstat -ano | findstr :20809
tasklist /FI "PID eq 実際のPID"
待受が正常なのにネットワークへアクセスできない場合は、ノードの可用性、ルーティング、DNSの調査に切り替えます。この段階でローカルポートを何度も変更する必要はありません。ポート層の確認は完了しています。問題を層ごとに絞り込むことで、ノード障害、名前解決の障害、ローカルインバウンド障害を混同せずに済みます。