V2Rayの実行ログの見方：よくあるエラーの意味と原因の切り分け

まずログが記録している段階を確認する

V2RayやXrayの接続は、単一の動作ではありません。アプリがリクエストをローカルの待受ポートへ渡し、コアがルーティング規則を読み込み、対象ドメインを解決して出方向を選び、リモートサーバーへ接続した後、プロトコル認証とトランスポートのハンドシェイクを行います。ログは通常、失敗した段階だけを記録し、修正方法を一式で示すわけではありません。トラブルシューティングでは、エラーを接続フローに戻して考え、赤い行を見ただけでクライアントを再インストールしないようにしましょう。

最も実用的な読み方は、同じ操作で時間が近い複数行の記録をまとめて確認することです。古いログを消去または一時停止し、明確なURLを1つ開くか、特定のアプリを起動してから、直後に追加された内容を確認します。これにより、数時間前のサブスクリプション更新エラーやバックグラウンドの検査結果を、現在の接続失敗と混同せずに済みます。

ログレベルも併せて確認します。info は正常な起動、接続の受信、ルーティング結果の記録に使われます。warning は異常な条件があることを示しますが、すべての接続が失敗するとは限りません。error は現在の処理が明確に失敗したことを示す重要な手がかりです。接続エラーの後、ブラウザが自動的に再試行して成功する場合もあるため、ページが開くか、ノードテストに通るか、エラーが繰り返し発生するかも併せて判断してください。

v2rayNとv2rayNGでログを確認する場所

v2rayN：まずコアの出力、次にクライアントの通知を確認

v2rayNの画面は、バージョンやレイアウト設定によって多少異なります。通常はメインウィンドウ下部のログまたは情報エリアで実行出力を確認できます。折りたたまれている場合は、メイン画面の表示、ログ、または関連メニューから再度開いてください。ノードの起動、サブスクリプションの更新、遅延テスト、システムプロキシの切り替えでは、クライアントの通知とコアのログが別の場所に表示されることがあります。接続問題の調査では、Xray、V2Ray、inbound、outbound、transportなどの語を含むコアの実行記録を優先して確認します。

起動をクリックしても新しいログがまったく追加されない場合は、まずコアプロセスが実際に起動しているか確認します。設定生成の失敗、ローカル待受ポートの競合、ファイルアクセス権の異常などにより、接続前の段階で処理が止まることがあります。この状態で繰り返し速度を測定しても有効な判断はできません。まず起動段階で最初に出たエラーを解決してください。

ログに accepted が表示され、ローカルアドレスからの接続と記録されている場合、ブラウザまたはアプリはすでに通信をローカルプロキシへ渡しています。その後に timeout、rejected、ハンドシェイク失敗が発生するなら、ノードのパラメータ、ネットワーク経路、リモートサービスを確認します。反対に、ブラウザが繰り返しエラーを出すのにログへ対応する新規接続がない場合は、システムプロキシの状態、アプリがシステムプロキシに従うかどうか、ローカル待受ポートがアプリの入力値と一致しているかを重点的に確認します。

v2rayNG：サイドメニューからログ画面を開く

v2rayNGでは通常、サイドメニューからログ画面を開けます。調査を始める前に設定を起動し、対象アプリへ戻って接続リクエストを1回発生させ、すぐにログ画面へ戻って末尾の内容を確認してください。Androidのバックグラウンド管理により、アプリが一時停止したりネットワーク接続を再構築したりすることがあるため、v2rayNGが有効な状態で動作し続けているかも確認します。

v2rayNGでXrayコアを使用している場合、プロトコル接続、DNS、ルーティング、トランスポートのエラーはコアから出力されます。システムネットワークの切り替えや仮想ネットワークインターフェースの状態に関する情報が、コアの記録と交互に表示されることもあります。判断の原則は同じです。最初に失敗した時刻を見つけ、最初に現れたエラーから後ろへ読み進め、最後の1行だけを切り取らないでください。

v2rayNGのログにローカルリクエストが受信された記録があり、すべてのノードが同じ段階でタイムアウトする場合は、まず現在のネットワークを一度切り替えて再テストします。1つのノードだけが失敗し、同じサブスクリプションの他のノードが正常なら、そのノードのパラメータや状態を優先して確認してください。1行のエラーだけを見続けるより、この比較のほうが効果的です。

rejected：どちら側でリクエストが拒否されたか

rejected は文字どおりリクエストが拒否されたことを意味しますが、拒否したのがリモートサーバーとは限りません。ローカルのルーティング規則、対象ホスト、プロキシプロトコルの認証、トランスポート層のハンドシェイク、または相手側による接続切断が原因の場合もあります。この行の前後にあるモジュール名や補足情報と併せて判断してください。

blocked、ルーティング規則名、または明確なブロック出方向が同時に表示される場合、リクエストがローカル規則によってブロック用の出方向へ送られている可能性があります。たとえば、カスタム規則で特定のドメインを拒否リストに入れている、または規則の順序によりプロキシ出方向へ到達する前にマッチしているケースです。現在のルーティングモードを確認し、対象ドメインを一時的にプロキシまたは直接接続にして比較してください。UUIDを変更する必要はありません。

connection refused が表示される場合、通常は対象IPへのネットワーク接続が明確に拒否されています。リモートポートが待ち受けていない、サーバーサービスが起動していない、ポートの入力ミス、中間ネットワーク機器による明示的な拒否などが主な原因です。単純なタイムアウトとは異なり、拒否はすぐに返ることが多く、タイムアウトは通常数秒以上待ってから発生します。

rejected と handshake、authentication、invalid user などが同時に表示される場合は、ノードのパラメータとサーバー側設定が一致しているかを重点的に確認します。プロトコル、サーバーポート、ユーザー識別子、トランスポート方式、セキュリティ設定、ホスト名、パスを順番に比較してください。サブスクリプションから取り込んだノードは、特定の項目を推測で手修正しないことをおすすめします。まずサブスクリプションを更新し、更新前後の設定を比較してください。

対象サイト自体による拒否にも注意が必要です。ノード接続とプロキシ経路は正常でも、特定の対象がアクセス制限を返したり接続を切断したりすることがあります。同じノードで複数の異なるサイトへアクセスして確認してください。大半のサイトは正常で、1つだけ継続的に失敗するなら、問題をすぐにV2Rayコアやノード認証のせいにすべきではありません。

timeout：まずタイムアウトが発生した段階を確認

timeout は最もよく見られる、範囲の広いエラーです。ある手順が制限時間内に完了しなかったことだけを示します。DNSクエリ、TCP接続、TLSハンドシェイク、WebSocket接続、レスポンスの読み取りなど、さまざまな段階で発生します。timeoutを見たら、同じ行または上位エラーにある lookup、dial、connect、handshake、read などの動詞を探してください。待機していた場所を特定する手がかりになります。

サーバーアドレスへの接続がタイムアウトする

記録がサーバーIPとポートを指し、dial または connect が表示されている場合、ローカル側は外部接続を試みたものの、時間内に完了しなかったことを示します。同じサブスクリプションの別ノードを試し、現在のネットワークも切り替えて確認してください。1つのノードだけがタイムアウトするなら、そのノードの状態またはポートの問題が考えられます。同じネットワークで全ノードがタイムアウトし、ネットワークを変えると復旧するなら、現在のネットワーク経路の問題に近いでしょう。すべてのネットワークとノードで失敗する場合は、ローカル設定とコアの起動状態に戻って確認します。

ハンドシェイク段階でタイムアウトする

下位接続が確立した後も、プロトコルとトランスポートはデータ交換を続けます。ログがTLS、WebSocket、その他のトランスポートハンドシェイクで止まっているなら、サーバー名、トランスポート種別、パス、ホストフィールド、セキュリティパラメータを確認してください。サーバーアドレスに到達できても、上位層のパラメータが一致しているとは限りません。証明書の有効期間や時間枠に依存する接続では時刻のずれも影響するため、デスクトップとAndroid端末の正確なシステム時刻を有効にしてください。

データの読み取り中にタイムアウトする

read timeout やコンテキストの期限到達は、接続自体は確立したものの、その後のデータが返ってきていない可能性を示します。大きなファイルのダウンロードや長時間接続でのみ発生する場合は、ネットワークの安定性を確認してください。任意のウェブページを開くたびに同じ秒数後に失敗するなら、リモートサービス、トランスポートパラメータ、DNS結果を引き続き確認します。遅延テストだけで実際のアクセスを代用しないでください。遅延検査と完全なウェブ接続では、異なるリクエストフローを通ることがあります。

timeoutを切り分ける比較手順
1. 同じノードで、別の対象サイトを試す
2. 同じネットワークで、別のサブスクリプションノードを試す
3. 同じノードで、現在のネットワークを切り替える
4. サブスクリプションを更新してから、ノードを選び直す
5. ログの dial、handshake、read、DNS の段階を比較する
6. 変更する変数を1つだけにして、次のテストを行う

invalid user：認証情報がサーバー側と一致しない

invalid user は、通常、VMessなどユーザー識別が必要なプロトコルの処理中に表示されます。サーバーが受信した認証情報を有効なユーザーと照合できないことを示します。UUIDの不一致、ノード設定の変更、サブスクリプション内の古いノードの使用、または実際には誤ったサーバーポートへ接続していることが主な原因です。

まずサブスクリプションを更新し、現在選択しているものが本当に更新後のノードか確認します。v2rayNには古いグループ、手動ノード、新しいサブスクリプションノードが同時に残っていることがあります。名前が似ていても、パラメータが同じとは限りません。v2rayNGにも重複した設定が存在する場合があるため、サブスクリプション更新が成功したかだけでなく、実際に実行している項目を確認してください。

ノードを手動で作成した場合は、UUID、プロトコル、ポートを一文字ずつ確認します。UUIDに空白が入っている、文字が欠けている、誤ったフィールドへ貼り付けているだけでも認証に失敗します。サブスクリプションURLをノードアドレス欄へ入力したり、ノード共有内容を分解して経験で項目を補ったりしないでください。VLESSでは認証やリクエスト解析に失敗した際の具体的な文言が異なることがありますが、確認すべき点はユーザー識別子、フロー制御、セキュリティ層、トランスポート方式、サーバー側の入口が一致しているかです。

複数の端末で同じ更新直後の設定を使い、1台だけinvalid userが続く場合は、その端末の古いノードを削除してサブスクリプションを再インポートし、同名の古い項目を選択していないか確認します。すべての端末で同じ時刻から失敗し、ローカルで設定を変更していないなら、サービス提供者にユーザー状態とサーバー側設定を確認してもらってください。

DNS解決失敗：ドメインが利用可能なアドレスに変換されない

DNSはドメイン名をIPアドレスへ変換します。ログに failed to lookup、no such host、DNS query failed、または名前解決のタイムアウトが表示される場合、接続はまだ対象サーバーへ到達していない可能性があります。まず、ノードサーバーのアドレスと、ユーザーがアクセスしている対象ドメインという2種類のドメインを区別してください。前者の解決に失敗するとノード全体の接続ができず、後者の失敗は特定サイトだけに影響することがあります。

ノードサーバーにドメイン名を使用していて、その名前の解決に失敗する場合、ログは通常、リモート接続前にエラーを出します。ドメイン名のつづりと、現在のネットワークでDNSクエリを正常に実行できるかを確認し、アドレスが変更されていないかサブスクリプションも更新してください。サーバーにIPアドレスを直接指定している場合、この段階でサーバードメインの解決は発生しませんが、対象サイトのDNS解決は必要です。

一部のドメインだけが失敗する場合は、ルーティング規則とDNS規則の組み合わせを確認します。たとえば、ドメインはプロキシ対象と判定されているのに、DNSクエリが現在のネットワークから到達できないリゾルバーへ送られているケースがあります。カスタム規則が現在の接続に適さない結果を返すこともあります。一時的にクライアント標準の基本ルーティングとDNS設定へ戻し、カスタム項目が原因かどうかを切り分けてください。

すべてのドメイン解決がタイムアウトする一方、既知のIPアドレスへ直接アクセスすると応答がある場合は、DNSサーバーへの到達性、システムネットワーク、クライアントのDNS設定を重点的に確認します。ループするクエリやリクエストの繰り返しがログに出る場合は、ローカル待受ポート、システムDNS、プロキシDNSが相互転送になっていないかも確認してください。変更後はコアを再起動し、古い接続とキャッシュを終了させます。

ドメインを解決できても、その結果が現在の経路に適しているとは限りません。解決されたアドレスへ接続できない場合、ログには解決成功の後、dial 段階でのタイムアウトが表示されることがあります。この時点で問題はDNS段階からネットワーク接続段階へ移っています。timeoutの手順に従い、ノード、ネットワーク、対象アドレスを比較してください。

設定、ポート、リソースファイルのエラー

問題によってはコアの起動前に発生するため、ウェブページからプロキシ接続が一切生成されません。設定の解析失敗、未知のフィールド、必須パラメータの不足、ファイルの読み込み失敗がログに出た場合は、まず起動可能な設定へ戻します。JSONを手動編集するときは、カンマ、括弧、フィールド階層、データ型をすべて正しい形式にしてください。v2rayNやv2rayNGのサブスクリプションインポートを使う場合は、設定ファイルとクライアントの生成結果が互いに上書きしないよう、できるだけ画面上で変更を行います。

address already in use などポート占有を示すメッセージは、ローカルのSOCKS、HTTP、その他の受信ポートを別のプロセスがすでに使用していることを意味します。よくある原因は、古いコアが終了していない、クライアントを重複起動している、別のローカルサービスが同じポートを使っていることです。まず現在のクライアントを完全に終了してから再起動します。それでもエラーが出る場合は、クライアントのローカルポートを変更し、そのポートに依存するアプリの設定も更新してください。

ルーティングデータファイルの読み込みに失敗すると、geosite や geoip に依存する規則が動作しなくなり、深刻な場合は設定の起動も妨げます。この種のログでは、ファイルが存在しない、読み取れない、規則名が無効などの内容が明確に示されることが多いです。現在のクライアントとコアに対応するリソースファイルを使用し、カスタム規則が参照するカテゴリ名が存在するか確認してください。リソースファイルのエラーをノード障害と取り違えないようにしましょう。

設定に未知のフィールドがある場合、クライアントとコアの機能が一致していない可能性もあります。まずダウンロードセンターで提供している現行クライアントを使用し、対応するコアをクライアントに管理させてください。古い設定を移行する場合は、サブスクリプションをインポートして基本設定を作成し、接続できることを確認してから、ルーティングやDNSのカスタム内容を1項目ずつ追加するのがおすすめです。

ローカル、ノード、サーバー側の問題を切り分ける方法

1行のログから分かるのは1つの失敗現象だけです。原因の所在を特定するには比較テストが必要です。最も確実なのは、「ノード、ネットワーク、端末、対象」という4つの変数を作り、毎回1つだけ変更する方法です。複数の設定を同時に変えて判断材料を失うことなく、範囲をすばやく絞り込めます。

ローカルの問題を判断するときは、コアが起動できるか、リクエストがローカル受信へ入るか、ルーティングが想定した出方向にマッチするかを確認します。ノードの問題では、同じクライアント内の他のノードが正常かを見ます。サーバー側の問題と判断するには、複数の端末またはネットワークで同じ結果が出て、ログが認証、リモートポート、サーバー処理の段階に集中している必要があります。

「遅延は正常なのにウェブページが開けない」ことは矛盾ではありません。遅延テストは特定ポートへの到達や短い接続の完了だけを確認している場合がありますが、実際のウェブアクセスではDNS、ルーティング、プロトコル、トランスポート、対象サイトへの接続まで必要です。実際の接続ログを基準にし、テスト後に出たハンドシェイク、読み取り、対象接続のエラーを引き続き探してください。

繰り返し実行できるログ調査の手順

1. クライアントが動作中であることを確認します。 v2rayNまたはv2rayNGの動作状態を確認し、コア起動後すぐに終了していないことを確かめます。
2. サブスクリプションを更新し、明確なノードを選択します。同名の古いノードを使い続けないようにし、現在のノード名と更新時刻を記録します。
3. 古いログを消去します。新しいテスト1回分の内容だけを残し、バックグラウンドのリクエストによる干渉を減らします。
4. 単一のリクエストを発生させます。確実にアクセスできるサイトを1つ開き、速度測定、サブスクリプション更新、大量ダウンロードを同時に実行しないでください。
5. 最初のエラーを探します。最初にerrorまたはwarningが現れた位置から数行上へ読み、設定、受信、ルーティング、DNS、接続、認証のどの段階に属するか確認します。
6. エラーの種類に応じて対処します。rejectedは拒否元、timeoutはタイムアウトした動作、invalid userは認証情報、DNSエラーは解決対象とリゾルバーを確認します。
7. 毎回1つの変数だけ変更します。まずノードを変え、次にネットワークを変える、またはルーティングを基本設定へ戻して再テストするなど、複数の項目を同時に変更しないでください。
8. 役立つ記録を残します。時刻、クライアントのバージョン、コアの種類、エラーの抜粋、実施した比較テストを記録し、同時に認証情報を削除します。

ログ調査の要点は、すべての英語エラーを暗記することではなく、接続経路のどの段階で失敗したかを確認することです。リクエストがローカルプロキシへ入ったか、DNSが完了したか、サーバーへ接続できたか、認証を通過したかを判断できれば、「まったく接続できない」という状態から、実行可能な確認項目へ問題を絞り込めます。

現在の設定を何度も手動変更している場合、必要な情報だけを残してサブスクリプションを再インポートし、基本ルーティングで一度接続してから、カスタム設定を1項目ずつ戻す方法が最も時間を節約できることが多いです。v2rayN、v2rayNG、v2flyNGはいずれも同じ変数管理の考え方に従います。まず動作する基準を作り、どの変更がエラーを引き起こしたかを特定してください。