ノード一覧のミリ秒表示とダウンロード速度は、異なる指標です。Tcpingはサーバーのポートに接続できるか、実接続遅延はプロキシ経由のリクエストが完了するか、速度テストは継続的なデータ転送能力を確認します。「遅延は低いのにページが開かない」「実接続がタイムアウトするのにポートにはつながる」といった場合に向けて、各テストの範囲や結果の読み方、確認手順を解説します。数値だけでノードを並べ替えるのではなく、使えるノードを見極める方法を紹介します。
3種類のテストで確認できる範囲
まず接続経路を分けて考えましょう。端末からノードのサーバーに接続し、プロキシコアがプロトコルや伝送方式をネゴシエーションした後、ノードから接続先のWebサイトへアクセスします。ノードサーバーが応答しても、認証に成功するとは限りません。認証に成功しても、接続先のWebサイトにアクセスできるとは限りません。3種類のテストは確認する範囲が異なるため、結果を相互に置き換えることはできません。
Tcping：サーバーポートへの接続確認
ノードのアドレスとポートへのTCP接続を試み、主に接続確立までの時間を測定します。VMessやVLESSの認証情報は検証せず、接続先のWebページにもリクエストしません。
用途：ポートに接続できない、サーバーアドレスが誤っているなど、基本的な接続問題の切り分け。
実接続遅延：プロキシ経由のリクエスト確認
おすすめテスト対象のノード経由で指定のテスト先にリクエストを送ります。プロキシプロトコルのネゴシエーションから、ノードの出口を経由したアクセスまでを確認できます。普段のWebアクセスに近いテストですが、結果が示すのはそのテスト先への接続だけです。
用途：普段使うノードを選ぶ際に、プロキシ経由のリクエストが完了する候補を絞り込む。
ダウンロード速度テスト：継続的な転送能力
テスト対象のノード経由でテストデータをダウンロードし、一定時間の転送速度を確認します。テストサーバー、ネットワークの混雑状況、測定時間、同時接続数などが結果に影響します。
用途：接続できることを確認した後、大容量ファイルのダウンロードなど、継続的に通信する用途を比較する。
v2rayNのメイン画面でサーバーを選択し、右クリックメニューから「サーバー遅延をテスト Tcping」「サーバー実接続遅延をテスト」「サーバー速度をテスト」などの項目を探します。画面やバージョンによって項目名や位置が異なる場合があるため、現在のメニューを確認してください。特定のバージョンのショートカットキーが、すべてのバージョンで使えるとは限りません。
Tcpingの値は低いのに、Webページが開かないのはなぜ？
Tcpingは、OSのpingとは異なります。一般的なpingはICMPを使いますが、ここで確認するのはTCPポートです。サーバーがICMP応答を無効にしていても、TCP接続は受け付ける場合があります。反対に、pingに応答するホストでも、ノードが使うポートが開いているとは限りません。
ノードにドメイン名を設定している場合、接続前にIPアドレスを取得する必要があります。DNS名前解決の時間が表示結果に含まれるかはテストの実装によるため、Tcpingの数値だけでDNSが正常だとは判断できません。実際の通信にTCPを使わない設定では、TCPによる疎通確認を実際のプロトコルテストの代わりにすることもできません。
- ポートには接続できるが、認証に失敗：UUID、パスワード、プロトコルの設定が誤っていても、TCP接続は成功し、プロキシ経由のリクエストだけ失敗する場合があります。
- 入口には接続できるが、伝送設定が不一致：WebSocketのパスやHost、TLSのサーバー名が一致しないと、その後のネゴシエーションで拒否されることがあります。
- 前段のサービスから応答：リバースプロキシやCDNを使うノードでは、Tcpingが測定するのは前段の接続先であり、バックエンドのプロキシサービス全体の状態とは限りません。
- 出口からのアクセスに制限：ノードへの接続後も、出口ネットワークの障害や接続先の制限などにより、テストサイトの名前解決や接続に失敗することがあります。
判断の目安：ポートに接続できたら、プロキシ経由のリクエストを確認
Tcpingの結果が出るのにWebページが開かない場合は、次に実接続遅延を測定し、コアのログを確認します。ミリ秒の値が低いというだけで、ローカルのシステムプロキシ設定を何度も変更しないでください。
実接続遅延に含まれる処理とタイムアウト時の確認先
実接続遅延は、単純な「端末からサーバーまでの距離」ではありません。通常はノードへの接続、プロキシプロトコルのネゴシエーション、ノードからテスト先へのアクセス、応答待ちなどが含まれます。HTTPSのテスト先を使う場合は、TLSの処理も関係します。計測範囲や接続の再利用、成功の判定方法はバージョンごとの実装で異なるため、異なるツールの結果をそのまま比較して順位付けするのは適切ではありません。
まず「設定」→「パラメーター設定」で、実接続テスト先、速度テスト先、タイムアウト関連の項目を確認します。画面に複数のタブがある場合は、「テスト」や「速度」に関連する設定を探してください。実際のURLを記録してからノードを比較します。空の応答や小さなデータを返すテスト先はリクエスト遅延の確認に、大きなファイルを返すテスト先は転送速度の確認に適しています。目的が異なるため、使い分けましょう。
- 一度にテストするノードは1つ。一括処理を停止し、同じノードを個別に再テストします。複数の接続によるローカル帯域の競合や、サーバー側の制限を避けられます。
- ノードの設定を確認。サーバー一覧で該当項目を編集し、参照元の情報とアドレス、ポート、認証情報、伝送方式、TLS設定を照合します。推測で項目を補わないでください。
- システム時刻を確認。OSの時刻を自動で同期する設定にします。時刻が大きくずれていると証明書の検証に影響し、時刻を要件とするプロトコル認証にも影響する場合があります。
- ログのエラー発生段階を確認。接続タイムアウトならまず疎通状況を、証明書エラーなら時刻とサーバー名を、認証や伝送のエラーならノード設定を確認します。timeoutの表示だけでは、どちら側に問題があるかは特定できません。
- アクセス可能な別のテスト先で再確認。元のテスト先だけで失敗する場合は、ノードの出口からそのテスト先への接続を引き続き確認します。すぐにノード全体が使えないと判断しないでください。
ダウンロード速度テストの見方：単位・時間・データ量
ダウンロード速度テストで測るのは転送速度であり、応答遅延ではありません。遅延の大きい回線でも、ダウンロードを続ければ高い速度が出る場合があります。一方、遅延の小さい回線でも、出口の帯域やサーバー側の速度制限で速度が伸びないことがあります。リクエストへの応答の速さと、長時間のダウンロードの安定性は分けて判断しましょう。
上記の帯域値は単位換算の例であり、本サイトで測定した結果ではありません。大文字のBと小文字のbに注意してください。MB/sは1秒あたりのメガバイト、Mbpsは1秒あたりのメガビットです。画面にMiB/sと表示される場合は、MB/sとは換算の基準も異なります。比較する前に単位をそろえ、通信事業者の公称帯域から速度テスト欄の数値をそのまま差し引かないでください。
- テストサーバーをそろえる：同じノードでも、ダウンロード先を変えると結果が変わることがあります。テストサーバー側の速度制限や負荷、設置場所も結果に影響します。
- テスト条件をそろえる：同じネットワーク、近い時間帯、同じ速度テスト設定で測定します。大容量ファイルのダウンロード、クラウド同期など、帯域を使う処理は一時停止してください。
- 一時的な最高速度だけで判断しない：短時間のテストでは、接続の確立や転送速度が上がる段階の影響を受けます。クライアントに表示される値が平均速度なのか、別の統計値なのかを確認してから結果を見てください。
- データ通信量に注意：仮に10 MB/sで10秒間ダウンロードすると、データ量はプロトコルのオーバーヘッドを除いて約100 MBです。複数ノードをまとめてテストすると、その分の通信量も増えます。
テスト結果をノード選びに活用する手順
最初からすべてのノードでダウンロード速度を測る必要はありません。まず接続できるかを確認し、次に実際のリクエストが完了するかを確認して、最後に少数の候補だけ速度を測ります。問題の切り分けがしやすくなり、不要なデータ通信も減らせます。以下の表は結果の組み合わせを解釈するためのもので、特定のノード群の実測データではありません。
| 結果の組み合わせ | まず確認すること | 次に行うこと |
|---|---|---|
| Tcping成功、実接続はタイムアウト | 入口には接続できるが、その後のプロキシリクエストが完了していない | プロトコル設定、コアのログ、テスト先を確認 |
| 実接続は成功、ダウンロード速度は低い | 基本的なリクエストは可能だが、転送速度に制限がある | テストサーバーを統一し、ローカルで帯域を使う処理を停止して再測定 |
| 実接続は遅いが、継続ダウンロードは速い | 応答遅延と継続的な転送速度は異なる | Webページの操作かファイルのダウンロードか、実際の用途に合わせて選ぶ |
| テストは成功するが、ブラウザーから接続できない | アプリのプロキシ経由設定や接続先のルーティングが異なる可能性がある | システムプロキシ、ブラウザーの設定、適用されるルールを確認 |
手順：リクエストが安定して完了するノードを残し、転送速度を比較
候補ノードごとに実接続テストを3回行い、失敗回数と所要時間の変化を記録します。何度もタイムアウトする項目を除外してから、残った候補のダウンロード速度を測定します。最後に、実際にアクセスしたいWebサイトで確認してください。
3回の結果を昇順に並べ、中央値を今回の比較の目安にしつつ、失敗した回数も記録します。タイムアウトを0ミリ秒として平均を計算しないでください。失敗したノードが「速い」と誤って評価されます。時間帯が異なる結果は分けて記録しましょう。夜間の混雑は、日中のテスト1回だけでは判断できません。
遅延テストでよくある質問
「-1」やタイムアウトと表示されます。ノードが完全に使えなくなったのでしょうか？
必ずしもそうとは限りません。負の値やタイムアウトは通常、実際の遅延ではなくテストの失敗を示します。まず対象ノードだけを再テストし、テスト先とログを確認してください。複数のノードが同じテスト先で失敗する場合は、別のテスト先でも確認します。1つのノードだけで失敗が続く場合は、そのノードの設定とサーバーの状態を調べてください。
テスト直後は速かったのに、しばらくすると遅くなるのはなぜですか？
一覧に表示されるのは1回分のテスト結果であり、継続的な監視結果ではありません。同じテスト先を使い、ダウンロードなどのバックグラウンド処理を止めて3回測定し、所要時間と失敗状況を記録してください。特定の時間帯に変動が集中する場合は、その時間帯の実際のアクセス状況も比較します。一度のピーク値だけで設定全体をすぐに変更する必要はありません。
ノードのテスト前に、システムプロキシやTUNを有効にする必要がありますか？
内蔵テストでは通常、テスト対象のノードに向けてテスト用の経路を作るため、システムプロキシやTUNを有効にすることは必須ではありません。まずコアが正常に起動していることを確認します。テスト成功後、ブラウザーなどのアプリに適用する経路を設定してください。複数の経路制御方式を同時に使う場合は、ループ接続や経路の混同が起きていないかも確認します。
実接続が最速のノードは、ダウンロードにも最適ですか？
必ずしもそうとは限りません。まず実接続テストで使えるノードを絞り、その中から少数の候補でダウンロード速度を測ります。ダウンロードでは継続速度と安定性を、Webページの操作では応答の速さと失敗率を重視します。テスト先と実際に使う接続先が異なる場合もあるため、最後は実際の利用環境で確認してください。