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

まずログがどの層から出ているか確認する

v2rayN、v2rayNG、v2flyNGはクライアント、V2RayとXrayは接続を処理するコアです。サブスクリプションの取得失敗はクライアントの更新機能で起きる場合があり、その時点ではコアにリクエストが届いていません。一方、ログに proxy/vless/outbound、transport/internet などのモジュールパスがあれば、通常はコアでの処理が始まっています。問題の種類によって確認を始める場所が異なります。

v2rayNでは、まずメイン画面のログ欄を確認し、「設定」→「パラメータ設定」でログ関連の項目を探します。v2rayNGでは、メイン画面のメニューから「ログ」を開き、「設定」でログレベルを確認します。項目の場所や表示名はバージョンによって異なる場合があります。クライアントのバージョンと、起動ログに表示されるコアの名称・バージョンを記録してください。「V2Rayを使用」とだけ記録するのでは不十分です。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用するため、アプリ名だけでエラー形式を判断できません。

ログレベルとエラーの流れを読む

V2Ray/Xrayでよく使われる loglevel の値は debug、info、warning、error、none です。トラブルの切り分けでは、まず一時的に info を使い、情報が足りなければ debug に上げます。error だけでは警告や通常の情報が表示されず、none ではログが出なくても接続が正常とは判断できません。

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

上記はコア設定に含まれるログ部分の例で、設定ファイル全体を置き換えるものではありません。クライアントで設定を生成している場合は、まず画面上の項目を変更してください。生成済みファイルを一時的に編集しても、ノードを切り替えると上書きされることがあります。アクセスログやエラーログの出力先は、access、error などの項目やクライアントの起動方法によって異なります。ログレベルを上げても、必ずファイルに出力されるとは限りません。

1. まず時刻を確認します。テストを実行したとき、またはページを再読み込みした時刻を記録し、その前後約10秒のログを探します。バックグラウンドアプリのリクエストと混同しないようにしましょう。
2. 次に関連情報を確認します。角括弧内に接続IDがあれば、同じIDの行をまとめて追います。IDがない場合は、接続先アドレス、ポート、時刻を手がかりに判断します。
3. 外側から内側へ読みます。failed to process outbound traffic は通常、外側の概要を示すエラーです。その後に続く connection refused や lookup ... のほうが、直接の原因に近い情報です。
4. 最初に発生した異常を確認します。プロセスの起動に失敗すると、その後のテストがすべてタイムアウトすることがあります。まず起動時のエラーを解消してから、通信リクエストの失敗を調べてください。

この流れは確認する層を絞るための目安であり、すべてのプロトコルが同じ順序で処理されるわけではありません。たとえばサーバーアドレスがIPアドレスなら、そのアドレスの名前解決は不要です。ルーティングルールによって別途ドメイン名が解決される場合もあります。現在の設定とログに基づいて判断してください。

接続タイムアウト、拒否、名前解決エラー

「タイムアウト」は待ち時間が上限を超えたことを示すだけで、ローカルDNS、リモートポート、ハンドシェイク応答のどこに問題があるかまでは分かりません。エラーに記載された接続先を確認してください。プロキシサーバーの場合もあれば、直接接続するWebサイトやサブスクリプションサーバーの場合もあります。timeout が見えただけで、DNSやルーティングルールを一括変更しないようにしましょう。

Windowsで名前解決とポートを個別に確認する

以下のコマンドでは、説明用に予約されたサンプルドメインを使用しています。実行前に、現在のノードの実際のサーバーアドレスとポートに置き換えてください。ブラウザーでアクセスするWebサイトのアドレスや、TLSの serverName は、サーバーアドレスと同じ場合を除いて入力しないでください。

Resolve-DnsName server.example.com
Test-NetConnection server.example.com -Port 443

• Resolve-DnsName で確認できるのはシステムの名前解決経路であり、コア内蔵DNSの結果とは異なります。システムでは名前解決できるのにコアでは失敗する場合は、コアのDNSサーバーとルーティングを確認してください。
• TcpTestSucceeded : True が示すのは、その時点でTCP接続に成功したことだけです。UUID、TLS、WebSocketのパス、リモート側の転送が正しいことまでは確認できません。
• TCPテストに失敗しても、UDPベースの通信については判断できません。まず実際の通信方式を確認し、それに合った診断方法を選んでください。

TLSハンドシェイク失敗と時刻のずれ

ハンドシェイク失敗は、安全な接続のネゴシエーションまたはプロトコルの初期化中に接続が中断したことを示しますが、原因が証明書とは限りません。TCP接続が可能なことを確認してから、安全性の種類、サーバー名、証明書、通信パラメーター、認証情報の順に確認します。VLESSのUUID検証とTLS証明書の検証は別の層です。証明書名を修正しても、UUIDが正しいとは限りません。

まず時刻を同期し、次にノードの設定項目を確認する

1. Windowsでは「設定」→「時刻と言語」→「日付と時刻」を開き、自動時刻設定を有効にして同期します。w32tm /query /status で時刻サービスの状態を確認できます。このコマンドがエラーになっても、時刻サービスがまだ起動していないだけの場合があります。
2. Androidではシステムの「設定」を開き、「日付と時刻」を検索して、自動設定を有効にします。実際の日付と時刻を確認してください。表示するタイムゾーンを切り替えるだけでは、システム時計は補正されません。
3. VMessでは、クライアントとサーバーの時刻のずれが認証失敗につながることがあります。両方の時刻を同期してください。スマートフォンの表示タイムゾーンだけを変更しても解決しません。VLESSに同じVMessの時刻認証の説明を当てはめることはできませんが、TLS接続で証明書を検証するには正確な時刻が必要です。
4. サーバーアドレス、ポート、UUID、安全性の種類、serverName、WebSocketの path とHost、またはgRPCの serviceName を一つずつ照合してください。各項目にはサーバー側で指定された値を使い、手当たり次第に変更して試さないようにしましょう。

ポート競合：まずコアを正常に起動する

ログに bind、address already in use、またはWindowsの Only one usage of each socket address が表示された場合は、まずローカルの待ち受けアドレスを確認してください。ローカルのインバウンドを作成できないと、システムプロキシを有効にしてもブラウザーの接続先がありません。リモートサーバーのポートが開いているかどうかとは別の問題です。

ログに 127.0.0.1:10808 のバインド失敗が表示された場合を例に、PowerShellで待ち受けプロセスを調べます。実際のエラーで別のポートが示されている場合は、コマンド内のポートも同じ値に変更してください。

Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 1234

2つ目のコマンドにある 1234 はプロセスIDの例です。1つ目のコマンドの結果に表示された OwningProcess の値に置き換えてください。該当する記録が見つからない場合は、ログがUDPの待ち受けに関するものか、プロセスがすでに終了していないか、古い起動ログではないかも確認します。

1. 待ち受けているのが重複起動したクライアントの場合は、余分なインスタンスを通知領域から通常の方法で終了し、一つだけ起動して確認してください。
2. 待ち受けているのが終了できない別のプログラムの場合は、クライアントのパラメーター設定でローカルの待ち受けポートを変更します。手動プロキシを使用するアプリ側のポートも新しい値に変更してください。
3. 変更後はコアを再起動し、正常な起動ログが表示されたことを確認してからWebページをテストします。正体の分からないシステムプロセスを強制終了しないでください。
4. エラーが permission denied または access permissions の場合は、システムによるポート予約やセキュリティポリシーが関係している可能性もあります。重複プロセスが原因と決めつけたり、原因を覆い隠すために管理者権限で常用したりしないでください。

再現可能なトラブル記録を作る方法

ノードの切り替え、DNSの変更、TUNの有効化、ルーティングの調整を同時に行うと、接続が復旧しても、どの変更が有効だったか分かりません。接続先、ノード、接続方式を一つずつ固定し、各テストの時刻とログを照合するのが確実です。以下の手順はデスクトップとAndroidの同様の問題に使えます。

1. 現在の状態を記録：クライアントとコアのバージョン、使用中のネットワーク、プロキシの接続方式、接続先を記録し、不要なバックグラウンドダウンロードを停止します。
2. 起動を確認：接続を再起動し、設定の解析失敗、待ち受け失敗、必要なリソースの不足など、起動時のエラーを先に解決します。
3. リクエストを1回だけ実行：時刻を記録し、ページを1つだけ一度再読み込みして、前後約10秒のログを残します。
4. 最も深い原因を特定：ローカルの待ち受け、名前解決、リモートへの接続、TLS、プロトコル認証のどの段階かを見分け、該当する項目を確認します。
5. 変更は一つだけ：たとえば時刻だけを同期する、または誤ったポートだけを修正します。同じ接続先を再テストし、具体的なエラーが消えたか、次の段階に移ったかを比較してください。
6. ログ設定を元に戻す：確認が終わったらデバッグレベルを解除し、有効だった変更を記録します。ログを共有する前に、UUID、サブスクリプション用トークン、サブスクリプションURL全体、個人のアクセス記録を削除し、モジュール名とエラーの流れは残してください。

アウトバウンドタグとルールの関係を詳しく知りたい場合は、設定項目の説明をご覧ください。リクエストがダイレクト接続のアウトバウンドに送られている場合は、ルーティングの一致条件を確認してください。直接接続先の失敗を、プロキシサーバーへの接続失敗と混同しないようにしましょう。

よくある質問：ログだけで判断できないケース