V2Rayのログの見方：failed to dial・rejectedなど頻出エラーの意味と原因特定

クライアントに「接続済み」と表示されても、コアが起動した、またはローカルプロキシポートが待ち受け状態になったことを示すだけで、対象サイト、ノードサーバー、リモート側の出力先まで到達できるとは限りません。本当に原因特定に役立つ情報は、通常ログの末尾にあります。どのインバウンドからリクエストが入り、どのルーティングに一致し、どのアドレスへの接続に失敗したのか、さらに失敗箇所が名前解決、TCP接続、TLSハンドシェイク、ユーザー認証のどの段階なのかを確認します。

まずアクセスログ、エラーログ、クライアント出力を区別する

V2RayまたはXrayのコアがリクエストを処理するときは、ローカルアプリ、インバウンドプロキシ、ルーティング、一連のアウトバウンド処理、リモートの対象先など複数の段階を通ります。ログの種類によって分かることも異なります。赤い文字を一行だけ見ていると、結果を原因と取り違えがちです。まずその行がどの種類のログなのかを確認し、時刻の近い前後の記録を読み進めてください。

アクセスログに対象ドメインが表示されるのは、リクエストがローカルのコアに届いたことを示すだけです。その直後にfailed to dialが続くなら、問題はアウトバウンド接続にあります。反対に、ウェブページを開いても新しいアクセスログがまったく出ない場合は、すぐにノードのパラメータを変更せず、まずシステムプロキシ、ブラウザのプロキシ、アプリごとのルールを確認してください。

v2rayN、v2rayNG、v2flyNGで有効なログを確認する

調査前に条件を固定します。ノードを1つ選び、現在時刻を記録し、通信を続けるダウンロードツールを終了してから、決めたページを一度だけ開きます。こうするとバックグラウンド通信によるノイズを減らせます。ログレベルはまずwarningまたはinfoがおすすめです。debugは接続の詳細が大量に出るため、通常の情報だけでは不足する場合に短時間だけ有効にします。

1. 使用中のコアを確認する

   v2rayN 7.xで「設定」→「パラメータ設定」→「Core タイプ」を開き、現在の設定がXrayとv2flyのどちらを使用しているか記録します。対応するプロトコルやエラーの表現は、コアによって異なる場合があります。

2. 情報パネルを開く

   v2rayNのメインウィンドウに戻り、画面下部の情報エリアを確認します。まず「サービスを再起動」を一度実行し、コアの起動、設定の読み込み、ローカルポートの待ち受けに関する記録が表示されることを確認してください。

3. リクエストを一度だけ再現する

   ログウィンドウを表示したまま、対象ページを一度だけ開きます。ローカルHTTPポートが10809の場合は、対象ドメインへのリクエストがログに出ているか先に確認してください。

4. Androidのログを確認する

   v2rayNG 1.9.xまたはv2flyNGのメイン画面でノードに接続した後、右上のメニューにある「ログ」を開きます。古い内容を消去してから対象アプリに戻り、問題を一度再現してください。

5. 一時的にログレベルを上げる

   warningだけでは失敗の流れが分からない場合、ログレベルをinfoまたはdebugに変更し、コアを再起動してから再現します。記録が終わったら元のレベルに戻し、ログが急速に増え続けるのを防いでください。

クライアント画面に簡略化された出力しか表示されない場合は、カスタム設定でログファイルを明示的に指定することもできます。以下は一般的な構成例です。パスは、現在のアカウントに書き込み権限があるディレクトリへ変更してください。変更後は必ず設定を再読み込みします。そうしないと、古いプロセスの出力を見続けることになります。

{
  "log": {
    "access": "D:/v2ray-logs/access.log",
    "error": "D:/v2ray-logs/error.log",
    "loglevel": "warning"
  }
}

ログファイルが生成されない場合は、まずディレクトリの存在、プロセスの書き込み権限、クライアントがカスタムのlog設定を上書きしていないかを確認します。情報を増やすために、プロトコル、DNS、ルーティング、ポートを一度に変更しないでください。複数の変数を同時に変えると、接続が戻ってもどの変更が効いたのか判断できません。

エラーの構造を読む：最後の原因から逆にたどる

V2RayとXrayのエラーは複数のモジュールで段階的にラップされることが多く、1行のログにtransport、proxy、common、internetなどのモジュール名が連続して現れ、呼び出しの流れが大なり記号でつながる場合があります。読むときはまず時刻、対象アドレス、末尾の原因を確認し、それがどのプロトコルまたはトランスポート段階に属するのかを前に向かって確認します。

2026/06/02 10:18:42 [Warning] transport/internet/websocket:
failed to dial WebSocket > transport/internet:
failed to dial to (wss://node.example:443/path):
dial tcp 203.0.113.20:443: i/o timeout

この例ではすでに数値のアドレスが表示されているため、「この端末でノードのドメインをまったく解決できない」という方向は優先度が低いです。末尾の原因はTCP接続のタイムアウトで、VMessまたはVLESSのユーザー認証にはまだ到達していません。この段階でUUIDを何度も変更しても、通常は結果は変わりません。まず443ポートに到達できるか確認してください。

末尾の原因がconnection reset by peerなら、接続確立後に相手側または途中の機器が接続を強制的にリセットしたことを示します。connection refusedなら、通常は対象ホストには到達できるものの、そのポートでサービスが待ち受けていないか、ポリシーによって明確に拒否されています。timeout、reset、refusedはネットワーク状態がそれぞれ異なるため、すべてを「ノードが無効」と一括りにできません。

failed to dial、rejected、invalid userでは何を確認するか

頻出エラーは、最外層にあるfailed to process outbound trafficだけを検索するのではなく、末尾の原因で分類します。外側の文言は「アウトバウンド処理に失敗した」という要約にすぎないことが多く、調査の方向を決めるのは最後の数段です。以下に代表的な原文と優先して行う操作をまとめます。

VLESS自体はVMessのような時刻認証方式を採用していません。そのためinvalid userが表示された場合は、実際に使用しているプロトコルと、そのログがどのノードのものかを先に確認します。サブスクリプションにはVMess、VLESSなど複数のノードが含まれることがあり、今回のログの文脈はクライアントで現在選択している項目です。

リクエストの流れに沿って段階的に特定し、設定を一度にすべて変更しない

ブラウザからリモートの対象先まで、1つのリクエストは少なくとも5段階を通ります。最も効果的なのは、自分に近い層から順に確認し、毎回1つの事実だけを検証する方法です。前の層を通過していないうちは、次の層のパラメータを変更しないでください。

1. システムプロキシを確認する。v2rayNを開き、システムプロキシが想定したモードになっているか確認します。ウェブページを開いてもログがまったく増えない場合、リクエストが127.0.0.1のローカルプロキシポートに入っていない可能性があります。
2. ローカルの待ち受けを確認する。クライアントのステータスバーに表示される値を基準にします。一般的な設定ではSOCKS 10808、HTTP 10809が使われますが、ポートは変更できるため、ガイドの初期値だけで判断しないでください。
3. ルーティング結果を確認する。一時的にシンプルなグローバルプロキシへ切り替えてテストします。グローバルモードでは利用でき、ルールモードでは失敗する場合は、ドメインルール、IPルール、blockアウトバウンド、最終的な一致順を重点的に確認します。
4. ノード接続を確認する。対象ノードのアドレスがログに出た後、DNS、TCP、TLS、WebSocket、gRPC、ユーザー認証のどの段階で失敗しているかを確認します。
5. 対象先による違いを確認する。複数の主要サイトで失敗するなら、ノードまたはローカル経路の問題である可能性が高くなります。1つのドメインだけ失敗する場合は、DNSの結果、ルーティングの一致、対象サイト自身の状態を優先して確認します。

ローカルポートはcurlで最小限のリクエストをテストできます。以下ではHTTPプロキシポート10809とSOCKSポート10808を使ってこのサイトへリクエストします。実際のポートはクライアントに表示される値へ置き換えてください。10秒の上限を設けると、即時の拒否と継続的なタイムアウトを区別しやすくなります。

curl --proxy http://127.0.0.1:10809 https://v2help.com -I --max-time 10
curl --proxy socks5h://127.0.0.1:10808 https://v2help.com -I --max-time 10

コマンドを実行してすぐに127.0.0.1へ接続できないと表示される場合は、ローカルの待ち受けまたはポート指定が問題です。ローカルポートには接続できても約10秒後にタイムアウトするなら、コアのログに戻ってリモート接続を確認します。HTTPレスポンスヘッダーを受信できるのにブラウザで開けない場合は、ブラウザのプロキシ上書き、拡張機能の設定、別のプログラムによるシステムプロキシの変更を重点的に調べます。

ログに現れるDNS、ルーティング、時刻の問題

DNSの問題は「ドメインが存在しない」場合だけではありません。同じノードのドメインがIPv4とIPv6の両方を返すことがあり、2種類のアドレスへの到達性はネットワークによって異なります。特定のIPv6アドレスを繰り返し試してタイムアウトし、IPv4へ切り替えると復旧する場合、名前解決は成功しているものの、現在のネットワークからそのアドレスファミリーへの経路が利用できないことを示します。

ルーティングの誤判定には、通常はっきりした「選択性」があります。特定のドメインは常に正常なのに、別のドメインは毎回directまたはblockへ送られます。アクセスログのアウトバウンドタグは、エラーログより重要です。ルールを変更したら再起動または設定の再読み込みを行い、新しいリクエストのタイムスタンプが変わっていることを確認してください。

時刻の問題は、主に時刻検証が必要な認証処理に影響します。確認するのは時計の表示だけでなく、日付、タイムゾーン、自動同期の状態も含まれます。画面上の時刻が正しく見えても、タイムゾーンの誤設定と手動時刻が組み合わさると実際の時刻がずれることがあります。

ログを整理するときに残す情報、隠すべき情報

問題を他人に説明するときは、failedの一部分だけを切り取るより、環境全体を示すほうが有用です。少なくともクライアント名とバージョン、使用中のコア、ノードのプロトコル、発生時刻、すべてのノードで失敗するか、現在のネットワーク種別、実施した比較テストを記載します。これにより同じ質問を繰り返す必要がなくなり、エラーが同じ操作から発生したものかも判断できます。

• 残す：エラー発生時刻、ログレベル、モジュール名、エラーの連鎖、対象ポート、トランスポートの種類、ローカルの待ち受けポート。
• 残す：v2rayN 7.x、v2rayNG 1.9.xなどのクライアントバージョンと、Xrayまたはv2flyのコア種別。
• 隠す：完全なサブスクリプションURL、UUID、パスワード、認証文字列、ノードのドメイン、個人を特定できるネットワーク情報。
• 説明：ノードアドレスはnode.exampleのように置き換えられますが、ポート、プロトコル、TLSの有効・無効、パスが一致しているかは明記してください。
• 添える：再現手順と結果。例：「グローバルモードは成功、ルールモードは失敗」「HTTP 10809には接続できるが、リモート443がタイムアウト」。

ログで原因を特定するうえで重要なのは、すべての英語表現を暗記することではなく、どの層で失敗したかを見分けることです。アクセス記録がなければプロキシ入口、no such hostならDNS、timeout・refused・resetならネットワークとポート、TLSやトランスポートのハンドシェイクまで進んでいれば該当パラメータ、invalid userなら認証情報と時刻同期を確認します。

変更を1つ行ったら、同じ対象、同じノード、同じテスト方法で再現し、新旧のログを比較します。条件をそろえなければ、本当に解決したのか、一時的に回避できただけなのか、別のバックグラウンドリクエストに隠れただけなのか判断できません。