まずTCPingでノードの接続口を確認し、実接続遅延でプロキシ経路を確かめ、最後にダウンロード速度で継続的な転送性能を見ます。「遅延は低いのにWebページが開かない」「速度測定は速いのに普段は重い」といった場合に役立つ内容です。同じネットワーク・同じ接続先で複数回測定し、一覧の最小値だけでなく結果を比べましょう。
1. 測定対象を確認：3つの数値はそれぞれ別の指標
まずメニューに表示されたテスト名を確認してから数値を比べましょう。TCPingは通常、ノードサーバーのTCPポートに接続し、接続確立までの時間を測定します。一般的なICMP Pingとは異なります。時間はms（ミリ秒）で表し、通常は小さいほど良好です。ダウンロード速度は一般にMB/sで表示され、1秒あたりの転送量を示します。こちらは通常、大きいほど高速です。
実接続遅延は、ノード経由で実際にリクエストを送り、プロキシから指定のテスト先にアクセスできるかを確認します。クライアントのバージョンやコア、テスト先によって計測の開始点と終了点は異なる場合があります。プロキシのハンドシェイク、接続先への接続、TLSハンドシェイク、応答待ちなどの時間が含まれることがあり、サーバーとのネットワーク往復時間と単純にみなすことはできません。
TCPing：接続口のポートを確認
「この端末から指定したアドレスとポートに接続できるか」を確認します。VMessやVLESSなどのプロキシ認証は検証せず、ノード経由で目的のWebサイトにアクセスできることも保証しません。
用途：接続口に到達できない設定を手早く除外し、アドレス・ポート・ローカルネットワークを確認する。
実接続遅延：普段使えるかを優先して確認
おすすめ設定を使ってプロキシ経路を確立し、テスト先にアクセスします。ポートへの単純な接続よりWebページを開く動作に近いテストですが、成功しても確認できるのはそのテスト先へのアクセスだけです。
用途：普段使いのノード選びや、プロトコル設定・プロキシ出口の動作確認。
ダウンロード速度：継続的な転送性能を確認
ノード経由でデータを継続して受信します。結果はローカル回線の帯域、ノードの負荷、出口までの経路、ダウンロードサーバーの制限にも左右され、Webページの表示速度にそのまま換算できるものではありません。
用途：動画や大容量ファイルのダウンロード、同じ時間帯における継続的な転送速度の比較。
2. TCPingは低いのにWebページが開かない：経路を順に確認
プロトコルを何度も切り替える前に、原因を切り分けましょう。TCPingの成功が示すのは、接続口のTCP接続が確立したことだけです。ノードの接続先がリバースプロキシや中継サーバーの場合、テストは接続口の段階で終わることがあります。その先のプロキシ認証、サーバーの転送処理、接続先サイトはまだ確認されていません。
| 症状 | まず確認する項目 | 次に行うこと |
|---|---|---|
| TCPingは成功、実接続は失敗 | プロトコル設定・認証・通信方式・セキュリティ設定 | サブスクリプションのアドレス、ポート、ユーザーIDに加え、TLS、SNI、通信パスを確認します。接続口に到達できることだけで、設定が正しいと判断しないでください。 |
| 実接続は成功、一部のドメインだけ失敗 | DNS・ルーティング・接続先サイトの制限 | テスト用ドメインと失敗するドメインの経路を比べ、失敗したリクエストが直接接続されていないか確認します。 |
| クライアントのテストは成功、ブラウザーからはアクセスできない | システムプロキシまたはアプリのプロキシ適用範囲 | ブラウザーがクライアントのローカル待ち受けポートを使っているか確認します。AndroidではVPN接続と、対象アプリがプロキシの適用範囲に含まれているかも確認してください。 |
| 別のネットワークに切り替えると復旧する | 現在の接続ネットワークとノードまでの経路 | Wi-Fiとモバイルネットワークの結果は別々に記録し、異なるネットワークの測定値を混ぜて順位付けしないでください。 |
TLSは通信を保護する暗号化プロトコルです。SNIはTLSハンドシェイクで接続先のホスト名を示す情報です。接続口に接続できても、SNI、証明書の検証、WebSocketのパス、REALITYの設定が一致しなければ、その後のハンドシェイクで失敗することがあります。まずサブスクリプションの設定を確認し、証明書の検証を無効にして問題を隠さないでください。
3. 実接続遅延の測り方：接続先を固定して複数回確認
テスト先を固定し、候補の設定を複数回測定しましょう。テスト先とは、クライアントが接続状態を判定するためのURLであり、ノードサーバーのアドレスではありません。Webサイトごとにサーバーの設置地域、応答方法、アクセス制限が異なります。日によってテスト先を変えると、結果をそのまま比較できません。
- テスト設定を確認します。v2rayNの「設定」→「パラメーター設定」で、遅延テスト先やダウンロード速度測定先に関する項目を探します。具体的な項目名はバージョンによって異なるため、まず現在の値を記録し、数値を下げるために頻繁に変更しないでください。
- テストを個別に実行します。v2rayNの設定一覧で項目を選び、右クリックメニューから「Tcping」「実接続遅延」といったテストをそれぞれ実行します。一括テストと大容量ファイルのダウンロードを同時に行わないでください。
- Androidでは利用できるテスト項目を選びます。v2rayNGのメイン画面で右上のメニューを開き、「すべての設定の実接続テスト」などを探します。バージョンによっては、先にサービスを起動する必要があります。項目名が異なる場合は、使用中のバージョンのメニューを確認してください。「テスト成功」は、すべてのアプリがプロキシ経由になったことを意味しません。
- 3回以上測定します。各回の終了後、約10秒待ってから次を測定します。各回の成功・失敗を記録し、成功した結果は最小値ではなく中央値を確認しましょう。
- 実際のアクセスも確認します。設定を選択して接続を開始し、普段使うWebサイトを開きます。テスト先には接続できても実際のサイトを開けない場合は、そのサイトのDNS、ルーティング、アクセス制限を確認してください。
ここに示した数値は測定手順の目安であり、ノードの実測結果ではありません。3回の測定は簡易的な選別に使えますが、長期的な安定性を保証するものではありません。会議や長時間の転送に使う場合は、実際に使う時間帯にも引き続き確認しましょう。一括テストは同時実行数が多いと、ローカルネットワークや端末のリソースを使い切ることがあります。異常が出たら、1つずつ再測定してください。
結論：繰り返し失敗する設定を除外し、成功した結果を比べる
1回だけ極端に短い時間で成功しても、ほかの回の失敗を見落とさないでください。複数回のテストに成功し、実際の接続先にもアクセスできる設定を残してから、典型的な所要時間とばらつきを比べましょう。
4. ダウンロード速度の見方：帯域・単位・測定負荷を確認
ダウンロード速度は、実接続テストに通った少数の設定だけで測定しましょう。スループットは単位時間あたりのデータ転送量で、遅延とは別の指標です。接続確立が速くても継続的な転送性能が高いとは限らず、ダウンロード速度が高くても小さなリクエストへの応答が速いとは限りません。
- まず単位をそろえます。1 Byteは8 bitです。プロトコルのオーバーヘッドを除けば、帯域幅100 Mbpsは約12.5 MB/sに相当します。これは単位換算であり、ノード速度の保証ではありません。表示がMiB/sの場合は、10進表記のMB/sと完全には一致しない点にも注意してください。
- 接続数を確認します。単一接続と複数接続のテスト結果をそのまま比べることはできません。複数接続なら帯域を使い切りやすくなりますが、単一のダウンロードや1本の通信が同じ速度になるとは限りません。
- 測定条件をそろえます。同じダウンロード先、同じ測定時間、同じネットワークを使用し、バックグラウンド同期、システム更新、ほかの端末による大容量通信を一時停止してください。
- 継続的な速度を確認します。開始直後の瞬間的なピーク値は、バッファリングやサンプリングの影響を受けやすいものです。その後も安定しているかを見て、実際の動画再生やファイルのダウンロードでも確かめましょう。
- 通信量に注意します。10 MB/sで20秒ダウンロードすると、データ量は約200 MBです。これにプロトコルのオーバーヘッドが加わります。一括テストではローカル回線とサブスクリプションの通信量がさらに増えます。
測定サーバー自体がボトルネックになることもあります。同じ時間帯にすべての設定で速度が近い低い値になる場合は、ノードがすべて混雑していると判断する前に、ローカルネットワークと測定元を確認してください。ブラウザーでの速度測定はブラウザーのプロキシ設定にも左右されます。選択した設定を通らず、直接接続の経路を測っている可能性があるため、リクエストが実際にプロキシを経由しているか確認しましょう。
5. デスクトップとAndroidでの選び方：同じ手順でプロキシ適用範囲を確認
まず「ノード自体が使えるか」と「アプリの通信がプロキシ経由か」を分けて確認しましょう。v2rayNはデスクトップクライアント、v2rayNGはXrayコアを使用するAndroidクライアントです。同じサブスクリプションを読み込んでも、接続ネットワーク、DNS、プロキシの適用範囲が異なれば結果に差が出ることがあります。2台の遅延が完全に一致する必要はありません。
おすすめの手順：まず設定をテストし、次に実際のアプリで確認
デスクトップ：v2rayN
- まず実接続テストを実行し、選択した設定でテスト先にアクセスできることを確認します。
- システムプロキシを使う場合は、対象のプログラムがシステムプロキシ設定を参照するか確認してください。コマンドラインツールは自動で設定に従うとは限りません。
- ローカルの待ち受けアドレスとポートを確認します。たとえば実際のポートが10808なら、アプリ側でも対応するポートとプロトコルを指定してください。記憶だけで入力しないようにしましょう。
- TUN仮想アダプターで通信を取り込む場合は、取り込み状態とルーティングを確認します。システムプロキシの動作と混同しないでください。
Android：v2rayNG
- 設定を選んでサービスを起動し、システムからVPN権限が付与されていることを確認します。
- アプリごとのプロキシ設定を有効にしている場合は、ブラウザーと実際に使うアプリが想定した範囲に含まれているか確認します。
- Wi-Fiとモバイルネットワークを切り替えたら、改めて測定してください。前のネットワークでの順位をそのまま当てはめないでください。
- バックグラウンドに移行してから通信が切れる場合は、システムのバッテリー制限も確認します。まずノード速度だけを原因と決めつけないでください。
両方の端末でテスト先をそろえつつ、ネットワーク、測定時刻、アプリのプロキシ適用状態はそれぞれ記録します。接続できることを確認してから、遅延とスループットを比べましょう。
結果を記録するときは、測定時刻、クライアントのバージョン、ネットワークの種類、接続先、成功回数、速度の単位を残せば十分です。スクリーンショットを共有する前に、サブスクリプションのリンク、ユーザーID、サーバーの機密情報を隠してください。設定全体を他人に送る必要はありません。まず失敗した段階と関連するエラーメッセージを伝えるだけでも、原因を絞り込めます。
6. よくある質問：タイムアウト・負の値・測定結果の順位
実接続の結果が-1です。遅延が低すぎて測れないのでしょうか？
いいえ。一部のバージョンでは、失敗、タイムアウト、有効な結果がないことを負の数や特別な文字列で表示します。まず使用中のクライアントのステータス説明を確認し、その設定だけを再測定して実行ログも確認してください。負の値を成功結果の順位付けに含めたり、「負の遅延」と解釈したりしないでください。
ブラウザーではWebページを開けるのに、クライアントのテストがタイムアウトするのはなぜですか？
まずテスト先だけが制限されていないか確認し、次にブラウザーが同じ設定を本当に経由しているか確かめます。ブラウザーはキャッシュを使っていたり、別のプロキシ拡張機能を使っていたり、ルーティング設定で直接接続していたりする可能性があります。接続先を固定して繰り返し比較してください。テスト先だけに問題がある場合は、設定で到達できることと応答の安定性を確認した別のテスト先に変更し、基準値を測り直しましょう。
遅延が最も低いノードなのに、動画がバッファリングするのはなぜですか？
まずほかのダウンロードを止め、現在の設定で継続的なスループットを測定します。動画のバッファリングは、動画配信サーバーまでの経路、ノードの出口負荷、ローカルの無線ネットワークが原因の場合もあります。同じ動画、同じ画質、同じ時間帯で比較し、テスト用トップページのミリ秒表示を動画の転送性能の代わりにしないでください。
測定のたびに順位が変わります。1位の設定に切り替え続けるべきですか？
1回だけの最小値を追いかける必要はありません。継続して使えるメイン設定と予備設定を1つずつ残し、3回測定して成功率を確認しましょう。何度も失敗する、明らかにばらつく、実際の作業が遅くなった場合に切り替えれば十分です。数ミリ秒程度の差なら、まず実際の使い勝手を確認し、現在の接続を頻繁に中断しないようにしましょう。
7. 最後に、この順番でノードを選ぶ
- まず接続口を確認。TCP通信ならTCPingで初期確認できますが、ポートに接続できることをプロキシが使えることと同一視しないでください。
- 次に経路を確認。実接続のテスト先を固定して複数回測定し、繰り返し失敗しない設定を優先して残します。
- 次に用途に合わせて確認。普段のWeb閲覧では実接続の安定性を重視します。動画や大容量ファイルではダウンロード速度も測定し、リアルタイム通信は実際のアプリで確認してください。
- 最後にプロキシの適用範囲を確認。システムプロキシ、TUN、Android VPNが適用される範囲を確認し、クライアントのテストは成功しても実際の通信がプロキシを通っていない状態を防ぎます。
各指標が測定する段階に当てはめて考えると、原因を絞り込みやすくなります。TCPingは接続口に到達できるか、実接続はプロキシ経由でリクエストを完了できるか、ダウンロード速度は継続してデータを転送できるかを確認します。まず使えることを確認し、次に安定性、最後にピーク速度を比べるほうが、1つの順位だけを見るより普段の用途に合った選び方です。