v2rayNの実行ログの見方：よくあるエラーの意味と切り分け手順

v2rayNのログに表示される3つの情報層を見分ける

v2rayNのウィンドウに表示される情報が、すべてエラーとは限りません。クライアント自身はサブスクリプション、画面の状態、システムプロキシ、コアプロセスを管理し、XrayまたはV2Flyコアは接続、プロトコル、DNS、ルーティングを処理します。アクセスログは、特定の宛先がどのアウトバウンドを経由したかを示します。これら3種類の情報は時系列上で混在するため、最後の1行だけを見ると、上流の結果を根本原因と取り違えやすくなります。

v2rayN 7.xの画面では、まずメインウィンドウ下部の情報エリアを確認します。ログの詳細度を変更する場合は、「設定」→「パラメーター設定」を開き、ログレベル、アクセスログ、コア出力に関する項目を探してください。マイナーバージョンによってラベル名が多少異なる場合がありますが、クライアントの画面から提供される設定を優先し、実行時に生成された設定ファイルを直接編集しないでください。次回コアを起動した際に、クライアントが再生成する可能性があります。

通常、1回のプロキシリクエストは、アプリケーション、ローカルリスニング、ルーティング判定、プロトコルの確立、リモート接続の順に進みます。ログ上でエラーの位置が前段にあるほど、まずはローカルポートとプロキシ設定を確認します。後段のエラーであれば、サーバーアドレス、ポート、トランスポート方式、TLS、ユーザー認証パラメーターを重点的に確認してください。

ログはどこから読み始めるべきか

まず時刻、次にレベルとモジュールを確認し、最後にエラーチェーンを末尾から前へたどります。Xrayのログでは、複数の大なり記号で呼び出し関係が示されることがあります。前半はどのモジュールが失敗を報告したかを示し、最後の部分が低レベルの原因に近いことが多いです。たとえば同じ行に「failed to process outbound traffic」と「i/o timeout」がある場合、優先して対処すべきなのは、一般的なアウトバウンド処理失敗ではなく接続タイムアウトです。

宛先アドレスも重要です。エラーの宛先がサブスクリプションのドメインなら、問題はサブスクリプション更新中に発生しています。ノードサーバーのアドレスなら、プロキシ接続の確立段階にあります。ノードが接続済みなのに特定のウェブサイトのドメイン解決に失敗している場合は、DNSまたはルーティングルールを確認します。サブスクリプション更新の一度の失敗だけで、読み込み済みの全ノードが使えないと判断しないでください。

2026/08/02 14:21:08 [Warning] transport/internet/tcp:
failed to dial TCP > dial tcp 203.0.113.10:443: i/o timeout

2026/08/02 14:21:24 [Info] proxy/http:
request to tcp:example.com:443 accepted [proxy]

上の1行目は、ノードの例示アドレスの443番ポートへTCP接続する際にタイムアウトしたことを示します。確認すべきなのは、ノードアドレス、ポート、ローカルネットワーク、リモートへの到達性です。2行目の accepted は、ローカルHTTPプロキシがアプリケーションのリクエストを受け付けたことを示すだけで、対象ページの取得成功を意味しません。同じ秒以降にプロキシのアウトバウンド失敗がないか、続けて確認してください。

rejected、timeout、invalid userの意味を見分ける

キーワードだけで特定できるのは障害の範囲であり、文脈なしに原因を一つへ絞ることはできません。同じ timeout でも、ノードポートに到達できない場合、DNSクエリの場合、対象サイトの応答待ちの場合があります。rejected も、ルーティングによる意図的な拒否と、サーバーによるプロトコルリクエストの拒否が考えられます。エラーを共有する際は、前後各2行以上、タイムスタンプ、モジュール名、完全なエラーチェーンを残してください。

invalid userでUUIDだけを確認してはいけない理由

VMessとVLESSはいずれもユーザー識別子を使いますが、互換性のあるプロトコルではありません。読み込み時にプロトコル種別を誤認すると、UUIDの文字列が完全に一致していても、サーバーはリクエストを正しく処理できません。古いVMess設定には追加パラメーターが含まれる場合もあります。現在は最新のサブスクリプション内容を基準にし、記憶に頼って手動で設定を組み立てないことをおすすめします。

エラーが現在選択中のノードから出ていることも確認してください。サブスクリプション更新後、一覧に古いグループと新しいグループが同時に残ることがあります。名前が似ていても設定が同じとは限りません。現在のノード名を控え、サーバー一覧で選択行を確認してから、1つのウェブページだけにアクセスしてテストします。ほかのバックグラウンドリクエストでログが流れてしまうのを防げます。

• プロトコル種別がVMessかVLESSかを確認し、ポート番号だけでプロトコルを推測しない。
• UUIDの文字、ハイフン、先頭と末尾に空白が混入していないか確認する。
• 該当するサブスクリプショングループを更新し、古いノードのコピーを選び続けていないことを確認する。
• システムの日付、時刻、タイムゾーンを確認する。大きなずれはハンドシェイクや認証に影響する可能性がある。
• コアを再起動してから再テストし、古い接続が確認中のログに影響しないようにする。

エラーから該当する設定項目を特定する

効果的な切り分けでは、変更する変数を一つに絞ります。一度に1つの設定だけを変更し、変更後は現在のログ末尾の時刻を記録またはログをクリアしてから、同じテストリクエストを送ります。ノード、DNS、ルーティングモード、ローカルポートを同時に変更すると、接続が回復しても何が効いたのか分からず、同じ問題を再び特定しにくくなります。

まず、正常に開けることが分かっている一般的なウェブページを固定のテスト先に選び、通信を続けるダウンローダーや同期アプリを終了します。そのうえで、現在のノード、システムプロキシの状態、ローカルポート、テスト時刻の4項目を記録します。設定を切り替えた後は約15秒待ち、同じエラーが出るか確認してください。同じ段階で3回続けて発生して初めて、安定した障害として扱います。

1. コアが起動しているか確認します。設定の解析エラーやローカルポートのリッスン失敗が先に出ているなら、リクエストはまだ本機の外へ出ていないため、リモートノードを調べる必要はありません。
2. アプリケーションがローカルプロキシを経由しているか確認します。ウェブページにアクセスしても accepted や対象ドメインの記録がまったくない場合は、システムプロキシ、ブラウザーのプロキシ設定、またはアプリケーションがシステム設定に従っているかを確認してください。
3. ルーティングの動作を確認します。対象が direct、proxy、blocked のどれに振り分けられたかによって、次に確認するのが直接接続、ノードのアウトバウンド、ブロックルールのいずれか決まります。
4. ノード接続の段階を確認します。ドメイン解決、TCP接続、TLSハンドシェイク、プロトコル認証の順に確認し、前の段階を飛ばして後の段階のパラメーターを変更しないでください。
5. 2つ目のノードと比較します。同じネットワーク、アプリケーション、ルーティングのままノードだけを切り替えることで、クライアント共通の設定と特定ノードの設定問題を区別できます。

ログは正常なのにウェブページを開けない場合の確認項目

ログに accepted と表示されても、リクエストがローカルプロキシに届いたことしか分かりません。その後に proxy が表示され、明らかなエラーがないのにページを開けない場合は、DNSの応答、ブラウザー独自のプロキシ方針、対象サイトへの接続を確認してください。ブラウザーによっては独自のDNS機能を使う場合があります。また、コマンドラインツールがシステムプロキシを自動的に読み取るとは限りません。そのため、「あるアプリは使えるが、別のアプリは使えない」という状況は、通常ノード全体の障害ではありません。

Windowsでv2rayNのシステムプロキシを有効にすると、システム設定に従うデスクトップアプリは該当プロキシを使用します。手動でプロキシを設定するプログラムには、クライアントが現在リッスンしているアドレスとポートを入力する必要があります。ローカル混合ポートが10808と表示されているなら、画面に表示された実際の値を使い、古い記事に10809と書かれているからといってそのまま入力しないでください。ポートが一致しないと、v2rayNのログに該当リクエストがまったく記録されないことがあります。

ルーティングルールによって、「接続は成功したのにアクセスできない」ように見えることもあります。たとえば対象ドメインが direct に一致していて、現在のネットワークからその宛先へ直接接続できない場合、コアは失敗したリクエストを自動的にプロキシへ切り替えません。blocked に一致すれば、ルールに従ってブロックされます。アクセスログのアウトバウンドタグを確認するほうが、システムプロキシを何度も切り替えるより早く原因を特定できます。

異なるプラットフォームとコアのログを比較する方法

Windows、macOS、Linuxでデスクトップ版を使う場合、画面表示はバージョンによって多少異なりますが、切り分けの順序は同じです。まずクライアントがコアを正常に起動したか、次にローカルリスニング、ルーティングの動作、プロキシのアウトバウンドを確認します。Androidのv2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。ログの表現は異なる場合がありますが、TCP、DNS、TLS、認証、ルーティングという段階は対応付けて確認できます。

あるコアの完全なエラー文が、別のコアでも一字一句同じになることを期待しないでください。あるバージョンでは context deadline exceeded と表示されても、別のバージョンでは同じ状況を timeout とだけ表示することがあります。比較すべきなのは、解析、接続、認証のどの段階でエラーが発生したかです。サブスクリプションにVLESSなどの設定が含まれる場合は、現在のクライアントとコアのバージョンが該当する設定フィールドに対応していることも確認してください。

ログを共有するときに残すべき情報

障害記録には、クライアントのバージョン、コアの種類、OS、発生時刻、選択中のプロトコル、エラー前後数行、試した手順を含めます。サーバーアドレス、UUID、サブスクリプションURL、その他の認証情報はそのまま公開せず、一貫したマスキング文字列に置き換えてください。ただし、ポート、プロトコル、トランスポート方式、エラー構造は残します。これらがないと、どの段階の問題か判断できません。

プラットフォーム: Windows
クライアント: v2rayN 7.x
コア: Xray
症状: システムプロキシを有効にするとウェブページがタイムアウト
再現時刻: 14:21:08
現在のプロトコル: VLESS
ノードアドレス: server.example
ノードポート: 443
主なエラー: dial tcp server.example:443: i/o timeout
試したこと: サブスクリプションを更新、別のノードに切り替え、その他の設定は変更しない

ログ分析で重要なのは、テキストをできるだけ多く集めることではなく、時系列を組み立てることです。ユーザーが何をしたか、リクエストがどの層に入ったか、どの段階で停止したか、どの項目を変更すると結果が変わったかを確認します。この流れで調べれば、rejected はルーティングまたはリモート側の拒否、timeout は具体的な接続段階、invalid user はプロトコルと認証パラメーターに結び付き、設定項目を手当たり次第に行き来せずに済みます。