Webページが開けないときは、まずローカルの待ち受けが成功しているか、リクエストがコアに届いているかを確認し、次に名前解決・接続先への接続・プロトコルのハンドシェイクを切り分けます。この記事ではWindows版v2rayNとXrayコアを例に、ポート確認コマンドや代表的なエラー、1回のリクエストで再現する手順を紹介します。ノードを登録済みで、問題の発生箇所を特定したい方に適しています。
1. クライアントの通知とコアのログを区別する
v2rayNはクライアント管理ツール、Xrayは接続を実際に処理するコアです。サブスクリプションのダウンロード失敗や画面上の設定保存エラーはクライアント側で発生することがあります。一方、ポートの待ち受け、ルーティング、ノードへの接続、TLSハンドシェイクは主にコアのログで確認します。クライアントが起動しても、コアの待ち受けが成功しているとは限りません。ノード一覧に表示されていても、接続できるとは限りません。
トラブル対処を始める前に、v2rayNとXrayそれぞれのバージョンを控えておきましょう。クライアントのバージョンは「ヘルプ」→「バージョン情報」で確認でき、Xrayのバージョンはコアの起動ログに記録されています。デスクトップ版のメニュー構成はバージョンによって異なる場合があります。この記事では「設定」→「パラメーター設定」の項目名を手掛かりにし、特定バージョンの既定ポートを全バージョン共通の値として扱いません。
処理の流れを逆にたどると、原因を絞り込めます。ローカル接続が拒否された場合は、まずノードのパスワードを変更する必要はありません。ノードのアドレスへの接続タイムアウトが記録されているなら、ブラウザーの設定だけを確認しても解決しません。証明書エラーが出ている場合はTLS検証まで処理が進んだことを示しますが、プロキシプロトコルの認証に成功したとは限りません。
2. ログレベルとログ1行の読み方
Xrayのエラーログには、主にdebug、info、warning、errorのレベルがあります。また、該当するログを出力しないnoneもあります。warningに設定すると、通常はそれより低いレベルのinfoやdebugは表示されません。アクセスログは別種の記録であり、infoレベルのエラーログと同じものではありません。
| レベル | 主な用途 | 使い方の目安 |
|---|---|---|
| debug | 接続や処理の詳細を確認する | 問題を再現する間だけ一時的に有効にする |
| info | 起動や接続処理など一般的なイベントを確認する | 最初の調査に適している |
| warning | 異常な接続や設定上の問題の可能性を確認する | 対象のリクエストと照らし合わせて影響を判断する |
| error | 重大な処理エラーの原因を特定する | 起動や待ち受けに影響していないか優先して確認する |
以下は簡略化したアクセスログの例であり、実測結果ではありません。ログの日付形式、接続ID、アウトバウンドのタグは、コアのバージョンや生成された設定によって異なります。角括弧内のタグは設定名です。名前だけで実際のルーティングが正しいと判断しないでください。
2026/10/03 10:20:31 from tcp:127.0.0.1:52134 accepted tcp:example.com:443 [socks -> proxy]127.0.0.1:52134は接続元のローカルアドレスです。52134は通常、一時ポートであり、ブラウザーに設定するプロキシの待ち受けポートではありません。example.com:443は今回のリクエスト先です。トラブル対処では、接続先Webサイトのアドレスとノードサーバーのアドレスを区別してください。acceptedはインバウンドのリクエストが受け付けられたことを示します。接続先への接続成功やWebページの読み込み完了を意味するものではありません。- 接続IDがある場合は、同じIDをたどって関連する記録を確認します。ない場合は、時刻と接続先アドレスを手掛かりに前後の記録を照合します。
ポイント：同じリクエストの記録を探し、最も内側の原因まで確認する
失敗したリクエストの前後約10～20行を残し、エラーの連鎖を最後のシステムエラーまたはTLSエラーまでたどります。最も外側にあるfailed to processだけを切り取っても、どの設定を変更すべきか判断できないことがほとんどです。
3. ポート競合：コアが実際に起動しているか確認する
コアが起動直後に終了する、または起動メッセージが何度も表示される場合は、bindやaddress already in useを検索してください。ポート競合はローカルPCで発生するため、サブスクリプションの変更や接続先ノードの切り替えでは通常解決しません。以下はよくあるエラーキーワードです。実際のログでは複数のエラープレフィックスが付く場合があります。
エラー：address already in use
原因：待ち受けようとしているローカルアドレスとポートが、別のプロセスに使用されています。
対処法：ポートを使用しているプロセスを特定し、重複して起動したクライアントを終了します。複数のプログラムを同時に使う必要がある場合は、それぞれ異なる待ち受けポートを設定してください。
エラー：Only one usage of each socket address
原因：Windowsでソケットのバインド競合が発生しています。以前起動したコアのプロセスが残っている場合によく起こります。
対処法：タスクマネージャーでプロセスを確認し、該当するプログラムを終了してからv2rayNを再起動します。正体の分からないシステムプロセスを無闇に終了しないでください。
まず「設定」→「パラメーター設定」でローカルの待ち受けポートを確認します。画面に10808と表示されている場合は、Windowsターミナルで以下の2つのコマンドを実行します。2つ目のコマンドにある4321は、1つ目の出力の最後の列に表示されたPIDの例です。実際の数字に置き換えてください。
netstat -ano -p tcp | findstr ":10808"
tasklist /FI "PID eq 4321"ローカルアドレスの列とLISTENINGの状態を確認してください。検索結果に10808が表示されたというだけで、ポートが使用中だと判断してはいけません。クライアントを終了しても別のプロセスが待ち受けている場合は、そのプロセスを特定します。ポートが空いたらコアを再起動し、バインドエラーが再発するか確認してください。
4. タイムアウトと接続拒否：名前解決と接続先ネットワークを切り分ける
「タイムアウト」は、ある処理が制限時間内に完了しなかったことを示すだけで、ノードの停止を意味するわけではありません。エラーがローカルポート、ノードサーバー、接続先Webサイトのどれに関係するかを確認し、名前解決、TCP接続、接続確立後の読み書きのどの段階で発生したかを調べます。
エラー：lookup … no such host
原因：ドメイン名の名前解決で有効な結果が得られませんでした。対象はノードのドメイン名の場合も、接続先Webサイトのドメイン名の場合もあります。
対処法：まずログに記録されたドメイン名のスペルを確認し、その名前解決を行うDNS設定を調べます。ブラウザー側で名前解決できるからといって、コア側の問題を除外することはできません。
エラー：dial tcp … i/o timeout
原因：TCP接続が時間内に完了していません。サーバーから応答がない、通信経路でパケットが失われる、ファイアウォールによる遮断、接続先アドレスの選択などが考えられます。
対処法：ノードのアドレスとポートを確認し、別のネットワークまたは別の利用可能なノードで1項目ずつ比較します。同じサーバーでのみ失敗するかどうかも記録してください。
エラー：connection refused
原因：接続が明示的に拒否されています。該当ポートでサービスが待ち受けていない場合や、ネットワーク機器が接続を拒否した場合によく起こります。
対処法：接続先が127.0.0.1ならローカルの待ち受けを確認します。ノードサーバーならリモートポートを確認し、サービス提供元に稼働状況を問い合わせてください。
Windowsでは次のコマンドで、ノードのTCPポートに接続できるか確認できます。ここに記載したドメイン名は説明用です。実行前にノード設定にある実際のサーバーアドレスへ置き換え、ポートもノードの設定と一致させてください。このテストは現在のシステムネットワークからTCP接続を試すもので、プロキシ接続全体をテストするものではありません。
Test-NetConnection -ComputerName node.example.com -Port 443TcpTestSucceeded : Trueで確認できるのは、今回TCP接続が成功したことだけです。UUID、TLS、REALITY、トランスポート層の設定は検証されません。- 結果がFalseの場合は、別のネットワークから同じポートをテストして比較してください。一度の失敗だけでは、どの通信区間で遮断されたかは特定できません。
- ノードのアドレスを名前解決できても、接続先WebサイトのDNSが正常とは限りません。両者で名前解決の経路が異なる場合があります。
- 速度テストとWebページへのアクセスでは、接続先やルーティングが異なる場合があります。失敗したWebページに対応するログを基準にしてください。
5. ハンドシェイク失敗：TLSとノード設定を確認する
TCP接続が可能でも利用できない場合は、次にハンドシェイクの段階を確認します。VLESSとVMessはプロキシプロトコル、TLSは安全な通信の一部、WebSocketやgRPCなどはトランスポート方式です。それぞれの設定には関連がありますが、互いに置き換えることはできません。プロトコルとポートを正しく設定しただけでは、設定は完了しません。
エラー：x509: certificate has expired or is not yet valid
原因：証明書の有効期間と現在時刻が一致していません。証明書の期限切れのほか、端末の日付や時刻のずれも考えられます。
対処法：まずWindowsの「設定」→「時刻と言語」→「日付と時刻」で時刻を同期します。時刻が正しいのにエラーが続く場合は、サーバー側で証明書の有効期間を確認してください。
エラー：x509: certificate is valid for …, not …
原因：検証に使われたサーバー名が、証明書の対象ドメインと一致していません。
対処法：サービス提供元の設定と照らし合わせ、TLSのサーバー名またはserverNameを確認してください。ノードのIPアドレスを証明書のドメイン名として安易に設定しないでください。
エラー：websocket: bad handshake
原因：WebSocketのアップグレード要求に期待した応答がありません。パス、Host、リバースプロキシの設定不一致などがよくある原因です。
対処法：WebSocketのパス、Host、TLSの有効・無効、ポートを1つずつ確認します。パスの大文字・小文字やスラッシュを維持し、UUIDだけを変更して済ませないでください。
EOFやconnection reset by peerだけが記録されている場合、分かるのは接続が途中で終了したことだけで、パスワードの誤りとは断定できません。サーバー側からの切断、プロキシプロトコルの設定不一致、途中のネットワークによるリセットでも同様のログが出ることがあります。まず設定全体を確認し、同じノードを別のネットワークで使った場合と比較してください。
- サーバーアドレス、ポート、プロトコル、ユーザーIDを確認します。手動編集でVLESSの設定をVMessノードに適用しないよう注意してください。
- TLSのサーバー名とトランスポート設定を確認します。WebSocketのHostとTLSのserverNameは別の項目です。混同して入力しないでください。
- REALITYを使う場合は、元の設定に従って公開鍵、shortId、serverNameなどを確認します。一般的な証明書エラーと同じ対処法を当てはめないでください。
- まずサービス提供元から有効なノード設定を再インポートしてから、項目ごとに比較してください。手作業で何度も変更すると、違いを追跡しにくくなります。
ポイント：ハンドシェイクエラーは設定を確認し、検証を無効にしない
証明書の名前や有効期間に問題がある場合は、まず時刻、serverName、またはサーバー側の証明書を修正します。証明書検証を無効にすると根本原因が隠れるため、通常の設定としてそのまま使うのは適切ではありません。
6. 1回のリクエストで最小限の再現テストを行う
トラブル対処で避けたいのは、DNSやルーティングを変更し、ノードも切り替え、TUNまで有効にすることです。その後に復旧しても、どの変更が効いたのか分からなくなります。以下の手順では、毎回ノードを1つ、接続先を1つ、接続方式を1つに絞り、変更前後を比較します。
-
現在の状態を記録する
クライアントとコアのバージョン、使用中のノード、ルーティングモード、ローカルポート、TUNの有効・無効を記録します。問題対処を始める前に元の設定を残し、復元できる基準を確保してください。
-
ログレベルを変更する
「設定」→「パラメーター設定」を開き、「ログレベル」を一時的にinfoに変更します。情報が不足する場合はdebugにします。保存後にコアを再起動し、起動ログが更新されたことを確認してください。
-
接続経路を固定する
まずTUNを無効にし、メイン画面で「システムプロキシ」→「システムプロキシを自動設定」を選び、システムプロキシに従うブラウザーでテストします。指定したプロキシポートでテストする場合は、自動設定による接続結果と混同しないでください。
-
1回だけ再現する
ページの自動更新やバックグラウンドのダウンロードを停止し、現在時刻を記録してから、失敗するアドレスに1回だけアクセスします。該当時刻前後の起動ログ、リクエスト、エラーをまとめてコピーし、最後の1行だけを切り取らないでください。
-
1項目ずつ比較する
ノードかネットワークのどちらか一方だけを変更し、同じアドレスに再度アクセスします。問題が解決したらログレベルを元に戻し、システムプロキシとTUNが意図した状態に戻っているか確認してください。
ブラウザーのプロキシ設定を介さずに比較するには、次のコマンドを使えます。10808は実際に有効なSOCKS待ち受けポートを想定しており、待ち時間は最大15秒です。ポートが異なる場合は、コマンドを先に修正してください。socks5hを指定すると接続先ドメインの名前解決をプロキシに任せますが、コア内部のDNS方針は指定しません。
curl.exe --proxy socks5h://127.0.0.1:10808 --max-time 15 --head https://example.com/HTTPステータスコードが返れば、403や405の場合でも、少なくともHTTP応答を受信できたことが分かります。接続タイムアウトとは分けて対処してください。このコマンドでは成功しブラウザーでは失敗する場合は、ブラウザー独自のプロキシ設定、拡張機能、システムプロキシの適用状態を優先して確認します。両方が同じ段階で失敗する場合は、コアのエラーをたどって原因を特定してください。
7. よくある質問とログ共有前の注意点
ノードの遅延時間が表示されるのに、Webページが開かないのはなぜですか？
まず、実行したのがTCP遅延テストか、実際の接続テストかを確認してください。TCP接続が成功しても、プロキシ経路全体が検証されたわけではありません。メイン画面でノードを選択し、右クリックして「サーバーへの実際の接続遅延をテスト」の結果を確認したうえで、失敗したWebページのログから接続先、ルーティング、ハンドシェイクの段階を照合します。
エラーもリクエストログもまったく表示されない場合は？
まずログレベルとアクセスログが有効か確認してください。SOCKSポートを指定したcurlコマンドで再現し、ブラウザーでのアクセスと比較します。ブラウザーからのリクエストだけがコアに届かない場合は、「システムプロキシ」→「システムプロキシを自動設定」とブラウザー独自のプロキシ設定を確認してください。
サブスクリプションの更新がタイムアウトした場合、ノードのハンドシェイクエラーとして調べるべきですか？
まず、失敗したのがサブスクリプションのダウンロードかノードへの接続かを確認します。「サブスクリプショングループ」でサブスクリプションURLと現在の更新方法を確認してください。プロキシ経由で更新する必要がある場合は、まず利用可能なノードがあることを確認し、「プロキシ経由で更新」を選択します。サブスクリプションのダウンロードエラーだけで、一覧のすべてのノードが使えないとは限りません。
ログにEOFがときどき出ます。すぐにノードを変更すべきですか？
この1行だけで判断する必要はありません。まず同じ時刻にWebページの読み込みが実際に失敗したか確認します。ページを閉じたり接続をキャンセルしたりしたときにも、接続終了の記録が残る場合があります。エラーが特定のリクエストに継続して結び付く場合に、ノード設定やネットワーク環境を比較してください。
他の人に調査を依頼する前に、どの情報を隠すべきですか？
サブスクリプションURL全体、アクセストークン、UUID、パスワード、秘密鍵、個人のアクセス記録を削除してください。エラーキーワード、時刻の順序、プロトコルとトランスポートの種類、ポート、置き換え後も一貫したホスト名は残します。公開の場では元の設定ファイル全体を添付しないでください。
有効な問い合わせ内容は簡潔にまとめられます。バージョン、OS、通信の取り込み方法、失敗する接続先の種類、再現時刻、ノードやネットワークを変更したときの変化を記載してください。スクリーンショットの大きさより、エラーの流れが分かることが重要です。ポートが待ち受けていないならローカルの起動を直し、接続先への接続に失敗するならネットワーク到達性を調べ、ハンドシェイクまで進んでいるなら設定を照合します。この順序で進めれば、同じ確認を繰り返さずに済みます。