TCPingはサーバーのポートに接続できるかを確認し、プロキシ接続遅延はプロキシ経由でリクエストが完了するかを検証、ダウンロード速度テストは継続的なデータ転送能力を測ります。サブスクリプションを読み込んだものの、どの項目で並べ替えればよいかわからない方に向けて、ポートへの接続、プロキシの利用可否、ダウンロード速度を順に切り分けます。遅延が最小でも正常に使えないノードを選ぶ失敗を防げます。
3種類の速度テストは測定区間が異なる
ノード一覧に表示されるミリ秒の値は、すべて同じ基準で測られているわけではありません。TCPingは通常、ノードのアドレスとポートにTCP接続を確立します。プロキシ接続テストはプロキシコアを使い、指定したノード経由でテスト先にアクセスします。ダウンロード速度テストは応答データを受信し続け、一定時間のスループットを測定します。測定の終点、リクエスト量、計測範囲が異なるため、数値をそのまま比べることはできません。
この流れは、プロキシ経由で接続先サービスにアクセスする際の論理的な手順を示しています。ノードが別のトランスポート層や中継を利用する場合、入口からプロキシサービスまでにほかの経路が含まれることもあります。TCPingが測定するのは多くの場合、経路の前半までです。後続の経路も検証するのは、プロキシ接続テストとダウンロードテストです。
| テスト方法 | 主に確認できること | これだけでは確認できないこと |
|---|---|---|
| TCPing | ノード入口のTCPポートに接続できるか | プロキシ認証、接続先サイトへのアクセス、継続的な通信速度 |
| プロキシ接続遅延 | 指定したプロキシ経路でテストリクエストが完了するか | すべてのサイトが使えるか、長時間のダウンロードが安定するか |
| ダウンロード速度テスト | 速度測定用リソースへの実効転送速度 | Webページの初回表示が速いか、別の時間帯も同じ速度が出るか |
TCPingの値が低いのにノードが使えないのはなぜ？
サーバーポート443を例にすると、TCPingで38 msと表示された場合、通常はこの端末から該当アドレスのTCP待ち受けポートへ比較的すばやく接続できることを示します。VMessやVLESSに必要な認証情報を送信したり、TLSの設定、WebSocketのパス、ノードの出口から接続先サイトへアクセスできるかを確認したりするわけではありません。
- 認証情報が一致しない：サーバーはTCP接続を受け付けても、その後のプロキシリクエストを拒否することがあります。TCPingを繰り返しても、認証情報の誤りは特定できません。
- トランスポート設定が一致しない：ポートに接続できても、TLSのサーバー名やトランスポートのパスなどが誤っていると、アプリケーション層の接続は失敗します。
- 入口が最終的なサーバーとは限らない：アドレスの手前に中継やCDNがある場合、低い数値は主に入口までの距離を反映している可能性があります。
- TCPだけで使えるプロトコルとは限らない：TCPingは実際のUDP通信のテストにはなりません。すべてのプロトコルが使えると判断する根拠にはできません。
逆にTCPingがタイムアウトした場合も、テストの実装やネットワーク環境を踏まえて判断しましょう。まず、クライアントが現在のノードアドレスと正しいポートを測定しているか確認し、次にプロキシ接続の結果を見ます。両方とも失敗する場合に、ローカルネットワーク、入口ポート、ノードの状態、サブスクリプションの設定を調べます。ひとつの結果だけでサーバーが停止していると決めつけないでください。
プロキシ接続遅延は実用性に近い指標。ただしテスト先に注意
プロキシ接続テストでは通常、コアを通じて対象ノードへのプロキシ経路を確立し、設定されたテストURLにリクエストを送信します。計測には、DNS名前解決、プロキシのハンドシェイク、接続先サイトとのTLSハンドシェイク、応答待ちなどが含まれる場合があります。計測の開始点と終了点はクライアントやコアの実装によって異なります。「TCPingに何往復かを加えた値」のように一律には分解できません。
テスト先によってはごく小さな応答を返したり、成功を示すために204ステータスコードを使ったりします。このようなリクエストは応答速度の確認に適していますが、継続的なデータ転送には不十分なため、ダウンロード帯域を推定することはできません。DNSキャッシュ、接続の再利用、テスト用リソースの設置地域も、繰り返し測定した結果に影響します。
プロキシ接続テストの記録
- 接続先
- 同じHTTPSテストURLを使用
- テスト回数
- ノードごとに5回
- 間隔
- 各回3秒以上空ける
- 記録する項目
- 中央値、最遅値、失敗回数
まず接続先とテスト方法をそろえてから、ノードを比較しましょう。
ダウンロード速度テストの記録
- ダウンロード用リソース
- 同じ速度測定用ファイルを使用
- テスト時間
- 例：1回10秒
- 同時実行数
- 同時に測定するノードは1つ
- 記録する項目
- 平均速度、変動、実際のデータ転送量
継続的な速度を測れるよう、リソースには十分なサイズが必要です。
テスト先そのものに接続できない場合、正常なノードが複数あっても同時にタイムアウトすることがあります。まず設定を残したまま、アクセスできることがわかっている小さなHTTPSの接続先に変更して比較し、その後、元のアドレスに戻して再測定します。特定の接続先だけ失敗する場合は、そのサイトのアクセス制限やノードの出口経路を確認しましょう。サブスクリプション全体をすぐに削除する必要はありません。
ダウンロード速度はスループットで比較。MB/sとMbpsを区別
ダウンロード速度は、ローカルのブロードバンド回線やWi-Fiの電波状況、ノードの入口、サーバーの出口、接続先リソースの速度制限、テストの同時実行数など、経路上の最も遅い部分に左右されます。ノードの入口が近ければ一部の往復時間を短縮できますが、出口の帯域が十分とは限りません。遅延が大きいノードでも、接続確立後に高いスループットを維持できる場合があります。
単位に注意してください。1 MB/s = 8 Mbpsです（10進単位で換算）。接続帯域が100 Mbpsの場合、理論上の換算値は約12.5 MB/sです。実際の速度はプロトコルのオーバーヘッドや共有ネットワークの影響も受けます。画面にMiB/sと表示される場合は、2進単位で別途換算してください。「M」が付く数値をすべて同じ基準で並べ替えることはできません。
| 表示値 | 10進単位で換算 | 見方 |
|---|---|---|
| 5 MB/s | 40 Mbps | 1秒あたり約5 MBのデータを転送 |
| 10 MB/s | 80 Mbps | 10 Mbpsしかないと誤読しない |
| 100 Mbps | 12.5 MB/s | 理論上の換算値であり、測定速度を保証するものではない |
v2rayNでノードを決まった順序で比較する
ここではWindows版v2rayNの一般的なデスクトップ画面を例に説明します。バージョンや画面の種類によってメニュー名は多少異なります。「Tcping」「真接続遅延」「速度」に相当するテスト項目を選んでください。テスト設定は通常、「設定」→「パラメータ設定」内の速度測定関連項目にあります。テストを始める前に、現在のテストURL、タイムアウト、ダウンロード時間を記録しましょう。
- リストを更新して確認：該当するサブスクリプショングループを更新し、測定するノードが同じリストに含まれていることを確認します。サブスクリプションの更新に成功しても、各ノードの接続テストに合格したわけではありません。
- ローカル環境をそろえる：ほかのダウンロードやクラウド同期を一時停止し、同じネットワーク接続を使います。一方のノードは有線LAN、もう一方は混雑したWi-Fiという条件で測定しないでください。
- まず入口を測定：サーバー一覧から候補の行を選択し、右クリックしてTcpingに相当するテスト項目を選びます。入口への接続性を判断するため結果を記録し、最も低い値だけで最終候補を決めないようにしましょう。
- 次にプロキシ接続を測定：右クリックして、プロキシ接続遅延に相当するテスト項目を選びます。前述のとおり5回測定して記録する方法がおすすめです。使用中のバージョンに同時実行数の設定がある場合、比較時は1にして、テスト同士の干渉を抑えます。
- ダウンロード測定は少数に絞る：プロキシ接続が安定しているノードを2～3個だけ選び、速度を測定します。平均速度を記録し、開始直後のピーク値を継続的な帯域とみなさないようにしましょう。
- 実際のアプリで確認：候補のノードを使用サーバーに設定し、「システムプロキシ」メニューの状態を確認します。ブラウザーがシステムプロキシを使っていることを確かめ、実際に利用するページを開いてダウンロードも試してください。
内蔵テストでは専用のテスト設定が使われることがあり、ブラウザーが実際に通る経路全体と一致するとは限りません。内蔵のプロキシ接続テストには成功するのにブラウザーで失敗する場合は、システムプロキシ、アプリ独自のプロキシ、ルーティングルール、DNSを確認してください。アプリに127.0.0.1:10808のようなローカルプロキシを手動で指定している場合、「設定」→「パラメータ設定」に表示される実際の待ち受けポートと一致させる必要があります。このポート番号は例であり、すべてのインストール環境で共通ではありません。
「遅延は低いのにダウンロードが遅い」を数値例で理解する
以下は判断方法を説明するための仮のデータです。本サイトでの実測値でも、サービスの性能保証でもありません。同じネットワーク、同じ時間帯、同じテスト先で測定したと仮定します。ノードAのTCPingは32 ms、プロキシ接続遅延の中央値は460 ms、ダウンロード平均速度は2 MB/sです。ノードBの結果は次のとおりです。
Aは入口までの接続が速い一方、プロキシ経由でテスト先にアクセスすると遅くなっています。入口以降の経路や処理を調べる余地があることを示します。この3項目だけでサーバーのCPU不足や回線の混雑とは断定できません。ログや別の接続先、異なる時間帯で再測定して確かめましょう。この例では、Bを実際のアプリで検証する価値があります。
判断のポイント：不安定な候補を除外して、用途に合わせて選ぶ
Webサイトの閲覧では、プロキシ接続の成功率と応答のばらつきを優先して比較します。大容量ファイルを転送する場合は、継続的なダウンロード速度も確認しましょう。一時的に最小の遅延が出ても、繰り返し測定して頻繁に失敗するノードは、安定した候補より優先すべきではありません。
平均値が異常値を隠すことにも注意してください。5回の結果が180、190、185、900、タイムアウトの場合、毎回220 ms前後の結果と同じ使い心地ではありません。更新後に最後に表示された数字だけを見るより、タイムアウト回数や遅いリクエストも記録するほうが役立ちます。夜間の利用が集中する時間帯にも再測定すると、日中には見つからなかった問題に気づけます。
速度測定でよくある疑問と対処法
TCPingでは数値が出るのに、プロキシ接続はすべてタイムアウトします。何から見直せばよいですか？
まずテストURLとタイムアウト設定を確認し、次にコアの実行ログを確認してください。TLSや認証に関するエラーがある場合は、サブスクリプションが最新か、システム時刻が正確か、トランスポート設定を手動で変更していないかを調べます。ポートに接続できているなら、ローカルの待ち受けポートを何度も変更しても、リモート側のハンドシェイクエラーは解決しません。
プロキシ接続テストは成功するのにブラウザーで開けません。ノードの故障でしょうか？
まず使用中のサーバーを確認し、「システムプロキシ」の状態とブラウザーのプロキシ設定を調べます。プロキシを手動設定したアプリでは、ローカルアドレスとポートも確認してください。一部のドメインだけ接続できない場合は、ルーティングによって直接接続されていないか、DNSが異常なアドレスを返していないかを調べましょう。ひとつの接続先での失敗を、ノード全体の故障と判断しないでください。
ダウンロードは最大速度が出るのに、Webページの表示に時間がかかるのはなぜですか？
継続的な転送が速くても、接続の確立が速いとは限りません。Webページは複数のドメインにアクセスし、名前解決やハンドシェイク、応答待ちが何度も発生します。まずプロキシ接続のばらつきを確認し、ブラウザーの開発者ツールにあるネットワークパネルで、DNS、接続、TLS、応答待ちの所要時間を切り分けます。必要に応じて別の接続先でも試し、サイト側の処理が遅い可能性を除外してください。
デスクトップとAndroidで測定結果が違います。どちらを信頼すればよいですか？
まず両方の端末を同じネットワークに接続し、同じノードとテスト先を使って近い時間帯に測定してから比較します。v2rayNはデスクトップクライアント、v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。テストの実装や設定も異なる場合があります。それぞれの結果は、まず各端末の測定時点での接続条件を示すものです。異なる端末の結果をそのまま順位付けするのは適切ではありません。
テスト日時、ネットワーク接続方法、ノード名、プロキシ接続の成功回数、遅延の中央値、ダウンロード平均速度を簡潔に記録しておけば十分です。サブスクリプションURLや認証情報を含む画面を公開しないでください。さらに調べる場合は、トラブル診断で「接続できない」または「一部のサイトにアクセスできない」から原因を絞り込めます。