「遅延は低いのにWebページが開かない」「Pingはタイムアウトするのにプロキシは使える」「速度測定は速いのに頻繁に途切れる」といった悩みがあるv2rayNユーザー向けの記事です。ホストへの応答、ポート接続、プロキシ経由のリクエスト、継続的な転送速度を区別し、測定先を固定して順番に再テストしたうえで、実際のアプリでも確認しましょう。1つのミリ秒値だけで使いやすさを判断しないことが大切です。
4種類のテスト：数値が示す範囲を確認
v2rayNはデスクトップ向けのGUIクライアントで、ノード設定は選択中のコアが処理します。サーバー一覧に表示される遅延はノード固有の値ではなく、利用中のネットワーク、テスト先、テスト方法によって変わります。Wi-Fiの切り替えやテストURLの変更、同じ時間帯に複数ノードを同時測定することでも、順位が変わる場合があります。
バージョンによってメニュー名やテスト項目、計測範囲が異なることがあります。実行前にテスト名を確認してください。TCPingの結果を「プロキシ経由の通信遅延」と呼ぶことも、ダウンロード速度をWebページの初回表示時間とみなすこともできません。
| 指標 | 主な測定対象 | 分かること | この結果だけでは分からないこと |
|---|---|---|---|
| ICMP Ping | 端末から宛先までのICMP往復通信 | 宛先の応答、往復時間、パケット損失 | プロキシポート、認証、接続先サイトの利用可否 |
| TCPing | 端末から指定TCPポートへの接続 | 該当するアドレスとポートがTCP接続を受け付けるか | VMess、VLESSなどのプロトコル設定が正しいか |
| 実接続遅延 | テスト対象のプロキシ設定を使ったテストURLへのアクセス | 指定したテスト条件で、その設定からリクエストを完了できるか | すべてのWebサイト、UDP通信、長時間ダウンロードが正常か |
| ダウンロード速度測定 | プロキシ経由でテスト用データをダウンロード | そのデータと測定時点における転送速度 | 普段の遅延、長期的な安定性、あらゆる用途での通信速度 |
PingとTCPing：遅延が低くてもプロキシが使えるとは限らない
ICMP Pingでは、プロキシプロトコルの認証情報は送信されず、TLSやWebSocketの経路、サーバー側の外部接続能力も確認されません。サーバーや途中のネットワークがICMPを制限している場合もあります。そのため、Pingのタイムアウトは期待した応答がなかったことを示すだけで、プロキシの障害とは断定できません。反対に、ICMPが正常でもプロキシポートでサービスが待ち受けているとは限りません。
TCPingはポートの疎通確認により近いテストです。たとえばノード設定がTCPの443番ポートを使うなら、設定にあるサーバーアドレスと443番ポートをテストし、別のホストに置き換えないでください。ポートへの接続が成功しても、その後の認証、TLSネゴシエーション、トランスポート経路の照合で失敗することがあります。CDNを使うノードでは、TCP接続がまずエッジの入口に到達する場合があり、実際のプロキシサービスへの到達を意味するとは限りません。
- Pingは応答するが、TCP接続に失敗する：まずノードのポート番号の誤り、ネットワークによるポート遮断、サーバーの待ち受け状態を確認します。
- TCP接続は成功するが、実接続がタイムアウトする：プロトコルのパラメーター、TLSのサービス名、トランスポート設定、サーバー側の転送能力を確認します。
- Pingはタイムアウトするが、実接続は正常：ICMP応答がないことだけを理由に、そのノードを削除しないでください。
- TCP以外のトランスポートを使うノード：TCPingでは該当トランスポートの利用可否を確認できません。コアで実際にプロキシ接続を確立してテストしてください。
実接続遅延：テストURLとコアの両方が結果に影響
実接続テストでは通常、対象の設定でプロキシのアウトバウンド接続を開始または利用し、指定URLにアクセスします。TCPポートだけを調べるより多くの段階を確認できますが、「実接続」の計測基準はすべてのバージョンで統一されているわけではありません。DNS名前解決、プロキシのハンドシェイク、TLS接続、応答の受信などがどこまで計測に含まれるかは、使用中のバージョンの実装によります。
v2rayNでは、「設定」→「パラメータ設定」を開き、遅延テスト先や速度測定先に関する項目を探します。サーバー一覧の右クリックメニューには通常、「実接続遅延」を含むテストコマンドがあります。メニューの分類や表記はインストール済みのバージョンによって異なります。変更前のテスト先を記録し、測定先を変えた後に旧データと新データをそのまま比較しないようにしましょう。
応答サイズの小さいテスト先を固定する
おすすめ安定してアクセスでき、応答サイズの小さい同じURLを使い、プロトコルとリダイレクトの動作もそろえます。ノードを比較するときは、テスト先を変えずノードだけを切り替えてください。
向いている用途：普段使うノードの絞り込み、再テスト結果の比較。
実際に利用するWebサイト
ログイン、ページ内のリソース読み込み、特定の出口制限を確認する際に使います。Webページ全体は複数のドメインへのリクエストで構成されるため、ページ全体の読み込み時間を小さな応答の遅延と同じものとして扱うことはできません。
向いている用途：一般的なテストは通るのに、特定のサービスだけ使えない場合。
大容量ファイルのダウンロード先
転送速度や継続的な通信の確認に適していますが、通信量の少ない頻繁な疎通確認には向きません。リソース側の速度制限、キャッシュの有無、測定時間によって表示結果が変わります。
向いている用途：接続テストを通過した候補ノードのダウンロード性能を比較する場合。
すべてのノードが同じURLで突然タイムアウトする場合は、すべてのサブスクリプションを再インポートする前に、テスト先に問題がないか確認してください。システム時刻、ログに表示された証明書エラー、サーバー側の出口でテスト先へのアクセスが拒否されていないかも確認します。実接続テストに一度成功しても、確認できるのはその時のリクエストが成功したことだけです。
ダウンロード速度測定：帯域幅、単位、瞬間的なピークを区別
遅延はリクエストの往復にかかる時間、スループットは単位時間あたりに転送できるデータ量を表します。両者に関係がある場合はありますが、同じ指標ではありません。遠距離のノードは往復時間が長くても安定したダウンロード速度が高いことがあり、近距離のノードは接続が速くても、共有帯域や混雑によって速度が制限されることがあります。
以下は単位換算の例であり、本サイトによる実測値でも、特定ノードの性能保証でもありません。小文字のbはbit、大文字のBはbyteを表し、10進単位では1 byte = 8 bitです。ソフトウェアの表示がMiB/sの場合は、2進単位との差も考慮してください。
判断の目安：まず接続を確認し、その後に通信量を使って速度を測る
実接続テストに安定して成功した候補のうち、2～3ノードだけを選び、短時間かつ1つずつダウンロードを測定します。最高値ではなく継続速度を記録し、サブスクリプションの通信量の課金方式も確認してください。
- ローカル側の上限：回線速度、Wi-Fiの電波状況、ルーターの負荷、ほかのダウンロードが測定結果を押し下げます。
- リモート側の上限：ノードの出口、速度測定用リソースのネットワーク、単一接続への速度制限、サーバーの混雑状況がスループットを制限します。
- 測定時間：短すぎると安定した転送に入る前に終わることがあり、長すぎると通信量を多く消費します。比較する際は測定時間をそろえてください。
- プロトコルのオーバーヘッド：暗号化、カプセル化、再送がリソースを消費するため、実際の通信速度は公称回線速度から計算した理論値に届かないのが一般的です。
再現性のある選び方：条件をそろえ、段階ごとに記録
全ノードを選択して、複数種類のテストを同時に実行しないでください。並行タスクがローカルの帯域、接続リソース、CPU時間を奪い合い、テスト自体が待ち行列を発生させることがあります。まず候補を広く絞り、対象を減らしてから実際のアプリで確認する方法が確実です。
- 環境を固定：システム更新や大容量ダウンロードを一時停止し、同じネットワークを使います。使用中のコア、テストURL、測定時刻も記録してください。
- ポートを初期確認：該当するTCPノードの接続性を確認します。この段階は候補を絞るためのもので、Pingの結果だけを理由にノードを除外しないでください。
- 実接続を再テスト：候補ノードを1つずつ5回測定し、成功回数と各回の所要時間を記録します。5回すべて成功しなかった場合、成功した回だけの平均値を記録しないでください。
- 中央値で比較：たとえば5回の結果が180、185、190、210、900 msなら、並べ替えた後の中央値は190 msです。900 msの突出値も記録し、中央値でばらつきを隠さないようにしてください。
- 短時間でスループットを測定：安定した候補2～3ノードを選び、同じリソースと測定時間で1つずつ実行します。上記の数値は計算例であり、実測ノードのランキングではありません。
- 実際のアプリで確認：使用するノードに切り替え、システムプロキシまたはTUNが想定どおり有効かを確認してから、普段使うWebサイト、動画、ファイル転送をテストします。
利用目的に合わせて再テストの重点を変える
Web閲覧とインタラクティブな通信
- 実接続の成功率と、繰り返し測定したときのばらつきを優先して確認します。
- 実際のWebサイトで、ドメインの名前解決、ログイン、リソースの読み込みを確認します。
- 混雑する時間帯の結果も記録し、空いている時間の最低値だけで判断しないでください。
大容量ファイルと継続的な通信
- まず接続が安定していることを確認し、その後に継続的なダウンロード速度を比較します。
- ダウンロード先、測定時間、ローカルネットワークを固定します。
- 途中で止まる、再接続するなどの挙動を確認し、瞬間的なピーク値だけで順位を付けないでください。
まとめ：主に使うノードは実際の用途で選び、予備ノードは利用可能な状態で確保。遅延とスループットは分けて記録しましょう。
テストに成功してもアクセスできない場合：実際の通信経路を確認
ノードテストとブラウザーの通信は、入口やルーティングが完全に同じとは限りません。クライアントから特定ノードへのテストが成功しても、ブラウザーがシステムプロキシを使っていない場合や、ルールによって直接接続になっている場合があります。「サーバー一覧のテストが成功した」ことと「現在のアプリの通信がそのノードを経由している」ことは別々に確認する必要があります。
- システムプロキシ：アプリがシステムのプロキシ設定を参照しているか確認してください。コマンドラインツールや一部のアプリは、自動的にシステム設定に従うとは限りません。
- TUN：仮想ネットワークインターフェースが正常に起動したか、必要な権限があるか、関連するルートが有効かを確認してください。スイッチの表示だけで判断しないようにしましょう。
- ローカルの待ち受け：パラメータ設定にある実際のポートを確認します。たとえば手動で
127.0.0.1:10808に設定した場合、アプリ側でも対応するポートと正しいプロキシ方式を使う必要があります。これは設定例であり、現在のバージョンの既定値を示すものではありません。 - ルーティングとDNS：対象ドメインに適用されるルールと通信の出口を確認します。テスト用ドメインにアクセスできても、実際に使うドメインが同じ経路を通るとは限りません。
- コアのログ：接続タイムアウト、認証失敗、証明書エラー、ローカルポートの競合を区別してから、どの設定を変更するか判断します。
VMessとVLESSはプロキシプロトコルの名称であり、速度のランクではありません。プロトコルを切り替えても、設定の確認にはなりません。TLSを使うノードでは、サーバーの要件に合わせてサービス名などを確認してください。テストを成功させるために証明書検証を安易に無効化してはいけません。設定とサーバーが一致していない場合、TCP遅延が低くても解決にはつながりません。
よくある質問：遅延表示、速度測定、ノードの選び方
遅延に-1と表示されます。ノードは完全に使えないのでしょうか？
バージョンによっては、負の値や空欄でテストの失敗を表します。「負の遅延」という意味ではありません。まずTCPingと実接続テストのどちらを使ったか確認し、同じテスト先で対象ノードを単独で再測定して、ログとタイムアウト設定を調べます。複数回失敗し、実際のアプリでも使えない場合に、ノードの障害として調査を続けてください。
遅延80 msのノードが、200 msのノードより遅いのはなぜですか？
まず、2つの数値が同じテストから得られたものか確認します。同じURLへの実接続遅延を比較しているなら、継続的なスループットとリクエストの成功率も確認してください。80 msのノードは接続が速くても出口が混雑している場合があり、200 msのノードは往復に時間がかかっても、より十分な転送帯域を確保できている場合があります。
速度測定時にシステムプロキシを有効にする必要はありますか？
クライアント内蔵のノードテストは、通常、測定対象のプロキシ設定を自動的に使用します。システムプロキシのオン・オフだけを前提にせず、実際の動作は使用中のバージョンで確認してください。ブラウザーや外部のダウンロードツールで検証する場合は、システムプロキシ、TUN、またはツール側のプロキシ設定が有効か、別途確認が必要です。
測定のたびに順位が変わります。常に自動切り替えしたほうがよいですか？
まず条件を固定し、空いている時間帯と混雑する時間帯にそれぞれ5回測定して記録します。差が数ミリ秒程度で成功率も同程度なら、現在の安定したノードを優先してください。継続的なタイムアウト、明らかな通信の停滞、サービスの利用不可が見られる場合に切り替え、通常の変動を障害と誤認しないようにしましょう。
ダウンロード速度が正常なら、動画やリアルタイム通信も問題ないと判断できますか？
いいえ。ダウンロード速度測定で主に分かるのは、特定のリソースに対するスループットです。リアルタイム通信は、ジッター、パケット損失、UDPへの対応、アプリ側の経路選択にも左右されます。実際のアプリを短時間使って確かめ、中断の有無を記録しましょう。1つのダウンロード結果から、あらゆる通信が正常だと判断することはできません。
最終的な選び方：成功率を優先し、遅延と速度は用途に合わせて比較
普段使うノードを1つと、動作を確認済みの予備ノードを1つ確保しましょう。異常が起きたら、まず同じテスト先で再測定し、アプリの通信経路を確認します。サブスクリプションやプロトコル設定を変更するのは、ノードの設定またはサーバー側に原因があると分かった場合に限ります。