V2Rayの速度テストの見方｜TCPing・実接続遅延・ダウンロード速度の違い

3種類のV2Ray速度テストで測定しているもの

v2rayNはデスクトップ向けGUIクライアント、v2rayNGはXrayコアを採用したAndroidクライアントです。画面上のテストはクライアントが実行しますが、実際の通信にはコア、ノード設定、接続先サイトも関係します。バージョンによってメニュー名や計測範囲、タイムアウトのしきい値が異なる場合があります。同じ項目内の数値は比較に使えますが、異なるクライアント間の数値をそのまま順位付けするのは適切ではありません。

ここでの「おすすめ」は、通常のノード選びでは実接続遅延を優先して参考にするという意味で、ほかのテストを置き換えられるということではありません。動画再生では安定した転送速度や変動の少なさ、インタラクティブな操作では応答時間が重要です。実際のアプリでは、テストとは異なる経路を通る場合もあります。

TCPingの値が低いのに実接続がタイムアウトする理由

TCPingは従来のICMP pingとは異なります。ノード設定のTCPポートが443だとすると、TCPingの成功から分かるのは通常、端末からそのアドレスのポートへTCP接続を確立できたことだけです。ポートの先にはプロキシサービスがあるとは限らず、前段の転送先や別の待ち受けプログラムの場合もあります。設定が使えるかどうかを確かめるには、プロトコルの通信まで成功する必要があります。

1. サーバーのポートを確認する。サブスクリプションに記載されたポートをテストしてください。経験則で443に固定してはいけません。ポートが変更済みでサブスクリプションが更新されていない場合、古いポートの測定結果は参考になりません。
2. プロトコルとセキュリティ設定を確認する。VLESSのユーザーID、TLSのサーバー名、REALITYの公開鍵やShort IDなどに誤りがあると、TCP接続の確立後に問題が表面化することがあります。
3. トランスポート層の設定を確認する。WebSocketのパスやHTTPのホスト名などがサーバー側と一致しないと、ポートへの接続は成功しても、その後のプロキシ通信に失敗することがあります。
4. テスト方法が適切か確認する。主にUDPを使うトランスポートは、TCPポートの確認だけでは稼働状況を判断できません。TCPingに失敗しても、すべての種類のプロキシ通信が失敗したとは限りません。

同様に、TCPingはパケットロス率のテストではありません。5回連続で接続できても、分かるのはその5回の確認が成功したことだけで、回線のパケットロスがゼロとは言えません。再測定では失敗回数と成功時の値の分布も記録してください。

実接続遅延に含まれるものと、測定値が毎回変わる理由

実接続テストでは、プロキシ設定を使ってテストURLにアクセスします。HTTPSの接続先では、ローカルまたはリモートでのDNS名前解決、ノードへの接続、プロキシ認証、接続先とのTLSハンドシェイク、応答待ちなどが発生します。どの処理が測定時間に含まれるかは、クライアントの実装や、接続の再利用・DNSキャッシュの有無によって異なります。

そのため、実接続遅延は「ノードからユーザーまでの純粋なネットワーク往復時間」ではなく、ウェブページ全体の読み込み時間でもありません。小さな応答を返すテストページでは受信データがわずかです。一方、実際のウェブページではスクリプトや画像、別ドメインのリソースも取得するため、使い心地が異なるのは自然です。

• テスト先を固定する。ノードを比較するときは、同じURLを使用してください。テスト先の地域やCDN、応答方式が変わると、結果からノードの差だけを比較できなくなります。
• 応答が期待どおりか確認する。テストによってはステータスコードや有効な応答を確認します。リダイレクト、認証ページ、接続先サイトのアクセス制限が原因でテストに失敗することがあります。
• 初回と2回目以降の結果を記録する。初回接続は時間がかかることがあり、その後はDNSキャッシュ、セッション再開、接続の再利用によって短縮される場合があります。最速の1回だけを切り取って判断しないでください。
• テストの経路を確認する。実接続テストは指定したノードの確認を目的としていますが、テスト設定やDNSの処理方法はバージョンによって異なる場合があります。ログと照らし合わせて確認し、ブラウザーからテストページへ直接アクセスする方法でプロキシテストを代用しないでください。

ダウンロード速度のMB/sとMbpsの換算方法

遅延はミリ秒で表し、転送速度は通常MB/sまたはMbpsで表示されます。両者を直接換算することはできません。遅延が180 msのノードでも12 MB/sで転送できる一方、60 msのノードが2 MB/sしか出ないこともあります。前者が低遅延を求める操作に向いているとは限らず、後者も大容量ファイルのダウンロードに適しているとは限りません。

以下は単位換算の例であり、本サイトでの実測値や回線速度の保証ではありません。10進法では1バイトは8ビットです。表示単位がMiB/sの場合は、2進法に基づいて別途計算してください。

公称100 Mbpsの回線は、理論上12.5 MB/sに相当します。実際の通信ではプロトコルのオーバーヘッドやネットワークの変動もあります。ダウンロード速度のボトルネックはノードではなく、テストサーバー側にある場合もあります。単一接続と複数接続の測定結果を混同しないでください。

• バックグラウンドのダウンロード、システム更新、クラウド同期を一時停止し、ローカル回線の帯域を共有しないようにします。
• 候補ノードを1つずつテストし、複数のダウンロードテストで同時に帯域を取り合わないようにします。
• 速度テストの前に通信量の上限を確認してください。長時間の測定では実際に通信量が発生するため、Android端末でモバイル回線を使う場合は特に注意が必要です。
• 開始直後のピーク値だけでなく、速度が安定している区間を確認し、実際にダウンロードするサービスでも検証してください。

v2rayN・v2rayNGで再測定する手順

まずクライアントとコアのバージョンを記録し、次にテスト設定を確認します。v2rayNでは「設定」→「パラメーター設定」を開き、現在のバージョンにある速度テスト関連の項目から、テスト先とタイムアウト設定を確認してください。メニューの分類はバージョンによって異なります。数値を小さくするために、これらの条件を頻繁に変更するのは避けてください。

たとえば実接続の結果が5回で142、149、151、158、410 msの場合、中央値は151 msですが、410 msへの大きな変動も記録する価値があります。2回がタイムアウトした場合、残り3回の平均だけを出して安定していると判断してはいけません。サブスクリプションのノードを切り替えた後は、アクティブノードが実際に変更されたことも確認してください。新しいノードを測定している一方で、ブラウザーが古い接続を再利用している可能性があります。

速度テストは成功するのにウェブサイトが開かない場合の切り分け

クライアント内蔵のテストとブラウザーからの接続は、それぞれ個別に確認する必要があります。内蔵テストは専用のテスト経路から通信する場合がありますが、ブラウザーはシステムプロキシ、アプリごとのプロキシ設定、またはTUNによる通信制御にも依存します。システムプロキシは通信をクライアントへ送る方法を決め、ルーティング設定はその後どの出口を通るかを決めます。

1. ローカルの接続先を確認する。たとえばHTTPプロキシに127.0.0.1:10809を設定している場合、アプリでも実際に待ち受けているこのアドレスを使用する必要があります。10809はあくまで例で、すべてのバージョンの既定値ではありません。また、SOCKSポートをHTTPポートとして設定しないでください。
2. ルーティングの設定を確認する。テスト先にプロキシ経由で接続できても、実際に使うドメインも同じ経路を通るとは限りません。ドメインが直接接続のルールに一致していないか、Androidのアプリ別設定で対象アプリが除外されていないか確認してください。
3. DNSを確認する。ノードのサーバーアドレスと実際に使うドメインは、どちらも名前解決が必要です。ログに記録された名前解決エラーと接続先を比較してください。ブラウザーで特定のドメインを名前解決できても、DNSの問題がすべて解消したとは限りません。
4. 接続先とアクセス先を確認する。小さな応答を返すテストサイトに接続できても、すべてのウェブサイトにアクセスできるとは限りません。特定のサービスだけ失敗する場合は、そのサービスの地域制限、出口制限、具体的なエラーを確認してください。

原因を切り分けるときは、一度に変更する項目を1つにして、変更前後の結果を保存してください。ノード、ルーティング、DNS、システムプロキシを同時にリセットすると、一時的に直っても本当の原因を特定しにくくなります。

遅延と速度テストに関するよくある質問