「クライアントは起動しているのに、Webページが開かない」という方に向けた内容です。まずクライアントログとコアのログを区別し、ローカルの待ち受け、ルール判定、名前解決、リモート接続、プロトコルのハンドシェイクの順に確認します。よくあるエラーメッセージやポート確認コマンド、再テストの方法も紹介します。ポート、DNS、ノードの設定を一度に変更せず、毎回一つずつ試してください。
1. まずログの場所を確認：クライアントの通知とコアのエラーは別
v2rayNはGUIクライアントで、実際の接続処理は通常、選択したコアが担います。Android版のv2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。クライアントはサブスクリプションの取得、設定の生成、プロセス管理を行い、コアは待ち受け、ルーティング、転送を担当します。そのため、「サブスクリプションの取得失敗」と「サーバーへの接続タイムアウト」は別々のログに記録される場合があります。ウィンドウに表示された最後のメッセージだけでノードの障害と判断しないでください。
v2rayNでは、まずメイン画面のログまたは情報欄を確認し、次に「設定」→「パラメータ設定」を開いて、現在のバージョンにあるログレベルやログ記録の項目を探します。画面やバージョンによって項目名や配置が異なるため、すべてのバージョンに同じボタンがあるとは限りません。Androidではクライアントのログ画面で接続状況を確認します。画面に概要しか表示されない場合は、利用可能なコアログやエクスポート機能も確認してください。
- クライアントログ：サブスクリプションの取得失敗、設定生成の失敗、コアの起動失敗、プロセスの終了情報を確認します。
- アクセスログ：アプリからの接続が記録されているか、接続先アドレスと適用されたアウトバウンドを確認します。記録される項目はコアや設定によって異なります。
- エラーログ：名前解決、ダイヤル、TLS、プロトコル処理中のエラーを確認します。一つのリクエストに複数の原因が入れ子になっていることもあります。
- ログファイル：ファイル出力が設定され、保存先のディレクトリに書き込み権限がある場合にのみ生成されます。特定のディレクトリにファイルが見当たらないからといって、コアが動作していないと決めつけないでください。
2. ログレベルと再現方法：リクエストの一連の流れを記録する
V2RayとXrayでよく使われるエラーログレベルは、debug、info、warning、error、noneです。通常はまずinfoで接続状況を確認します。情報が足りない場合は一時的にdebugを有効にし、問題を再現したら元の設定に戻してください。アクセスログは通常、別途出力設定が必要です。エラーログをdebugにしても、必ず表示されるわけではありません。
- 現在のクライアント名、実際に使用中のコア、ノードのプロトコル、プロキシモード、ローカルの待ち受けポートを記録し、ノード設定はまだ変更しないでください。
- テスト開始時刻を記録し、自動更新を続けるWebページやバックグラウンドのダウンロードを停止して、無関係な接続を減らします。
- コアを再起動してログ設定が反映されたことを確認し、既知の接続先に一度だけアクセスします。
- 同じ時刻に記録されたエラーの一連の内容を切り出し、外側の「処理に失敗しました」だけでなく、最も深い階層の具体的な原因を確認します。
- 一度に一つの条件だけを変更して同じリクエストを再実行し、エラーが「ローカルで拒否」から「リモートでタイムアウト」など、別の段階に変化するかを比べます。
以下はコアのJSONログの一部です。項目を理解するための例であり、完全な設定ではありません。GUIクライアントを使っている場合は、クライアントの設定画面から変更してください。自動生成された実行設定を直接編集すると、ノードの切り替えや再起動時に上書きされることがあります。
{
"log": {
"loglevel": "info"
}
}3. 手前から順に確認：リクエストがどの段階まで進んだかを特定する
この流れはトラブルシューティングの目安であり、すべての設定で必ずこの順に処理されるわけではありません。たとえば、ルーティングルールの適用前にDNSクエリが行われる場合や、プロキシサーバーのドメイン名と接続先Webサイトのドメイン名が異なる経路で名前解決される場合があります。重要なのは、「アプリからローカルクライアント」「クライアントからプロキシサーバー」「プロキシサーバーから接続先Webサイト」の3区間を分けて考えることです。
Webページにアクセスしても該当するログがない場合は、アプリがシステムプロキシに従っているか、ローカルアドレスを迂回していないか、現在のログ設定でアクセス接続が記録されるかを確認します。システムプロキシの影響を受けるのは、その設定に従うアプリだけです。有効にしても、すべてのプログラムの通信が自動的にコアに入るわけではありません。TUNモードでは仮想インターフェース、権限、ルーティングも関係するため、他の通信制御方式と同時に有効にせず、個別に検証してください。
以上は診断用の例であり、すべてのクライアントで同じポートを使う必要はありません。まずパラメータ設定で実際のインバウンドプロトコルとポートを確認してください。10808でSOCKSインバウンドを受け付けていない場合、以下のコマンドはそのまま使えません。Windowsのターミナルではcurl.exe、macOSのターミナルではcurlを使います。
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 -I https://example.com/socks5hは、接続先ドメインの名前解決をSOCKSプロキシ側で行う指定です。ただし、プロキシサーバー自体のドメイン名はローカルで解決する必要がある場合があります。HTTPレスポンスが返れば、そのリクエストは少なくとも接続先サービスまで到達しています。拒否やエラーのステータスコードが返っても、プロキシへの接続失敗とは限りません。
4. ポート競合と接続拒否：まずローカルの入口を直す
エラー：bind: address already in use
原因：コアが待ち受けようとしたアドレスとポートを別のプロセスがすでに使用しています。Windowsでは「Only one usage of each socket address」と表示される場合もあります。
対処：ポートを使用しているプロセスを特定し、重複して起動したクライアントを正常終了するか、ローカルの待ち受けポートを変更します。アプリ側のプロキシ設定も同じポートに更新してください。
エラー：connect: connection refused
原因：接続が明示的に拒否されています。指定したアドレスでサービスが待ち受けていない場合によく発生します。ファイアウォールによって拒否されることもあるため、まずエラーに記載された接続先アドレスを確認してください。
対処：接続先が127.0.0.1なら、ローカルのコアとポートを確認します。リモートサーバーが接続先なら、サーバーの待ち受けポートとインバウンドルールを確認してください。
Windowsでは、まずローカルの10808を使用している待ち受けプロセスを調べ、表示されたPIDからプロセスを確認します。ポートが使用中だからといって、見慣れないシステムプロセスを終了しないでください。別のクライアントが起動したままになっていないか、先に確認します。
netstat -ano -p tcp | findstr ":10808"
tasklist /FI "PID eq 1234"2つ目のコマンドにある1234は例示用のPIDです。1つ目の出力に表示された実際のプロセスIDに置き換え、状態がLISTENINGかどうかも確認してください。macOSではlsof -nP -iTCP:10808 -sTCP:LISTENで待ち受けプロセスを確認できます。ポートを変更したらコアを再起動し、先ほどの単発リクエストテストをもう一度実行します。
5. 接続タイムアウトと名前解決エラー：アドレスと通信経路を切り分ける
エラー：dial tcp: lookup …: no such host
原因：接続先のドメイン名を有効なアドレスに解決できていません。エラーに表示されたドメイン名は、プロキシサーバーのものか接続先Webサイトのものです。
対処：ドメイン名の入力とサブスクリプションの内容を確認し、その問い合わせで使われたDNSリゾルバーを特定します。まずプロキシサーバーのアドレスが解決できるかを確認し、その後、接続先WebサイトのDNS経路を調べてください。
エラー：dial tcp …: i/o timeout
原因：制限時間内に接続が完了しませんでした。ネットワークに到達できない、パケットロスがある、ファイアウォールが通信を破棄している、リモートサービスが応答しないなどの可能性があります。
対処：エラーに表示されたアドレスとポートが、想定しているノードのものか確認し、同じノードでネットワークを切り替えて試します。複数のネットワークで失敗する場合は、サーバー管理者に待ち受け状態とアクセスルールを確認してもらってください。
エラー：context deadline exceeded
原因：処理が制限時間を超えました。このメッセージだけでは、サブスクリプションの取得、DNSクエリ、プロキシ接続のどの段階で起きたかは特定できません。
対処：前後のログを読み、まず何の処理がタイムアウトしたかを特定します。サブスクリプションのURLとノードへの接続はそれぞれ個別にテストし、すべてのタイムアウトをノードの障害と決めつけないでください。
Windowsではnslookup example.comを実行して、システムの名前解決結果を確認できます。ただし、これは現在のシステムリゾルバーの動作を示すだけで、コアの設定にあるDNS経路も正常とは限りません。リモートポートはPowerShellのTest-NetConnectionでテストできます。次の例にあるドメイン名は、ノードの実際のサーバーアドレスに置き換えてください。
Test-NetConnection -ComputerName node.example.net -Port 443TcpTestSucceededがTrueでも、TCP接続が成功したことを示すだけで、VMess、VLESS、TLS、REALITYのハンドシェイクが成功したとは限りません。通常のTCPテストでは、別のトランスポート方式を使うすべての状況を確認できません。また、DNSを「回避」しようとサーバーアドレスを任意のIPアドレスに置き換えると、TLSの名前不一致など別の問題を招くことがあります。
6. 証明書エラーとハンドシェイク失敗：最も深い原因を確認する
エラー：x509: certificate has expired or is not yet valid
原因：現在時刻が証明書の有効期間外です。端末の時刻がずれている場合と、サーバー証明書の有効期限が切れている場合があります。
対処：まずシステムの自動時刻合わせを有効にし、日付を確認してください。時刻が正しいのにエラーが続く場合は、サーバー側で証明書を更新し、新しい証明書が実際に読み込まれていることを確認します。
エラー：x509: certificate signed by unknown authority
原因：証明書の信頼チェーンを構築できません。サーバーが証明書チェーンを正しく送信していない場合や、証明書を差し替えるネットワーク機器を経由している場合があります。
対処：サーバーの証明書チェーンと端末の信頼環境を確認し、必要に応じてネットワークを切り替えて再テストします。原因を調べずに証明書検証を無効にしないでください。
エラー：tls: handshake failure
原因：TLSネゴシエーションが拒否されたか、完了しませんでした。接続先サービスの間違い、サーバー名の不一致、両端のTLS設定の非互換などが考えられます。
対処：サーバー側の情報と照らし合わせ、アドレス、ポート、サーバー名、トランスポート設定を確認します。まず一致が確認できている設定に戻し、項目を一つずつ試してください。
エラー：EOF / connection reset by peer
原因：接続先が接続を終了またはリセットしました。通信中、ハンドシェイク中、正常な接続終了時のいずれでも起こり得るため、このエラーだけで認証情報の誤りとは判断できません。
対処：エラーが発生した時刻と前後の状況を確認し、プロトコルとトランスポートの設定を見直します。同じ時刻のサーバーログも確認してください。
VMessとVLESSの認証情報、トランスポート設定、安全性に関する設定はサーバー側と一致させる必要があります。WebSocketのパス、Host、TLSのサーバー名はそれぞれ別の項目です。どれもドメイン名のように見えるからといって、すべて同じ値にしないでください。VMessではシステム時刻も確認し、時刻を同期してから調査を続けます。
- 通常のTLS：サーバー名、証明書の対象名、有効期間、信頼チェーンを確認します。ノードの表示名はTLS検証に使われるサーバー名ではありません。
- REALITY：サーバーから提供された公開鍵、Short ID、サーバー名、クライアントの対応状況を確認します。通常のTLSと同じ証明書の確認方法は使えません。
- コアの互換性：v2rayNGとv2flyNGでは使用するコアが異なります。同じリンクをインポートできても、同じ機能すべてに対応しているとは限りません。REALITYを使う場合は、対応するXrayの設定とコアを使用しているか確認してください。
7. サブスクリプション、ルーティング、一部サイトだけ失敗する場合のよくある質問
サブスクリプションの更新はタイムアウトしますが、既存のノードは使えます。ノードを変更すべきですか？
まず変更しないでください。サブスクリプションの更新は、クライアントからサブスクリプションサーバーへ接続する処理であり、ノードの接続テストとは異なります。サブスクリプションURLが有効か確認してください。クライアントに「プロキシ経由で更新」機能があり、既存のノードが使える場合は、その機能を有効にして再試行できます。サブスクリプションURLをノードのプロキシサーバーアドレスとして入力しないでください。
速度テストは正常なのにブラウザーでページが開きません。まず何を確認すればよいですか？
まずブラウザーのリクエストがローカルの待ち受けに届いているかを確認し、次に適用されたアウトバウンドを確認します。速度テストは遅延や特定の接続先だけを測る場合があり、ブラウザーのリクエストが同じ経路を通るとは限りません。この記事のようにSOCKSポートを明示したコマンドで再テストすると、システムプロキシ設定による不確定要素を減らせます。
一部のWebサイトだけ開けない場合、DNSとルーティングのどちらを確認すればよいですか？
接続できるサイトとできないサイトを一つずつ選び、同じ時間帯の接続先ドメイン、名前解決結果、アウトバウンドのタグを比べてください。失敗したリクエストが直接接続に振り分けられている場合は、まずルールの順序を確認します。プロキシ経由でも失敗する場合は、名前解決、ハンドシェイク、接続先サービスの応答を調べます。すべてのルールを削除しないでください。
ログにwarningが出続けます。debugを常に有効にすべきですか？
その必要はありません。まず、警告が実際に失敗したリクエストに関係しているか確認してください。ブラウザーが接続をキャンセルした場合や、バックグラウンドの確認処理でもログが残ることがあります。debugは一時的に有効にして一度だけ問題を再現し、確認後は元のレベルに戻します。アクセス記録を含む古いログは必要に応じて削除してください。
8. 問い合わせ前に準備すること：再現に必要な最小限の記録を残す
トラブルシューティングの目的は、ログから赤いエラー表示をなくすことではなく、どの区間で失敗し、どの設定変更で結果が安定して変わるかを特定することです。ローカルの待ち受けが正常で、サーバーアドレスを解決でき、TCP接続もできるなら、クライアントを何度も再インストールするのではなく、プロトコルとハンドシェイクを調べてください。ローカルで待ち受けができていない場合は、起動失敗やポート競合を先に解決します。
- 環境：OSの種類、クライアントとコアの実際のバージョン、システムプロキシまたはTUNモードの使用状況。
- 設定の概要：プロトコル名、トランスポートの種類、TLSまたはREALITYの使用有無。認証情報を公開する必要はありません。
- 再現手順：テスト時刻、使用したローカルポート、接続先、問題を安定して再現できるかどうか。
- 比較結果：ネットワークの切り替え、既知の正常なノードへの変更、または元の設定への復元で、何がどう変わったか。
- ログの前後関係：リクエスト開始からエラー発生までの短い区間を、機密情報を伏せて共有します。最後の「接続失敗」という1行だけでは不十分です。