Windows版v2rayNの起動時にコアの起動に失敗する、ログに待受ポートの競合が表示される、またはポート変更後もブラウザーが接続できない場合の対処法です。「エラーのアドレスを確認→プロセスを特定→ポートを解放または変更→システムプロキシを更新→接続を確認」の順に進め、ポート使用中とシステムの予約ポートを切り分けます。プロセスの誤終了やポートの無闇な変更を避けましょう。
まず確認：エラーはローカルの待受ポートで発生している
v2rayNはGUIクライアントで、実際にポートを待ち受けてプロキシ接続を処理するのは起動したコアです。ブラウザーがシステムプロキシを使う場合、通常はまず127.0.0.1:10808などのローカルアドレスに接続します。この入口が確立できていないと、サブスクリプションやノード設定に問題がなくても、ブラウザーからリクエストを送信できません。
v2rayNのメイン画面にあるログ欄を開き、直近の起動失敗箇所を確認します。「起動に失敗しました」という最後の行だけでなく、エラーに記載されたプロトコル、アドレス、ポートを控えてください。10808はよくある例ですが、すべてのバージョンや設定で使われるとは限りません。実際の調査ではログに記録されたポートを使います。
エラー：Only one usage of each socket address (protocol/network address/port) is normally permitted.
原因と対処：Windowsでソケットアドレスが競合しています。TCPポートがすでに待ち受け状態になっている場合によく発生します。まず待受プロセスを特定し、重複起動したインスタンスを終了するか、v2rayNのポートを変更してください。
エラー：An attempt was made to access a socket in a way forbidden by its access permissions.
原因と対処：システムによってバインドが拒否されていますが、必ずしも別のプロセスがポートを使用中とは限りません。待受プロセスが見つからない場合は、システムの除外ポート範囲とセキュリティポリシーを確認してください。
一方、connection refusedは接続が拒否されたことを示す場合が多く、接続先アドレスと合わせて判断する必要があります。ローカルの旧ポートへの接続拒否と、リモートノードへの接続拒否は別の問題です。ノードのアドレスに対するタイムアウトだけで、ローカルポートが原因だとは判断できません。
使用中のポートを特定：ポートからプロセスのパスを調べる
以下のコマンドはWindows PowerShellで実行します。まず10808のTCP待受状態を調べます。出力がない場合、この検索では該当ポートのTCP待受プロセスが見つからなかったことを示します。ポートを必ずバインドできるという意味ではありません。
Get-NetTCPConnection -State Listen -LocalPort 10808 -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, State, OwningProcess特に確認するのはLocalAddressとOwningProcessです。待受アドレスが0.0.0.0の場合、すべてのローカルIPv4インターフェイスが対象となるため、127.0.0.1にバインドされた同じポートの待受と競合することがあります。IPv6の::とIPv4が競合するかどうかはソケットのオプションにも左右されるため、アドレス全体を確認してください。
次に、該当プロセスの名前、実行ファイルのパス、コマンドラインを確認します。以下のコマンドは検索結果からプロセスIDを取得するため、PIDを手入力する必要はありません。
$listeners = Get-NetTCPConnection -State Listen -LocalPort 10808 -ErrorAction SilentlyContinue
$ownerIds = $listeners | Select-Object -ExpandProperty OwningProcess -Unique
foreach ($ownerId in $ownerIds) {
Get-CimInstance Win32_Process -Filter "ProcessId = $ownerId" |
Select-Object ProcessId, Name, ExecutablePath, CommandLine
}| 検索結果 | 意味 | 次の手順 |
|---|---|---|
| 別のv2rayNフォルダー内のパス | 別フォルダーのクライアントを重複して起動している可能性があります | 不要な方を通知領域のトレイメニューから終了し、ポートを再確認します |
| 名前がxray.exeで、クライアントフォルダー内のパス | 現在使用中のコアか、終了後に残ったコアの可能性があります | まずクライアントを終了し、待受も停止するか確認します |
| 既知の別プログラムのパス | 2つのプログラムが同じローカルポートを使用しています | 必要なプログラムはそのままにし、もう一方のポートを変更します |
| TCPの待受結果がない | ポート予約、UDPの競合、またはプロセスが一時的に終了した可能性があります | ログのプロトコルを確認し、システムの除外範囲を調べます |
プロセスのパスが空欄の場合は、管理者としてPowerShellを開き直して詳細を確認できます。プロセス名だけでシステムサービスを終了したり、すべてのコアプロセスを残存プロセスと判断したりしないでください。正常に動作しているコアは、クライアントに設定された待受ポートを使用します。
ポートを解放：まず重複したインスタンスを終了する
同じクライアントの別インスタンスが見つかった場合は、タスクバーの通知領域にあるトレイメニューから「終了」を選ぶ方法が確実です。メイン画面の閉じるボタンを押しても、ウィンドウが隠れるだけで待受が続くことがあります。終了後にポートを再検索し、待受が消えたことを確認してから、使用するクライアントを起動してください。
- 使用中のプロセスのPID、ファイルパス、コマンドラインを控え、どのプログラムフォルダーに属するか確認します。
- 該当プログラムの通常の終了操作を行い、数秒待ってから
10808を再検索します。 - クライアントを終了した後も、そのフォルダーに属するコアが動作していると確認できた場合は、タスクマネージャーの「詳細」タブでPIDを照合してから終了します。
- v2rayNを1つだけ起動し、同じバインドエラーがログに再び表示されないか確認します。
待受ポートを変更：代替例は11808
元のポートを別のプログラムに割り当てる必要がある場合は、v2rayNのローカル待受ポートを11808に変更できます。この番号は代替例であり、お使いのPCで空いているとは限りません。先ほどのコマンドで11808を確認し、必要に応じて後述のシステム除外範囲も調べてください。
-
現在の設定を控える
現在のポート、待受アドレス、システムプロキシの状態を控えておきます。この記事では
127.0.0.1:10808を127.0.0.1:11808に変更します。ノードのリモートポートは変更しません。 -
パラメーター設定を開く
「設定」→「パラメーター設定」を開き、基本設定の項目からローカル待受ポートを探します。画面上の項目名は「ローカル混合待受ポート」や「ローカル待受ポート」など、バージョンによって異なる場合があります。お使いのバージョンに表示される項目を確認してください。
-
新しいポートを入力する
該当するローカル入口を
11808に変更します。画面にSOCKSとHTTPの入口が個別に表示される場合は、それぞれの項目を確認してください。独立した2つの待受に同じポートを設定することはできません。混合入口では、1つのポートで両方のプロトコルを受け付けられます。 -
保存して再起動する
設定を保存し、コアを再読み込みします。自動で再起動しない場合はv2rayNを終了して起動し直し、
11808の待受プロセスを検索して、今回起動したクライアントのパスであることを確認します。 -
システムプロキシを更新する
メイン画面またはトレイの「システムプロキシ」メニューで、「システムプロキシを解除」を選んでから「システムプロキシを自動設定」を選びます。その後、システムプロキシの接続先が新しいポートになっているか確認してください。
ローカル待受ポートとノードのリモートポートは、別々の設定です。ノード編集画面にある443などのポートはリモートサーバー側のものです。これを変更するとノードへの接続に失敗することがあり、ローカルの10808の競合解消には使えません。カスタム設定を使用している場合は、実際に有効なインバウンド設定も確認してください。共通のパラメーター画面では、カスタムインバウンドが上書きされないことがあります。
プロキシ設定を同期：旧ポートに接続するアプリを確認する
ポート変更後によくあるのが、アプリが古い入口に接続し続ける問題です。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」でアドレスとポートを確認できます。Windows 10では「設定」→「ネットワークとインターネット」→「プロキシ」を開きます。一般的なローカルHTTPプロキシの場合は、接続先が127.0.0.1、ポートが11808になっているか確認してください。
- システムプロキシを使うブラウザー：システムプロキシを更新した後、ページを再読み込みします。ブラウザーに独自のプロキシ拡張機能がある場合は、その設定も確認してください。
- プロキシを手動設定したアプリ：アプリ内の
127.0.0.1:10808を新しい接続先に変更し、HTTPとSOCKSのどちらが必要か確認してください。 - コマンドライン環境：
HTTP_PROXY、HTTPS_PROXY、ALL_PROXYが古いポートを指していないか確認します。すでに開いているターミナルには、後から変更した環境変数は自動で反映されません。 - TUNを使用する場合：システムプロキシとTUNは、通信を中継する別の方法です。ローカル入口を調べる間はテスト方法を1つに固定し、ルーティングや通信制御の設定を同時に切り替えないでください。
以下のコマンドで、現在のPowerShellセッションに設定されているプロキシ環境変数を確認できます。古い値が見つかった場合は、ブラウザーを更新するだけでなく、設定元のターミナル構成またはシステム環境変数の画面で修正してください。
Get-ChildItem Env: |
Where-Object Name -Match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$'動作確認：待受と外部接続を分けてテストする
まず新しいポートで待ち受けていることを確認し、その後、そのポート経由でリクエストを送ります。以下の例は11808がHTTP対応の混合入口またはHTTP入口であることを前提としています。独立したSOCKS入口の場合は、後述のSOCKS用コマンドを使ってください。
Get-NetTCPConnection -State Listen -LocalPort 11808 -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, OwningProcess
Test-NetConnection -ComputerName 127.0.0.1 -Port 11808
curl.exe --noproxy "" --proxy http://127.0.0.1:11808 --connect-timeout 10 --max-time 20 -I https://example.com/TcpTestSucceeded : TrueはTCP接続が成功したことを示すだけで、待受プロセスがv2rayNであることや、リモートノードが利用可能であることを示すものではありません。プロセスのパスを確認し、リクエスト時にコアのログへ対応する記録が出るかも確認してください。HTTPレスポンスヘッダーが表示された場合は応答を受信できていますが、ステータスコードは接続先サイトに応じて判断が必要です。
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:11808 --connect-timeout 10 --max-time 20 -I https://example.com/SOCKSの例にあるsocks5hは、接続先のホスト名の名前解決をプロキシ側で行う指定です。2つのコマンドは入口の種類に応じてどちらか一方を使ってください。テストを成功させるために、ノードのプロトコルをむやみに変更しないでください。プロキシを明示したリクエストは成功するのにブラウザーで失敗する場合は、待受ポートを再変更するのではなく、システムプロキシとブラウザー独自の設定を確認します。
使用中のプロセスが見つからない：システムの予約ポートを確認する
アクセス権に関するバインドエラーが発生し、TCP検索でも何も見つからない場合は、管理者権限のターミナルでWindowsの除外ポート範囲を確認してください。仮想化機能やネットワークコンポーネントによって、こうした範囲が設定されることがあります。ポートが範囲内にあると、ユーザープロセスが待ち受けていなくてもバインドできない場合があります。
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp出力には範囲の開始ポートと終了ポートが表示されます。たとえば、ある行が11800から11899までの場合、11808も範囲内です。これは出力の読み方を示す例で、お使いの端末にこの予約範囲があるとは限りません。範囲外で待受プロセスのいないポートを選び、設定を保存してテストしてください。由来のわからないシステム予約を直接削除しないでください。
- ログに
udpと記載されている場合は、Get-NetUDPEndpoint -LocalPort 10808 -ErrorAction SilentlyContinueでUDPの使用状況を確認してください。TCPだけを検索しないようにします。 - バインド先のアドレスが現在の端末に割り当てられていない場合は、プロセスを終了し続けるのではなく、待受アドレスの設定を確認してください。
- 予約されていない空きポートを複数試しても拒否される場合は、セキュリティソフトのイベントと組織のデバイスポリシーを確認し、ログ全体を保存して管理者に判断を依頼してください。
ポート競合に関するよくある質問
11808に変更したのに、Webページを開けないのはなぜですか？
まず新しいポートを正しいコアが待ち受けていることを確認し、「システムプロキシ」で設定を解除してから自動設定し直してください。ブラウザー拡張機能、手動プロキシ、環境変数に10808が残っていないか確認します。新しいポートを明示したcurlコマンドで、ローカル入口の問題かノードの問題か切り分けられます。
起動するたびに競合します。毎回手動でプロセスを終了する必要がありますか？
プロセスの終了を毎回の手順にする必要はありません。タスクマネージャーの「スタートアップ アプリ」とタスクスケジューラを確認し、クライアントが2つ自動起動していないか調べてください。起動方法を1つに統一します。2つのプログラムを同時に使う必要がある場合は、別々のポートを割り当ててください。
ノードの変更やサブスクリプションの更新で10808の競合は解消しますか？
ローカル待受ポートを直接解放することはできません。サブスクリプションにはノード設定が含まれますが、ノードのリモートポートとローカルのインバウンドポートは別です。まずコアがローカルポートにバインドできるようにし、その後、実際の接続遅延とノードの稼働状況を確認してください。
管理者として起動したら成功しました。今後も毎回その方法で起動すべきですか？
まず、通常起動時との違いを調べてください。ループバック用プロキシの待受に通常は管理者権限は不要です。管理者として起動すると適用されるポリシーが変わることもありますが、2回目の起動時に元の占有プロセスが終了しただけかもしれません。待受プロセス、予約範囲、ログを再確認し、権限昇格で原因を覆い隠さないようにしてください。