TCPingはサーバーのポートを簡易チェックするのに適し、実接続遅延はプロキシ経由の通信確認、ダウンロード速度は継続的な転送能力の評価に向いています。ノードをインポートしたものの、どの数値を基準に並べればよいかわからない方向けに、まず測定範囲を整理します。同じ接続先・ネットワークで複数回測定して普段使いのノードを選び、「遅延は低いのにウェブページが開かない」原因も確認します。
1. 3種類のテストは測定する通信経路が異なる
v2rayNGはXrayコアでプロキシ接続を処理しますが、一覧にあるTCPingは通常、設定されたサーバーのアドレスとポートにTCP接続を試みるだけです。システムのICMP Pingとは異なり、VMessやVLESSのプロキシ認証も行いません。サーバーにドメイン名を設定している場合は、テスト前に名前解決も必要です。名前解決にかかる時間が表示値に含まれるかは実装によって異なるため、純粋な回線の往復時間とは限りません。
TCPing：サーバーポートへの到達性
スマートフォンからノードのポートにTCP接続できるかを確認します。たとえばノードのポートがTCP 443で、測定値が45 msでも、そのポートへの接続が速いことを示すだけです。UUID、TLSのserverName、Realityのパラメーターが正しいとは限りません。
適した用途：候補の一括チェック、アドレスやポートへの到達確認。
実接続遅延：プロキシ経由でテスト先にアクセス
おすすめテスト対象の設定を使ってテストURLにリクエストを送り、プロキシのハンドシェイク、接続先ドメインの名前解決、TLS接続、HTTP応答などにかかる時間を測ります。ポートの疎通確認より普段のウェブ閲覧に近い一方、結果が示すのはテスト先への接続だけです。
適した用途：設定が機能するかの確認、普段の閲覧に使うノード候補の選定。
ダウンロード速度：継続的なデータ転送能力
プロキシ経由でデータを継続してダウンロードし、単位時間あたりの受信量を測ります。結果はノード側の速度制限、混雑、接続先サーバーの帯域、測定時間などに左右され、遅延テスト1回の結果からは推測できません。
適した用途：動画再生、大容量ファイルのダウンロード、夜間の混雑時の速度確認。
まずは実接続遅延を確認するのがおすすめですが、ミリ秒の値が最も小さいノードを常に選べばよいわけではありません。テストURLと実際に使うサイトが別の地域にあれば、テストサイトには速くても、目的のサイトへの通信は遠回りになることがあります。UDPを主に使う用途では、TCPingや通常のHTTPSダウンロードでUDP転送の性能は確認できません。
2. v2rayNGで順番にテストする
既存の設定はそのままにし、測定しながらルーティング、DNS、通信方式のパラメーターを変更するのは避けてください。v2rayNGはバージョンによってメニュー名が多少異なる場合があります。ここでは一般的なTCPingと実接続テストの項目を例に説明します。同じ名前の項目が見つからない場合は機能で判断し、一覧下部の現在の接続テストを全ノード対象のテストと混同しないようにしてください。
- ほかの通信を止める。アプリの更新、クラウドストレージの同期、動画のダウンロードを停止し、同じWi-Fiまたは同じモバイル回線を使います。時刻とネットワークの種類を記録し、測定の途中で接続先を切り替えないでください。
- ポートをまとめて確認する。メイン画面右上の「⋮」を開き、「すべての設定をTCPingでテスト」または該当するTCPing項目を選択します。失敗したノードに印を付け、成功したノードは残しておきます。すぐに設定を削除する必要はありません。
- プロキシ経由の通信をまとめて確認する。同じメニューから「すべての設定を実接続テスト」または該当する実接続テスト項目を選びます。バージョンによっては「設定」に「テストURL」や「接続テストURL」があります。設定値を記録し、比較中はURLを変更しないでください。
- 現在の接続を再確認する。候補のノードを選び、右下の接続ボタンをタップしてAndroidのVPN接続を許可します。画面下部に接続状態のテスト機能がある場合は実行し、現在の設定でリクエストが完了するか確認してください。
- 転送速度は候補ノードだけ測る。プロキシ経由で通信していることを確認したブラウザーで、固定の速度測定サイトを開くか、十分な帯域がある同じテストファイルをダウンロードします。端末側の帯域を取り合わないよう、複数ノードを同時に測定しないでください。
一括実接続テストと現在の接続テストでは、実行方法が異なる場合があります。特に、クライアントがテスト用のコアを一時的に起動する場合は注意が必要です。比較するときは「一括テスト」か「現在の接続テスト」かも記録し、別々の方法で得た数値を同じ測定結果として扱わないでください。
3. 繰り返し測定して低遅延と高スループットを見分ける
以下は数値の読み方を説明するためのサンプルであり、本サイトでの実測値でも、特定のサービスの速度を保証するものでもありません。3つのノードで同じテストURL、同じダウンロードファイル、同じネットワークを使い、実接続を各3回測定、ダウンロード速度は安定した区間の平均値とします。
| 候補ノード | TCPing | 実接続の3回測定 | ダウンロード平均速度 | 判定 |
|---|---|---|---|---|
| A | 38 ms | 310 / 920 / 460 ms | 1.2 MB/s | ポート接続は速いが、リクエスト全体のばらつきが大きい |
| B | 82 ms | 205 / 218 / 211 ms | 8.0 MB/s | リクエストが安定しており、普段使いの候補に適している |
| C | 65 ms | 3回ともタイムアウト | 未測定 | まず設定を確認し、転送速度の比較対象から外す |
AはTCPingの値が最も小さいものの、実接続3回の中央値は460 msでした。Bの中央値は211 msで、3回の値もほぼ揃っています。この場合はBを先に試すのが妥当です。3回の測定は手早い候補選びには使えますが、信頼できるパケット損失率を算出できる回数ではありません。タイムアウト1回を回線のパケット損失と決めつけることもできません。
MB/sとMbpsでは数値が8倍異なり、MiB/sはバイトの数え方も異なります。速度測定サイトで64 Mbps、ダウンロードアプリで約8 MB/sと表示されても、通常は矛盾しません。平均8 MB/sで15秒間測定すると約120 MBのデータを消費します。複数回測る前に、モバイルデータの通信量に注意してください。
結論：繰り返し失敗するノードを除外し、中央値と安定時のダウンロード速度を比較する
Aは38 msでも、すぐに普段使いのノードに設定しないでください。まずCの失敗原因を確認し、AとBを実際の用途でそれぞれ試します。Bが安定して使えるなら、Bをメイン、Aを予備として残します。
4. TCPingは低いのに、実接続がタイムアウトするのはなぜ？
ポートに接続できても、確認できるのは接続経路の入口の一部だけです。プロキシ認証の失敗、通信方式のパラメーター誤り、ノードからテスト先への到達不能は、いずれもTCP接続の確立後に起こり得ます。次の順で確認すれば、設定の問題をサーバーの帯域不足と取り違えにくくなります。
「TCPingは40 msなのに、実接続がずっとタイムアウトするのはなぜ？」
ノードの編集画面を開き、アドレス、ポート、UUID、通信設定を確認します。VLESS + Realityでは公開鍵、shortId、serverNameも確認してください。WebSocketではpathとHostを確認します。次にメイン画面の「ログ」で接続エラーやハンドシェイクエラーを確認し、証明書の検証を無効にして問題を隠さないでください。
「実接続が-1と表示されるのは、遅延が大きいから？」
負の値は通常、遅延ではなく失敗を示します。具体的な表示の意味は使用中のバージョンで確認してください。同じノードを再測定し、ログに名前解決の失敗、接続タイムアウト、TLSエラーがないか確認します。すべてのノードで同時に失敗する場合は、まずテストURL、ローカルネットワーク、端末の日時を確認してください。
「実接続は良好なのに、特定のサイトだけ遅いのはなぜ？」
同じブラウザーで異なる2つの接続先を試し、遅いのが特定のサイトだけか確認します。次に、そのドメインへの通信がプロキシ経由になっているか、DNSが適切なIPアドレスを返しているか確認してください。実接続テストで検証できるのはテストURLだけです。すべてのサイトの名前解決や出口までの経路が正常とは限りません。
「ダウンロードは最初だけ速く、その後ずっと遅くなるのはなぜ？」
測定を少なくとも15秒続け、最高速度ではなく安定した区間を確認します。ほかの通信を停止して同じファイルを再測定してください。それでも速度が落ち続ける場合は、別のノードと比較します。一時的なバースト速度、サーバー側の速度制限、回線の混雑などで同じような変化が起こるため、1回の測定だけでは原因を特定できません。
UDP通信を主に使う設定では、TCPingに失敗しても、それだけでノードが使えないとは判断できません。同じアドレスとポートでTCPサービスを提供していない可能性があるためです。まずノードの通信方式を確認し、クライアントが対応する実接続テスト、または実際の用途で検証してください。
5. ウェブ閲覧とファイルのダウンロードでは、ノード選びの順番が異なる
ウェブページは小さなリクエストを何度も送るため、接続確立の時間、名前解決の時間、遅延のばらつきの影響を受けやすくなります。大容量ファイルのダウンロードでは、安定したスループットが重要です。用途を問わず「遅延の小さい順」のランキングに頼ったり、プロトコル名から速度を決めつけたりしないでください。
おすすめの選び方：用途に合わせてメインと予備を決める
ウェブ閲覧、メッセージ、APIリクエスト
- 実接続が3回連続で成功することを確認する。
- 中央値を比較し、最大値が大きく外れていないかも確認する。
- 普段使うサイトを実際に開き、初回表示と連続リクエストを確認する。
- 接続先のサイトに問題が起きたときに備え、出口の異なるノードを予備として残す。
動画、大容量ファイルのダウンロード
- まず実接続を確認してから、継続的なダウンロードを測定する。
- 同じファイルを同じ時間ダウンロードしたときの平均速度を比較する。
- 普段利用する夜間にも測定し、空いている時間帯だけで判断しない。
- 最高速度だけでなく、再生の途切れや接続切断がないか確認する。
メインノードは実際の用途に合わせて選び、予備ノードは使える状態を保つ。ネットワークを切り替えたら再検証し、以前の順位をそのまま使わないでください。
デスクトップ版のv2rayNでも同じ手順で判断できます。ただし、クライアントによってテスト先、同時接続数、タイムアウトのしきい値、計測範囲が異なる場合があります。スマートフォンで200 ms、パソコンで150 msと表示されても、パソコンで使うノードのほうが速いとは限りません。条件を揃えてから結果を比較してください。
6. 後から確認できる速度測定記録を残す
緑色のミリ秒表示だけをスクリーンショットに残しても、ネットワークを切り替えた後に結果が変わった理由は判断しにくいものです。記録は簡単なもので構いませんが、接続ネットワーク、時刻、テスト方法、接続先を含めてください。次の項目を残しておけば、日常的な再確認に使えるほか、夜間の混雑や特定の接続先だけの問題を調べやすくなります。
- 環境：Wi-Fiかモバイルデータか、測定した日付と時刻を記録し、充電中か、省電力機能の制限が有効かも記入します。
- クライアント：「バージョン情報」で実際のバージョン番号を記録し、v2rayNGかv2rayNかを明記します。アップデート後は基準値を取り直してください。
- 測定条件：テストURL、ダウンロード先、測定時間のほか、アプリごとのプロキシ設定やルーティングモードに変更があったか記録します。
- 結果：TCPing、実接続3回の各測定値、失敗回数、安定区間のダウンロード速度を記録し、単位を統一します。
- 実際の利用確認：よく使うサイトが開くか、動画が途切れず再生できるかを記録してから、メインノードに設定するか決めます。
最終的な選定手順は、ポートの初回チェック → 実接続の確認 → 繰り返し測定 → 必要に応じたダウンロード速度の測定 → 実際の用途で再確認、の順にできます。無駄な一括ダウンロードを減らし、「設定が機能していない」「テスト先に問題がある」「転送速度が足りない」を切り分けられます。
クライアントのインストールと初回接続
OSに合わせてv2rayNGまたはv2rayNを選びます。初回利用時は設定のインポートと接続を済ませてから、この記事の手順でノードをテストしてください。