まずTCPingでノードのポートに接続できるかを確認し、次に実接続遅延でプロキシ経由のリクエストを検証します。最後に候補を絞ってダウンロード速度を測定しましょう。「遅延は低いのにWebページが開かない」「測定はタイムアウトするが実際には使える」といった場合に向けて、各テストの範囲や結果の読み違い、繰り返し実行できるノード選定手順を解説します。
3種類の速度測定の違い：ポート接続・プロキシリクエスト・連続転送
数値の大小だけでなく、何を測定しているかを確認しましょう。TCPingは通常、ノードの指定TCPポートへの接続を試みます。実接続遅延は、選択したノード経由で測定先のWebサイトにリクエストを送ります。ダウンロード速度測定では、プロキシ経由でデータを受信し、単位時間あたりの転送量を確認します。測定範囲はそれぞれ異なるため、同じ基準で順位付けすることはできません。
TCPing：まずポートへの接続を確認
主に、ノードのTCPポートに接続するまでの時間を示します。プロキシの認証、サーバーからの外向き通信、接続先サイトの応答までを検証するものではなく、システムのpingで使われるICMPによる疎通確認とも異なります。
向いている用途：ポート拒否、接続タイムアウト、明らかに異常な接続先を手早く絞り込む。
実接続遅延：現在使えるかを優先して確認
おすすめ測定リクエストをプロキシ経由にするため、Webページへのアクセスに近い測定ができます。計測の開始・終了条件、測定先URL、成功判定はクライアントやコアの実装によって異なります。
向いている用途：日常的なノード選び、設定の検証、「ポートには接続できるのにプロキシが使えない」状態の確認。
ダウンロード速度測定：次に連続転送性能を確認
接続確立後に継続して受信できるデータ量を測定します。テストファイル、同時接続数、測定時間、回線の混雑状況、ローカル回線の帯域などに左右されます。
向いている用途：大容量ファイルのダウンロードや高画質動画など、データ転送が続く場面の比較。
v2rayNはクライアントで、実際のプロキシ接続は選択したコアが処理します。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。クライアント画面で名称が似ている測定項目でも、計測方法が完全に同じとは限りません。クライアント間で比較する前に、測定先と測定方式を確認してください。
TCPingの結果が良好なのに、Webページが開かないのはなぜ？
ノードの接続先ポートがTCP 443の場合を例にすると、TCP接続の成功から分かるのは、その時点で指定のアドレスとポートが接続を受け付けたことだけです。接続先がプロキシサービスではなく、前段のリバースプロキシや別の入口である可能性もあります。その後のTLSハンドシェイク、プロキシ認証、接続先へのアクセスが失敗することもあります。
- ノードのパラメーターを確認。VMessまたはVLESSの認証情報とトランスポート方式がサーバー側の設定と一致しているか確認します。TLSを有効にしている場合は、サーバー名などのセキュリティ設定も確認してください。測定を通すためだけに証明書の検証を無効にしないでください。
- トランスポート設定を確認。WebSocketを使用している場合、パスやHostの設定が誤っていると、TCP接続の確立後にエラー応答が返ることがあります。接続先の応答が速くても、これらの設定が正しいとは限りません。
- サーバー側の外向き通信を確認。ノードが接続を受け付けても、接続先のドメインを名前解決できる、またはアクセスできるとは限りません。外向きネットワークの異常や接続先サイトのアクセス制限によって、実接続テストが失敗することがあります。
- ローカル側の通信経路を確認。内蔵テストは独自にテスト接続を開始することがあります。一方、ブラウザーはシステムプロキシ、アプリごとのプロキシ、またはTUNに依存します。テストに成功しても、ブラウザーが同じ経路を使っているとは限りません。
システムのpingにも同様の制約があります。ICMP応答が制限されていてもTCPサービスは正常に動作することがあり、反対にICMP応答があってもプロキシのポートが開いているとは限りません。トラブルシューティングでは「どのテストに失敗したか」を記録し、ひとまとめに「pingが通らない」としないでください。
実接続遅延：測定先・タイムアウト・経路を確認
実接続遅延は通常、TCPingより多くの処理を測定します。ローカル側のテスト入口、ノードとのハンドシェイク、サーバーからの外向き通信、接続先の名前解決、HTTPまたはHTTPSリクエストなどが関係する場合があります。ただし、どの処理が最終的なミリ秒数に含まれるか、接続を再利用するかは実装によって異なります。2地点間の物理的な往復遅延とそのまま解釈することはできません。
- 測定先URLを統一。ノードを比較するときは同じURLを使い、一方は近いサイト、もう一方は遠いサイトにアクセスする状況を避けます。測定先サイト自体に障害があると、正常なノードが複数同時にタイムアウトすることがあります。
- タイムアウトの上限を統一。たとえば一律5秒に設定します。上限を超えた場合に分かるのは、リクエストが時間内に完了しなかったことだけで、遅延がちょうど5000ミリ秒だったという意味ではありません。
- 応答結果を確認。測定によっては、特定のステータスコードや応答形式が成功条件になります。Webページの内容を受信しても、測定ツールが成功と判定する条件を満たすとは限りません。
- テスト時と通常利用時の経路を区別。複数ノードの一括測定では、候補ごとに一時的なテスト経路を作ることがあります。一方、ブラウザーのアクセスは現在のルーティングルールに従います。この2つの経路が同じだと決めつけないでください。
v2rayNでは、ノード一覧の右クリックメニューから「実接続遅延」といった項目を探します。測定先URLやタイムアウトなどの設定は、「設定」→「パラメーター設定」から確認できます。バージョンによって項目名やメニューの表示が異なる場合があるため、現在の画面を確認してください。v2rayNGでは、メイン画面のメニューから接続テスト関連の項目を探します。設定一覧のテスト結果と、現在のVPNトンネルの状態を混同しないようにしてください。
判断のポイント：測定先だけ失敗するなら、別のサイトで確認
元のノード設定を変えずに、異なるHTTPSサイトを2つ実際に開いてみます。どちらも正常に開く場合は、測定先URLや成功判定を確認してください。1つの測定先がタイムアウトしただけで、プロトコルの設定を何度も変更しないでください。
ダウンロード速度測定：単位と条件を確認
ダウンロード速度測定で分かるのはスループットであり、「より正確な遅延」ではありません。接続確立に少し時間がかかるノードでも、大容量ファイルの転送は速い場合があります。遅延が低いノードでも、サーバー側の帯域制限やピーク時の混雑によってスループットが低くなることがあります。短時間のダウンロードは、接続の立ち上がりや一時的な帯域の影響も受けやすくなります。
以下は仕組みを説明するための例であり、本サイトでの実測値や性能の保証ではありません。あるノードのTCPingが48ミリ秒、実接続遅延が280ミリ秒で、ダウンロードでは4秒間に20 MiBを受信したとします。平均スループットは5 MiB/s、約41.9 Mbpsです。この3つの数値は矛盾しません。
| 条件 | 結果への影響 | 比較時の調整方法 |
|---|---|---|
| 単位 | MB/s、MiB/s、Mbpsでは数値が異なる | 単位を統一する。1 MiB/sは約8.39 Mbps |
| 同時接続数 | 複数接続にすると、合計スループットが高くなることがある | 同じ同時接続数で測定し、単一接続と複数接続の結果を混ぜない |
| 測定時間 | 短すぎると、接続の立ち上がりや瞬間的な帯域の差が大きく出やすい | 候補ノードの測定時間を統一する |
| ローカルネットワーク | Wi-Fiの電波状況や別のダウンロードが帯域を奪い合う | バックグラウンドのダウンロードを停止し、同じネットワークで順に測定する |
| 測定先 | 接続先の帯域制限や回線の違いによって上限が変わる | まず測定先を統一し、実際の用途でも比較する |
速度測定では実際の通信量が発生します。上の例では1回で20 MiBを受信しています。30ノードをそれぞれ1回測定すると、応答データだけで約600 MiBになり、プロトコルの通信量は含まれません。データ通信量に制限のあるプランでは、先に候補を絞り、すべてのサブスクリプションに対して何度もダウンロード速度を測定しないでください。
繰り返し実行できるノード選び：使えるか、安定しているか、最後に速度を確認
同じ端末・同じネットワーク・近い時間帯で比較しましょう。候補を3つ選び、それぞれ実接続テストを5回行い、成功回数と成功した測定値の中央値を記録します。失敗した回数も別に記録し、失敗を除外して見栄えのよい平均値だけを示さないでください。
- ローカル環境を確認。大容量ファイルのダウンロードを停止し、システム時刻を確認して、コアが正常に起動していることを確かめます。サブスクリプションを更新した場合は、選択した設定を再確認し、古くて使えないノードを測定しないようにしてください。
- まずポートへの接続を確認。TCP接続を使うノードにはTCPingを実行し、接続拒否やタイムアウトを記録します。最も遅延が低かった1回だけを残さないでください。
- プロキシ経由のリクエストを検証。測定先URLを変えずに、各ノードで実接続テストを5回行います。成功が2回だけのノードは、最小値が100ミリ秒でも、安定して成功する候補より優先すべきではありません。
- 候補を絞ってダウンロードを確認。残った2～3ノードだけでダウンロード速度を測定し、測定先、同時接続数、測定時間を統一します。複数ノードを同時に測定して、ローカル回線の帯域を奪い合わないようにしてください。
- 実際に使うアプリで確認。普段使うWebサイトを開く、動画を再生する、実際のファイルをダウンロードするなどして確認します。夜間に利用することが多いなら、早朝の結果だけに頼らず、夜間にも再測定してください。
用途別の確認ポイント：Web閲覧と連続ダウンロードを分けて判断
Web閲覧・日常的な操作
- まず実接続テスト5回がすべて成功するか確認
- 成功した測定値の中央値とばらつきを比較
- 実際に対象サイトが開くか確認
動画・大容量ファイル
- まず接続の安定性を確認し、その後にスループットを比較
- ダウンロード先、測定時間、同時接続数を統一
- 実際の利用中に速度が落ち続けないか確認
一度だけ記録された最低遅延は、1つの測定結果にすぎません。メインで使うノードは、成功率、ばらつき、実際の用途での使い勝手を総合して選びましょう。
ブラウザーで接続できない場合：ローカルプロキシを明示して確認
内蔵テストは成功するのにブラウザーで開けない場合は、コマンドラインでプロキシの入口を明示して、ノード自体の問題とアプリがプロキシを使っていない問題を切り分けられます。まずクライアントの設定で、ローカルの待ち受けアドレス、ポート、受け入れ方式を確認してください。以下では、有効なHTTPまたは混合プロキシの入口が127.0.0.1:10808であると仮定します。このポートは操作例であり、すべてのバージョンの既定値ではありません。
curl --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 --output response.html --write-out "HTTP=%{http_code} total=%{time_total}s\n" https://v2rayalpha.com/Windowsではcurlが別のコマンドとして解釈される環境があるため、curl.exeを使用できます。この例では、応答を現在のディレクトリのresponse.htmlに保存し、ステータスコードと合計所要時間を表示します。リクエストが完了するか確認するためのもので、最大ダウンロード帯域を測定するものではありません。
- ローカルポートへの接続にすぐ失敗する：クライアントが起動しているか、待ち受けポートが一致しているか、入口がHTTPプロキシに対応しているか確認してください。
- ローカル入口には接続できるが、リクエストがタイムアウトする：コアのログを確認し、ノードへの接続、TLS、接続先へのアクセスを調べてください。ブラウザーの設定だけを変更しないでください。
- コマンドは成功するがブラウザーでは失敗する：v2rayNのシステムプロキシの状態、ブラウザー独自のプロキシ設定、ルーティングルールによって両者の通信経路が異なっていないか確認してください。
- 403などのステータスコードが返る：HTTP応答を受信したことを示しますが、目的のアクセスに成功したとは限りません。接続先サイトの制限か、中間経路からの応答かを確認してください。
速度測定でよくある疑問：タイムアウト・ばらつき・速度は出るのに快適でない場合
TCPingは数十ミリ秒なのに、実接続では数百ミリ秒かかるのはなぜ？
測定範囲が異なるためです。測定先URLを固定して5回連続で測定してください。実接続が毎回成功し、ばらつきも小さい場合、差はプロキシのハンドシェイク、ノードから接続先サイトまでの経路、サイトの応答に起因する可能性があります。差があるだけでノードの故障と判断しないでください。
すべてのノードで実接続がタイムアウトします。サブスクリプションを再インポートすべきですか？
まず共通する要因を確認してください。ローカルネットワーク、コアの起動ログ、システム時刻、測定先URLを調べます。別の測定先でも確認し、使用可能と分かっている設定で実際にアクセスしてみてください。サブスクリプションの設定が古い、またはパラメーターが変更されたと確認できた場合に、更新してください。
ダウンロード速度は速いのに、動画が止まるのはなぜ？
速度測定用ファイルと動画は、異なるネットワークから配信されていることがあります。動画が止まる時間帯に再測定し、動画アプリがプロキシを経由しているか、ルールによって直接接続になっていないか確認してください。最初の数秒のピーク値だけでなく、スループットが安定して続くかも確認しましょう。
Androidでのテストは成功するのに、ほかのアプリから接続できない場合は？
v2rayNGで接続が開始され、VPNの許可が完了していることを確認し、アプリごとのプロキシ設定で対象アプリが除外されていないか調べてください。画面ロック後にだけ使えなくなる場合は、システムのバッテリー最適化やバックグラウンド実行の制限を確認します。バックグラウンドで停止した状態を、ノードの遅延問題と混同しないでください。
まとめ：単一の数値で順位付けせず、失敗した段階から確認
ポートに接続できない場合はアドレスとポートを確認し、プロキシリクエストが失敗する場合は設定とログを調べます。帯域を重点的に比較するのは、連続転送が不足している場合です。最低遅延を追い続けるより、実際の用途で確認した予備ノードを1つ確保しておくほうが実用的です。