V2Rayの実行ログの読み方：connection refusedなど、よくあるエラーの意味と切り分け手順

まず、ログがどの接続段階を記録しているか確認する

プロキシリクエストでは、クライアントがWebページをそのままリモートノードへ渡すわけではありません。v2rayNでよく使われるローカルSOCKSポート 127.0.0.1:10808 を例にすると、ブラウザーなどのアプリがまずローカルのインバウンドへ接続し、コアがノードのドメインを解決してTCPまたはUDP接続を確立し、TLSまたはREALITYのハンドシェイクを完了させ、最後にVMess、VLESSなどのプロトコル認証を行います。どこか1段階でも失敗すると、画面上は「接続失敗」と表示されることがあります。

そのため、ログ末尾の単語だけを切り取らないでください。「遅延をテスト」をクリックした時刻、Webページを開いた時刻、設定を起動した時刻を確認し、その時点から上へ10～30行読みます。retry や failed to process outbound traffic の繰り返しは上位層の集約メッセージにすぎないことが多く、実際の原因はその前にある dial、lookup、handshake、authentication の行に現れます。

アクセスログはリクエストがコアに到達したかを確認するためのもので、対象ドメイン、対象ポート、インバウンドタグ、選択されたアウトバウンドタグなどが記録されます。エラーログは接続がどの段階で中断したかを示します。アクセスログに新しい記録がまったくなければ、まずシステムプロキシ、TUN、アプリ自体のプロキシ設定を確認します。アクセスログに対象アドレスがあり、その後エラーログで接続失敗が報告されるなら、ノードのアドレス、ポート、ネットワーク経路を重点的に調べます。

ログレベルを設定し、有効な前後関係を残す

ログレベルは通常、debug、info、warning、error、noneに分かれます。通常運用では warning または error にすると出力を抑えられます。接続問題を調べるときはまず info に切り替え、ハンドシェイクの設定やルーティングの適用状況を確認できない場合だけ一時的に debug を使います。調査後は元のレベルに戻し、ログファイルが増え続けないようにします。

v2rayN 7.xを例にすると、「設定」→「パラメーター設定」→「Core タイプ」で、現在のノードがXrayコアとV2Flyコアのどちらを呼び出しているか確認します。その後、メイン画面のログ欄でコア再起動後の出力を確認します。ログレベルやCoreタイプを変更した場合は、現在の設定を停止して再起動する必要があります。既存のプロセスには新しいパラメーターが自動適用されません。

1. テスト時刻を固定する

   現在のログ末尾の時刻を消去するか記録し、10秒以内に「実接続遅延をテスト」を1回だけ実行するか、テストページを1回だけ開きます。

2. コアの種類を確認する

   v2rayN 7.xで「設定」→「パラメーター設定」→「Core タイプ」を開き、ノードが実際に使用しているコアを確認します。別プロセスのログを読まないようにするためです。

3. ログレベルを上げる

   まず info で1回再現し、ルーティング、ハンドシェイク、DNSの詳細が見えない場合だけ debug に変更します。

4. コアを再起動する

   現在のサービスを停止して再起動し、新しいログに 127.0.0.1:10808 または実際の設定ポートでリッスンを開始したことを示す情報が出るか確認します。

5. 完全なログ断片を保存する

   エラーの前後10～30行を残し、ノードのプロトコル、通信方式、ポート、再現操作も記録します。

生成されたコア設定を直接確認する必要がある場合は、トップレベルの log オブジェクトを確認します。次の例では、エラーとアクセス記録を標準出力へ書き込みます。実際のファイル場所はクライアント側で管理されます。クライアントが生成した一時設定を手動で変更しても、次回起動時に上書きされる可能性があるため、まずクライアントの設定を使用してください。

{
  "log": {
    "access": "",
    "error": "",
    "loglevel": "info"
  }
}

Android版のv2rayNG 1.10.xとv2flyNGも操作の考え方は同じです。対象の設定を起動したら、メイン画面のメニューからログ画面を開き、すぐに問題を再現します。システムによってはバックグラウンドプロセスが制限されるため、アプリ切り替え後にログの更新が止まった場合は、1回のテストが終わるまでクライアントを前面に表示しておきます。「新しいログがない」だけでノードが正常だと判断しないでください。

エラーの原文からネットワークとポートの問題を切り分ける

connection refused は、TCP接続があるアドレスまで到達したものの、対象ポートから明示的に拒否されたことを示します。単純なタイムアウトとは異なり、通常はすぐに返ります。サーバー側のプロセスがそのポートで待ち受けていない、ポートの指定間違い、ドメインが誤ったホストを指している、ローカルのインバウンドポートをリモートポートとして誤って使用している、といった原因が考えられます。

context deadline exceeded は、処理が制限時間を超えたことを示します。DNSクエリ、TCP接続の確立、TLSハンドシェイク、リモートからの応答などで発生する可能性があります。この1行だけでノードの停止とは判断できません。前の行に dial tcp、lookup、TLS handshake など具体的な対象がないか確認してください。

タイムアウトの位置を判断するときは、所要時間も比較します。LAN内のポート競合は通常、起動後1秒以内に発生します。リモートポートの拒否も数百ミリ秒から数秒で返ることが多く、約10秒待ってからdeadline exceededが出る場合は、ネットワーク経路のパケットロス、ファイアウォールによる無応答の破棄、ハンドシェイク段階の応答停止が疑われます。この時間差だけで断定はできませんが、調査の優先順位を決める手がかりになります。

invalid userとハンドシェイク・認証エラーに対処する

invalid user、invalid account、認証失敗に関するメッセージは、通常、ネットワーク接続がすでにプロトコル処理段階まで到達しているものの、クライアントが送信した認証情報とサーバー設定が一致していないことを示します。VMessではUUID、サーバー時刻、ノードが停止されていないかを重点的に確認します。VLESSではUUID、暗号化フィールド、Flow、セキュリティ方式を確認します。ノードのコピー時に空白が1つ余分に入るだけでも、認証パラメーターが無効になることがあります。

VMessはシステム時刻の影響を受けやすいプロトコルです。デスクトップやAndroid端末の時刻が大きくずれていると、アドレスとポートが正しくても認証を完了できない場合があります。システムの自動日付、自動時刻、自動タイムゾーンを有効にしてから、クライアントを再起動してください。画面上で分だけ手動調整して近い時刻に合わせるのでは不十分です。タイムゾーンと秒単位のずれも補正する必要があります。

WebSocket、gRPC、REALITYを使用する場合は、認証パラメーターだけでなくトランスポート層も確認します。WebSocketではpathの不一致、Hostの不一致、HTTP 404の返却がよくあります。gRPCではserviceNameを確認し、REALITYではserverName、公衆鍵、shortId、フィンガープリントを確認します。アドレスに接続できることはTCP経路が存在する証拠にすぎず、これらのフィールドが正しいことまでは意味しません。

• VMess：UUID、alterId、暗号化方式、システム時刻、通信方式、TLS設定を確認します。
• VLESS：UUID、Flow、通信方式、セキュリティ方式、サーバー名を確認します。
• WebSocket：pathとHostを確認します。パスのスラッシュと大文字・小文字はサーバー側と一致させます。
• gRPC：serviceNameを確認します。ノードの備考やドメイン名をこのフィールドに入力しないでください。
• REALITY：serverName、公衆鍵、shortId、フィンガープリント、Flowの組み合わせを確認します。どれか1つだけ変更して、そのまま再利用しないでください。

ノード障害、サブスクリプションの問題、ルーティングを切り分ける

同じサブスクリプション内の全ノードが同時に失敗する場合は、まずローカル環境、サブスクリプションの更新結果、DNS、システム時刻を確認します。1つのノードだけが失敗するなら、そのノードのアドレス、ポート、アカウント状態が変わった可能性が高いです。ノードのテストは成功するのに特定のWebサイトだけ開けない場合は、サブスクリプションを何度も再インポートするのではなく、ルーティングルール、DNSの分割、対象サイトへの接続を調べます。

ルーティング問題の典型例は、ログに対象ドメインがすでに表示されているのに、意図しないアウトバウンドタグが選ばれている状態です。たとえばプロキシ経由にすべきドメインが direct に送られたり、LANアドレスがプロキシアウトバウンドへ送られたりします。ルールを変更したら設定を再読み込みし、同じ対象に対して選ばれたアウトバウンドタグを再確認します。クライアントの状態アイコンだけを見て判断しないでください。

サブスクリプションの更新に成功したという表示は、クライアントが応答を受け取ったことを示すだけで、含まれるすべてのノードに接続できるとは限りません。更新後はノード数、更新時刻、主要フィールドが変化したかを確認します。更新後に一覧が空になった場合は、まずサブスクリプショングループの絞り込み条件を確認します。古いノードが残っている場合は、正しいサブスクリプショングループが更新されたか確認してください。

決めた順番で最終確認を行う

効率的なトラブルシューティングでは、無作為に設定を試すのではなく、確認する順番が重要です。まずコアがローカルポートで正常に待ち受けているかを確認し、次にリクエストがインバウンドへ届いているかを確認します。その後、DNS、リモート接続、トランスポートのハンドシェイク、プロトコル認証を確認します。前段階が通って初めて、次の段階のログを分析する意味が生まれます。

たとえばログに accepted tcp:example.com:443 が表示され、その後ノードアドレスの connection refused が出る場合、アプリからローカルインバウンドまでの経路は正常です。システムプロキシを調整し続ける必要はありません。この場合はリモートノードのポートを重点的に確認します。逆に、Webページを開いてもアクセスログがまったく増えないなら、ブラウザーまたはシステムが実際に 127.0.0.1:10808 を指しているかを確認します。

1. 待ち受けを確認する

   クライアントの起動後、address already in use が出ていないことを確認し、ローカルのインバウンドポートが正常に待ち受けていることを確認します。

2. リクエストを確認する

   固定したテストページを開き、アクセスログに対象ドメインと 443 ポートが表示されるか確認します。記録がなければシステムプロキシまたはアプリのプロキシを確認します。

3. 名前解決を確認する

   lookup、no such host、ノードのドメイン名を検索し、DNSが利用可能なアドレスを返しているか確認します。

4. 接続を確認する

   refused、timeout、unreachableをもとに、ポート拒否、経路のタイムアウト、ネットワーク到達不能を区別します。

5. ハンドシェイクを確認する

   TLS、REALITY、WebSocket、gRPCのパラメーターを確認し、その後VMess、VLESSの認証フィールドを確認します。

6. ログレベルを戻す

   問題の特定後、debugをwarningまたは元の設定に戻し、コアを再起動します。

他の人に調査情報を共有するときは、クライアント名とバージョン系列、コアの種類、ノードのプロトコル、通信方式、エラー発生時刻、完全なログ断片を含めます。アカウント認証情報、サブスクリプションURL、UUID、公衆鍵以外の機密性のある接続情報は、必要に応じてマスキングしてください。ただし、エラー前後の段階表示、対象ポート、アウトバウンドタグは削除しないでください。