Webページにアクセスできるかを確かめるなら、まずプロキシ経由の実接続リクエストを確認します。大容量ファイルのダウンロード速度を知りたい場合は、持続的なスループットを測定します。ICMP pingとTCPハンドシェイクで確認できるのは、経路の一部に限られます。v2rayNやv2rayNGの測定結果を比較する方向けに、測定範囲やタイムアウトの意味、同じ宛先・ネットワークで複数回測定する方法を解説します。
4種類のネットワークテストでわかること
遅延は特定の処理にかかる時間、速度は単位時間あたりに転送されるデータ量です。クライアント一覧に表示されるミリ秒数は、ノード固有の固定値ではありません。測定先や名前解決の結果、接続の再利用状況が変われば、結果も変わります。比較する前に、列名の「遅延」だけを見るのではなく、テストボタンが実際に何を測っているかを確認しましょう。
| テスト | 主な測定対象 | 直接確認できないこと |
|---|---|---|
| ICMP ping | 宛先ホストからのICMPエコー応答の往復時間 | プロキシポートの利用可否、プロトコル認証の成功 |
| TCPハンドシェイク | 指定したIPアドレスとポートへのTCP接続にかかる時間 | TLS、VMess、VLESSの設定が正しいこと |
| 実接続遅延 | プロキシ経由でテストURLにリクエストした際の所要時間。測定範囲は実装によって異なる | すべてのWebサイトに接続できること、ダウンロード速度が持続すること |
| ダウンロード速度測定 | 指定した経路でデータを受信した際の実効スループット | 最初のリクエストへの応答が速いこと、通信が安定すること |
たとえば、あるノードのTCPハンドシェイクが45 ms、実接続リクエストが260 msでも矛盾ではありません。後者には、プロキシプロトコルのハンドシェイク、サーバーから宛先サイトへの接続、サイトとのTLSハンドシェイク、応答待ち時間などが含まれる場合があります。測定の終点が異なるため、数値の差をそのまま「暗号化のオーバーヘッド」として計算することはできません。
ICMP pingとTCPハンドシェイクでわかるのは経路の前半
システムのpingは通常、ICMPエコー要求を送信します。HTTPプロキシやSOCKSプロキシを設定しても、自動的にプロキシ経由で送信されるわけではありません。ノードのドメイン名に対してpingを実行すると、主にローカルネットワークから、そのドメインが名前解決されたアドレスへの到達性を確認できます。ドメイン名が中継用の入口を指している場合、結果に表れるのは入口までの通信であり、最終的な出口から宛先サイトまでの経路全体ではありません。
- pingがタイムアウトしてもプロキシが使える場合：ホストや経路上の機器がICMPに応答しないことがあります。まず実際のサービスポートをテストし、その後プロキシ経由でリクエストを送信してください。
- pingが低遅延でもWebページの表示が遅い場合：入口までの距離が近くても、中継経路や出口の帯域、宛先サイトの応答が速いとは限りません。
- TCPハンドシェイクは成功しても実接続に失敗する場合：ポート上のサービスが応答していても、UUID、TLSのサービス名、トランスポート経路、プロトコルパラメーターなどに誤りがある可能性があります。
TCPテストでは、ノード設定で指定されている実際のポートを使ってください。ノードのポートが443なら、そのアドレスの443番ポートを測定します。同じホストの80番ポートで代用することはできません。設定がTCP以外のトランスポートを使う場合、TCPプローブの参考価値はさらに低くなります。リモート側の正しいポートでハンドシェイクが完了しても、確認できるのはTCPレイヤーの接続性だけで、アプリケーションレイヤーがプロキシ設定を受け入れたことまではわかりません。
実接続遅延：プロキシ経由で特定のURLにリクエスト
実接続テストでは通常、カーネルがテスト対象のノードを通じてHTTPまたはHTTPSのテスト先にアクセスします。単なるポート測定よりWeb閲覧に近い指標ですが、「どこから計測を始め、どこで終えるか」はクライアントやカーネルの実装によって異なります。レスポンスヘッダー受信までを測る実装もあれば、接続の再利用が結果に影響するテストもあります。すべてのクライアントの実接続結果を、完全に同じ条件の数値として扱うことはできません。
HTTPSの宛先では、用途の異なる2つのTLS処理が含まれる場合があります。1つはノード自体の通信を保護するTLS、もう1つはクライアントから宛先サイトにアクセスするためのHTTPSです。VMessとVLESSはプロキシプロトコルです。TLSを使用するか、どのトランスポート方式を使うかは、ノード設定を確認してください。プロトコル名だけから測定時間を推測することはできません。
テストURLには、データ量が小さく、応答が安定し、想定するステータスコードが明確なHTTPSエンドポイントを選びましょう。タイムアウトしても、ノードが完全に利用できないとは限りません。宛先サイトが特定の出口を拒否している、名前解決に失敗している、またはテスト実装が受け付けないステータスを返している可能性があります。まず別の独立したテスト先でも確認し、接続・TLS・応答に関するエラーをログで調べてください。
実接続テストの比較条件
- 宛先プロトコル
- HTTPS。URL全体を記録
- 宛先ポート
- 一般的には443。URLに合わせる
- 測定回数
- 同じノードを連続で5回テスト
- 記録する結果
- 中央値、失敗回数、測定時刻
これは比較実験の推奨条件であり、クライアントの既定値ではありません。
ダウンロードテストの比較条件
- テスト対象のデータ
- URLを固定した大容量ファイル、または継続的にデータを返すリソース
- 接続数
- まず単一接続を測定し、次に並列接続を個別に測定
- 測定時間
- 1回あたり約20秒。速度が安定した区間を記録
- ネットワーク条件
- 同じネットワークを使い、ほかのダウンロードを一時停止
速度測定ではデータ通信量が発生します。モバイル回線では、まずデータ残量を確認してください。
ダウンロード速度：スループットと遅延は別の指標
ダウンロード速度は、ローカル回線の帯域、ノードの速度制限、出口の混雑、宛先サーバーの制限、TCP輻輳制御の影響を受けます。低遅延は接続確立や操作の応答性に有利ですが、十分な帯域を保証するものではありません。遅延が大きい回線でも、接続が安定した後に高いスループットが得られることがあります。測定開始直後は接続確立や輻輳ウィンドウの拡大中である可能性があるため、一時的なピーク値だけを切り取って判断しないでください。
Mbpsの小文字bはビット、大文字BのMB/sはバイトを表します。100 Mbpsを8で割ると12.5 MB/sですが、これはプロトコルや回線のオーバーヘッドを差し引く前の理論上の上限です。アプリケーションが常にこの速度に達するとは限りません。表示単位がMiB/sの場合は単位も異なるため、データを記録する際は元の単位を残してください。
- 単一接続テスト：通常のダウンロードを再現しやすい一方、単一ストリームの速度制限や往復遅延の影響を受けやすくなります。
- 複数接続テスト：帯域を使い切りやすい一方、単一接続の遅さを見落とす可能性があります。単一接続の結果と直接順位を比較しないでください。
- 測定中にWebページの表示が明らかに遅くなる場合：帯域を使い切っているか、キューが滞留している可能性があります。まず速度測定を停止して遅延を測り、アイドル時と負荷時の遅延を比較してください。
v2rayNとv2rayNGを比較する：条件をそろえて測定
クライアントのメニューは、バージョンや画面構成によって変わります。デスクトップ版v2rayNでは、サーバー一覧からノードを選択し、右クリックメニューにある「サーバーの実接続遅延をテスト」を探してください。一括テストの前にノードを1つだけ選び、テスト先とログの内容を確認しましょう。Android版v2rayNGでは、メイン画面右上のメニューから「全構成の実接続をテスト」を探します。現在のバージョンで名称が異なる場合は、「実接続」機能かどうかを確認し、TCPテストを一連のリクエスト全体の測定と取り違えないようにしてください。
- 環境を記録：クライアントとカーネルのバージョン、接続ネットワーク、測定時刻を記録します。一方がWi-Fi、もう一方がモバイル回線なら、同じ条件での比較ではありません。
- テスト先を固定：現在のバージョンで設定できるテストアドレスを確認し、URLをそろえます。設定が見つからない場合は、少なくとも同じクライアントと同じテスト機能を使ってください。
- ほかの通信による影響を避ける：同期、システムアップデート、ほかのダウンロードを一時停止します。ローカル帯域やサーバーのリソースを奪い合わないよう、ノードを1つずつ測定してください。
- 繰り返し測定し、失敗も記録：各ノードを5回測定します。タイムアウトを0 msとして扱ったり、記録から削除したりしないでください。
- 実際の利用アプリで確認：ノードを選択し、普段使うWebサイトにアクセスしてから、別途テストファイルをダウンロードします。クライアント内蔵テストでは独立した一時インバウンドを使う場合があり、システムプロキシやアプリ別プロキシの経路と同じとは限りません。
手動で確認する場合、HTTPに対応した混合インバウンドがローカルで設定済みで、ポートが10808なら、コマンドラインのリクエストを明示的にその経由にできます。このポートは例です。実際の待ち受け設定を確認してください。SOCKSインバウンドしかない場合は、HTTPプロキシ用のパラメーターをそのまま使えません。以下のコマンドは当サイトのHTTPSページにアクセスして経路を確認するもので、このページを共通の速度測定基準とするものではありません。
curl --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --output /dev/null --silent --show-error --write-out "HTTP=%{http_code} TTFB=%{time_starttransfer}s TOTAL=%{time_total}s\n" https://v2ray-best.com/この書き方はLinuxまたはmacOSのターミナルで使えます。Windowsではcurl.exeを使用し、/dev/nullをNULに置き換えてください。TTFBはリクエスト開始から最初の1バイトを受信するまでの累積時間、TOTALはリクエスト完了までの時間です。クライアントの実接続テストとは計測範囲が異なる場合があります。また、ローカルプロキシポートへの接続時間を、リモートノードへのTCP遅延として扱うことはできません。
遅延測定の結果を読み解く
まず成功率、次に中央値、最後にばらつきを確認します。以下は測定値の読み方を説明するための例で、実際のノードの測定結果ではありません。同じ宛先を5回測定した結果が180、190、185、920 ms、タイムアウト1回だった場合、成功した測定値の中央値は187.5 msです。ただし、5回中4回成功・1回失敗という結果も必ず評価に含めてください。「約188 ms」だけでは、利用可能性の問題が見えなくなります。
| 結果の組み合わせ | 考えられる原因 | 次に確認すること |
|---|---|---|
| TCPは速いが、実接続がタイムアウト | プロトコル設定、宛先サイト、DNS、出口接続の異常 | 別のテスト先を試し、カーネルログを確認 |
| 実接続は安定しているが、ダウンロードが遅い | 帯域、単一ストリームの速度制限、テスト対象リソースの制限 | 同じリソースで単一接続と複数接続を比較 |
| アイドル時は速いが、ダウンロード中に遅延が増える | 帯域の飽和、回線上のキュー滞留 | ダウンロードを停止して再測定し、速度制限も試す |
| テストは成功するが、特定のアプリが開かない | アプリがプロキシを経由していない、ルーティングが異なる、サイト固有の制限 | そのアプリのプロキシ入口と実際のアウトバウンドログを確認 |
時間帯をまたいで比較する場合も、同じ条件を保ってください。夜間の混雑時と午前中の空いている時間帯との差が、2つのノード間の差より大きいこともあります。動画視聴や大容量ファイルのダウンロードが目的なら、成功率が安定し、十分なスループットが続く回線を優先します。Web閲覧やリモート操作が目的なら、リクエスト遅延とそのばらつきを重視してください。あらゆる使い方を判断できる万能な数値はありません。
よくある質問：低遅延・タイムアウト・ルーティング
pingが通らなくても、ほかのテストを続けるべきですか？
はい。まずノード設定に記載された実際のサービスポートを確認し、次に実接続テストを実行してください。実接続に成功すれば、ICMPに応答しなくてもプロキシ経由のリクエストは通っています。その後は実際のWebページ表示やダウンロードを確認し、pingに応答させるためにプロトコル設定を変更する必要はありません。
実接続は100 msなのに、Webページの表示に数秒かかるのはなぜですか？
テストでは小さな単一の宛先にしかアクセスしていませんが、Webページは複数のドメインや多数のリソースを読み込む場合があります。まずダウンロードを停止し、ブラウザーの開発者ツールにある「ネットワーク」パネルで遅いリクエストを確認します。次に、そのドメインのルーティング先と名前解決を確認してください。テストURLの応答速度が、すべてのリソースドメインの速度を示すわけではありません。
v2rayNGのテストは成功するのに、特定のアプリがプロキシを経由しないのはなぜですか？
システムでVPN接続が許可されていることを確認し、v2rayNGの「設定」にあるアプリ別プロキシの項目で、「選択したアプリをプロキシ経由にする」のか「選択したアプリを除外する」のかを確認してください。保存後、画面の案内に従ってサービスを再起動し、対象アプリを開き直して接続ログを確認します。内蔵テストの成功だけでは、アプリが実際に通る経路を確認したことにはなりません。
サブスクリプション更新後に遅延が変わりました。ルーティングもリセットされたのでしょうか？
まずノードのアドレス、ポート、トランスポートのパラメーターがサブスクリプション更新で変わっていないか確認し、次に現在選択されているノードを確認してください。サブスクリプションで更新されるのは主にサーバー設定で、通常はローカルのルーティングルールを直接書き換えません。ノード名が同じでも、アドレスの名前解決、出口の負荷、測定時刻が変われば結果に影響します。
選定の手順は、まずプロキシ経由のリクエストが成功することを確認し、次に複数回測定した遅延と失敗回数を比較します。その後、持続的なスループットを測定し、最後に実際のアプリで確認してください。ICMPとTCPの結果はトラブルの範囲を絞るのに役立ち、実接続はリクエスト経路の確認に、ダウンロードテストは帯域の把握に適しています。それぞれの測定範囲を踏まえれば、数値が異なる理由を正しく説明できます。