V2Rayの遅延測定方法|TCPing・実接続遅延・ダウンロード速度を比較

TCPing・実接続遅延・ダウンロード速度の測定範囲を解説。TCPingが低くてもWebサイトを開けない理由と、v2rayN・v2rayNGでサーバーを選ぶ際に見るべき結果がわかります。

この記事のポイント

TCPingでわかるのはサーバーとのTCPハンドシェイク時間、実接続遅延ではノード経由の実際のリクエスト、ダウンロードテストでは継続的な転送能力を測定します。普段使いのノード選びでは、実接続が成功し安定しているかを優先し、大容量ファイルを転送する場合はダウンロード速度も比較しましょう。v2rayN・v2rayNGでの測定手順と、遅延が低いのにWebサイトを開けない場合の確認方法を紹介します。

3種類の測定値が示すもの

遅延とは、操作を開始してから結果が返るまでにかかる時間です。回線に固有の固定値ではありません。測定方法や接続先、接続を再利用するかどうかで結果は変わります。クライアントの画面に表示されたミリ秒数をそのまま比べると、異なる処理を比較している場合があります。

TCPing

ノードサーバーのアドレスとポートにTCP接続し、主にその区間のハンドシェイク時間を測ります。接続に成功しても、プロキシの認証や接続先Webサイトへのアクセスが成功したとは限りません。

用途:ポートに接続できないノードや、ハンドシェイクが明らかに遅いノードをまとめて除外

実接続遅延

おすすめ

クライアントからノード経由で測定先にリクエストを送ります。プロキシ接続の確立や接続先へのリクエストなど、より多くの処理を測定しますが、測定先やタイムアウト設定にも左右されます。

用途:普段使いのノード選び。まずリクエストが完了することを確認

ダウンロード速度

テスト用ファイルを継続して取得し、一定時間内に受信したデータ量を測ります。ファイルサーバーや端末の性能、同時に行う通信の影響も受けます。

用途:大容量ファイルのダウンロードや継続的なデータ転送の比較

TCPingは、すべての通信方式に使える汎用的な遅延測定ではありません。ノードへの接続にTCP以外の方式を使う場合、TCPポートへのハンドシェイク時間を実際の接続時間の代わりにはできません。また、実接続テストも現在の測定先へのリクエストを示すものです。接続先のDNSや経路、応答速度が変われば、測定値も変化します。

結論:測定対象を確認してから数値を比較

実接続遅延は、同じクライアント・測定先・時間帯の条件で比較しましょう。TCPingは疎通確認の一次チェックに使い、Webサイトを必ず開ける根拠にはしないでください。

TCPingは低いのにWebサイトを開けない理由

たとえばTCPingが40 msなら、その時点でサーバーのポートまでのTCPハンドシェイクが速かったことを示します。ノードのVMessまたはVLESSの設定がサーバー側と一致していない可能性もあります。プロキシ接続後に、接続先ドメインの名前解決やルーティング、接続先サーバーで問題が起きることもあります。Webサイトを開けない場合は、「測定先へのリクエストが失敗する」のか「特定のWebサイトだけ失敗する」のか、まず切り分けましょう。

40 ms
TCPハンドシェイク時間の例
240 ms
実接続遅延の例
5.8 MB/s
継続ダウンロード速度の例
10808
ローカルSOCKSポートの例

上記は単位の違いを説明するための例であり、特定ノードの性能を保証するものではありません。40 msと240 msは矛盾しません。前者はサーバーポートとのハンドシェイクまで、後者はクライアントやプロキシ経路、測定先も含む時間です。5.8 MB/sは転送速度で、Webページの最初の応答までの時間には換算できません。10808はローカルの待ち受けポートで、測定結果ではありません。

  1. まず実接続テストが成功するか確認します。失敗する場合はクライアントのログを開き、接続タイムアウト・認証エラー・接続先へのリクエストエラーを切り分けます。
  2. 測定したノードが現在のアクティブノードであることを確認し、システムプロキシまたはアプリ内プロキシが現在のクライアントを参照しているか確認します。
  3. ルーティングルールで接続先ドメインがプロキシ経由になっているか確認します。同じドメインでも、直接接続とプロキシ経由では問題の発生箇所が異なります。
  4. 一部のWebサイトだけ開けない場合は、そのドメインの名前解決結果と接続先の稼働状況を確認しましょう。TCPingを一度試しただけで、サブスクリプション全体を変更する必要はありません。

v2rayN・v2rayNGでノードを比較する方法

まずサブスクリプションを更新し、測定条件を統一します。測定中はなるべく同じネットワークを使い、帯域を消費する大容量ファイルの転送は一時停止しましょう。同じ候補ノードを、同じ測定先とタイムアウト設定で測ります。メニューの名称はバージョンによって異なる場合があるため、現在のクライアント画面の表示を確認してください。

おすすめの手順:接続可能なノードを絞り、次に継続転送を測定

デスクトップ版 v2rayN
  • サーバー一覧から同じ候補ノードを選び、まずTCPingを実行してポートに接続できないノードを除外します。
  • 続いて一覧の「サーバーの実接続遅延をテスト」機能を使い、成功回数とミリ秒数を記録します。
  • 候補ノードを1つずつアクティブに設定し、実際にWebページへアクセスして確認します。
Android版 v2rayNG
  • 設定一覧で候補ノードの接続テストまたは実接続テストを行い、失敗時のメッセージを確認します。
  • 選んだ設定を有効にしたら、システムのVPN接続がアクティブになっていることを確認します。
  • 同じネットワークで普段使うWebページにアクセスし、転送量が多い用途のノードはダウンロードテストも行います。

デスクトップ版とAndroid版の結果は分けて記録しましょう。有線接続のデスクトップとモバイルネットワークのAndroidで測ったミリ秒数を、そのまま比較して順位を付けないでください。

v2rayNでは、サーバー一覧の操作に実接続テストの名称がそのまま表示されることが一般的です。v2rayNGでは、テストの場所や一括テストの名称がバージョンによって変わる場合があります。同じ名称が見つからないときは、設定一覧のメニューにある接続テストを確認してください。どちらのクライアントでも測定先に注意が必要です。測定先の応答が遅いと、すべてのノードが遅く見えることがあります。

候補ノードごとに少し間隔を空けて3回測定し、成功したかどうかとおおよその値を記録しましょう。たとえばAノードが180、195、188 ms、Bノードが90 ms、タイムアウト、310 msの場合、Bの最小値だけを見ると失敗や大きなばらつきを見落とします。普段使いでは、リクエストが安定して完了するノードを優先しましょう。

結論:1回の最小値より、リクエストが安定して完了することを優先

まず実接続が何度もタイムアウトするノードを除外し、安定している候補の遅延を比べます。ダウンロードが主な用途の場合に限り、ダウンロード速度で最終順位を決めましょう。

ダウンロード速度の見方と再測定のタイミング

ダウンロード速度と遅延では、わかることが異なります。実接続遅延が同程度でも、長時間の転送では一方の回線が速い場合があります。ダウンロード速度が同程度でも、小さなWebページの表示では別の回線の応答が速いことがあります。ダウンロードテストでは、ファイルのサイズが十分に大きく、一定時間転送が続いたことを確認しましょう。開始直後の瞬間的なピークだけで回線全体を判断しないでください。

測定結果まず確認すること次の対応
TCPingは低いが、実接続がタイムアウトするプロトコル設定、ノードのログ、測定先順位付けの前にリクエスト失敗を解消する
実接続は安定しているが、ダウンロードが遅いテストファイルの配信元、同時ダウンロード、回線の混雑同じテストファイルを使い、時間帯を変えて再測定する
ダウンロードは速いのに、Webページの表示が遅い接続先の応答、ドメインの名前解決、ルーティングルール普段使うWebサイトを個別に測定し、転送量で応答時間を判断しない

測定先自体も結果に影響します。ダウンロードファイルのサーバーに速度制限がある場合、測定できるのは「ノードとファイルサーバーの組み合わせ」の速度であり、ノードの最大速度ではありません。同様に、ルーティングルールで測定先を直接接続にしていると、ダウンロード速度はプロキシ経由の転送速度を示しません。測定前に、通信が現在のアクティブノードを経由していることを確認してください。

よくある測定結果への対処

ノード一覧に遅延の低い結果が複数ある場合は、まず実際にリクエストが完了したノードを確認し、普段使うWebサイトでも試しましょう。1回の結果は、その時点の状況にすぎません。ネットワークの切り替えやサーバー負荷、接続先の変化によって、次の測定では順位が変わることがあります。

TCPingは30 msなのに、実接続がタイムアウトする?

まず現在のノードのアドレス・ポート・プロトコル設定を確認し、次にクライアントのログを見ます。TCPポートに接続できても、一部のネットワーク障害を除外できるだけで、VMessまたはVLESSのプロキシリクエストが成功したことは確認できません。

実接続の結果は出るのに、ブラウザーでWebページを開けないのはなぜ?

ブラウザーがシステムプロキシ、または正しい手動設定のプロキシポートを使っているか確認します。次に接続先ドメインのルーティングルールを確認してください。測定先に接続できても、すべてのドメインが同じ経路を通るとは限りません。

v2rayNとv2rayNGで測定した遅延が大きく違う?

まず同じノード、同じ測定先、同じネットワークを使っているか確認します。次に両方のコア設定とルーティングを確認してください。条件がそろっていない場合、ミリ秒数だけで端末を比較するのは適切ではありません。

ダウンロード開始直後は速いのに、その後遅くなる?

転送全体の平均速度を記録し、時間帯を変えて同じファイルを再測定します。開始直後のピークはキャッシュや一時的に利用可能な帯域の影響を受ける場合があるため、それだけでノードを選ばないでください。

遅延が最も低いノードだけを選ぶべき?

普段使いでは、リクエストが失敗するノードや大きくばらつくノードを除外してから、安定した候補の実接続遅延を比較しましょう。大容量ファイルの転送ではダウンロードテストも行い、実際に使う時間帯の結果を参考にしてください。

用途に合わせて選びましょう。Webページの表示ではリクエストが安定して完了するか、継続的な転送では一定時間の速度、接続入口の問題を調べる場合はTCPingを優先します。最低のミリ秒数だけでなく、測定日時やネットワークの種類、失敗時のメッセージも記録しておくと、次回の問題切り分けに役立ちます。

v2rayNをダウンロード