v2rayNのログエラー対処法｜よくあるエラーの意味と原因の調べ方

エラーは最後の1行だけでなく、全体を確認する

v2rayNは設定、サブスクリプション、プロキシ設定を管理するクライアントで、実際の接続処理は選択したコアが行います。メイン画面の操作に関する表示とコアのログは、別の処理段階から出力されることがあります。サブスクリプションの更新に成功しても、設定を取得できたことしか分かりません。コアの起動に成功しても、接続先サーバーに到達できるとは限りません。

メイン画面下部のログまたは情報欄を開き、接続に失敗した時刻を記録して、同じエラーの前後も確認します。バージョンによって画面の項目名や場所が異なる場合があります。ここではWindowsデスクトップ版を例に説明します。設定を確認するときは、画面上の位置を推測せず、「設定」→「パラメーター設定」から実際の設定を確認してください。

1. テスト条件を固定する

   サーバーを1つ、接続先のWebページを1つ選び、ほかのアプリによる連続再試行を止めます。システムプロキシとTUNの現在の状態を記録し、調査中に両方を切り替えないようにします。

2. 最初に失敗した箇所を特定する

   現在の時刻を記録し、接続先のWebページを1回だけ開き直します。この操作の前後に出たエラーだけを確認し、以前のログを新しい問題と取り違えないようにします。

3. エラーの前後も記録する

   エラーの前後数行を残し、接続先のアドレス、ポート、最も内側に記録された原因を確認します。ログを共有する前に、サブスクリプションURL、ユーザーID、認証情報を隠してください。

4. 変更は一度に1つだけ

   ポート、DNS、サーバー、トランスポート設定のうち、一度に変更するのは1項目だけにします。設定を保存してコアを再起動した後、同じ接続先で再テストし、エラーが変わったか記録します。

ローカルの待ち受けに失敗する場合：プロキシポートを確認

コアが起動直後に終了する場合は、まずノードの設定を変更しないでください。アプリが最初に接続するのはPC上のプロキシポートで、その後にリモートへ接続します。ログにある127.0.0.1はループバックアドレスです。同じ「接続拒否」でも、ローカルの接続口で発生した場合とサーバー側で発生した場合では、確認すべき箇所が異なります。

PowerShellで次の読み取り専用コマンドを実行します。例では10808を確認します。使用中のローカルポートが異なる場合は、先に数字を置き換えてください。最初のコマンドで何も表示されなければ、その時点で該当するTCPの待ち受けは見つかりません。UDPの状態やリモートへの接続状況を確認するコマンドではありません。

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

Get-NetTCPConnection -LocalPort 10808 -State Listen -ErrorAction SilentlyContinue |
  ForEach-Object { Get-Process -Id $_.OwningProcess }

接続拒否とタイムアウト：明示的な拒否と応答なしを見分ける

ローカルの待ち受けに問題がないことを確認したら、ログに記録された接続先アドレスとポートを確認します。接続拒否は通常、拒否の応答を受け取ったことを示します。タイムアウトは、制限時間内に処理が完了しなかったことを示します。どちらのエラーだけからも、アカウントが無効かどうかは判断できません。また、すべてのタイムアウトをDNSの問題と決めつけるのも誤りです。

ドメイン名の解決に失敗する場合：どのドメイン名かを確認

DNSはドメイン名をIPアドレスに変換します。ログで解決に失敗した名前は、ノードのサーバー名、接続先Webサイトのドメイン名、DNSサーバー自身のドメイン名など、さまざまです。まず対象を特定してから対処すれば、「Webページが開かないからDNSを全部変更する」といった試行錯誤を避けられます。

• システム側の確認：PowerShellでResolve-DnsName -Name example.comを実行すると、システム側で名前解決できるか確認できます。ノードを調べる場合は、実際にノードが使用するホスト名を指定してください。
• コア側の確認：現在のDNS設定とルーティングを確認します。システムで名前解決できても、コアで指定したリモートDNSに接続できるとは限りません。
• アドレスを安易に置き換えない：DNSで取得したIPアドレスを、TLSノードのすべての項目にそのまま設定しないでください。サーバーアドレス、SNI、HTTP Hostはそれぞれ異なる役割を持つ場合があります。サービス側の指定に従ってください。

特定のWebサイトだけ開けず、ノードのサーバーには接続できる場合は、そのサイトの名前解決結果、適用されるルーティング、接続先サービスを確認します。ルーティングは「接続をどの出口へ送るか」を決めるもので、すべてのドメイン名を自動的に解決可能にする機能ではありません。

TLSハンドシェイクに失敗する場合：時刻、ホスト名、トランスポート設定を確認

TCP接続が確立しても、TLSに失敗する場合があります。TLSは暗号化された接続を確立する仕組みです。VMess、VLESSなどのプロキシプロトコルにも、それぞれ設定要件があります。ポートに接続できても、TLS、トランスポート、プロキシ認証がすべて成功したとは限りません。

EOFやconnection reset by peerは、接続が途中で終了したことを表すエラーで、特定の認証エラーではありません。トランスポートの種類が一致しない、WebSocketのパスが誤っている、リバースプロキシの設定に問題がある、接続先サービスが切断したなど、さまざまな原因が考えられます。発生した段階もあわせて確認してください。EOFを見ただけでクライアントを再インストールする必要はありません。

• WebSocketを使用する場合は、サーバー側の設定と照らし合わせてパスとHostを確認します。パスの大文字・小文字や文字を推測で変更しないでください。
• gRPCを使用する場合は、サービス名とサーバー側の設定を確認します。WebSocketのパスをそのまま流用することはできません。
• VLESSまたはVMessを使用する場合は、プロトコルの種類、ユーザーID、関連する設定が一致しているか確認します。サブスクリプションを更新する前に、必要なカスタム設定を保存してください。
• 現在の設定が選択中のコアに対応しているか確認します。v2rayNの画面、コアのプログラム、サブスクリプションの内容はそれぞれ別の要素です。どれか1つを更新しても、残りが自動的に更新されるわけではありません。

リクエストがログに出ない場合：システムプロキシとルーティングの入口を確認

Webページを開いてもコアに該当するリクエストが記録されない場合、アプリからクライアントに通信が渡されていない可能性があります。一方で、ログレベルの設定によりアクセスの詳細が記録されていないだけかもしれません。「ログが見つからない」だけでは、ノードが正常とも、プロキシを経由せず通信しているとも判断できません。

1. プロキシへの接続口を確認する

   v2rayNのメイン画面またはタスクトレイのメニューから「システムプロキシ」の状態を確認します。システムプロキシを使う場合は「システムプロキシを自動設定」を選び、Windowsに記録されたアドレスとポートがローカルの待ち受け設定と一致するか確認してください。

2. アプリごとの設定を確認する

   ブラウザーや対象アプリに、直接接続、別のプロキシポート、プロキシ拡張機能が設定されていないか確認します。アプリ独自の設定は、システムプロキシに従わない場合があります。

3. ルーティング先を確認する

   リクエストがコアに届いたら、該当する出力タグと現在のルーティングルールを確認します。直接接続に割り当てられた宛先は、サーバーを選択しただけでは自動的にプロキシ経由になりません。

4. 必要な間だけ詳細ログを有効にする

   「設定」→「パラメーター設定」でログレベルに関する項目を探します。必要であれば一時的にdebugを設定して1回だけ再現し、確認後に元のログレベルへ戻してください。接続先アドレスなどの機密情報が長期間記録されるのを防げます。

よくある質問とトラブル情報の共有方法

問い合わせる前に、最後の確認を順番に行います。ローカルのポートが待ち受けていること、アプリの通信がプロキシに入っていること、サーバーのドメイン名が想定どおりに解決されること、リモートポートに接続できることを確認し、最後にTLSとプロキシプロトコルの設定を調べます。サーバーを自分で管理している場合は、同じ時刻の待ち受け、ファイアウォール、証明書、サーバー側のエラーログも確認してください。サブスクリプションサービスを利用している場合は、「タイムアウトした」と伝えるだけでなく、確認済みの項目をサービス提供元に共有すると、より適切な回答を得やすくなります。