v2rayNのログの見方｜よくあるエラーの意味と原因の特定方法

画面のメッセージとコアのログを区別する

v2rayNはクライアントの管理画面です。ローカル接続を受け付け、ルーティングを行い、サーバーへ接続するのは選択中のコアです。サブスクリプションの更新失敗、速度測定の失敗、コアの起動失敗は、それぞれ異なる処理の結果です。赤い通知が表示されたからといって、ノードが使えないとは限りません。この記事ではXrayコアを使う構成を中心に説明します。他のコアでは、エラーの表現やログ項目が異なる場合があります。

メイン画面の情報・ログ欄では、起動時の処理やその場で発生したエラーを確認できます。アクセスがどのインバウンドを通り、どのアウトバウンドに振り分けられたかを追うには、一時的にログレベルをinfoに設定します。さらに詳しい情報が必要な場合のみdebugを使いましょう。ログのwarningは警告を示すもので、コアが終了したという意味ではありません。

1. 現在の状態を記録する

   v2rayNとコアのバージョン、選択中のノード、ローカルの待ち受けポート、ルーティングモードを記録します。バージョン情報は「ヘルプ」→「バージョン情報」または起動ログで確認できます。現在の設定を保存し、ひとまずサブスクリプションの更新やノードの一括変更は避けてください。

2. ログを有効にする

   一般的なデスクトップ版では、「設定」→「パラメーター設定」を開き、ログ関連の項目でログ記録を有効にして、ログレベルをinfoに設定します。保存後、コアを再起動してください。バージョンによってタブ名や表示名が異なる場合があるため、実際のログ記録スイッチとレベルの項目を確認してください。

3. 一度だけ再現する

   表示中のログをクリアするか開始時刻を記録し、決めたURLに一度だけアクセスします。成功または失敗を確認したら、繰り返し再読み込みせず、エラーの前後約20行を保存してください。最後の1行だけではなく、前後の流れが分かる範囲を残します。

4. ログレベルを戻す

   原因を特定したら、ログレベルをwarningまたは元の設定に戻してください。ログを共有する前に、サブスクリプションURL、ノードの認証情報、UUID、グローバルIPアドレス、アクセス履歴を伏せてください。設定ファイル全体をそのまま公開しないでください。

独自のXray設定を管理している場合、ログ部分には次のような断片を記述できます。これはlogオブジェクトのみで、config.json全体ではありません。設定全体をこの内容で置き換えないでください。通常、v2rayNが生成するノード設定は、ノード切り替え時に書き換えられる場合があります。まずはクライアントに用意された設定項目を使ってください。

{
  "log": {
    "loglevel": "info"
  }
}

インバウンド・ルーティング・アウトバウンドの順にログを読む

トラブルシューティングでは、まず「リクエストがどの段階まで進んだか」を確認します。ブラウザーからローカルプロキシへの接続がインバウンド、直接接続・プロキシ・ブロックをコアが判断するのがルーティング、ノードへの接続とプロトコルのネゴシエーションがアウトバウンドです。ノード名が選択されているのは、画面上で設定が選ばれていることを示すだけで、3つの段階すべてが正常とは限りません。

以下はログの簡略例です。すべてのバージョンで同じ文言が出力されるとは限りません。角括弧内のタグは設定によって異なるため、アウトバウンドが常にproxyという名前だとは限りません。acceptedはローカルのリクエストが受け付けられた、または処理に入ったことを示しますが、リモートのWebページから正常に応答があったことまでは保証しません。

from tcp:127.0.0.1:53124 accepted tcp:example.com:443 [socks-in -> proxy-out]

まず宛先のexample.com:443を確認し、次にルーティングタグを見て、最後に近い時刻または同じ接続IDの後続エラーを探します。エラーの接続先がノードサーバーのアドレスなら、アウトバウンド経路を重点的に確認します。直結アウトバウンドでWebサイトのアドレスが表示されている場合は、ノードのパスワードを先に変更する必要はありません。

よくあるエラーの意味と最初の確認事項

エラーには「接続の処理に失敗」のような外側の説明と、内側のconnection refusedのような詳細が含まれることがあります。エラーの末尾にある具体的な原因から読み、上位の情報に戻って、ローカル・ノード・接続先サイトのどこで失敗したかを確認しましょう。以下はよくあるエラーの一部です。OSやコアのバージョンによって、異なる接頭辞が付く場合があります。

ローカルポートでリクエストがコアに届いているか確認する

以下はWindowsでの確認例です。SOCKSの待ち受けポートを10808、ノードのサービスポートを443と仮定しています。これらの数値は説明用で、すべての環境における初期値ではありません。実行前に、画面または実行中の設定で有効になっている実際のポートに置き換えてください。

PowerShellで待ち受けを確認してから、プロキシを明示してリクエストを送信します。2つ目のコマンドではドメイン名の解決をSOCKSプロキシに任せ、ブラウザーがシステムプロキシを正しく使っているかという要因を切り分けます。テスト用URLは同じ状態を再現するためのもので、すべてのサイトが利用できるかを判断するものではありません。

Get-NetTCPConnection -State Listen -LocalPort 10808

curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 -I https://example.com/

• 待ち受けの記録がない：コアの起動エラーを確認してください。ポート競合のメッセージが出た場合は、netstat -ano | findstr :10808でPIDを確認し、タスクマネージャーでプロセスを特定します。正体の分からないシステムプロセスをそのまま終了しないでください。
• ローカルプロキシへの接続が拒否される：待ち受けアドレスとポートを確認してください。ループバックアドレスのみで待ち受けている場合は、同じ端末からテストします。別の端末からの接続結果でノードの状態を判断しないでください。
• コマンドは成功するがブラウザーでは使えない：システムプロキシ、ブラウザー固有の設定、拡張機能を優先して確認します。一般的なv2rayNの画面では、タスクトレイメニューから「システムプロキシ」→「システムプロキシを自動設定」を選べます。プロキシを明示するコマンドは、この設定に依存しません。
• コマンドも失敗する：コマンドの開始時刻とコアのログを照らし合わせ、ルーティングとアウトバウンドを追ってください。コマンドの15秒タイムアウトは今回のテスト上限であり、コアやサーバーの固定タイムアウト値ではありません。

ルーティング・DNS・ハンドシェイク設定を個別に確認する

ローカルポートでリクエストを受け付けられたら、次はルーティングが想定どおりかを確認します。Xrayのルールは通常、上から順に照合されます。前方にある広い条件のルールが、後方の詳細なルールより先に適用されることがあります。生成された実際の設定にあるタグを確認し、画面のノード名だけでアウトバウンドを判断しないでください。

1. アウトバウンドタグを確認：ルールのoutboundTagは、接続先アウトバウンドのtagと一致させる必要があります。ログでブロック用アウトバウンドに振り分けられている場合は、TLSではなくルールを確認してください。
2. 2種類のドメイン名解決を区別：ノードのドメイン名を解決できないと、サーバーに接続できません。接続先のドメイン名を解決できない場合は、直結やIPアドレスを使うルールに影響する可能性があります。Resolve-DnsName example.comで確認できるのはシステムのリゾルバーであり、コア内の名前解決テストの代わりにはなりません。
3. 時刻を確認：Windowsの「設定」→「時刻と言語」→「日付と時刻」で自動設定を有効にし、時刻を同期してください。時刻のずれは証明書の有効期間判定に影響し、時刻に依存する認証にも影響することがあります。
4. トランスポート設定を確認：WebSocketのパスとHost、TLSのサーバー名、ノードのポート、暗号化設定がサーバー側と一致している必要があります。同じIPアドレスに接続しても、同じ仮想ホストに接続しているとは限りません。
5. コアの対応状況を確認：v2rayNは管理クライアントで、プロトコルへの対応は実際に使用するコアによって異なります。特にREALITYやXTLS Visionは、共有リンクをインポートできたことだけで、実行時の設定が対応しているとは判断できません。

一度だけ、クライアントのグローバルプロキシルーティングを使って比較できます。事前に元のモードを記録し、テスト後すぐに戻してください。グローバルモードでは成功し、元のルールベースのモードでは失敗する場合、ルールとDNSポリシーを重点的に比較します。ただし、2回のリクエストで異なる名前解決経路が使われる場合もあるため、失敗の原因が必ずルーティングだとは限りません。

ログの確認でよくある質問

トラブルシューティングのゴールは、ログから警告をなくすことではありません。同じリクエストが安定して成功し、どの段階で失敗していたかを説明できる状態にすることです。修正を確認したら、通常のログレベルと元のルーティングモードに戻し、本来直結する宛先とプロキシを経由する宛先をそれぞれテストしてください。一時的な設定をそのまま使い続けないようにしましょう。