v2rayNの速度測定を解説：Tcping・接続遅延・ダウンロード速度の違い

3種類の速度測定：それぞれ測る範囲が異なる

まず結論として、3種類の結果は相互に置き換えられません。Tcpingの値が低くてもプロキシ認証の成功はわからず、接続遅延が低くても大容量ファイルのダウンロードが速いとは限りません。ダウンロード速度が高くても、Webページが毎回すぐ表示されるとは限りません。それぞれ接続確立、リクエスト全体、継続的なデータ転送を測定しており、単位も測定範囲も異なります。

v2rayNはGUIクライアントで、測定処理はクライアントが制御し、一部の測定では選択中のコアを呼び出します。XrayとV2Flyでは、対応するプロトコルや設定項目が完全には一致しません。測定前に、現在のコアでノードを正しく読み込めることを確認しましょう。ポートに接続できることを、プロトコルの互換性確認の代わりにはできません。

Tcping：接続を確立するだけで、プロキシ全体は検証しない

Tcpingは一般的なICMP Pingとは異なります。通常はTCP接続の確立にかかった時間を測り、ノードのサーバーアドレスとポートを確認します。たとえばノードの設定ポートが443なら、測定対象はそのポートであり、任意のWebサイトのポートではありません。ノードがドメイン名で指定されている場合は、先に名前解決も行います。その時間が表示値に含まれるかどうかは実装によって異なります。

TCP接続を確立できても、UUID、パスワード、TLSのサービス名などの設定が誤っていれば、プロキシサーバーに接続を拒否されることがあります。リバースプロキシやCDNを経由するノードでは、Tcpingで確認できるのはフロントエンドの入口までで、バックエンドのプロキシが正常とは限りません。入口がローカルに近くても、出口から接続先のWebサイトまで近いとは限りません。

• 数値が表示される：測定時に対象のTCPポートへ接続できたことを示します。VMess、VLESS、Trojanのプロキシセッションが確立したという意味ではありません。
• タイムアウト：ポートがフィルタリングされている、アドレスが無効、ネットワーク経路に問題がある、サーバーが応答しないなどの可能性があります。ログやほかの測定結果とあわせて判断してください。
• 対象外の場合：実際の通信がそのTCPポートを経由しないなら、Tcpingでは実際の通信経路を確認できません。測定に失敗しても、ノードが使えないとは限りません。
• 値のばらつきが大きい：まず同じネットワークで何度か測定してください。一度の接続遅延を、恒常的な障害と決めつけないようにしましょう。

接続遅延：テスト先までの経路も結果に影響する

接続遅延は、「このノードを経由して指定したリクエストを完了するまでの時間」に近い値です。通常は、ローカルからプロキシの入口への接続、プロキシプロトコルのネゴシエーション、ノードの出口からテスト先へのアクセス、レスポンスのローカルへの返送が含まれます。設定や実装によっては、名前解決、TLSハンドシェイク、コネクションの再利用、リダイレクトも関係します。ノードサーバーまでの距離だけを測るものではありません。

「接続」遅延といっても、Webページの読み込み全体を再現するわけではありません。ページには複数のドメイン、スクリプト、画像が含まれることがありますが、遅延測定は通常、小さなリクエストを1回送るだけです。レスポンスヘッダー、特定のステータスコード、リクエスト完了など、完了と判定する条件はバージョンによって異なる場合があります。結果を比較するときは、テスト先とクライアントのバージョンをそろえましょう。

テスト先が204を返す場合、通常はレスポンス本文がなく、小さなリクエストの確認に適しています。ただし、すべてのv2rayNのバージョンがこのステータスだけを成功と判定するとは限りません。クライアントが対応するテスト先と成功判定の条件を使ってください。システムプロキシを有効にするだけでは、内蔵速度測定が成功するとは限りません。内蔵テストは専用の設定を使い、普段のルーティング設定をそのまま使うとは限らないためです。

ダウンロード速度：転送速度と遅延は分けて見る

ダウンロード速度では、最初のレスポンスが届くまでの時間ではなく、一定時間にどれだけのデータを読み込めたかを測ります。結果には、ローカル回線の帯域、Wi-Fi、プロキシ出口の容量、サーバー側の速度制限、輻輳制御、測定時間、同時接続数などが影響します。接続遅延とダウンロード速度で異なるテスト先を使う場合、順位が異なるのは自然です。

まず単位を確認しましょう。MB/sは1秒あたりのメガバイト、Mbpsは1秒あたりのメガビットです。10進法で換算すると、8 MB/s × 8 = 64 Mbpsです。実際の通信ではプロトコルのオーバーヘッドも発生します。以下の数値は説明用の例であり、このサイトでの実測値でも、特定のノードサービスの性能を示すものでもありません。

この結果は矛盾していません。入口への接続は速くても、リクエスト全体にはより多くの処理が必要な場合があります。一方、接続後の継続的な転送速度は良好なこともあります。たとえばノードBの接続遅延が180 ms、ダウンロード速度が2 MB/sなら、小さなリクエストにはB、継続的なデータ転送にはAが向いている可能性があります。最後に、実際に使うアプリでも確認してください。

速度測定の手順：一次確認から再チェックへ

v2rayNのノード一覧で対象を選び、右クリックメニューから測定項目を実行します。一般的な項目にはTcping遅延、接続遅延、サーバー速度がありますが、デスクトップ版のバージョンによって表示名が異なる場合があります。測定の設定は「設定」→「パラメータ設定」から確認できます。項目の場所は現在の画面に従ってください。見慣れない設定をコピーせず、まず現在の値を記録しましょう。

1. 条件をそろえる：バックグラウンドのダウンロードを一時停止し、同じローカルネットワークを使います。クライアントとコアのバージョン、テスト先、測定時間帯を記録してください。Wi-Fiと有線LANの結果をそのまま比較しないようにしましょう。
2. 入口を一次確認する：Tcpingを実行し、接続できる項目を残します。TCPでの一次確認が適さない通信方式では、プロキシ経由のリクエストを使って確認してください。
3. 接続性を再確認する：候補ごとに接続遅延を3回測定し、各回の間隔を約10秒空けます。失敗回数を記録し、成功した値の中央値を使い、最良の1回だけで判断しないようにしましょう。
4. ダウンロード測定の対象を絞る：候補を2〜3個に限定して、1つずつ測定します。画面で測定時間を設定できる場合は15秒に統一してください。設定できない場合は初期値のまま測定し、実際の時間を記録します。
5. 実際のアプリで確認する：候補のノードを選択して、普段使うWebサイトを開き、想定した経路で通信できるか確認します。速度測定には成功するのにアプリでは失敗する場合、ルーティング、システムプロキシ、TUNによる通信の取り込みを重点的に確認してください。

たとえば接続遅延が3回で180、195、420 msなら、中央値は195 msです。別のノードが160 ms、タイムアウト、タイムアウトなら、成功した1回だけを見て優れていると判断できません。タイムアウトは接続性を示す情報として別途記録し、無視したり、安易にゼロへ換算したりしないでください。

測定結果に異常があるとき：どの段階で失敗したかを特定する

遅延欄の負の値、空欄、タイムアウトは、通常は失敗を示す表示であり、「負の遅延」ではありません。具体的な意味はクライアントのバージョンによって異なるため、ログも確認してください。切り分けでは一度に変更する条件を1つに絞り、ノード、テスト先、DNSのどれが影響したか判別できるようにします。

測定記録を保存して、次回の比較に役立てる

ノード名が同じでも、入口、出口、バックエンドの経路が常に変わらないとは限りません。サブスクリプションを更新した後は、普段使う候補を簡単に再確認してください。記録にはサブスクリプションURLや認証情報を含めず、測定条件と結果だけを残しましょう。

• 環境：OS、v2rayNとコアのバージョン、ローカルネットワークの種類、測定日時。
• 条件：テスト先、測定時間、1つずつ測定したかどうか、そのときのプロキシとルーティングの設定。
• 結果：Tcpingの値、接続遅延3回分の数値と失敗回数、ダウンロードの平均速度と単位。
• アプリでの確認：普段使うWebサイトに接続できるか、継続的な転送が安定しているか、実際の通信経路が想定どおりか。

通信経路を詳しく確認するには、DNS設定の説明とTUNモードの説明をご覧ください。速度測定ではなくサブスクリプションの更新時に問題が起きる場合は、サブスクリプション更新のトラブル対処をご確認ください。まず問題が発生している段階を特定してから、設定を変更しましょう。