まず失敗したリクエストの前後のログを保存し、ローカルの待ち受け、名前解決、リモート接続、認証の順に確認しましょう。起動に失敗する、接続がタイムアウトする、Webページが開かない場合に向けて、v2rayN・v2rayNGのログの確認場所、V2Ray/Xrayのログレベル、エラーごとの次の確認ポイントを解説します。
失敗を再現して、該当するログを確認する
まず問題が起きた時刻を記録し、ダウンロードやバックグラウンド更新を止めて、確認したいページだけを開きます。ログには複数の接続が混在することがあります。時刻と接続先が分からないと、バックグラウンド処理の失敗をページの問題と取り違えがちです。最後の1行だけでなく、エラー前後の10～20行ほどを残すと、原因の流れを追いやすくなります。
- v2rayN（デスクトップ版）：メイン画面の実行情報やログ欄を確認し、クライアントの起動メッセージとコアの出力を見分けます。詳細なログが必要な場合は、「設定」→「パラメータ設定」を開き、コアやログに関する項目を探します。項目名や分類はバージョンによって異なるため、画面上の「ログレベル」または
loglevelを確認してください。 - v2rayNG（Android版）：メイン画面のメニューから「ログ」を開き、サービスを起動してから問題を再現します。使用中のバージョンで「設定」からログレベルを変更できる場合は、一時的にレベルを上げてサービスを再起動してください。AndroidのVPN許可ダイアログをコアのエラーと混同しないようにしましょう。
- V2Ray/Xrayのカスタム設定：実際に起動している設定の
logセクションを確認します。errorはエラーログの出力先、accessはアクセスログの出力先です。ファイルが指定されていない場合、出力先は起動方法や、クライアントがコンソール出力をどう受け取るかによって異なります。 - ログファイルが見つからない場合：まず、ファイルへの書き込みが設定されているか確認します。デスクトップ版では、実行ファイルの場所、作業ディレクトリ、設定ディレクトリが異なることがあります。ログが必ずインストール先にあるとは限りません。相対パスの場合は、実際の作業ディレクトリを基準に確認してください。
loglevelの設定：まずinfo、必要なら一時的にdebug
loglevel はログの詳しさを指定します。まず info に変更して保存し、コアを再起動して問題を再現します。情報が足りない場合に限り、短時間だけ debug を使ってください。ログレベルは通信モードではありません。レベルを上げても接続は直らず、プロキシ経由になるアプリが増えるわけでもありません。
| レベル | 使用する場面 | 確認する内容 |
|---|---|---|
debug | 複雑な問題を短時間追跡するとき | 詳細な状況を確認できます。取得できる情報はコアやバージョンによって異なります。 |
info | 通常の接続トラブルを調べるとき | 起動、接続、ルーティングに関する情報。 |
warning | 日常的に異常を確認するとき | 警告以上の問題が記録されます。通常の接続情報は少なめです。 |
error | エラーだけを確認するとき | リクエストがコアに届くまでの流れを把握できないことがあります。 |
none | この種のログ出力を無効にする | 問題を再現している最中の使用には適しません。 |
以下は既存のトップレベル設定に追加できるログ設定の例です。プロキシ設定全体ではありません。最初の切り分けでディレクトリの権限問題が加わらないよう、ファイルパスは指定していません。クライアントが設定を生成する場合は、画面から変更してください。生成されたファイルを直接編集しても、次回の起動時に上書きされる可能性があります。
{
"log": {
"loglevel": "info"
}
}- ファイルに出力する場合は、
errorまたはaccessに現在のプロセスが書き込めるパスを指定し、親ディレクトリが存在することを確認してください。 - 追加の権限が必要なシステムディレクトリにログを出力しないでください。ログを書き込むために、すべてのプログラムを管理者権限で常時実行するのも避けましょう。
- 問題を再現したら、通常のログレベルに戻し、不要になったデバッグファイルを削除します。アクセスログには接続先のドメインやアドレス、接続時刻が含まれる場合があります。
エラーの発生段階を把握する
コアは、プロキシ通信を実際に処理するプログラムです。インバウンドは端末上のアプリからリクエストを受け取り、アウトバウンドはリクエストを接続先またはプロキシサーバーへ送ります。まずリクエストがインバウンドに届いているかを確認し、次にアウトバウンドの選択とネットワークのハンドシェイクを調べましょう。設定を一つずつ手当たり次第に変えるより効果的です。
1行のエラーに複数の原因が連なっていることがあります。外側には「アウトバウンドの処理に失敗」と表示され、その内側に connection refused や i/o timeout が記録されている場合があります。まず最も内側にある具体的な原因を読み、その接続先のアドレスを確認してください。ログの接続先はプロキシサーバーとは限らず、直接接続するWebサイトやDNSサーバーの場合もあります。すべてをノードの問題と決めつけないようにしましょう。
これらの数値は接続の役割を見分けるための目安であり、一律に変更する設定ではありません。実際の待ち受けポートはクライアントの設定、リモート側のポートはサーバーから提供された情報を確認してください。ログに 443 とあるだけでは、その接続がプロキシ経由かどうかは判断できません。
接続エラー：拒否、タイムアウト、接続先なし
エラー：connection refused
原因：接続が明示的に拒否されています。接続先ポートでサービスが待ち受けていない場合や、ファイアウォールが接続を拒否している場合によく発生します。
対処：まず接続先アドレスを確認します。127.0.0.1:10808 の場合は、ローカルのコアと待ち受けポートを確認してください。リモートアドレスの場合は、ノードのポートとサーバーの待ち受け状態を確認します。
エラー：i/o timeout
原因：ネットワーク上の読み書きが制限時間内に完了していません。接続開始時、TLSハンドシェイク中、応答待ちなど、さまざまな段階で発生します。
対処：エラーの接頭辞からタイムアウトした段階を確認します。同じノードを使ってWi-Fiとモバイル回線を切り替えて比較してください。タイムアウトの原因をすべてDNSの問題と決めつけないようにしましょう。
エラー：failed to find an available destination
原因：現在の接続先への試行後も、利用可能な接続が確立されていません。多くの場合、複数の失敗をまとめたエラーであり、これだけでは根本原因を特定できません。
対処：同じエラーの流れにある名前解決の失敗、接続拒否、タイムアウトの記録を探し、それぞれドメイン、ポート、通信経路を確認してください。
エラー：no such host
原因：名前解決に使ったDNSがドメインの有効なアドレスを取得できませんでした。アドレスの入力間違いや、DNSリクエストの経路が正しくない可能性もあります。
対処：ログにあるドメインがノードのものか接続先サイトのものかを確認し、実際に使用しているDNSサーバーとルーティングルールを調べます。
v2rayNを使っているWindowsユーザーは、まず例に示したローカルポートが待ち受けているか確認できます。以下のコマンドはTCPの状態を照会するだけで、システム設定は変更しません。結果が表示されなくても、リモートノードに問題があるとは限りません。まずクライアントの起動エラーを確認し、ポートが実際に 10808 かどうか調べてください。
Get-NetTCPConnection -State Listen -LocalPort 10808そのポートでSOCKSプロキシが動作していることを確認したら、プロキシを明示したリクエストを実行します。socks5h は、接続先のドメイン名をプロキシ側で名前解決する指定です。ここでの15秒は手動で設定したテスト上限であり、コアのデフォルトのタイムアウトではありません。
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 15 --max-time 30 -I https://example.com/- ローカルで即座に拒否される：コアが起動していない、ポートの指定が間違っている、またはプロキシの種類が一致していない可能性を優先して確認します。
- リクエストがコアに届いた後、リモート接続がタイムアウトする：ノードのアドレス、ネットワークへの到達性、ハンドシェイクの設定を続けて確認します。
- コマンドは成功するのにブラウザーでは失敗する：システムプロキシ、ブラウザー独自のプロキシ設定、関連するルーティングを確認します。クライアントの再インストールを先に試す必要はありません。
認証・TLSエラー：設定を確認し、検証を無効にしない
TCP接続が確立しても、ポートに到達できたことしか分からず、プロキシプロトコルの認証が成功したとは限りません。UUIDは一部のプロキシプロトコルでユーザーを識別するための認証情報です。TLSはサーバーの身元を確認し、通信を暗号化する仕組みです。この2種類の問題は分けて対処してください。ログレベルの変更やローカルポートの変更では、通常解決できません。
エラー：invalid user
原因：ユーザー認証に失敗しています。このメッセージはサーバーログに記録されることが多く、認証情報の不一致、ユーザーの削除、プロトコル設定の違いなどが考えられます。
対処：サーバーとクライアントのユーザー識別子およびプロトコルを確認します。VMessの場合はシステム時刻も確認してください。必要に応じて、同じ時刻のサーバーログを管理者に確認してもらいましょう。
エラー：x509: certificate has expired or is not yet valid
原因：証明書の有効期間と現在のシステム時刻が一致していません。証明書の期限切れだけでなく、端末の日付が正しくない可能性もあります。
対処：まず端末の日付と時刻を自動設定にし、サーバー管理者に証明書の有効期間と設定状況を確認してもらいます。
エラー：x509: certificate signed by unknown authority
原因：現在の環境で信頼できる証明書チェーンを構築できません。中間証明書の不足、自己署名証明書、ネットワーク上での証明書の差し替えなどが考えられます。
対処：サーバーの証明書チェーン全体と、システムの信頼状態を確認します。管理者に正しい証明書を確認し、検証を無効にしたまま使うことは避けてください。
エラー：EOF
原因：読み取りが完了する前に接続が閉じられています。このエラーだけで認証失敗とは判断できません。
対処：前後のログとあわせてTLS、通信方式、サーバーの応答を確認してください。クライアント側にこの1行しかない場合は、管理者に該当するサーバー側のログを確認してもらいましょう。
- サブスクリプションを更新し、使用する設定を選び直します。更新すると一覧は最新になりますが、現在の接続設定が自動で切り替わるとは限りません。
- サーバーアドレス、ポート、プロトコル、ユーザー識別子、通信方式、TLSの有効・無効を一つずつ確認します。WebSocketを使う場合はパスとHostも確認してください。別の通信方式には、これらの項目をそのまま当てはめないようにしましょう。
- SNI、つまりTLSハンドシェイクで指定するサーバー名を確認します。接続先のIPアドレスと同じとは限らないため、サーバー側の設定に従ってください。
- REALITYを使う場合は、サーバーの指定に従って公開鍵、Short ID、サーバー名を確認します。一般的な証明書エラーへの対処方法をそのまま適用しないでください。
起動エラー：ポート競合と設定の読み込みを確認する
サービスの起動直後に終了する場合は、まず起動ログを確認し、Webページへの接続テストはいったん後回しにします。コアが正常に待ち受けを開始できていない状態でブラウザーに表示されるプロキシ接続エラーは、二次的な結果です。ノードを切り替えても、ローカル設定の構文エラーや待ち受けアドレスの競合は解決できません。
エラー：address already in use
原因：待ち受けアドレスとポートが別のプロセスに使用されているか、コアが重複して起動しています。
対処：ポートを使用しているプロセスを調べ、重複しているインスタンスを通常の方法で終了します。ローカルの待ち受けポートを変更する場合は、そのポートを使うアプリの設定もあわせて変更してください。
エラー：failed to load config files
原因：設定の読み込みに失敗しています。パスを読み取れない、JSONの構文に誤りがある、現在のコアが特定の項目に対応していない、といった原因が考えられます。
対処：続くログに記載されたファイル名、項目名、行・列の情報を確認します。直近の正常な設定に戻し、設定とコアの組み合わせが適切か確認してください。
Windowsでは、前述のポート確認コマンドで OwningProcess を調べてから、次のコマンドでプロセスを確認できます。どのプロセスか特定したら、該当するアプリを通常の方法で終了してください。ポートが使われているからといって、正体の分からないシステムプロセスを強制終了しないでください。
Get-NetTCPConnection -State Listen -LocalPort 10808 |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Name *v2ray*, *xray* -ErrorAction SilentlyContinueよくある質問：警告、ログが出ない、速度測定は正常なのに接続できない場合
ログにwarningが出ていてもWebページが開ける場合、すぐに設定を変えるべきですか？
まず警告の時刻と接続先を確認してください。バックグラウンド処理でリクエストがキャンセルされたり、直接接続先の一つで失敗したりしても、表示中のページとは無関係な場合があります。安定して再現し、利用に影響するエラーだけ対処しましょう。ログを比較しながら確認し、警告の数だけでノードの品質を判断しないでください。
infoに設定しても、Webページにアクセスしたとき新しいログがまったく出ない場合は？
まずコアが起動しているか確認し、動作を確認したローカルポートを明示したプロキシコマンドでテストします。明示的なプロキシ接続ではログが出るのにブラウザーでは出ない場合、ブラウザーまたはシステムのプロキシ設定を確認してください。v2rayNGではVPNサービスの状態と、アプリごとのプロキシ設定から対象アプリが除外されていないかを確認します。
遅延テストが正常なのに、実際の接続がタイムアウトするのはなぜですか？
まず速度測定の種類を確認してください。TCPの遅延テストで検証できるのは接続の一部であり、認証、TLS、接続先へのアクセスが成功するとは限りません。同じノードで実際にWebページへアクセスし、ログを見てリモートへの接続開始で止まっているのか、その後のハンドシェイクで止まっているのかを確認します。遅延値だけでノード設定の問題を除外しないでください。
サブスクリプション全体とログをまとめて管理者に送ると便利ですか？
サブスクリプションのURL、ユーザー識別子、トークン、パスワード、個人のアドレスは必ず隠してください。エラーの原文、時刻、必要な前後の情報だけを残します。「ローカルアドレス」「ノードのアドレス」「接続先アドレス」の区別は維持し、機密情報は削除したうえで非表示にしたことを明記してください。設定全体が写ったスクリーンショットは送らないでください。
調査結果をまとめ、次のテストで確認することを明確にする
1回の切り分けが終わったら、同じノード、同じ接続先、同じネットワークで再テストします。1回成功しても、その時点でそのリクエストが通ったことしか分かりません。断続的なタイムアウトが起きていた場合は、実際の利用環境で引き続き様子を見てください。管理者への報告では、「まだ直らない」だけでなく、操作と結果を具体的に伝えると原因を調べやすくなります。
- 環境：OSのバージョン、クライアントのバージョン、コアの名称とバージョン、システムプロキシまたはVPN/TUNのどちらを使っているか。
- 再現手順：どの設定で起動し、どの接続先にアクセスしたか、いつ問題が発生したか、ネットワークを切り替えても再現するか。
- 記録：機密情報を隠したエラーの原文と前後のログ。エラーがクライアント側かサーバー側かも明記します。
- 変更した設定：変更した項目、変更前後の動作、元の設定に戻した後も同じエラーが起きるかを記録します。
最後に通常のログレベルへ戻し、動作する設定のバックアップを残します。接続拒否は待ち受け状態とポート、タイムアウトは発生段階、認証エラーは認証情報とプロトコル、証明書エラーは時刻と信頼チェーンを確認してください。段階に分けて調べることで、関係のない設定を何度も切り替えずに済みます。