Windows版v2rayNで待受に失敗する、または起動後にブラウザーからローカルプロキシへ接続できない場合に役立ちます。まずログでエラーのポートを確認し、待受情報からプロセスを特定します。重複起動したインスタンスを終了できる場合はポートを解放し、難しければ空いていることを確認したポートに変更します。最後にWindowsとアプリのプロキシ設定も更新し、カーネルは復旧したのにアプリが古いアドレスへ接続する状態を防ぎます。
1. ローカルの待受失敗を確認する。ノードは先に変更しない
v2rayNのメイン画面にあるログで、今回の起動記録を確認します。listen、bind、127.0.0.1:10808を探してください。カーネルがローカルの接続口を確立できていなければ、リクエストはノードに届きません。この段階でサブスクリプションを更新したり、VLESSやVMessのサーバーポートを変えたりしても、PC側の待受競合は解消されません。
エラー：bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
原因と対処：Windowsでよくあるアドレス使用中のエラーで、エラーコード10048に該当します。ログに記録されたポートを待ち受けているPIDを調べ、重複プロセスを終了するか、ローカルの接続口を変更します。
エラー：bind: An attempt was made to access a socket in a way forbidden by its access permissions.
原因と対処：エラーコード10013でよく見られます。ポート予約範囲やセキュリティポリシーが関係している可能性があり、既存プロセスが待ち受けているとは限りません。PIDが見つからない場合は、除外ポート範囲を確認してください。プロセスを繰り返し終了させないようにしましょう。
エラー：No connection could be made because the target machine actively refused it.
原因と対処：アプリが接続しようとしているアドレスに利用可能な待受サービスがないか、変更前の古いポートを参照している可能性があります。まずカーネルが正常に起動したことを確認し、アプリが実際に使用しているプロキシアドレスを調べてください。
エラーメッセージはWindowsの表示言語やカーネルのバージョンによって異なります。ローカルアドレス、ポート、エラーの意味を基準に判断してください。127.0.0.1はPC自身を指すループバックアドレスで、サブスクリプションサーバーのアドレスではありません。0.0.0.0はすべてのIPv4インターフェースで待ち受ける指定です。このポートの競合がループバックでの待受にも影響する場合があります。
2. 現在の設定で10808・10809が何に使われているか確認する
「設定」→「パラメータ設定」を開き、ローカル待受に関する項目を確認します。従来の2ポート構成ではSOCKSに10808、HTTPに10809を使うことがよくあります。一方、混合ポート構成ならHTTPとSOCKSで1つのポートを共用できます。古い解説だけを根拠に、PCで2つのポートを必ず待ち受ける必要があると考えないでください。
ローカルポートは、アプリからクライアントへ接続する入口を決めるものです。ルーティングは接続後の出口を決め、リモートノードのポートはカーネルの接続先を決めます。これらを混同して変更しないでください。ここで例として挙げる11808・11809は候補であり、必ず空いている番号ではありません。
3. netstatでポートを使用中のPIDを特定する
Windowsのスタートメニューで「ターミナル」を検索し、PowerShellまたはコマンドプロンプトを開いて、次の2つのコマンドを実行します。通常は一般ユーザー権限で接続情報を確認できます。保護されたプロセスの情報を調べる必要がある場合は、管理者としてターミナルを起動してください。
netstat -ano -p tcp | findstr ":10808"
netstat -ano -p tcp | findstr ":10809"ローカルアドレスの列とLISTENINGの状態を優先して確認します。以下は表示形式の例で、実際のPCで取得した結果ではありません。最後の列の6420がPIDです。同じプロセスがIPv4とIPv6の両方で待ち受ける場合があります。
TCP 127.0.0.1:10808 0.0.0.0:0 LISTENING 6420
TCP [::1]:10808 [::]:0 LISTENING 6420取得した実際のPIDを次のコマンドに指定します。結果がESTABLISHEDまたはTIME_WAITだけの場合、そのPIDを待受競合の原因と決めつけないでください。ローカルポートが一致しているのか、リモート接続先のアドレスなのかも確認します。
tasklist /FI "PID eq 6420"- 別のv2rayNが見つかった場合：通知領域とタスクマネージャーを確認し、古いインスタンスの通知領域メニューから終了するのを優先します。
- プロキシカーネルのプロセスが見つかった場合：どのクライアントのものか、ファイルの場所とあわせて確認し、正常に動作中のインスタンスを終了しないようにします。
- 別のアプリやシステムサービスが見つかった場合：用途を確認します。引き続き必要なサービスなら終了せず、v2rayNのローカルポートを変更してください。
- 見覚えのないプロセスが見つかった場合：タスクマネージャーの「詳細」タブでPIDを指定し、「ファイルの場所を開く」から確認します。名前だけで判断しないでください。
4. 重複インスタンスを終了するか、ローカル待受ポートを変更する
変更中にアプリが使えなくなった接続口へアクセスし続けないよう、まず通知領域のメニューでシステムプロキシを「システムプロキシをクリア」に設定します。単に2つのインスタンスを誤って起動していた場合は、余分な方を終了して残すクライアントを再起動すればよく、ポートの変更は不要なこともあります。
-
現在の値を記録する
「設定」→「パラメータ設定」を開き、現在のローカル待受ポート、LANからの接続を許可するかどうか、独立した入口と混合ポートのどちらを使っているかを記録します。項目名はバージョンによって異なる場合があるため、現在の画面を確認してください。
-
変更候補のポートを確認する
前の手順と同じ方法で11808を調べます。設定に独立したHTTP入口がある場合は、11809も確認してください。待受中なら別の候補に変更し、他のサービスのポートを上書きしないようにします。
-
ローカルの接続口を変更する
「設定」→「パラメータ設定」のローカル待受設定で、SOCKSポートを11808に変更します。独立したHTTPポートの項目があれば、11809に変更してください。画面に混合ポートしかない場合は、そのポートだけを11808に変更します。11809を別途探したり追加したりする必要はありません。
-
保存して再起動する
「確定」をクリックして保存し、画面の案内に従ってカーネルを再起動します。値が変わらない場合は、v2rayNを終了してから起動し直してください。その後ログを確認し、新しいローカルアドレスでbindエラーが再発していないことを確かめます。
-
新しい待受を確認する
11808と、設定で使用しているHTTP入口を再検索します。待受PIDが現在動作中のクライアントカーネルに属していることを確認してください。古いポートが使われなくなっただけでは、新しいポートで待受が開始した証拠にはなりません。
netstat -ano -p tcp | findstr ":11808"
netstat -ano -p tcp | findstr ":11809"カスタム設定ファイルを使用している場合、待受アドレスは通常、設定内のinboundsで指定されます。画面上のポート設定がそのファイルに反映されるとは限りません。まずバックアップを取り、実際に読み込まれている設定のlisten、port、protocolを確認します。画面だけ変更しても、実行時には古いポートが読み込まれている場合があります。
5. Windowsとアプリ内のプロキシ設定を更新する
カーネルが新しいポートで待ち受け始めたら、v2rayNの通知領域メニューで「システムプロキシ」→「システムプロキシを自動設定」を選びます。次に、Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」で反映されたアドレスを確認してください。「システムプロキシを自動設定」を選んでも、すべてのアプリの手動プロキシ設定が自動で更新されるわけではありません。
| 設定箇所 | 2ポート構成の例 | 混合ポート構成の例 | 確認ポイント |
|---|---|---|---|
| Windowsのシステムプロキシ | 127.0.0.1:11809 | 127.0.0.1:11808 | HTTPプロキシに対応した入口を指定 |
| アプリで手動設定するSOCKS5 | 127.0.0.1:11808 | 127.0.0.1:11808 | ホスト、ポート、プロキシの種類を確認 |
| アプリで手動設定するHTTP | 127.0.0.1:11809 | 127.0.0.1:11808 | SOCKS専用の入口は指定できません |
| ターミナルの環境変数 | HTTPまたはSOCKSの種類に合わせて設定 | アプリが対応するプロキシの種類に合わせて設定 | 古いターミナルには変更前の値が残る場合があります |
ブラウザーが独自のプロキシ設定を使っている場合は、ブラウザー側でも変更してください。コマンドラインのプログラムがWindowsのシステムプロキシを参照するとは限りません。既存のHTTP_PROXY、HTTPS_PROXY、ALL_PROXY環境変数を確認し、10808や10809を含む値が残っていないか注意します。ユーザー環境変数を変更した後は、新しいターミナルを開いてテストしてください。
まとめ：待受が復旧したら、古いポートの参照先を確認する
一部のアプリは復旧したのに、1つのアプリだけ接続拒否が続く場合は、すぐにポートを再変更せず、そのアプリの手動プロキシ設定とプロセス環境を確認してください。アプリの接続先を待受確認済みの新しい入口に変更するほうが、サブスクリプション設定全体をリセットするより手早く解決できます。
6. 待受プロセスが見つからない場合は、予約ポートと起動方法を確認する
ポート検索に結果が出ないのにアクセス権限に関するエラーが続く場合は、管理者として起動したターミナルでWindowsのTCP除外ポート範囲を確認します。仮想化、コンテナー、システムのネットワークコンポーネントがこれらの範囲を使用している可能性があり、通常の待受検索では使用中のPIDが表示されないことがあります。
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp- 候補ポートが開始ポートと終了ポートの範囲内にある：範囲外のポートに変更し、待受状況を再確認します。プロキシの接続口を1つ作るためだけに、システムの予約範囲を削除しないでください。
- 手動起動では正常なのに、サインイン後に競合する：「タスクマネージャー」→「スタートアップ アプリ」と、自分で作成したタスクを確認し、同じクライアントが複数の場所から起動しないようにします。
- 終了直後にポートが再び現れる：PIDを再検索し、バックグラウンドタスクが古いインスタンスを自動起動していないか確認します。プロセスを1つ終了するだけでは、重複起動の原因は解消されません。
- UDPだけでエラーが出る：
netstat -ano -p udpで該当ポートを確認します。TCPとUDPは異なるトランスポートプロトコルです。TCPの検索結果だけで、すべての入口の状況を判断することはできません。
ローカルポートの変更だけなら、通常はファイアウォールの受信規則を追加する必要はありません。このPCだけで使う場合はループバックでの待受を維持してください。待受アドレスを0.0.0.0に変えてもポート競合は解消されず、LAN内の機器からプロキシの入口に接続できる状態になる可能性があります。共有が本当に必要な場合に限り、接続範囲とファイアウォール規則を個別に検討してください。
7. 3つの層で修復を確認する
まずローカルのTCP入口、次にアプリのプロキシ設定、最後にノードへの接続を確認します。以下のPowerShellコマンドで確認できるのは、ローカルポートへのTCP接続が確立できるかどうかだけです。リモートノード、DNS、ルーティングが正常であることまでは確認できません。
Test-NetConnection -ComputerName 127.0.0.1 -Port 11808- ローカル層：結果の
TcpTestSucceededがTrueで、ログに新たな待受エラーがなく、PIDが正しいカーネルプロセスに対応していることを確認します。 - アプリ層：Windowsのシステムプロキシと手動プロキシが新しいポートを指していることを確認します。テストするアプリを完全に終了して起動し直し、古いプロセスに設定が残っていないか確認してください。
- 外向き通信層：以前アクセスしようとしていたページやサービスでテストします。ローカルの入口が正常なのにログにリモート接続のタイムアウトが出始めた場合は、ノードのアドレス、サブスクリプションの有効性、ネットワーク状況を確認してください。
Android版v2rayNGはXrayカーネルを使用しますが、VPNの許可やアプリごとのプロキシ設定はWindowsのシステムプロキシとは別の設定です。この記事のコマンドはWindows版v2rayN向けで、スマートフォンにそのまま適用するものではありません。PCでのトラブル対処にスマートフォンの設定変更は不要です。ただし、スマートフォンからLAN経由でPCのプロキシ入口に接続している場合は例外です。