「クライアントは起動するのに接続できない」「コアが起動直後に停止する」といった場合に役立ちます。まずログの出力元となるコアを確認し、時刻、入口、ルーティング、最も内側のエラーの順に追って原因を特定しましょう。検索可能な実際のエラー例、ポート確認コマンド、設定を一度に一つだけ変更して再テストする手順も紹介します。証明書の問題をDNSの問題として扱うような誤診を防げます。
1. まずログの出力元を確認する：クライアントの通知とコアのエラーを分けて見る
v2rayNはデスクトップ向けのGUIクライアントで、接続処理は選択したコアが担当します。ウィンドウに表示されるサブスクリプションの更新、速度テスト、システムプロキシの設定通知と、Xrayの接続ログは近い場所に表示される場合がありますが、発生する層は異なります。トラブルシューティングを始める前に、使用中のノード、コア、プロキシの入口、操作時刻を記録してください。Xrayの出力だと確認できた場合に限り、Xrayの設定項目に基づいて読み解きます。クライアント名にV2Rayが含まれているからといって、内部で同じコアが使われているとは限りません。
デスクトップ版では、まずv2rayNのメインウィンドウにあるログや情報の表示欄で起動ログを確認し、続いて「設定」→「パラメーター設定」からログ関連の項目を探します。画面構成によって項目名が異なることがあるため、現在のクライアントに表示されている名称を確認してください。Androidでは、v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。それぞれのログ画面から出力を確認し、別のクライアントの設定パスをそのまま当てはめないでください。
- 起動時のログから確認：設定の読み込み、ルールリソースの読み込み、ローカルポートのリッスンが成功しているか確認します。起動時点で失敗している場合は、リモートのWebサイトへの接続テストは後回しにしましょう。
- 確認対象を絞る：現在時刻を記録し、速度テストの繰り返しやバックグラウンドでの一括リクエストを停止して、安定して再現できるアクセスを一度だけ行います。
- 前後のログも残す：最初に失敗した箇所の前後にある関連行をコピーします。ログに接続IDが含まれる場合は、複数の接続が混在したログをまとめず、同じIDを追ってください。
- エラーの原因をたどる：
failed toが何段も続く場合は、最も外側のメッセージだけでなく、その後に続く根本原因まで確認してください。
2. ログレベルとログ行の見方：時刻を確認して接続の段階を追う
Xrayのエラーログでよく使われるレベルはdebug、info、warning、errorです。設定のnoneは、該当するログの出力を無効にします。調査中は一時的にinfoへ引き上げ、情報が足りない場合に限り短時間debugを使いましょう。調査が終わったら元の設定に戻し、接続の詳細を長時間大量に記録しないようにします。アクセスログとエラーログは用途が異なり、エラーログのレベルを上げてもアクセスログが自動で有効になるわけではありません。
2026/11/03 10:15:20 [Info] [123456789] proxy/socks: TCP Connect request to tcp:example.com:443これは個人情報を伏せた形式の例であり、本サイトでの実測結果ではありません。時刻は操作との照合に使い、[Info]はログレベルを示します。数字は同じ接続を追う手掛かりとなり、proxy/socksは処理モジュール、最後のアドレスはそのログに関連する宛先です。形式はコアや出力設定によって異なるため、すべての行に同じ項目があるとは限りません。
この流れに沿って、段階ごとに証拠を確認します。ローカルの入口で受信した記録があっても、アプリからコアへリクエストが渡ったことしか分かりません。特定のアウトバウンドが選ばれた記録があっても、リモートとのハンドシェイクが成功したとは限りません。アクセスログのacceptedは通常、リクエストが受け付けられたことを示すもので、Webページの読み込み完了を意味しません。EOFやcontext canceledはブラウザーがリクエストを取り消した場合にも発生するため、毎回失敗するか、どの段階で起きるか、前後の状況も確認してください。
- 起動直後に停止する：設定の構文、リッスンポート、リソースファイル、ディレクトリのアクセス権を優先して確認します。
- 入口の記録はあるが、想定したアウトバウンドがない：ルーティングで選択されたタグ、直接接続のルール、デフォルトのアウトバウンドを確認します。
- 接続を開始してから失敗する：DNS解決、TCP接続、TLSハンドシェイク、プロトコル設定を切り分けます。
3. 接続タイムアウトと接続拒否：「timeout」だけで判断しない
エラー：i/o timeout
原因と対処：ネットワークの読み込みまたは書き込みが期限内に完了していません。直前に記録されたアドレスとモジュールを確認し、DNS解決、接続、ハンドシェイクのどの段階かを特定してから、その段階のネットワーク経路を調べます。
エラー：connection refused
原因と対処：接続先または中間機器によって接続が明示的に拒否されています。リモートポート、サービスのリッスン状態、ファイアウォールのルールを確認してください。待ち時間を延ばすだけでは、通常解決しません。
エラー：failed to find an available destination
原因と対処：使用可能な宛先の選択または接続に失敗しています。DNSの結果、宛先アドレス、接続エラーをそれぞれ確認するため、内側に続く原因まで読みましょう。このメッセージだけでDNS障害と断定することはできません。
エラーに記録されたアドレスが、ノードのサーバーなのか最終的なアクセス先のWebサイトなのかを見分けましょう。プロキシのアウトバウンドからサーバーへの接続に失敗している場合は、ノードのアドレスとポートを確認します。直接接続で宛先へのアクセスに失敗している場合は、直接接続のネットワークやルーティングルールを調べます。ホスト名に複数のアドレスレコードがある場合は、実際に試行されたのがIPv4かIPv6かも確認し、一つの到達不能な経路だけを見てすべての接続が使えないと判断しないようにしてください。
Windowsでは、次のコマンドでTCPの到達性を確認できます。ドメイン名とポートは説明用の例です。実際に使う場合は、利用許可を得ているノードのアドレスとポートに置き換えてください。テストは使用が許可されたネットワーク環境で行います。出力から分かるのはTCP層の結果だけで、VMess、VLESS、TLSの設定は検証されません。
Test-NetConnection -ComputerName example.com -Port 443- TCPテストも失敗する：アドレスが古くなっていないか、ポートが正しいか、現在のネットワークで接続が制限されていないか、サーバーが正常にリッスンしているかを確認します。
- TCPは成功するがコアが失敗する：すぐにノードが正常と判断せず、ハンドシェイク、トランスポート方式、認証パラメーター、サーバー側のログを確認します。
- 一部のWebサイトだけ失敗する：該当するリクエストで選ばれたアウトバウンド、DNSの結果、宛先の種類を比較し、まずルーティングの違いを調べます。
4. 証明書の検証エラー：時刻、名前、信頼チェーンを確認する
TLSエラーは接続が該当するハンドシェイク段階まで進んだことを示しますが、証明書エラーの種類によって対処方法は異なります。通常のTLS証明書検証を行う接続では、サーバーアドレスと、証明書の名前検証に使うserverNameは異なる場合がありますが、サーバーの構成に合っている必要があります。この項目に、任意のアクセス可能なドメインを入力しないでください。また、別のセキュリティモードのパラメーターをTLS設定に流用しないでください。
エラー：x509: certificate has expired or is not yet valid
原因と対処：端末の日時が証明書の有効期間から外れているか、サーバー証明書の期限が切れています。まずシステムの日付、時刻、タイムゾーンを正確に設定し、証明書の更新が必要かサーバー管理者に確認してください。
エラー：x509: certificate signed by unknown authority
原因と対処：証明書チェーンを信頼できる認証局までたどれません。サーバーが中間証明書を含む完全なチェーンを送信しているか、端末の信頼ストアとネットワークの検査ポリシーに問題がないか確認します。
エラー：certificate is valid for
原因と対処：証明書の名前が一致しないエラーでよく見られるメッセージです。ログに表示された名前と、実際に検証に使われた名前を比較し、ノードの編集画面にあるTLSホスト名またはSNIの設定を確認します。
システムの日付が正しく、設定にも変更がないのに、突然「認証局が不明」というエラーが出た場合は、現在のネットワークでHTTPS検査が有効になっていないか、サーバーの証明書チェーンが最近変更されていないか確認してください。証明書の信頼設定は組織のネットワークポリシーに従い、エラーを消すためだけに見知らぬルート証明書を安易にインポートしないでください。
5. ポート競合：まずローカルの入口を正常にリッスンさせる
address already in useが表示された場合は、まず端末上のリッスンポートの競合を解消します。クライアントを重複して起動している、以前のコアのプロセスが終了していない、または別のプログラムが同じアドレスとポートを使用していることがよくある原因です。Windowsでは、同様のエラーがOnly one usage of each socket addressと表示される場合があります。この場合、リモートノードの設定を変更してもローカルポートの競合は解消しません。
これらの数字は各ポートが使われる層の違いを示すもので、設定を一律に変更する指示ではありません。ローカルプロキシのポートはクライアントの設定で決まり、ノードのポートはサーバーの構成で決まります。DNSも従来のポートではなく、暗号化された通信を使う場合があります。実際のログに表示されるリッスンアドレスとポートを確認してください。127.0.0.1へのバインドと、すべてのネットワークインターフェースへのバインドでは、アクセス可能な範囲が異なります。トラブルシューティングのために、安易にリッスン範囲を広げないでください。
# Windows PowerShell：例のポートをリッスンしているプロセスを確認
Get-NetTCPConnection -LocalPort 10808 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
# Linux：TCPのリッスン状態とプロセス情報を確認
ss -ltnp 'sport = :10808'
# macOS：例のポートでTCPをリッスンしている状態を確認
lsof -nP -iTCP:10808 -sTCP:LISTEN結論：まずプロセスを特定し、終了するかポートを変更する
占有しているプロセスが重複起動したインスタンスだと確認してから、正常な方法で終了してください。別のサービスを動かし続ける必要がある場合は、クライアントのローカル入口を変更し、アプリ側のプロキシ設定も合わせて更新します。クライアントのポートだけを変更してアプリの接続先を変えないと、新たに「接続拒否」が発生します。
6. ルールファイルとDNS：起動エラーと名前解決エラーを切り分ける
ログにfailed to load geosite、failed to load geoip、またはgeosite.datやgeoip.datを指すファイルエラーがある場合は、ノードを何度も変更するのではなく、まずルールリソースを確認します。geosite:またはgeoip:を使うルールは、対応するデータに依存しています。ファイルがない、読み取り権限がない、データ形式に互換性がない、参照先のカテゴリが存在しないといった問題で、設定の読み込みに失敗することがあります。
- 失敗したパスを確認：ログに記録された実際のパスをたどってファイルを探します。クライアントやインストール方法によってデータの保存先は異なります。リソースが必ず実行ファイルと同じ場所にあるとは限りません。
- リソースの入手元を確認：クライアントに用意されたルールリソースの更新機能を優先して使い、ダウンロードしたものがエラーページではないことを確認します。元のファイルを残し、問題があった場合に戻せるようにしてください。
- カテゴリ名を確認：ファイルが存在していても、すべてのカテゴリが含まれているとは限りません。ルーティングルールで参照しているカテゴリが、現在のリソースに実際に存在するか確認します。
- 再起動して起動時のログを確認：リソースの読み込みとコアのリッスンが成功してから、アクセスをテストします。生成された設定を手動で編集しても、次回の起動時にクライアントによって上書きされる場合があります。
エラー：no such host
原因と対処：現在の名前解決経路で使用可能なホスト情報を取得できていません。ドメイン名の入力ミス、使用するリゾルバー、ルールを確認し、ノードのドメインとアクセス先のWebサイトのどちらを解決しているか切り分けます。
エラー：no such file or directory
原因と対処：プログラムが参照したパスが存在しません。直前のファイル名から、ルールリソース、証明書、ログ用ディレクトリのどれに関係するかを確認してパスを修正します。このメッセージだけを根拠に、すべてのコンポーネントを再インストールしないでください。
システムの名前解決とコア内蔵DNSでは、異なる経路を通る場合があります。システムのコマンドで名前解決に成功しても、コアが選択したDNSアウトバウンドが動作するとは限りません。逆に、ブラウザー独自の名前解決がコアのDNSを経由しない場合もあります。まずシステムの名前解決コマンドでノードのドメインを確認し、そのうえでコアのログに記録されたDNSサーバー、リクエストのドメイン、失敗段階を調べてください。特に、ノードのアドレス解決がまだ確立されていないプロキシ経路に依存して、起動時の依存関係が循環していないか注意します。
7. 再テストと問い合わせ：変更は一度に一つ、証拠は前後をまとめて提示
トラブルシューティングの目的は、ログから警告を完全になくすことではなく、障害の原因を一貫して説明できるようにすることです。変更は一度に一つだけにします。たとえば、まずTLS名を修正し、コアを再起動して同じリクエストをもう一度試します。ノード、DNS、ルーティングモード、トランスポート方式を同時に変えると、接続が回復しても何が効いたのか判断できません。
- 起動の確認：コアがすぐに終了せず、ローカルの入口が正常にリッスンし、ルールリソースの読み込みが完了している。
- 入口の確認：一度アクセスすると、そのリクエストに対応するログが記録される。ログがない場合は、アプリで正しいプロキシアドレスとポートが指定されているか確認する。
- アウトバウンドの確認：リクエストが想定したアウトバウンドを通り、接続やハンドシェイクで同じエラーが繰り返し発生しない。
- アプリの動作確認：以前失敗したページや機能を実際に開く。TCPテストの成功や速度テストの結果だけでは、アプリが正常に使えることの確認にはなりません。
- 設定を元に戻す：一時的に有効にしたデバッグレベルを解除し、不要になったテスト設定を戻して、今回の変更内容を記録します。
問い合わせる際は、OSの種類、クライアントとコアの実際のバージョン、失敗した時刻、再現手順、同じ接続の前後のログを提示してください。バージョンは現在のクライアント画面またはコアの起動ログで確認し、インストーラーのファイル名から推測しないでください。投稿前に、サブスクリプションURL、認証情報、パスワード、秘密鍵などの機密情報を伏せます。エラーの種類、ポート、発生段階、および一貫した方法で伏せたアドレス同士の関係は残してください。