v2rayNのコア起動に失敗し、ログにbindやaddress already in useが表示されたり、ブラウザーのプロキシが突然使えなくなったりしたWindowsユーザー向けです。失敗した待受アドレスとプロトコルを確認し、ポートを使用しているPIDを特定して、それが二重起動したv2rayN、残存コア、別のプログラムのどれかを判断します。競合プロセスを安全に終了できない場合に限ってポートを変更し、システムプロキシ、ブラウザー、ターミナル、その他の手動プロキシ設定も更新します。
まずローカル待受の失敗か、リモートノードの問題かを確認する
v2rayNはサブスクリプション、ノード、ルーティング、システムプロキシの状態を管理するGUIクライアントです。設定を読み込み、接続を処理するのはプロキシコアです。起動時、コアはWindows上で127.0.0.1:10808のような待受アドレスをバインドします。ブラウザーやターミナルがこの入口にリクエストを渡すと、コアがルーティング規則に従って直接接続またはプロキシ経由で外へ接続します。
ポートが別のプロセスに使用されている場合、コアは通常、ローカルインバウンドの作成段階で停止します。この場合、VMessやVLESSのノードを変更したりサブスクリプションを更新したりしてもポートは解放されません。競合はリモートサーバーへの接続前に発生しているためです。まずv2rayNのコアログを確認し、listen、bind、ローカルアドレス、ポート番号を含む行を探してください。
エラー：listen tcp 127.0.0.1:10808: bind: Only one usage of each socket address is normally permitted.
原因と対処：TCPポート10808は別のプロセスが待ち受けています。まずPIDでプロセスを特定し、二重起動したクライアントや残存コアであれば、該当プロセスを正常終了してから再起動します。
エラー：failed to listen on address: 127.0.0.1:10809
原因と対処：コアが指定されたローカルインバウンドを作成できません。10809のTCPとUDPの使用状況を確認し、設定内で2つのインバウンドに同じアドレス、ポート、転送プロトコルを指定していないか確認します。
エラー：listen tcp 0.0.0.0:10808: bind: address already in use
原因と対処：プログラムがすべてのローカルネットワークインターフェースで10808を待ち受けようとし、既存の待受と重複しています。本機だけで使うなら127.0.0.1にバインドすべきか確認してください。競合を避けるためだけに待受範囲を広げないでください。
Windowsでポートを使用しているPIDを特定する
まずログに記録されたポート番号を書き留め、必ず10808だと決めつけないでください。設定、旧バージョンからの移行結果、ユーザーによる変更によって異なるポートが使われることがあります。以下ではTCP 10808を例にします。ログが10809など別の番号を示している場合は、コマンドのポート番号を実際の値に置き換えてください。
方法1：PowerShellを使用
PowerShellを開き、次のコマンドを実行します。State Listenで待受中のTCPポートに絞り込み、OwningProcessで使用プロセスのPIDを確認できます。
Get-NetTCPConnection -LocalPort 10808 -State Listen |
Select-Object LocalAddress, LocalPort, State, OwningProcess
Get-Process -Id 14632 |
Select-Object Id, ProcessName, Path2つ目のコマンドにある14632はサンプルのPIDです。1つ目のコマンドが実際に返したOwningProcessに必ず置き換えてください。通常のウィンドウでプロセスパスを確認できない場合は、管理者権限でPowerShellを開き直します。ただし、名前が似ているだけでシステムサービスを強制終了しないでください。
方法2：コマンドプロンプトを使用
netstatは古いWindows環境で素早く確認するのに便利です。-aは待受項目を表示し、-nはアドレスを数値のまま表示、-oはPIDを表示します。
netstat -ano | findstr ":10808"
tasklist /FI "PID eq 14632"127.0.0.1:10808が表示され、状態がLISTENINGなら、ローカルループバックアドレスのTCPポートをプロセスが使用しています。0.0.0.0:10808が表示される場合、そのプロセスはすべてのローカルIPv4インターフェースで待ち受けています。そのため、別のプログラムが127.0.0.1:10808をバインドすることもできません。TIME_WAITだけなら、通常はプログラムが現在も待ち受けていることを意味しません。LISTENINGの項目と対応するPIDを引き続き探してください。- インバウンドでUDPが必要な場合は、
Get-NetUDPEndpoint -LocalPort 10808も実行します。TCPの検索結果が空でも、UDPの競合がないとは限りません。
二重起動、残存コア、他のプログラムによる競合を見分ける
PIDを特定したら、プロセスの正体に応じて対処します。多くの場合、ポート自体が壊れているのではなく、同じクライアントを2回起動している、前回終了時にコアだけが動き続けている、または別のローカルプロキシツールや開発サービスが同じポートを使用しています。
まずタスクバーの通知領域とタスクマネージャーを確認します。v2rayNはメインウィンドウを閉じても通知領域に残ることがあるため、もう一度ダブルクリックしてもインスタンスが1つだけとは限りません。通知領域のメニューから正常終了し、関連するコアプロセスも終了したことを確認してください。強制終了は、画面が応答せず、PIDの正体を確認できた場合に限って使います。
| 検索結果 | よくある原因 | 推奨される対処 |
|---|---|---|
| 別のv2rayNプロセス | 二重起動、または旧インスタンスが通知領域で動作中 | 1つのインスタンスだけ残し、クライアントメニューから他のインスタンスを正常終了して、コアを再起動する |
| 独立したコアプロセス | クライアントの異常終了後、関連するコアが終了していない | プロセスのパスと起動時刻を確認し、所属を特定してから残存プロセスを終了する |
| その他のプロキシまたはネットワークツール | 2つのプログラムが同じローカル待受ポートを設定している | どちらのプログラムに元のポートを残すか決め、もう一方には空いているポートを指定する |
| 開発サービスまたはローカルデバッグプログラム | サービスが10808、10809、またはカスタムポートを偶然待ち受けている | 作業中のプロセスをむやみに終了せず、依存関係を確認してどちらか一方の設定を変更する |
| 同一設定内の2つのインバウンド | 手動設定でSOCKS、HTTP、混合インバウンドに同じエンドポイントを指定している | 生成された設定とカスタム設定を確認し、同じアドレス、ポート、プロトコルの組み合わせを避ける |
- ログに記録された待受アドレス、ポート、TCPまたはUDPの種別を書き留めます。
- PowerShellまたは
netstatでPIDを特定し、プロセス名、パス、起動時刻を確認します。 - 二重起動なら、まず正常終了します。業務用プログラムなら影響を評価し、いきなり強制終了しないでください。
- v2rayNのコアを再起動し、ポートを再検索して、PIDが現在のコアプロセスになっていることを確認します。
競合プロセスを解放できない場合に待受ポートを変更する
使用中のプロセスが停止できないサービスである場合や、2つのプロキシ環境を並行して動かす必要がある場合は、v2rayNのローカル待受ポートを変更できます。まずPowerShellで候補ポートが空いているか確認します。たとえば10818を使う場合は、TCPとUDPをそれぞれ調べてください。
Get-NetTCPConnection -LocalPort 10818 -ErrorAction SilentlyContinue
Get-NetUDPEndpoint -LocalPort 10818 -ErrorAction SilentlyContinue2つのコマンドが何も返さないのは、その時点で対応するエンドポイントが見つからなかったという意味にすぎず、永久に予約されたわけではありません。続いてv2rayNの「設定」→「パラメーター設定」を開き、ローカル待受、SOCKS、HTTP、混合プロキシのポート項目を探します。画面のバージョンによって項目名は多少異なるため、現在の画面と生成された設定を基準にしてください。リモートノードのポートをローカル待受ポートに置き換えないでください。
- 元のポート（例：10808）を控えておくと、設定を戻したり、古い値を参照しているアプリを探したりする際に役立ちます。
- 空いている新しいポート（例：10818）を選びます。ポート番号は1～65535の範囲内にしてください。
- 「設定」→「パラメーター設定」で変更を保存し、プロキシコアを再起動して新しいインバウンド設定を反映します。
Get-NetTCPConnection -LocalPort 10818 -State Listenを実行し、新しいポートを現在のコアが待ち受けていることを確認します。- 10808も再検索して、古い待受が消えたか確認します。変更に成功したと思っていても、実際には旧インスタンスがサービスを提供し続けている場合があるためです。
変更後もエラー：listen tcp 127.0.0.1:10818: bind
原因と対処：新しいポートも使用中か、別のv2rayNインスタンスが同じ設定を読み込んでいます。10818のPIDを再検索し、プロセスの特定を省略してポートを次々に試さないでください。
変更後にエラーは出ないが、ブラウザー接続が拒否される
原因と対処：コアは新しいポートで待ち受けていますが、ブラウザーや拡張機能がまだ古いポートを指しています。手動プロキシを127.0.0.1:10808から実際の新しいエンドポイントに更新してください。
待受アドレスの変更にも注意が必要です。本機のアプリだけで使う場合は、通常ループバックアドレス127.0.0.1を維持します。アドレスを0.0.0.0に変えてもポート使用中の解決にはなりません。アクセス可能な範囲が変わり、すべてのインターフェースで待ち受ける既存プログラムとの競合が続く可能性もあります。
ポート変更後はすべてのプロキシ入口を更新する
コアの待受ポートとアプリのプロキシアドレスは一致していなければなりません。v2rayNのパラメーターを変更しても、すべてのブラウザー拡張、ターミナル環境変数、開発ツール、仮想マシンの手動設定が自動で書き換わるわけではありません。システムプロキシをv2rayNが管理している場合は、システムプロキシの状態を設定し直すことで新しいポートが書き込まれることがあります。手動設定のアプリは個別に変更してください。
SOCKSとHTTPの種類も区別する必要があります。どちらも本機上の入口でも、同じポートを使うとは限りません。HTTPクライアントをSOCKS専用ポートに向けると、接続失敗、プロトコルエラー、またはアプリがプロキシを完全に迂回するといった症状が出ることがあります。これはポート使用中とは別の問題です。
| 接続先 | 確認内容 | 変更例 |
|---|---|---|
| Windowsのシステムプロキシ | プロキシサーバーのアドレスとポートがv2rayNによって再設定されているか | 127.0.0.1:10808から127.0.0.1:10818に更新 |
| ブラウザー独自のプロキシ | ブラウザーや拡張機能がシステムプロキシを上書きしていないか | 実際の入口の種類に応じてHTTPまたはSOCKSのポートを更新 |
| ターミナル環境変数 | HTTP_PROXY、HTTPS_PROXY、ALL_PROXY |
古いターミナルウィンドウを閉じ、変数を変更してからセッションを開き直す |
| 開発・ダウンロードツール | アプリ内部に保存されたプロキシのホスト、ポート、プロトコル | 古い10808の参照を削除して再接続 |
| LAN内のデバイス | LANからのアクセスが本当に必要か、対応する待受アドレスは何か | まずアクセス範囲を明確にし、待受範囲を広げることでポートの問題を解決しようとしない |
set HTTP_PROXY=http://127.0.0.1:10818
set HTTPS_PROXY=http://127.0.0.1:10818
$env:HTTP_PROXY="http://127.0.0.1:10818"
$env:HTTPS_PROXY="http://127.0.0.1:10818"前半の2行は現在のコマンドプロンプトセッション、後半の2行は現在のPowerShellセッションに適用されます。いずれもHTTPプロキシの例です。実際の入口がSOCKSの場合は、アプリが対応するSOCKS形式を使い、そのアプリが該当する環境変数を認識するか確認してください。ウィンドウを閉じると、セッション単位の変数は通常保持されません。
よくある疑問と見落としやすい注意点
使用中のプロセスを終了したのに、なぜv2rayNは10808が使用中と表示するのですか？
ポート検索をもう一度実行し、PIDを確認してください。バックグラウンドサービスが自動的に再起動したか、2つ目のv2rayNインスタンスが存在する可能性があります。まず通知領域にある重複インスタンスを終了し、TCPとUDPの両方のエンドポイントが解放されたことを確認します。
10808を10818に変更したら、サブスクリプションも再インポートする必要がありますか？
通常は必要ありません。サブスクリプションにはリモートノードと関連設定が保存され、ローカル待受ポートはクライアント側の接続設定です。変更後はコアを再起動し、システムプロキシと手動設定のプロキシアプリも更新してください。
ログにbindエラーはないのに、ウェブページが開けない場合はどうすればよいですか？
まず新しいポートがLISTENINGになっていることを確認し、アプリが実際にそのポートを使っているか調べます。ローカル入口が正常なら、その後でノードの可用性、ルーティング、DNS、リモートTLS設定を確認します。
システムプロキシを無効にするだけでポートは解放できますか？
それだけでは判断できません。システムプロキシのスイッチは一部のアプリにリクエストの送信先を伝えるもので、コアが待受を続けるかどうかは実行状態で決まります。コアまたはクライアントを終了し、ポートコマンドで再確認してください。
ポートが空いているのに、起動した瞬間にまた使用中になるのはなぜですか？
2つのインスタンスが同時に起動したか、検索後にバックグラウンドプログラムが先にバインドした可能性があります。競合時のPID、プロセスパス、起動時刻を記録すると、ポートを無作為に変更し続けるより原因を見つけやすくなります。
Windowsファイアウォールによる遮断とポート使用中は別の問題です。使用中エラーは、コアが本機でバインドする段階に失敗したことを示します。ファイアウォール規則は通常、接続を許可するかどうかに影響します。明確なbindやaddress already in useが表示されたら、まず待受の競合を解決し、最初からファイアウォールを無効にしないでください。
TUNを使う場合、アプリのトラフィックを取り込む方法はシステムプロキシと異なりますが、コアがローカル制御ポート、DNS入口、その他のインバウンドを作成することはあります。TUNを有効にしたからといって、ログに示された具体的な待受アドレスを無視しないでください。エラーに表示されたポートごとに特定し、漠然とクライアントを再インストールするのは避けます。
完了後の確認リスト
トラブル解決の基準は「エラーウィンドウが消えた」ことではありません。コアが正常に待ち受け、アプリが正しい入口を指し、旧インスタンスが元のポートを使用していないことが重要です。次の順序で確認すれば、ローカルの問題とリモートノードの問題を切り分けられます。
- コアログに
bind、address already in use、または同じ意味の待受失敗が記録されていない。 Get-NetTCPConnectionで新しいポートがListenになっており、PIDが現在使用中のプロキシコアに対応している。- 元のポートが使われていない場合は、残存コアが引き続き待ち受けていないことを確認します。別のサービスが保持している場合は、その用途を記録してください。
- Windowsのシステムプロキシに設定されたアドレス、ポート、プロトコルがv2rayNの現在の待受設定と一致している。
- ブラウザー独自のプロキシ、ターミナル変数、その他の手動設定が古いポートを参照していない。
- まず1つのアプリでローカル接続を確認し、その後で他のアプリを調べます。ノード、ルーティング、DNS、待受ポートを同時に変更しないでください。
- ローカル待受が正常なのにリモート接続に失敗する場合は、ノードアドレス、プロトコルパラメーター、システム時刻、TLS、ルーティング規則の確認に進みます。
要するに、ポート競合は「ログのエンドポイント—PID—プロセスの正体—設定箇所」の順に確認します。二重起動や残存コアはまずプロセスを終了し、停止できない別サービスはローカルポートを変更して回避します。ポートを変更したら、実際にプロキシを使うすべてのアプリにも反映してください。そうしないとコアの起動に成功しても、ブラウザーやターミナルは使えなくなった古い入口にアクセスし続けます。