Windows版v2rayNの起動後に「bind」「address already in use」やポートへのアクセス拒否が発生した場合に適用できます。まずログでローカルポートを確認し、PowerShellで待受プロセスを特定します。重複起動なら通常の手順で終了し、別の用途のプロセスなら空いているポートに変更します。最後にシステムプロキシと手動プロキシのアドレスを更新し、コアの待受、プロキシのハンドシェイク、Webリクエストの3段階を確認します。
1. まずログで競合しているローカルポートを確認
v2rayNのメイン画面でログを開き、コアを再起動して、listen、bind、アドレスとポートが記載されたエラー全体を確認します。ここでは127.0.0.1:10808を例にします。ログに別のポートが記載されている場合は、以降のコマンドもその値に置き換えてください。チュートリアルの既定値だけで判断しないようにしましょう。
bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
原因と対処：同じ、または重複する待受アドレス・プロトコル・ポートがすでに使用されています。待受プロセスを調べ、正体を確認してから重複インスタンスを終了するか、ローカルのインバウンドポートを変更します。
bind: An attempt was made to access a socket in a way forbidden by its access permissions.
原因と対処：ポートがシステムによって予約されているか、セキュリティポリシーで制限されている可能性があります。通常の待受プロセスが存在するとは限りません。まず待受状況を調べ、次に除外ポート範囲を確認してください。ファイアウォールを安易に無効化しないでください。
このエラーは、リモートノードへの接続が始まる前、プロキシリクエストを受け付けるローカル側の入口で発生します。サブスクリプションの変更、VMessやVLESSへの切り替え、リモートサーバーのポート変更では、使用中のローカルポート10808は解放されません。また、ローカルポートとノードのサーバーポートを同じにする必要はありません。
判断のポイント：まず待受を復旧し、その後ノードをテスト
ローカルのbindエラーが引き続きログに出る場合は、ノードの遅延テストをいったん中止してください。まず指定ポートで待受が始まる状態にします。その後で初めて、ノードテストが原因の切り分けに役立ちます。
2. PowerShellで10808を使用中のプロセスを特定
Windows PowerShellを開き、まずTCPの待受レコードを確認します。次のコマンドはローカルポートだけを検索するため、リモートの10808に接続している通常の通信を待受競合と誤認しません。該当がなければ出力は空のままです。ただし、これは検索時点で一致するTCP待受がなかったことを示すだけです。
Get-NetTCPConnection -State Listen -LocalPort 10808 -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, State, OwningProcessLocalAddressとOwningProcessを確認します。0.0.0.0はすべてのIPv4アドレスで待ち受けることを示し、ループバックアドレス上の同じポートの待受と競合する場合があります。::はIPv6のワイルドカードアドレスです。デュアルスタックの動作も考慮して判断してください。アドレスが127.0.0.1ではないからといって、レコードを無視しないでください。
# 前の手順で返された OwningProcess が 6240 の場合。実際の結果に置き換える
Get-Process -Id 6240 |
Select-Object Id, ProcessName, Path
Get-CimInstance Win32_Process -Filter "ProcessId = 6240" |
Select-Object ProcessId, ParentProcessId, ExecutablePath, CommandLine6240は説明用のPIDであり、固定のプロセス番号ではありません。パスやコマンドラインが空欄の場合は、管理者権限でもう一度調べてください。コアのプロセスが表示された場合は、親プロセスも確認します。v2rayNの起動中にコアがプロキシポートを使用するのは通常の動作なので、プロセス名だけで異常と判断しないでください。
- 同じv2rayNの正常なコア：ログが古いものではないか、現在のリクエストが実際に通るかを確認し、正常な接続を誤って終了しないようにしてください。
- 別のフォルダーから起動した重複インスタンス：該当する通知領域のアイコンを見つけ、通常の手順で終了します。メインウィンドウを閉じただけでは、通知領域に最小化されている場合があります。
- 別の用途のプログラム：その待受は維持し、既存サービスに影響しないよう、優先してv2rayNのローカルポートを変更してください。
- パスや用途が不明：タスクマネージャーでファイルの場所と関連サービスを確認してください。PIDだけを見て安易に終了しないでください。
3. 待受レコードがない場合：UDPとシステムの予約ポートを確認
TCPとUDPは異なるトランスポートプロトコルです。同じ番号のポートをTCPとUDPでそれぞれ使用できます。UDPのレコードだけでは、TCPの待受競合があるとは判断できません。ログでUDPインバウンドのバインド失敗が明示されている場合は、UDPエンドポイントを検索し、表示されたPIDからプロセスを特定してください。
Get-NetUDPEndpoint -LocalPort 10808 -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, OwningProcessアクセス拒否のエラーが出ており、TCPとUDPのどちらにも該当するレコードがない場合は、Windowsの除外ポート範囲を確認します。仮想化、コンテナー、システムのネットワークコンポーネントが範囲に影響することがあります。次のコマンドは確認のみで、設定は変更しません。必要に応じて管理者権限のターミナルで実行してください。
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp- 出力された開始ポートから終了ポートまでの範囲に
10808が含まれているかを確認します。同じ数値が書かれた行だけを探さないでください。 - 除外範囲に含まれている場合は、その範囲外から新しいポートを選び、すでに待受に使われていないか再確認してください。
- ログでUDPが問題と示されている場合は、検索時に
protocol=tcpをprotocol=udpに置き換えてください。 - システムの予約範囲を安易に削除しないでください。また、ローカルプロキシの不具合を解決するためにセキュリティ保護全体を無効化しないでください。それでも拒否される場合は、セキュリティソフトのイベントと組織のデバイスポリシーを確認します。
プログラムの起動直後に終了し、検索時点ですでに待受がなくなっている場合もあります。その場合はコアを再起動し、最新のログとポート状況をすぐ確認してください。一度出力が空だっただけでは、ポートが常に空いているとは言えません。また、ノードが利用できないと判断する根拠にもなりません。
4. パラメーター設定でローカル待受ポートを変更
ここでは10808を10818に変更する例を紹介します。新しいポートはあくまで例です。使用前に、前述の待受確認と予約範囲の確認をもう一度行ってください。v2rayNの画面によって、項目名が「ローカル混合待受ポート」になっていたり、SOCKSとHTTPのポートが別々に表示されたりします。実際の項目の意味に従って設定してください。
-
現在の設定を控える
現在のローカルポート、待受アドレス、システムプロキシの状態を控えてください。ブラウザー拡張機能、ターミナルの環境変数、開発ツールで古いポートを手動指定している場合は、それらも記録します。
-
新しいポートを確認
検索コマンドの
10808を10818に置き換え、競合する待受がないことと、新しいポートが該当する除外範囲に含まれていないことを確認します。 -
インバウンドポートを変更
「設定」→「パラメーター設定」→「基本設定」を開き、ローカル待受ポートの項目を探します。混合インバウンドには
10818を入力します。画面でSOCKSとHTTPを別々に設定する場合は、それぞれの項目に異なるポートを指定してください。独立した2つのインバウンドで、同じTCPアドレスとポートを待ち受けないようにします。 -
保存して再起動
「OK」をクリックして保存し、コアに設定を再読み込みさせます。自動的に再起動しない場合は、通常の手順でv2rayNを終了してから再度開いてください。今回の起動ログを確認し、新たなbindエラーがないことを確かめます。
-
プロキシアドレスを更新
メイン画面下部の「システムプロキシ」で、まず「システムプロキシをクリア」を選び、続けて「システムプロキシを自動設定」を選択します。その後、手動プロキシツールで使用している古いポートを新しいポートに変更してください。
古い設定では、SOCKSとHTTPを10808と10809に分けている場合があります。一方、混合インバウンドなら1つのポートで両方のプロキシリクエストを受け付けられます。「HTTPは必ずSOCKSのポート番号に1を足す」という規則を当てはめないでください。カスタム設定を使用している場合、画面上の項目がその設定のインバウンドに反映されないことがあります。実際に読み込まれている設定ファイルとログを確認してください。
5. ポート変更後、3段階でプロキシの復旧を確認
まず新しいポートで現在のコアが実際に待ち受けていることを確認します。次にプロキシを明示してコマンドラインからテストし、最後にアプリが古いポートを参照していないか確認してください。これにより、「コアが起動していない」「ノードに接続できない」「アプリの設定が更新されていない」を切り分けられます。
Get-NetTCPConnection -State Listen -LocalPort 10818 -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, State, OwningProcess
# 10818 が HTTP または混合インバウンドとして設定されている場合のみ
curl.exe --proxy http://127.0.0.1:10818 --connect-timeout 10 --max-time 20 -I https://www.microsoft.com/curl.exeを明示的に実行し、一部のPowerShell環境でcurlが別のコマンドとして解釈されるのを避けます。テスト対象には公開HTTPSページを指定します。対象に接続できない場合は、アクセスできることを確認済みのHTTPSアドレスに変更してください。サブスクリプションのリンクやノードの認証情報をスクリーンショットやログで公開しないでください。
| 確認結果 | 内容 | 次の手順 |
|---|---|---|
| 10818で待受がない | 設定が反映されていないか、コアの起動に失敗しています | 最新の起動ログを確認し、項目名と実際に読み込まれた設定を照合する |
| ローカルプロキシに接続できないと表示される | アドレス、ポート、またはインバウンドプロトコルが一致していません | 待受アドレスを確認し、SOCKSポートをHTTP用として使っていないか確認する |
| CONNECTは成功するが、その後のリクエストが失敗する | ローカルプロキシのハンドシェイクは確立したものの、その後の通信経路に問題があります | ノード、DNS、TLS、接続先サイトの応答を引き続き確認する |
| 最終的なHTTPレスポンスを受信 | このリクエストは指定したローカルプロキシ経由で完了しました | ブラウザーや他のアプリのプロキシ設定も確認する |
ポートがSOCKS専用の場合は、次のコマンドを使います。socks5hを指定すると、接続先のドメイン名をプロキシ側で解決します。HTTPとSOCKSのテストはインバウンドの種類に応じて選択してください。すべての設定で両方を同時にサポートする必要はありません。
curl.exe --proxy socks5h://127.0.0.1:10818 --connect-timeout 10 --max-time 20 -I https://www.microsoft.com/まとめ：ローカルリクエストの成功を確認してから、アプリごとの差を調べる
プロキシを明示したテストが成功するのにブラウザーでは失敗する場合は、ブラウザー独自のプロキシ設定、古いポートのキャッシュ、システムプロキシの状態を先に確認してください。ポートを何度も変更する必要はありません。リクエストがローカルプロキシに届いても、必ずリモートノードを経由するとは限りません。最終的な送信先はルーティングの振り分けルールで決まります。
6. ポートの使用中や変更後によくある質問
使用中のプロセスがコアなら、そのまま終了してもよいですか？
パスと親プロセスから、どのプログラムに属するか確認してください。現在正常に動作しているコアの場合も、別のv2rayNインスタンスに属している場合もあります。まず該当する管理プログラムを終了してください。残存プロセスだと確認できた場合に限り、タスクマネージャーで終了することを検討し、その後ポートを再確認します。
10818に変更したのに、ターミナルで10808への接続失敗が表示されるのはなぜですか？
HTTP_PROXY、HTTPS_PROXY、ALL_PROXYの環境変数と、開発ツール独自のプロキシ設定を確認します。使用するポートを正しい新しいポートに変更し、ターミナルを開き直してください。起動済みのプロセスは、後から変更した環境変数を通常は自動で読み込みません。
PCの再起動後は直るのに、しばらくするとまたポートが使用中になる場合は？
競合が起きたときに、PID、パス、親プロセスをもう一度記録し、v2rayNが2つ起動していないか、別のプロキシサービスが同時に自動起動していないか確認します。必要な起動設定だけを残してください。複数のプログラムを同時に動かす必要がある場合は、重複しない待受ポートをそれぞれに割り当てます。
TUNを有効にした後もポートエラーが出る場合、この記事の手順で確認できますか？
ログにローカルインバウンドのbind失敗が明記されている場合は、該当ポートをこの記事の手順で確認してください。仮想ネットワークアダプターの作成、ドライバー、ルート権限に関するログであれば、別の層の問題です。まずTUNを無効にし、ローカルHTTPまたはSOCKSインバウンドで基本動作を確認してから、TUNを個別に調べてください。
非常に大きな番号のポートに変更してもよいですか？
使用中ではなく、予約範囲にも含まれていないポートを選べます。有効なポート番号は1～65535です。番号が大きくても空いているとは限らないため、変更前に検索し、変更後は手動プロキシの設定もすべて更新してください。
確認が終わったら、競合したポート、使用中プロセスのパス、変更後のインバウンド種類とポート、確認結果を簡潔に記録しておきましょう。次回クライアントを更新したり設定を復元したりする際に、これらの値を先に確認すれば、ノードを何度も切り替えるより原因を見つけやすくなります。