ノードを追加したのにWebサイトが開けない、接続がタイムアウトする、コアの起動に失敗するv2rayNユーザー向けです。まず失敗したリクエストのエラー全文を記録し、ローカルの待ち受け、通信の受け入れ、DNS、サーバー側ポート、プロトコルのハンドシェイクの順に確認します。ログレベルの設定方法、よくある英語エラーの意味、Windowsでのテストコマンドも紹介。すべてを「ノードの障害」と決めつけず、原因を切り分けられます。
1. 実行ログを開き、失敗を再現する
v2rayNはGUIクライアントで、プロキシ接続を実際に確立するのは起動したコアです。クライアント画面の異常、コアの起動失敗、個別の接続失敗は、それぞれ別の問題です。ログを確認するときは、選択中のノード、コアの種類、障害が発生した時刻を確認してください。ノードを切り替えた際の複数のエラーを混ぜて分析しないようにしましょう。
-
現在の設定を記録する
メイン画面でクライアントのバージョン、選択中ノードのプロトコルとトランスポート方式を記録し、「設定」→「パラメーター設定」でローカルの待ち受けポートを確認します。新旧の画面では設定項目の分類が異なる場合があります。使用中のバージョンの表示に従ってください。
-
診断ログを有効にする
「設定」→「パラメーター設定」で、コアの「ログレベル」を探します。バージョンによっては「Core: 基本設定」にあります。Xrayを使用している場合は、まず
infoを選び、情報が足りなければ一時的にdebugに変更します。保存後、コアを再起動して設定を反映してください。 -
問題を一度だけ再現する
メイン画面下部の実行情報またはログ欄を開き、現在時刻を記録します。一括速度測定を停止し、ノードを1つだけ選んで、開けないWebサイトに一度アクセスします。該当時刻の前後を含むログをコピーし、最後の1行だけを切り取らないでください。
-
ログレベルを元に戻す
原因を特定したら、ログレベルを
warningまたは元の値に戻します。ログをファイルに記録している場合は、保存先とファイルサイズも確認してください。診断ログには、アクセス先のドメイン、ローカルアドレス、アウトバウンドのタグが記録されることがあります。
Xrayで使われるログレベルには、debug、info、warning、error、none があります。ログレベルは記録の詳しさを変えるもので、接続ポリシーには影響しません。error だけでは有用な接続過程を見落とすことがあります。一方、debug を長時間有効にすると記録量が増え、アクセス情報が漏れるリスクも高まります。
2. エラーの連鎖を読む：アドレスを確認し、根本原因を探す
ログには複数のエラーが重なって記録されることがあります。外側には「接続の処理に失敗」、その内側には「利用可能な接続先が見つからない」と表示され、最も内側に接続拒否やタイムアウトが記録される、といった形です。まずエラーの連鎖に含まれるアドレスを確認し、最も具体的なシステムエラーを探しましょう。failed を見ただけでプロトコルを変更するのは避けてください。
| ログの手がかり | 意味 | 次に確認すること |
|---|---|---|
127.0.0.1:10808 | 本機のループバックアドレスとポート。アプリがローカルプロキシに接続するときによく表示されます。 | 待ち受け状態を確認し、アプリに設定したポートと照合します。 |
dial tcp | TCP接続を確立しようとしています。 | 後続のアドレスがノードサーバーか接続先サイトかを確認します。 |
lookup、no such host | ドメイン名の名前解決で問題が発生しています。 | エラーに記載されたドメイン、DNSの経路、応答内容を確認します。 |
accepted | コアがインバウンドリクエストを受け付けました。 | 対応するアウトバウンドの結果を確認します。リモート接続の成功を意味するわけではありません。 |
direct、proxy | 現在の設定で使われているアウトバウンドのタグの可能性があります。 | 実際のルーティング設定と照合してください。タグ名に固定の標準はありません。 |
以下はログの読み方を示す簡略例で、実際の計測記録ではありません。ローカルのTCPポートが接続を拒否したことを表しています。この情報だけから、リモートノードの品質は判断できません。
dial tcp 127.0.0.1:10808: connectex: No connection could be made because the target machine actively refused it.ポイント：アドレスから調査対象を特定する
ループバックアドレスが示されている場合は、まずローカルの待ち受けを確認します。ノードサーバーのアドレスが示されている場合は、リモート側のポートを調べます。接続元と接続先を特定してから、ノードの設定を変更する必要があるか判断してください。
3. よくあるエラーと対処方法
同じ問題でも、コアやOSによって英語の表現が多少異なることがあります。以下のエラー例と照らし合わせる際は、前後の文脈も残してください。特にアドレス、ポート、トランスポート方式、証明書名を確認しましょう。警告が1回出ても通信に問題がなければ、すぐに設定を変更する必要はありません。繰り返し発生し、実際の通信失敗と一致する場合に診断材料になります。
エラー：connection refused
原因：接続先から接続を拒否されました。該当ポートでサービスが待ち受けていない場合によく発生します。ファイアウォールが明示的に拒否している可能性もあります。
対処：まずアドレスを確認します。ローカルポートの場合はコアが起動しているか確認し、リモートポートの場合はサブスクリプションに記載されたサーバーとポートを照合して、サーバー管理者に待ち受け状態を確認してもらいます。再試行だけではポートの問題は解決しません。
エラー：i/o timeout
原因：読み込みまたは書き込みが制限時間内に完了しませんでした。TCP接続の確立、TLSハンドシェイク、またはその後のデータ転送中に発生することがあります。
対処：dial、read、write の記述から発生段階を判断します。同じノードのまま別のネットワークで再テストしてください。タイムアウトだけを根拠にパスワードの誤りと決めつけたり、タイムアウト値をむやみに大きくしたりしないでください。
エラー：failed to handshake
原因：ハンドシェイクに失敗したことを示す概要です。具体的な原因を判断するには、後続の証明書、認証、EOF、タイムアウトなどの情報を確認する必要があります。
対処：サーバー側の要件に沿って、プロトコル、TLS、SNI、トランスポート方式、認証パラメーターを一つずつ確認します。REALITYを使用している場合は、公開鍵、shortId、serverName、クライアントの対応状況も確認してください。
エラー：bind: Only one usage of each socket address
原因：Windowsでバインドしようとしたローカルアドレスとポートが、別の待ち受けプロセスに使用されています。インスタンスを重複して起動した場合によく発生します。
対処：待ち受けプロセスを特定して重複したインスタンスを終了するか、ローカルポートを変更します。ポートを変更した場合は、ブラウザー、ターミナル、手動設定したプロキシアドレスも忘れずに更新してください。
エラー：no such host
原因：ドメイン名の名前解決で有効な結果を取得できませんでした。ドメインの入力ミス、DNSからの「存在しない」という応答、名前解決経路の異常などが考えられます。
対処：まずノードのドメインと接続先サイトのドメインを区別します。入力ミスとサブスクリプションの更新結果を確認したうえで、該当するDNS設定を調べてください。すべてのドメインをIPアドレスに置き換えると、TLSのホスト名照合に影響する場合があります。
エラー：x509: certificate has expired or is not yet valid
原因：証明書の有効期間の検証に失敗しました。サーバー証明書の期限切れのほか、本機の日付や時刻が正しくない可能性もあります。
対処：まずシステム時刻を同期し、サーバー管理者に証明書の更新状況と証明書チェーンを確認してもらいます。証明書検証を無効にすることを恒久的な解決策にしないでください。
エラー：failed to find an available destination
原因：通常は接続先への接続失敗を示す概要で、DNSの問題だけに限りません。内側のエラーには接続拒否、タイムアウト、到達不能などが含まれることがあります。
対処：エラーの連鎖全体を確認し、最も具体的な lookup、dial tcp、またはシステムエラーを探して、該当する項目に沿って対処します。このメッセージだけを見てDNSを変更しないでください。
EOF や connection reset by peer だけでは、認証失敗とは断定できません。相手側が接続を終了またはリセットしたことを示しており、トランスポート設定の不一致、サーバー側のポリシー、接続の再利用、中間ネットワーク機器などが原因として考えられます。Webページを閉じるときにまれに発生し、新しいリクエストが正常なら、まずは経過を見てください。ハンドシェイクのたびに発生する場合は、サーバーログも照合します。
4. ローカルポートからサーバー設定まで順に切り分ける
以下ではWindows PowerShellを使用し、ローカルプロキシが実際に 127.0.0.1:10808 で待ち受けていることを前提とします。このポート番号は例であり、すべてのバージョンで共通ではありません。「設定」→「パラメーター設定」でローカルの待ち受けポートとインバウンドの種類を確認してください。システムプロキシ、HTTP専用ポート、混合ポートを記憶だけで同じものとして扱わないようにしましょう。
第1段階：ローカルでプロセスが待ち受けているか確認
Get-NetTCPConnection -LocalPort 10808 -State Listen
Test-NetConnection -ComputerName 127.0.0.1 -Port 108081つ目のコマンドで待ち受けの記録と OwningProcess を確認します。該当する記録がない場合は、一致するオブジェクトがないと表示されます。2つ目のコマンドで TcpTestSucceeded : True と表示されるのは、ローカルTCPポートに接続できたことを示すだけです。SOCKSのネゴシエーションやリモートプロキシの接続成功を意味するものではありません。プロセスを特定する場合は、Get-Process -Id の後に確認したプロセス番号を指定し、別のサービスを誤って終了しないようにしてください。
第2段階：プロキシを明示してリクエストを送信
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 -I https://example.com/このコマンドを使うには、対象ポートがSOCKS5に対応している必要があります。socks5h を指定すると、接続先ドメインの名前解決をプロキシ側に任せられるため、curlがローカルで先に名前解決するのを防げます。コアでの実際の名前解決方法は、DNSとルーティングの設定によって決まります。example.com は説明用の接続先で、ノードサーバーではありません。HTTPレスポンスヘッダーを受信できれば、そのリクエストでは該当する経路で接続できています。ただし、すべてのサイトが正常に開けることを示すものではありません。
- コマンドがすぐに接続拒否になる：ローカルポートと待ち受けプロセスを確認します。まずサーバー側の設定を変更する必要はありません。
- ローカルポートには接続できるが、リクエストがタイムアウトする：同じ時刻のコアログで、DNS、ノードアドレス、ハンドシェイクのエラーを確認します。
- コマンドは成功するが、ブラウザーでは失敗する：ブラウザー固有のプロキシ設定、システムプロキシ、プロキシ除外リストを確認します。
- 特定のサイトだけ開けない：別の接続先でもテストし、そのドメインに適用されるルーティング、DNSの結果、接続先サービスの状態を確認します。
第3段階：ルーティングとリモート接続性を切り分ける
システムプロキシは、それに従うアプリがどのように接続するかを決めます。ルーティングの振り分けは、コアが受け取った通信をどのアウトバウンドに送るかを決めます。問題を切り分けるため、テスト対象をプロキシのアウトバウンドに送るルーティングモードに一時的に切り替え、テスト後に元の設定へ戻します。ノードのポートをテストする場合は、Test-NetConnection のコンピューター名とポートをノード詳細に記載された実際の値に変更します。TCP接続に成功しても、VLESS、VMess、Trojanの認証やハンドシェイクが検証されたわけではありません。
ポイント：明示的なプロキシ接続の成功を確認してから、システム側の接続設定を調べる
curlでプロキシを明示したリクエストが成功し、ブラウザーでは失敗する場合は、ノード設定を変えずに、まずシステムプロキシとブラウザーの設定を確認します。すでに使えるリモート接続に新たな変数を加えずに済みます。
5. ハンドシェイクに失敗したらプロトコルとトランスポート設定を確認
サブスクリプションのインポート成功は、クライアントが設定を読み込んだことを示すだけです。サーバーに現在も接続できることや、使用中のコアがすべての設定項目に対応していることを保証するものではありません。更新後は、選択中の項目が本当に更新されたものか確認してください。古いノードを使いながら、新しいサブスクリプションの内容を基準に調査しないようにしましょう。
| 設定の組み合わせ | 優先して確認する項目 | よくある誤った変更 |
|---|---|---|
| VMess | ユーザーID、サーバー側の認証設定、端末の時刻、トランスポート設定。 | サーバー側の要件を確認せずに認証項目を変更する。 |
| VLESS + REALITY | ユーザーID、公開鍵、shortId、serverName、flow、コアの対応状況。 | 別のノードの公開鍵やflowをコピーする。 |
| Trojan + TLS | パスワード、サーバーアドレス、ポート、SNI、証明書チェーン。 | ドメインや証明書の問題を、証明書検証を無効にして隠す。 |
| WebSocketトランスポート | パス、Host、TLS設定、リバースプロキシの設定。 | パスの大文字・小文字や末尾のスラッシュを関係ない情報として扱う。 |
| gRPCトランスポート | serviceName、TLS設定、リバースプロキシのHTTP/2対応。 | ノードのポートだけを変更し、リバースプロキシを確認しない。 |
トランスポート方式とプロキシプロトコルは別のレイヤーです。VLESSだからといって自動的にREALITYになるわけではなく、TLSはWebSocketと同じではありません。サーバー側の完全な設定を基準にしてください。クライアントのメニューに選択肢があるからといって、ノードの組み合わせを自由に変更してはいけません。調査では一度に変更する項目を1つに絞り、同じリクエストを再現して結果を記録します。
6. よくある質問とログを共有する前の確認
遅延テストでは数値が出るのに、Webサイトが開けないのはなぜ？
TCP遅延が示すのは特定ポートへの接続状況であり、プロトコル認証やWebサイトへのアクセスまで含まれるとは限りません。まず上記のプロキシを明示したリクエストを再実行し、その時刻のコアログと照合してください。1つの遅延値だけで通信経路全体を検証したことにはなりません。
サブスクリプションの更新がタイムアウトしたら、ノードに問題がある？
サブスクリプションのダウンロードとノードへの接続は別のリクエストです。まず「サブスクリプショングループ」で登録先URLが期限切れになっていないか確認し、更新時に直接接続とプロキシ接続のどちらを使っているかを確認します。プロキシ経由で更新する場合は、先に利用可能なノードが必要です。ログを共有するときは、サブスクリプションURL全体を公開しないでください。
ブラウザーは使えるのに、コマンドラインやゲームは接続できないのはなぜ？
システムプロキシを参照しないアプリもあります。コマンドラインではプロキシを明示して接続を確認してください。その他のアプリでは、プロキシへの対応状況を調べます。TUNを検討する前に、権限、ルーティング、DNSを確認しましょう。接続方法とノード設定を同時に変更すると、比較が難しくなります。
debugを有効にしたのに、原因を特定できないのはなぜ？
まずバックグラウンドのリクエストを減らし、ノードと接続先を1つずつに絞って一度だけ再現します。エラーの連鎖全体を残し、クライアント、コア、OSの各バージョンと発生時刻を記録してください。必要に応じて、サーバー管理者に同じ時間帯のサーバーログを確認してもらいます。
他の人に相談するときは、原因の切り分けに必要な構造を残しつつ、機密情報を削除してください。ユーザー名、サブスクリプションのトークン、ノードの認証情報、不要なアクセス記録は公開しないでください。「タイムアウト」と表示された画面だけでは、問題のレイヤーを判断できないことがほとんどです。ログ全体を貼るより、機密情報を伏せたエラーの連鎖を短くまとめる方が役立ちます。
- 環境情報を残す：クライアントのバージョン、コアのバージョン、OSのバージョン、システムプロキシまたはTUNの使用状況。
- 再現状況を残す：障害の発生時刻、接続先の種類、毎回発生するか、ネットワークを変えた場合の結果。
- 設定の構成を残す：プロトコル、トランスポート方式、TLSまたはREALITYの有効・無効、エラーがローカルとリモートのどちらに関係するか。
- 機密情報を削除する：サブスクリプションURL全体、UUID、パスワード、秘密鍵、トークン付きクエリパラメーター。必要のないサーバーアドレス全体も伏せてください。
最後に、元の順序で再テストします。コアが正常に起動する、ローカルポートに接続できる、プロキシを明示したリクエストに応答がある、普段使うアプリが想定どおりに接続する、の4点を確認してください。すべて問題なければ、通常のルーティングとログレベルに戻します。DNS、ポート、プロトコルを同時に変更するより、この順序で確認する方が検証可能な結論を得やすくなります。