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

1. まずログの種類を見分け、リクエストを1回再現する

v2rayNはクライアントで、V2RayまたはXrayが接続を処理するコアです。サブスクリプションのダウンロード失敗や画面設定の保存失敗はクライアント側の問題です。一方、待ち受けポートの起動失敗やプロキシのハンドシェイク失敗は、通常コア側で発生します。Android版のv2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。コアやバージョンによってログの表現は異なるため、ログ全体をそのまま検索しても答えが見つかるとは限りません。

コアのログには、アクセスログとエラーログがあります。アクセスログでは、リクエストがインバウンドに到達したか、どの宛先にアクセスしたか、どのアウトバウンドが選ばれたかを確認できます。エラーログでは、起動時や接続中の異常を確認できます。acceptedと表示されても、通常はリクエストがインバウンドに受け付けられたことを示すだけです。リモート接続の成功や、Webページの内容が返されたことまでは意味しません。

上記の流れは、調査する段階を切り分けるためのものです。すべての接続で、必ず同じ順番で名前解決が行われるわけではありません。DNSの解決はルーティング判定時に行われることも、リモート側に委ねられることもあります。まずはリクエストがどの段階で失敗したかを特定し、DNS、ルーティング、ノード設定を一度に変更するのは避けましょう。

1. 現在の設定を保存し、システム時刻、選択中のノード、実際に使用しているコアを記録します。
2. クライアントのログ画面を開き、サブスクリプション更新の通知だけでなく、コアの実行ログが表示されていることを確認します。
3. ほかのアプリからのネットワークリクエストを一時的に止め、決まった宛先にアクセスして、失敗を1回だけ再現します。
4. 失敗の前後を含む連続したログを保存し、時刻、宛先アドレス、接続IDを手掛かりに同じリクエストを特定します。

2. loglevelの選び方：普段はwarning、調査中だけdebug

log.loglevelはエラーログの詳細度を制御する設定です。接続速度の設定でも、アクセスログのオン・オフでもありません。普段はwarningにしてログのノイズを抑え、問題を再現するときだけ一時的にinfoまたはdebugへ切り替えます。原因を特定したら元のレベルに戻し、ログの増え続けや接続情報の露出を防ぎましょう。

以下はV2Ray形式の設定におけるトップレベルのlogオブジェクトの例で、実行可能な設定ファイル全体ではありません。GUIクライアントでは、ログ設定画面から変更するのが基本です。クライアントが生成する設定ファイルは、次回起動時に上書きされる場合があります。ファイルとコンソールのどちらに出力されるかは、ログの出力先設定やクライアント側の出力取得方法にも左右されます。

{
  "log": {
    "loglevel": "debug"
  }
}

3. connection refusedとポート競合：まず接続先がどちら側か確認

connection refusedは接続が明示的に拒否されたことを示します。接続先ポートでサービスが待ち受けていない場合や、ファイアウォールが接続を拒否した場合によく発生します。まずエラーに記載されたIPアドレスとポートを確認してください。127.0.0.1ならローカルの入口を、ノードのサーバーを指しているならリモート側のサービスを調べます。この2つを混同すると、ノード設定を変更してもローカルプロキシに接続できないままになります。

以下の数値は一般的な設定例であり、現行バージョンの固定された初期値ではありません。HTTPとSOCKSを1つの混合ポートで受け付ける設定もあります。実際の待ち受け項目は、クライアントに表示される内容を確認してください。リモート側のポートが443でも、TLSを使うサービスだとは限りません。

Windowsでは、次のコマンドでこの2つのローカルポートを調べられます。出力の最終列はPIDです。TCPの行がLISTENING状態かどうかを確認してください。その後、タスクマネージャーの「詳細」タブでプロセス名を確認し、見覚えのないプロセスをポート番号だけで終了しないようにしましょう。

netstat -ano | findstr ":10808"
netstat -ano | findstr ":10809"

• 待ち受けがまったくない：まずコアの起動エラーを解消してから、ブラウザーやターミナルでテストします。
• 待ち受けはあるがプロトコルが違う：HTTPプロキシの接続先に、SOCKS専用ポートをそのまま指定することはできません。
• ポートを10810に変更した場合：アプリが10808を参照したままでは失敗が続きます。システムプロキシとターミナルの環境変数をそれぞれ確認してください。

4. timeoutとDNSエラー：最も具体的な原因から判断

i/o timeoutは読み書きが待ち時間を超えたことを示し、context deadline exceededは処理が期限を超えたことを示します。どちらも「ノードが使えなくなった」と直接示すものではありません。DNS問い合わせ、TCP接続、TLSハンドシェイク、応答待ちなど、さまざまな段階でタイムアウトが起きる可能性があります。エラーの連鎖をたどって最も具体的な子エラーを確認し、どのアドレスへの、どの段階の処理でタイムアウトしたかを特定しましょう。

たとえば、ブラウザーでアクセスに失敗し、ログにはノードのドメイン名の名前解決エラーだけが記録されている場合、ノードへの接続はまだ確立していません。アクセス先サイトのルーティングルールを先に変更する必要はありません。反対に、ノードには接続できていて特定の宛先ドメインだけ失敗する場合は、その宛先の名前解決とルーティング結果を確認します。

1. ノードのaddressがドメイン名かIPアドレスか、またポートがサーバー側と一致しているかを確認します。
2. システムの名前解決コマンドを実行し、ローカルで正常に解決できるかを確認します。Windowsではnslookupの後に実際のノードのドメイン名を指定します。
3. システムの問い合わせが成功しても、コアのDNS解決が成功するとは限りません。dns.servers、リゾルバーへの到達性、関連するルーティングを確認してください。
4. 変更する項目は一度に1つにし、変更前後のエラーを記録します。どの設定が効果をもたらしたのか判断できなくなるのを防げます。

5. TLSハンドシェイク失敗：時刻、証明書名、通信設定を確認

TCP接続が成功したことは、リモートのポートに接続できたという意味にすぎません。その後のTLS接続は、証明書、サーバー名、プロトコルのネゴシエーションが原因で失敗する場合があります。streamSettings.securityがサーバーの要件と一致しているか確認してください。通常のTLSを使用している場合は、tlsSettings.serverNameも確認します。サーバーアドレスと証明書名が異なる構成もありますが、サーバー側の設定に合っている必要があります。

TLS接続に成功しても、その後の通信や認証でエラーが発生することがあります。WebSocketのpathやリクエストのHost、gRPCのserviceNameは、サーバー側の設定と一致している必要があります。websocket: bad handshakeは、パス、Host、リバースプロキシの転送設定、通信方式の不一致などでよく発生し、証明書の問題とは限りません。

6. ログから設定項目を特定する：失敗した段階に合わせて変更

設定項目は、障害が発生した段階に合わせて確認します。起動時に待ち受けエラーが出るなら、まずインバウンドを確認します。リモート接続の失敗なら、アウトバウンドの接続先を確認します。リクエストが誤った経路に進むなら、ルーティングタグを確認してください。以下は一般的なV2Ray形式のJSONを例にした対応表です。実際の構造は使用するコアとクライアントの設定に従ってください。

VMess、VLESS、Trojan、Shadowsocksでは認証に使う設定項目が異なります。プロトコル認証の段階まで進んでいることを確認してから、UUID、パスワード、暗号化方式を調べてください。すべてのエラーを「パスワードが違う」と決めつけるのは避けましょう。EOFが繰り返し発生しても、読み取り中に接続が終了したことを示すだけです。ハンドシェイクの前かデータ転送の後かを確認して判断してください。

• 変更前：設定をバックアップし、エラーの原文と発生時刻を記録します。
• 変更：現在の失敗段階に直接関係する項目だけを変更します。サブスクリプションで管理されているノードは、更新によって手動変更が上書きされる場合があるため注意してください。
• 確認：コアを再起動して設定を反映し、同じアプリから同じ宛先へ再度アクセスします。
• 後処理：アクセスが復旧したらログレベルを下げ、不要になった診断ファイルを削除します。

7. ログ調査でよくある質問