失敗したリクエストを起点に、時刻、宛先、アウトバウンドのタグ、エラーの詳細を確認して原因を特定します。サブスクリプションを追加したものの接続できない、またはWebページが開かない場合に役立つ内容です。ローカルの待ち受け、ノードへの接続、TLSハンドシェイク、DNS名前解決の問題を切り分け、GUIクライアントで一つずつ検証する方法を説明します。設定を一度に複数変更するのは避けましょう。
まずログの場所を確認：クライアントとコアを分けて見る
「クライアントの操作に失敗した」のか「プロキシ接続に失敗した」のかを切り分けます。v2rayNはサブスクリプションの管理、設定の生成、コアの起動、システムプロキシの設定を担当します。接続処理を実際に行うのはXrayまたはV2Flyコアです。サブスクリプションの取得タイムアウトはノードのハンドシェイク失敗とは別の問題です。また、コアの起動失敗はブラウザーを切り替えても解決しません。
v2rayNのメイン画面下部にあるログ欄を開き、まず起動ログでコア名、バージョン、起動時刻を確認してから、問題を再現します。バージョンによってログが画面下部のタブに表示されたり、別ウィンドウで開いたりするため、メニュー名や場所が異なる場合があります。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。Android版ではメイン画面のメニューからログ画面を開けます。デスクトップ版と同じメニュー位置とは限りません。
- サブスクリプションの取得：更新時のメッセージを確認し、URLへのアクセス、認証、内容の解析のどこで失敗したかを特定します。サブスクリプションURL全体を公開しないでください。
- 起動：設定の読み込み、プロトコルの項目、待ち受けポート、コアの終了メッセージを確認します。起動に成功していない場合は、接続先のWebサイトを調べる前に起動時の問題を解消しましょう。
- アクセス：受信リクエスト、ルーティングの選択、接続先への接続、応答の読み込みを確認します。エラーと直前にアクセスした宛先を照らし合わせてください。
ログレベル、アドレス、エラーの流れを読み解く
まずエラーがどの層で発生したかを確認し、次にログレベルを見ます。XrayとV2Flyでは、主にdebug、info、warning、errorが使われ、関連ログの出力を止めるにはnoneを指定できます。アクセスログとエラーログは、必ずしも同じ経路に出力されるとは限りません。acceptedはローカルでリクエストを受け付けたことを示すだけで、接続先からページが正常に返ったことを意味しません。
| レベル／記録 | 主な用途 | 確認のポイント |
|---|---|---|
debug | 内部処理の詳細を確認する | 短時間の再現時だけ有効にし、終わったら元に戻す |
info | 起動時や実行中の情報を確認する | コアが起動したか、リクエストが届いたかを確認する |
warning | 異常や失敗を知らせる | 宛先と照らし合わせ、現在のアクセスに影響するか確認する |
error | 重大なエラーを記録する | 設定の読み込みと待ち受けの失敗を優先して確認する |
| アクセスログ | 送信元、宛先、ルーティングタグを表示する | トラフィックの入口を確認するために使い、成功の判断には単独で使わない |
以下は読み方を示すための例で、実測結果ではありません。バージョン、コア、設定によって項目の順序は異なります。127.0.0.1:53124はアプリが使う一時的な送信元ポートです。この値を理由に、クライアントの待ち受けポートを53124に変更する必要はありません。宛先の443は今回のリクエスト先のポートであり、ノードサーバーのポートとは限りません。
2026/08/14 10:15:30 from 127.0.0.1:53124 accepted tcp:example.com:443 [socks -> proxy]
[Warning] ... failed to process outbound traffic > ... dial tcp 192.0.2.10:443: connect: connection refusedエラーの流れは、外側の処理失敗に続いて、より低い層の原因が示されることがよくあります。まず末尾の具体的なエラーを見つけ、それがどの宛先、どのアウトバウンドに関係するかを確認します。例にある192.0.2.10は文書用のサンプルアドレスであり、ノードの設定には使えません。ログに接続IDがあれば同じIDの行をたどります。IDがない場合は時刻と宛先で照合し、バックグラウンドの更新リクエストをブラウザーのリクエストと取り違えないようにします。
接続拒否・タイムアウト：まずエラーの発生先を確認
connection refusedが表示されたら、まずアドレスの部分を確認します。127.0.0.1:10808を示している場合は、アプリが古いプロキシポートを使っているか、ローカルのコアが待ち受けていない可能性があります。ノードのアドレスとポートを示している場合は、ノードが利用可能か、サブスクリプションに記載されたポートが変わっていないかを確認します。10808はよくある例にすぎません。実際の待ち受けポートは現在のクライアント設定を確認してください。
エラー：connect: connection refused
原因：接続先から拒否応答が返っています。宛先ポートでサービスが待ち受けていない場合や、ネットワーク機器が接続を拒否している場合に発生します。
対処：まずローカルアドレスかノードのアドレスかを見分けます。ローカル側の問題なら待ち受けとシステムプロキシを確認し、ノード側ならサブスクリプションを更新して、利用できることが分かっている別のノードと比べます。
エラー：i/o timeout
原因：接続、読み込み、書き込みのいずれかが制限時間内に完了していません。このメッセージだけではDNSの問題とは断定できません。
対処：前のログ行にあるモジュール名と宛先を確認し、接続開始時と読み込み時のどちらで発生したかを見ます。同じノードを使ったままネットワークを切り替えて比較してください。
エラー：bind: address already in use
原因：ローカルの待ち受けアドレスまたはポートが、別のプロセスやクライアントの複数起動によって使用されています。
対処：クライアントを複数起動している場合は、重複分を終了します。それでも競合する場合は「設定」→「パラメーター設定」を開き、ローカルの待ち受けポートを探して変更・保存してください。プロキシを手動設定しているアプリのポートも合わせて変更します。
Windowsでは、ポートの競合が「通常、各ソケット アドレスは 1 回のみ使用できます」といったシステムメッセージで表示されることがあります。上記の待ち受け競合と同様の意味です。正体の分からないシステムプロセスを終了したり、確認せずにランダムなポートを次々と試したりしないでください。
判断の目安：ローカルの待ち受けに失敗したら、まず起動時の問題を解消
コアが10808番ポートにバインドできていない場合、VMessやVLESSへの切り替え、リモートDNSの設定変更では待ち受けの競合は解消しません。まず起動ログからバインド失敗がなくなったことを確認し、その後、リクエストがログに記録されるかテストします。
ハンドシェイク失敗：TLSとトランスポートの設定を分けて確認
ハンドシェイクエラーは接続の確立後に発生しますが、プロトコル認証まで進んでいるとは限りません。TLS証明書の検証、トランスポートの経路、ユーザー認証はそれぞれ別の確認項目です。すべてのハンドシェイクエラーを「パスワード間違い」と決めつけたり、証明書の検証を無効にする方法を万能策として使ったりしないでください。
エラー：x509: certificate has expired or is not yet valid
原因：証明書の有効期間と端末の時刻が一致していません。端末の時計がずれているか、サーバー証明書の期限が切れている可能性があります。
対処：まずシステムの自動時刻設定を有効にして時刻を同期し、再試行します。時刻が正しいのにエラーが続く場合は、ノードの提供元に証明書の対応を依頼してください。
エラー：remote error: tls: handshake failure
原因：接続先がTLSハンドシェイクを拒否しています。サーバー名、TLSパラメーター、サーバー側のポリシーなどが関係している可能性があります。
対処：ノードの編集画面を開き、元の設定と照らし合わせてTLSの有効・無効とサーバー名（SNI）を確認します。サブスクリプションを更新してから再テストしてください。
エラー：websocket: bad handshake
原因：WebSocketのアップグレードで期待した応答が返っていません。パス、Host、リバースプロキシの接続先が一致していない場合によく発生します。
対処：トランスポート方式、パス、Hostを確認します。パスの先頭のスラッシュと元の大文字・小文字を維持してください。SNIとHostは、常に同じ項目とは限りません。
- まずプロトコルを確認：VMessとVLESSは別のプロトコルです。プロトコル名だけ変えて、ほかの設定をそのまま流用することはできません。
- 次にトランスポートを確認：WebSocketやgRPCなどの設定は、サーバー側と一致させる必要があります。gRPCではサービス名も確認してください。
- 最後にセキュリティ層を確認：TLSとREALITYでは、それぞれ異なる設定項目を使います。REALITYを使うノードでは、提供元の情報に沿って公開鍵、Short ID、サーバー名を確認してください。一般的な証明書エラーの対処手順をそのまま適用しないでください。
EOFやunexpected EOFは、接続が終了した、またはデータの受信が途中で途切れたことを示すだけで、認証失敗の証拠にはなりません。この一文しかログにない場合は前後の記録を残し、トランスポート方式とノードの状態を照らし合わせてください。ユーザーIDを何度も新しく作り直して接続を試すのは避けましょう。
DNSタイムアウト：ノードのドメインとアクセス先のドメインを切り分ける
どちらも名前解決の失敗でも、発生箇所によって対処は異なります。ノードのアドレスがドメイン名の場合、クライアントはまずノードのIPアドレスを調べる必要があります。アクセス先がドメイン名の場合は、ローカルDNS、コアのDNS、または接続先側で処理されることがあります。実際の動作は設定によって異なるため、ログにDNSとあるだけで特定のパブリックDNSへ変更しないでください。
エラー：lookup example.com: no such host
原因：リゾルバーから、そのドメインの有効なアドレスが返されていません。名前の入力ミス、DNSレコードの不存在、または現在の名前解決経路から異常な応答が返っている可能性があります。
対処：まずノードのドメインかWebサイトのドメインかを確認し、つづりと現在のネットワークでの名前解決結果を調べます。DNSルール全体をすぐに変更するのは避けてください。
エラー：context deadline exceeded
原因：処理が制限時間を超えています。前のログ行でDNSモジュールからのエラーだと確認できた場合に限り、名前解決のタイムアウトとして優先的に調べます。
対処：DNSリクエストが直接接続とプロキシ接続のどちらを通るか、その出口から選択したDNSサーバーに到達できるかを確認し、該当するDNS設定だけを変更します。
| 確認できる症状 | 優先して確認する項目 | 確認方法 |
|---|---|---|
| ノードのドメインを名前解決できない | ノード接続前の名前解決経路 | ネットワークを切り替えて同じノードを再試行し、同時にプロトコルは変えない |
| 一部のドメインだけ開けない | 該当ドメインのルールと名前解決結果 | 開けないドメインと開けるドメインのアウトバウンドタグを比較する |
| プロキシを有効にするとDNSが失敗する | DNSのアウトバウンド依存関係とルーティングループ | 動作確認済みのDNS設定に戻し、カスタムルールを一つずつ有効にする |
従来のDNSはUDP 53、DNS over HTTPSはTCP 443を使うことがよくあります。ポートに接続できても名前解決の結果が正しいとは限りません。また、443のタイムアウトが必ずWebサイトへのアクセス障害を意味するわけでもありません。特に「ノードへの接続に必要なノードのドメイン名を、プロキシ経由で解決しようとする一方、そのプロキシを使うには先にノードへ接続しなければならない」という依存関係のループに注意してください。
5つの手順で再テスト：変更する項目は一度に一つ
ログを再現可能な操作記録として活用します。以下はデスクトップ版のv2rayNを例にした手順です。設定名はバージョンによって変わる場合があるため、現在の画面に表示される項目を確認してください。コアの設定ファイルを手動で編集する必要はありません。Android版を使う場合も同じ順序で確認し、接続時にシステムVPNの許可を取得済みかを確認します。
-
現在の状態を記録する
クライアントとコアのバージョン、選択中のノード、ネットワークの種類、失敗した時刻を記録します。メイン画面のログ欄を開き、既存のエラーを保存してから表示をクリアし、過去の記録が混ざらないようにします。
-
起動結果を確認する
「設定」→「パラメーター設定」を開き、実際の待ち受けポートを確認します。詳細を確認したい場合はログレベルの項目を探し、一時的に
infoまたはdebugに切り替えます。保存後、画面の指示に従ってコアを再起動し、設定の読み込みやポートのバインドでエラーが発生していないことを確認してください。 -
トラフィックの入口を固定する
トレイメニューの「システムプロキシ」から「システムプロキシを自動設定」を選択します。テスト中は、経路が重なるのを避けるためTUNを無効にしてください。システムプロキシの設定が適用されるのは、その設定に従うアプリだけです。別途プロキシを設定しているアプリは個別に確認します。
-
リクエストを1回だけ再現する
システムプロキシを利用するブラウザーで、同じHTTPSページを開きます。リクエストの時刻を記録し、ログから対応する宛先を探してください。該当する記録がまったくない場合は、ノードの故障と決めつけず、まずアプリの通信経路とログレベルを確認します。
-
項目を一つずつ変更して再テストする
エラーの流れに基づき、ノードの選択、SNI、DNSの経路など、一つだけ変更します。同じリクエストで変更前後を比較してください。復旧を確認したら詳細ログを元のレベルに戻し、最終的に有効だった設定を記録します。
アクセスログのアウトバウンドがdirectなのに、プロキシを通る想定だった場合は、ノードの証明書ではなくルーティングルールとその順序を確認します。アウトバウンドタグは変更できるため、proxyやdirectはあくまで一般的な名前です。実際の設定ファイルと画面で選択中のルーティングモードを確認してください。
判断の目安：同じリクエストで失敗する段階が変わったか比較する
変更後に「ノードへの接続タイムアウト」から「TLSハンドシェイク失敗」に変わった場合は、エラーの発生箇所が変わったということです。解決したとは限りません。新たに示された、より低い層の原因を引き続き確認してください。同じページが正常に表示され、関連リクエストのエラーが続かなくなった時点で、今回の検証は完了です。
ログを使ったトラブル対処：よくある質問
ログに赤いエラーがないのにWebページが開かないのはなぜ？
まず、該当する宛先のアクセスログがあるか確認してください。記録がなければ、ブラウザーがシステムプロキシを使用しているか、プロキシのポートが一致しているかを確認します。記録がある場合は、アウトバウンドタグと後続のエラーを確認してください。ログレベルが高すぎる場合やアクセスログが無効の場合も、記録が少なく見えることがあります。
warningが何度も出ます。すべてのノードを削除したほうがいいですか？
その必要はありません。まずバックグラウンドでネットワークにアクセスしているアプリを終了し、Webページを一つだけ開いて再現します。そのリクエストと同じ時刻の警告を探してください。キャンセル済みのリクエストや到達できない宛先による少数の失敗もあり、警告の数だけで全ノードに問題があるとは判断できません。
サブスクリプションの更新に失敗した場合も、ハンドシェイクエラーとして対処しますか？
まず、サブスクリプションのダウンロードとノードとの通信を切り分けます。「サブスクリプショングループ」で更新結果を確認し、サブスクリプションURLが有効か、現在のネットワーク環境に適したアクセス方法かを調べてください。プロキシ経由で更新する設定がある場合は、すでに利用可能なプロキシ接続があるときだけ試します。まだ追加していないノードに依存する状態を避けましょう。
遅延テストは成功するのに、実際のアクセスがタイムアウトするのはなぜ？
遅延テストで確認するのは、接続または特定のテスト先だけの場合があります。すべてのWebサイト、DNS、トランスポートが正常とは限りません。同じノードを使い、ブラウザーで開けないページを再現して、ドメイン、宛先ポート、アウトバウンドタグを照合し、実際のリクエストのエラーの流れを確認してください。
ログを他の人に見せる場合、どの情報を残せばよいですか？
クライアントとコアのバージョン、エラーの時刻、プロトコルとトランスポートの種類、ポート、エラーの流れ全体を残します。機密性のあるアドレスを置き換える場合は、「ノードのドメイン」「アクセス先のドメイン」など一貫した名前を使い、別々の宛先を同じ名前で塗りつぶさないでください。スクリーンショットにサブスクリプションURLやユーザーの認証情報を含めないようにします。