TCPingはノードの入口とTCP接続が確立できるかを確認します。接続テストはプロキシ経由で指定先にアクセスできるかを検証し、ダウンロード速度測定は継続的な転送性能を確認します。v2rayN、v2rayNG、v2flyNGの利用者向けに、測定範囲、操作方法、結果の記録、トラブルの切り分けを順に解説。接続性を確認してから応答時間を比べ、最後に転送速度を測る手順を紹介します。
3種類の速度測定で確認できる通信経路
クライアント一覧のミリ秒値を比較できるのは、測定方法が同じ場合です。TCP接続が成功しても、VMessやVLESSの認証が成功したとは限りません。テストページの応答が速くても、大容量ファイルを安定して高速転送できるとは限りません。まずメニューで実行する測定の種類を確認してから、結果を読み取りましょう。
TCPing：ノードへの接続を確認
ノードのアドレスとポートにTCP接続し、通常は接続確立までの時間を測ります。システムのpingで使うICMPとは異なり、プロキシプロトコルやアカウント情報、ノードの出口までは検証しません。
用途：入口のポートに接続できない設定をまとめて除外し、次の測定対象を絞り込む。
接続テスト：プロキシ経由のリクエストを確認
おすすめ測定対象の設定とコアを使って、指定先にリクエストを送信します。所要時間にはノードへの接続、プロキシのハンドシェイク、接続先の名前解決や応答が含まれる場合があります。計測範囲はクライアントの実装によって異なるため、単純にネットワークの往復時間と同じとはいえません。
用途：Webサイトへのアクセスに使うノードを選び、プロトコル設定とリクエスト経路が機能するか確認する。
ダウンロード速度測定：継続的な転送性能を確認
測定対象の設定を経由してテストデータをダウンロードし、転送量と所要時間から速度を算出します。ダウンロード元、回線の混雑、サーバー側の速度制限、測定時間、端末の処理能力が結果に影響します。
用途：利用可能なノードを絞ったうえで、大容量ファイルの転送性能を比較する。
たとえばノードの入口にTCP 443番ポートを使う場合、TCPingの成功が示すのは、その時点でアドレスの443番ポートに接続できたことだけです。UUIDが間違っていても、WebSocketのパスが一致しなくても、入口の応答時間が低く表示されることがあります。TCP以外の転送方式を使う設定では、TCPingの失敗だけで設定全体が使えないと判断することもできません。
v2rayNとAndroidクライアントでの速度測定
まずサブスクリプションを更新し、少数の設定を選んで測定します。メニュー名はバージョンや画面によって多少異なります。以下では一般的な中国語UIの表記を例にしていますが、実際の画面にある「Tcping」「接続テスト」「速度」などの操作名を確認してください。すべてのクライアントで同じ測定機能が使えるとは限りません。
- v2rayN：設定を選択。サーバー一覧でCtrlキーを押しながら3～5個のノードを選択します。右クリックメニューから「サーバー遅延をテスト（Tcping）」を実行して結果を確認し、同じノードに対して「サーバーの接続遅延をテスト」を実行します。すべての測定が終わるまで待ちましょう。
- v2rayN：速度を比較。接続テストに成功した候補を2～3個残し、右クリックして「サーバー速度をテスト」を実行します。この間は大容量通信を伴うほかの作業を避け、数百個のノードを一度にダウンロード測定にかけないでください。
- v2rayN：測定条件をそろえる。「設定」→「パラメーター設定」を開き、使用中のバージョンに測定関連の項目があれば、遅延テスト先、ダウンロードテスト先、タイムアウト時間を確認します。項目がない場合は、そのバージョンの既定の動作を記録してください。設定を探すためにノードのプロトコルを変更する必要はありません。
- v2rayNG：複数設定の接続テスト。設定一覧の右上にあるメニューを開き、「すべての設定の接続テスト」を選びます。現在のノードを確認するには、設定を選択してサービスを起動し、AndroidのVPN接続を許可してから、画面下部の接続状態エリアをタップして接続テストを実行します。
- v2flyNG：実際のメニューに従って測定。設定一覧のメニューで、使用中のバージョンにある接続テスト機能を探し、測定の種類を記録します。事前に設定がV2Flyコアの対応範囲に含まれることを確認してください。Xray固有の機能を使うVLESS + REALITY設定は、対応するクライアントとコアでテストします。
条件をそろえて遅延とばらつきを比較
以下は計算方法を説明するための仮の記録で、実際のノード測定ランキングではありません。同じ端末、同じWi-Fi、同じ測定先でノードAを5回測定したとします。TCPingの結果は31、34、35、37、52ミリ秒、接続テストの結果は168、175、182、194、620ミリ秒です。
5つの結果を小さい順に並べ、3番目の値を中央値とします。単発の最小値より、今回の測定における典型的な値として参考になります。ただし、5回では長期的な安定性を判断できません。620ミリ秒という値は今回の測定で大きなばらつきが出たことを示します。すぐに長期的な不安定さと決めつけず、追加で測定しましょう。
| 記録項目 | ノードA | ノードB | 判断方法 |
|---|---|---|---|
| TCPingの中央値 | 35 ms | 68 ms | 入口への接続確立時間だけを比較 |
| 接続テストの中央値 | 182 ms | 146 ms | この測定先への応答はBのほうが速い |
| 接続テストの成功回数 | 5 / 5 | 5 / 5 | 今回の測定では両方ともリクエスト成功 |
| ダウンロード平均速度 | 8 MB/s | 5 MB/s | このダウンロード元への転送速度はAのほうが高い |
結論：用途に合わせて候補を2つ残す
この仮の結果なら、Webページの操作にはまずノードB、大容量ファイルの転送にはまずノードAを試せます。それぞれ実際の接続先を開いて確認し、普段利用する時間帯にも再測定してください。入口への遅延が最も低いノードを、すべての用途で自動的に第一候補にしないようにしましょう。
タイムアウトは「5回中4回成功、1回タイムアウト」のように別途記録します。タイムアウトを0ミリ秒として扱ったり、失敗回数を伏せて成功分だけの平均を出したりするのは避けてください。アプリケーション層のタイムアウトは、名前解決、ハンドシェイク、接続先の応答などが原因になり得るため、ネットワーク層のパケット損失率にそのまま換算できません。
ダウンロード速度の単位・時間・通信量
回線速度の公称値は通常Mbpsで、クライアントではMB/sやMiB/sと表示されることがあります。10進単位で換算すると、8 MB/sは約64 Mbps、8 MiB/sは約67.1 Mbpsです。ツール間で比較する前に単位を確認してください。数値が同じでも速度が同じとは限りません。
- 測定元を固定。同じノードでもダウンロード元が違えば結果は大きく変わります。配信元の同時接続数制限、コンテンツのキャッシュ、ノードの出口から配信元までの経路が転送速度に影響します。
- 測定時間を固定。ツールで設定できる場合は、測定時間を10～15秒にそろえ、平均速度と後半の速度を記録します。開始直後のピークだけを見ると、一時的なキャッシュやバースト帯域を継続速度と誤認することがあります。
- 通信量を見積もる。8 MB/sで15秒間ダウンロードすると、1ノードあたりのデータ通信量は約120 MBです。5ノードを連続で測定すると約600 MBになり、実際にはプロトコルのオーバーヘッドも加わります。
- 同時測定を避ける。1台ずつ測定すると、各ノードの性能を比較しやすくなります。複数ノードの同時ダウンロードは端末側の回線帯域を取り合うため、共有帯域で競合した結果が測定されます。
遅延は低いのにWebページが開かない：失敗箇所を切り分ける
まず失敗時のログを保存し、設定を1つだけ変更して再試行します。DNS、ルーティングモード、転送プロトコル、測定先を一度に変更すると、成功しても失敗しても原因を特定できません。ログにサーバーアドレス、アカウント識別情報、サブスクリプション情報が含まれる場合は、共有前に該当箇所を伏せてください。
TCPingは30ミリ秒なのに、接続テストが毎回タイムアウトするのはなぜ？
ノードの編集画面を開き、提供元の設定情報と照らし合わせて、アドレス、ポート、UUID、転送方式、安全設定を確認します。WebSocketではパスとHost、TLSではサーバー名も確認してください。入口に接続できても、これらの設定が正しいとは限りません。設定ミスを隠すために証明書の検証を無効にしないでください。
接続テストは成功するのに、ブラウザーでWebページが開かないのはなぜ？
まず、現在選択中のノードが測定したノードと同じか確認します。デスクトップではシステムプロキシまたはTUNが想定どおり有効か、ブラウザー独自のプロキシ設定がないか確認してください。AndroidではVPNサービスが起動しているか、アプリごとのルールで対象アプリが除外されていないかを確認します。その後、実際の接続先にアクセスし、ログのアウトバウンドとエラーを確認してください。
すべてのノードがタイムアウトするのは、サブスクリプションが無効になったから？
まずローカルネットワークに接続できるか確認し、コアが正常に起動しているか、ログにエラーがないか調べます。すべてのノードで同じ測定先だけが失敗する場合は、「設定」→「パラメーター設定」に速度測定先の項目があれば、別の確認可能な接続先に変えて再測定してください。測定先の問題とアカウントの無効化は、それぞれ別に検証します。
速度測定は速いのに夜はダウンロードが遅い。プロトコルを変えるべき？
まず夜間に同じダウンロード元、同じ測定時間で再測定し、ほかのダウンロードは停止します。複数のノードが同時に遅くなるなら、ローカルネットワークや共有帯域を確認してください。特定のノードだけ遅い場合は、ほかのノードと比較します。VMessやVLESSに変更しても、出口の混雑やサーバー側の速度制限が自動的に解消するわけではありません。
「一部のドメインだけ失敗する」場合は、DNSとルーティングも確認します。測定ツールは候補ごとに独立したテスト用アウトバウンドを作ることがありますが、ブラウザーの通信は現在のルーティングルールに従います。両者がまったく同じ経路を通るとは限りません。ルーティングと分流の説明およびDNS設定の説明を確認し、対象へのリクエストが実際にどこへ向かうかを確かめてください。
繰り返し使えるノード選定手順を作る
初回の選定と日常的な再測定を分けます。初回は利用可能な設定を少数に絞り、日常の再測定では普段使う時間帯にも適切な状態かを確認します。わずか1ミリ秒の差を追いかけて、サブスクリプション全体に高負荷の測定を何度も行う必要はありません。
測定手順：初回選定と日常的な再測定
初回インポート後
- サブスクリプションを更新し、設定項目がそろっているか確認する。
- TCPingを使い、対象となるTCPの入口を絞り込む。
- 候補を3～5個選び、それぞれ接続テストを5回行う。
- 候補のうち2つを選び、1つずつ短時間のダウンロード測定を行う。
普段使う前
- 端末、ネットワーク、測定先を固定する。
- 成功回数、中央値、大きなばらつきを記録する。
- 普段利用する夜の時間帯に、同じノードを再測定する。
- 実際のWebサイトやファイルを開き、用途に使えるか確認する。
まずリクエストが成功するか確認し、次に応答時間を比較します。継続的な転送が必要な場合に限り、ダウンロード速度も測定してください。
記録には測定日時、接続ネットワーク、クライアント名、コア、測定の種類、測定先を残してください。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。v2rayNでは選択したコアも記録しましょう。プロトコルやコアを比較する際、ノードの出口、測定先、時間帯まで変わっていると、差のすべてをコアの違いに結び付けることはできません。
- まず成功率を確認。頻繁に失敗するノードは、ときどき遅延が低くても、すぐにメイン用途として使うのは適切ではありません。
- 次に応答時間とばらつきを確認。接続テストを複数回行い、実際の接続先に合った候補を選びます。
- 最後に転送速度を確認。実際のダウンロード用途に合わせて継続速度を比較し、検証済みの予備設定も残しておきます。