Windowsでv2rayNの起動時にコアの起動に失敗し、ログにbindやaddress already in useと表示される場合が対象です。まずポート競合と権限の問題を切り分け、netstatまたはPowerShellで待受プロセスを特定します。用途を確認したうえで重複起動したプロセスを終了するか、ローカル待受ポートを変更します。最後にシステムプロキシとアプリの設定を更新し、接続を確認します。
まずログを確認：ローカル待受に失敗しているか
v2rayNのウィンドウが開いていても、プロキシコアが正常に起動したとは限りません。画面は設定を管理し、コアはローカル接続を受け付けてリモートサーバーへ接続します。ログに 127.0.0.1:10808 で待受できないと表示される場合、問題はPC側の接続口にあります。この状態でサブスクリプションを何度も更新したり、VMessやVLESSのノードを切り替えたりしても、通常は待受エラーを解消できません。
まずメイン画面のログ欄を確認し、エラー行を省略せず記録してください。特にアドレス、ポート、末尾に表示されるシステムエラーが重要です。エラーの表現はコアやシステムの言語、バージョンによって異なるため、以下は実際のエラーによく見られる部分です。行全体の文言が完全に一致する必要はありません。
bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
原因と対処：同じ待受アドレスとポートが競合しています。該当するPIDを調べ、別のv2rayNや他のローカルサービスか確認してから、プロセスを終了するかポートを変更してください。
bind: address already in use
原因と対処：対象のソケットが使用中です。使われているポートはログに表示された値を調べ、普段使う10808だけを確認しないようにしてください。
bind: An attempt was made to access a socket in a way forbidden by its access permissions.
原因と対処：システムがバインドを拒否しています。ポートの除外範囲やセキュリティポリシーが原因の可能性があり、プロセスがすでに待ち受けている状態とは限りません。PIDが見つからない場合は、システムの予約ポートを確認してください。
ポートを確認：10808と10809を同時に使うとは限らない
一部の旧バージョンや旧設定では、10808をSOCKS用、10809をHTTP用の入口として使用します。一方、HTTPとSOCKSの両方を1つの混合待受ポートで受け付けるバージョンもあります。現在の「設定」→「パラメーター設定」にある項目と起動ログを基準にしてください。チュートリアルを参考に、存在しない入口を追加で作らないようにしましょう。
ローカル待受ポートとサーバーのポートは別の設定です。ノード編集画面の「ポート」はリモートサーバーへの接続設定であり、ローカルの10808の競合解消には使えません。サブスクリプションで指定されたサーバーアドレス、ユーザーID、伝送方式、TLS設定も変更しないでください。
判断のポイント：競合しているローカル接続口だけを変更
ログに10808と表示されている場合は、まず10808の待受プロセスを特定してください。10809も確認する必要があるのは、現在の設定で独立したHTTP接続口を有効にしている場合だけです。ノードのリモートポートを変更すると、別の接続障害を招く可能性があります。
プロセスを特定：PIDから待受中のアプリを調べる
Windowsの「ターミナル」または「コマンド プロンプト」を開き、次の2つのコマンドを実行します。通常の確認に管理者権限は不要です。プロセスのパスを確認できない場合は、管理者としてターミナルを開いて調べてください。コマンドはネットワークの状態を読み取るだけで、プロセスを終了しません。
netstat -ano -p tcp | findstr ":10808"
netstat -ano -p tcp | findstr ":10809"ローカルアドレスの末尾が対象ポートになっているか、状態が LISTENING かを確認してください。例：127.0.0.1:10808、0.0.0.0:10808、[::]:10808。リモートアドレスに含まれる10808や、状態が TIME_WAIT の古い接続を、現在の待受プロセスと取り違えないでください。
一番右の列がPIDです。以下は出力形式の例で、実際の端末で取得した結果ではありません。6420はプロセス名の確認方法を説明するための例です。実際には画面に表示されたPIDに置き換えてください。
TCP 127.0.0.1:10808 0.0.0.0:0 LISTENING 6420
tasklist /FI "PID eq 6420"PowerShellでポートを絞り込む
出力を1行ずつ確認したくない場合は、PowerShellでローカルポートと待受状態を条件に絞り込めます。何も表示されない場合、検索した時点で一致するTCP待受項目がないことを示します。ポートを確実にバインドできるという意味ではなく、プロセスが繰り返し起動している可能性もあります。
Get-NetTCPConnection -State Listen -LocalPort 10808,10809 -ErrorAction SilentlyContinue |
Select-Object LocalAddress,LocalPort,OwningProcess
Get-Process -Id 6420 | Select-Object Id,ProcessName,Path- v2rayNまたはそのコアのプロセスが見つかった場合：クライアントを別々のフォルダーから起動していないか、前回終了した際にコアのプロセスが残っていないか確認してください。
- 他のアプリが見つかった場合：プロセスのパス、ウィンドウ、スタートアップ項目を確認してください。停止できないサービスは終了せず、v2rayN側のポートを空いている番号に変更できます。
- システムサービスや不明なプロセスが見つかった場合：まずPIDとパスを記録し、強制終了は避けてください。優先的にv2rayNのローカル接続口を変更します。
競合を解消：重複起動を終了するかローカルポートを変更
ポートを使用しているのが重複起動したクライアントなら、まずシステムトレイの右クリックメニューから「終了」を選んでください。ウィンドウ右上の閉じるボタンを押しただけでは、ウィンドウが閉じて待受ポートが残る場合があります。終了後にもう一度検索し、元の待受項目が消えたことを確認してから、使用するv2rayNを起動してください。
- 現在の設定を記録：「設定」→「パラメーター設定」を開き、ローカル待受に関する項目を確認します。バージョンによって「ローカル待受ポート」「ローカル混合待受ポート」など表示が異なる場合があります。ポート、待受アドレス、独立したHTTP接続口の有無を記録してください。
- 候補ポートを確認：以下のコマンドで11808を確認します。2つ目の独立した接続口が必要な場合のみ、11809も確認してください。待受項目がないことを確認するのは最初の手順です。保存後も起動に成功したか確認してください。
- ローカル接続口を変更：競合しているローカル待受ポートを11808に変更します。画面に独立したHTTPポートが明示され、その接続口も競合している場合は、11809など別の空きポートを設定してください。混合ポートの設定では、2つ目の項目を追加する必要はありません。
- 保存して再起動：設定を保存して読み込み直します。新しい起動ログが表示されない場合は、v2rayNを終了して再度開き、新しいポートの待受状態を確認してください。
- 待受範囲を維持：PC内だけで使う場合はループバックアドレスのままにしてください。ポート競合を解消するために「LANからの接続を許可」を有効にしないでください。待受範囲を広げてもポート競合は解消しません。
Get-NetTCPConnection -State Listen -LocalPort 11808,11809 -ErrorAction SilentlyContinue |
Select-Object LocalAddress,LocalPort,OwningProcess11808と11809は説明のための候補値であり、常に安全に使えるポートではありません。他のサービスが使用中の場合は、未使用でシステムの除外対象にもなっていない高い番号のポートを選んでください。ポート競合とルーティングの振り分けは別の問題です。修正中にGeoSiteルール、DNS、TUNモードまで変更すると確認項目が増えるため、変更する必要はありません。
待受プロセスが見つからない場合：Windowsのポート除外範囲を確認
netstatで待受プロセスが見つからないのに、ログに権限関連のbindエラーが繰り返し表示される場合は、管理者として開いたターミナルでWindowsのTCP除外範囲を確認してください。仮想化ソフト、コンテナー、システムのネットワークコンポーネントがポートを予約している場合、予約ポートに対応するPIDが表示されないことがあります。
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp出力には開始ポートと終了ポートが表示され、両端のポートも範囲に含まれます。たとえば、ある行に11700から11799と表示されていれば、11750も範囲内です。これは出力の読み方を示す例で、システムが実際にこの範囲を予約しているという意味ではありません。ログに記載された待受アドレスをもとに、該当するアドレスファミリーの結果を確認してください。
- 候補ポートが除外範囲に含まれている場合は、範囲外の別のポートを選び、設定を保存してからコアを起動し直してください。
- ローカルプロキシの接続口を空けるために、システムの除外範囲を削除したり、よく分からないネットワークサービスを停止したりしないでください。
- ポートが待受中でも除外範囲内でもないのにバインドできない場合は、セキュリティソフトのイベント、コアのログ、重複したインバウンド設定を確認してください。
- 同じ設定内で待受接続口が重複して定義されている場合も、競合が発生することがあります。カスタム設定を使っている場合は、インバウンドのアドレスとポートの組み合わせを確認してください。
修復を確認：システムプロキシと手動プロキシを更新
新しいポートで待受が始まったら、プロキシを使うアプリの接続先も新しい接続口に変更してください。コアが復旧しても、ブラウザーが古い10808に接続し続けると、ページを開けない場合があります。まずv2rayN画面下部の「システムプロキシ」メニューから「システムプロキシをクリア」を選び、続けて「システムプロキシを自動設定」を選択します。現在の設定に基づいて、クライアントがプロキシアドレスを書き直します。
混合接続口 127.0.0.1:11808 を例に、WindowsターミナルからHTTPプロキシ経由でリクエストを送信できます。ここでは curl.exe を使います。PowerShellの環境によっては、curl が別のコマンドとして解釈されるためです。独立したHTTP接続口を使っている場合は、コマンドのポートを実際の値に変更してください。
curl.exe --proxy http://127.0.0.1:11808 --connect-timeout 10 --max-time 20 -I https://example.com/コマンドの10秒は接続タイムアウト、20秒はリクエスト全体の制限時間であり、通信速度の測定値ではありません。最終的な接続先からHTTP応答が返れば、このリクエストでローカルプロキシとその先の経路が使えたことを示します。プロキシトンネルの確立メッセージが表示されただけでは、接続先のページが正常に応答したとは限りません。また、1回の成功で全アプリがシステムプロキシを使っていると判断することはできません。
- 待受状態を確認：新しいポートに
LISTENINGの項目があり、PIDが現在使用中のクライアントコアに属していることを確認してください。 - ログを確認：元のbindエラーが再発していないことを確認してください。リモート接続のタイムアウトが表示された場合は、ローカルポートを変更し続けるのではなく、ノードの接続状況を調べてください。
- アプリの設定を確認：ブラウザー拡張機能、開発ツール、ターミナルの環境変数、その他の手動プロキシ設定は、システムプロキシの更新に連動するとは限りません。それぞれ新しいアドレスに変更してください。
- 再起動後を確認：一度終了して起動し直し、ポートの変更が保存されていることを確認します。システムのスタートアップ項目から別のクライアントが起動していないかも確認してください。
よくある質問：ポート変更後も接続できない
ウィンドウを閉じたのに、なぜ10808で待受中ですか？
まずシステムトレイにv2rayNのアイコンが残っていないか確認してください。ウィンドウを閉じても、最小化されてトレイに残っていることがあります。アイコンを右クリックして「終了」を選んでください。その後、PIDをもう一度調べます。まだ待受項目がある場合は、別のフォルダーにあるインスタンスや残ったコアがないか確認し、使用元を特定してから対象のプロセスを処理してください。
10809で何も見つかりません。設定が壊れていますか？
必ずしもそうではありません。現在のバージョンで混合接続口を1つだけ設定している場合、10809で待受がないのは正常です。「設定」→「パラメーター設定」で接続口の種類を確認してください。HTTPとSOCKSのリクエストには、旧チュートリアルの初期値ではなく、現在有効なポートを使ってください。
11808に変更したらブラウザーは使えるのに、ターミナルでは使えません。
ターミナルの HTTP_PROXY、HTTPS_PROXY、ALL_PROXY が古いポートを指していないか確認してください。クライアント側でポートを変更しても、プロキシ環境変数は自動更新されません。変更後は通常、新しいターミナルを開く必要があります。環境変数の影響を切り分けるには、上記の --proxy を指定するコマンドで接続口を明示する方法もあります。
起動のたびに競合します。毎回ポートを変える必要がありますか？
その必要はありません。「タスク マネージャー」→「スタートアップ アプリ」で起動項目を確認し、クライアント側の自動起動設定も調べて、必要な起動方法だけを残してください。もう一方が必要なローカルサービスの場合は、双方に別々のポートを割り当てて固定し、各アプリのプロキシ設定も新しいポートに合わせてください。