「遅延は低いのにWebページが開かない」「速度テストはタイムアウトするのにブラウザーは使える」といった場合は、入口ポート、プロキシ経路、ダウンロード速度を切り分けましょう。4種類の指標が測る範囲、v2rayNでのテスト手順、再現可能な記録方法、タイムアウトの調べ方を解説します。サブスクリプションを登録済みで、普段使うノードを選びたい方に向けた内容です。
4種類のテストを比較：数値が測る範囲
ノードの状態は、ミリ秒の数値ひとつでは表せません。Webページへのリクエストは、ローカルプロキシポート、ノードの入口、プロトコルのハンドシェイク、ノードの出口、接続先サイトを経由することがあります。ICMP pingやTCPingは通常、入口付近までを測定します。実接続遅延はプロキシ経由のリクエストまで確認し、ダウンロード速度は継続的なデータ転送能力を測ります。測定の終点が異なるため、数値を同じ「速さランキング」に並べて比べることはできません。
| テスト | 主な測定範囲 | このテストだけでは確認できないこと |
|---|---|---|
| ICMP ping | この端末から対象ホストまでのICMP往復時間と応答状況 | ノードのサービスポートが開いていること、プロキシ認証が正しいこと |
| TCPing | この端末からノードの指定TCPポートへ接続するまでの時間 | VMessまたはVLESSの設定が正しいこと、出口からWebサイトにアクセスできること |
| 実接続遅延 | テスト対象ノード経由でテスト先へリクエストを送る時間 | すべてのWebサイトにアクセスできること、長時間の転送が安定すること |
| ダウンロード速度 | ノード経由で指定リソースから継続的にデータを受信する速度 | Webページの応答が速いこと、ゲームでUDP通信が安定すること |
ICMPにはTCPポートがありません。ノードのサービスが443番ポートで待ち受けていても、通常のpingではそのポートを調べられません。また、サーバーがICMPを制限している場合もあるため、「pingが通らない」からといってプロキシが使えないとは限りません。ノードのアドレスの前に中継サーバーやCDNがある場合、調べているのは最終的な出口ホストではなく、その手前の入口である可能性もあります。
TCPingの成功で確認できるのは、特定のTCPエンドポイントが接続を受け付けたことだけで、プロキシプロトコルの検証まではできません。ポートの応答が速くても、ユーザーID、TLSサーバー名、トランスポート経路などの設定が誤っていれば、その後のリクエストは失敗します。TCP以外のトランスポートを使う設定では、TCPingで実際の通信を確認することもできません。
指標の選び方：まず接続可否、次に速度を確認
実接続遅延
おすすめ普段使うノードを選ぶときは、まずプロキシ経由のリクエストが完了するかを確認し、複数回の結果を比べましょう。テスト先と実際のWebサイトで経路が異なる場合もあるため、実際のアクセスも確認してください。
向いている用途：Web閲覧、オフィスアプリ、普段使いのノード選び
TCPing
ノード入口のTCPポートに接続できるかをすばやく確認できます。実接続に失敗したときの原因切り分けに役立ちますが、最小値だけでメインのノードを選ぶのは避けましょう。
向いている用途：入口の接続確認、障害の切り分け
ダウンロード速度
一定時間の転送速度を確認します。ファイルサイズ、測定時間、通信量に注意してください。配信元サーバーの速度制限によって、測定値が低くなることもあります。
向いている用途：大容量ファイルの転送、動画再生時のバッファリング性能の確認
実接続遅延は、Webページの読み込み時間全体と同じとは限りません。バージョンによって、テストリクエストの計測範囲、接続の再利用、成功判定が異なる場合があります。HTTPSリクエストには、DNS、プロキシプロトコル、TLS、接続先からの応答が関わることもあります。比較する際は、クライアントのバージョン、コア、テスト先、ネットワーク環境をそろえ、別の端末での単発の結果と比べて結論を出さないようにしましょう。
判断のポイント：継続して失敗するノードを除外し、安定性を比べる
実接続テストを5回連続で行い、成功回数と中央値を記録します。すべて成功した候補の中から、実際のWebサイトでの使い勝手やダウンロード用途に合わせて選びましょう。TCPingが一度だけ極端に低い値を示しても、繰り返しタイムアウトする事実を見落とさないでください。
v2rayNで条件をそろえてテストする
まずサブスクリプションを更新し、ノードの設定がすべて読み込まれていることを確認します。次に、システム更新、クラウド同期など、大量の通信が発生する作業を一時停止してください。以下はv2rayNの一般的な中国語UIを前提にしています。バージョンによってメニュー名は多少異なりますが、右クリックメニューの「Tcping」「真连接延迟」「速度」はそれぞれ異なるテストです。結果を混同しないようにしましょう。
- テスト条件を記録する。「ヘルプ」→「バージョン情報」または現在のバージョン情報を確認できる画面でバージョンを記録し、使用中のコア、Wi-Fiか有線接続か、テスト日時も控えます。速度テストのために複数の設定を同時に変更しないでください。
- 候補を絞る。ノード一覧から3～5個を選び、右クリックして「Tcping」と表示されるテストを実行し、まず入口ポートを確認します。大規模なサブスクリプションの全ノードを一度に並列テストするのは避けましょう。
- 実接続テストを実行する。ノードを選択したまま、右クリックメニューから「真连接延迟」と表示されるテストを選びます。失敗したら、まずタイムアウトとして記録し、すぐにテストのタイムアウト時間を大幅に延ばさないでください。
- テスト先を固定する。「設定」→「パラメーター設定」で速度または遅延テストに関する項目を探し、現在のテスト先とタイムアウト設定を記録します。バージョンによって専用の設定画面がある場合は、実際の画面に従ってください。各回でテスト先を変えないようにします。
- 複数回測定する。各回を約10秒空けて、合計5回測定します。タイムアウトは別に数え、成功した値を並べて中央値を求めます。タイムアウトを0ミリ秒として平均に含めないでください。
- ノードごとにダウンロード速度を測る。残したノードを個別に速度テストするか、信頼でき、速度テストが許可されたリソースを使って約20～30秒間測定します。続ける前にサブスクリプションの通信量残高を確認してください。
測定例を読む：低遅延と高速通信が食い違う理由
以下は結果の読み方を説明するための例であり、本サイトでの実測値やノード性能を保証するものではありません。ノードAの実接続テストを5回行った結果が176、184、181、179、180ミリ秒で、ダウンロード中の平均速度が8.0 MB/sだったとします。測定条件は固定し、ほかにダウンロードは実行していないものとします。
42ミリ秒と180ミリ秒は矛盾しません。前者は入口までのTCP接続確立だけを示し、後者はより多くのプロキシリクエスト処理を含みます。また、テストごとに接続、経路、計測範囲が異なるため、差し引いた値を「ノードの処理時間」とみなすことはできません。
| ノード例 | TCPing | 実接続 | ダウンロード | 結果の見方 |
|---|---|---|---|---|
| A | 42 ms | 5回中5回成功、中央値180 ms | 8.0 MB/s | 普段使いの候補にできる |
| B | 18 ms | 5回中3回成功、成功値の中央値290 ms | 1.2 MB/s | 入口は速いが、リクエスト全体が不安定 |
| C | 96 ms | 5回中5回成功、中央値240 ms | 15.0 MB/s | 大容量ファイル向き。応答性は別途確認 |
ノードCはノードAより転送速度が高くても、すべてのWebページをより速く開けるとは限りません。Webページの表示には複数のリクエスト、スクリプトの実行、リソースサーバーの応答が関わります。一方、大容量ファイルのダウンロードでは接続確立後に帯域を使い続けやすくなります。単位もそろえてください。10進法では8.0 MB/sは約64 Mb/sです。これはアプリケーション層で測定したデータ転送速度であり、回線の公称速度と完全に一致するとは限りません。
タイムアウトの切り分け：入口、プロトコル、接続先を順に確認
タイムアウトが発生したら、まずどのテストが失敗したのかを確認します。すべての失敗を「ノードの故障」と考えると、サブスクリプションを何度も切り替えるだけで、ローカルポートの競合、テスト先への接続不可、ルート設定による直接接続など、実際の原因を見落としかねません。
TCPingは低遅延なのに、実接続がタイムアウトするのはなぜ？
クライアントのログを開き、認証失敗、TLSハンドシェイクエラー、接続切断などの記録を確認します。サブスクリプションに含まれるアドレス、ポート、ユーザーID、トランスポート設定を照合し、システム時刻も確認してください。TCPの入口に接続できても、プロキシプロトコルのハンドシェイクが完了したとは限りません。
ブラウザーでは開けるのに、実接続テストがタイムアウトするのはなぜ？
内蔵テストの接続先だけにアクセスできない可能性を確認し、ブラウザーが本当にテスト対象ノードを経由しているか調べます。直接接続や別のノードを使っている場合もあります。アクセス可能なテスト先をひとつ決めて再テストし、ログで実際に選択された出力先を確認してください。
実接続は成功するのに、ダウンロード速度が数百KB/sしか出ないのはなぜ？
ほかのデータ転送を一時停止し、ノードをひとつずつテストしたうえで、ダウンロードが許可された別のリソースでも確認します。特定のリソースだけ遅い場合は、配信元の速度制限やそのサイトまでの経路が原因かもしれません。すべて遅い場合は、ローカルネットワークやノードの混雑を調べましょう。
pingが通らなくてもWebページは見られる。ノードを変更すべき？
ICMPの結果だけを理由にノードを変更する必要はありません。サーバーがICMPに応答しない場合もあります。実接続の成功率と実際のWebアクセスを引き続き確認してください。パケットロスを調べる場合は、継続的なリクエストや使用中のトランスポートに応じた診断を行い、ICMPの無応答をプロキシ通信のパケットロスと決めつけないようにしましょう。
VMessとVLESSはプロトコル名であり、性能のランクを示すものではありません。特定のノードが速い理由には、入口までの距離、出口の帯域、異なる中継経路などがあります。遅延の数値を2つ比べただけで、特定のプロトコルが必ず速いとは判断できません。プロトコルを変更するときにサーバーも同時に変更すると、条件をひとつだけ変えた比較にはなりません。
ブラウザーの経路を確認する：ローカルプロキシポートを明示する
Windowsでは、利用可能なcurl.exeを使って追加の確認を行えます。ここでは、v2rayNの「設定」→「パラメーター設定」でローカルHTTPプロキシまたは混合プロキシのポートが10808であることを確認し、候補のノードをアクティブにした場合を想定します。このポート番号は例です。画面に別の番号が表示される場合は、実際の値に合わせてコマンドを変更してください。SOCKS専用ポートをHTTPプロキシのポートとして使うことはできません。
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --output NUL --silent --show-error --write-out "http=%{http_code} start=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/- 接続先を確認する：ここでは、コマンドの書き方を例のドメインで説明します。実際に比較するときは、アクセス可能でテストが許可された、内容の安定したHTTPSページを使い、毎回同じアドレスを指定してください。
- 出力を確認する：
httpはHTTPステータスコード、startはリクエスト開始から最初の1バイトを受信するまでの累積時間、totalは今回の転送にかかった合計時間です。v2rayNの実接続欄の値を直接置き換えるものではありません。 - まずローカル側の問題を確認する：
127.0.0.1に接続できないというエラーが表示されたら、クライアントが起動しているか、ポート番号が正しいか、コアが動作しているかを確認してください。すぐにリモートノードの故障と判断しないでください。 - HTTPステータスと接続可否を区別する：403などの応答が返ればHTTPレスポンスを受信していますが、接続先がアクセスを制限している可能性があります。ステータスコードが返ったことだけで、目的の通信が利用可能とは判断できません。
プロキシを明示すると「アプリがシステムプロキシを使っていない」という疑問を減らせますが、コアのルーティングも確認が必要です。ドメインがルールによって直接接続に振り分けられている場合があります。候補ノードを検証するときは、ログでリクエストが該当するプロキシ出力を経由したか確認し、TUNやほかのネットワークソフトが実際の経路を変えていないかにも注意してください。
用途に合わせてメインと予備のノードを選ぶ
用途別の選び方：応答性と継続的なダウンロードを分けて評価
Web閲覧・普段の作業
- 実接続テストが5回すべて成功した候補を優先する。
- 中央値を比較し、最も遅かった回が極端に高くないか記録する。
- 普段使うWebサイトを2つ開き、ログインとリソース読み込みを確認する。
- 入口や経路の異なるノードを予備としてひとつ残す。
動画・大容量ファイル
- 接続可否を確認してから、ノードごとの継続的なダウンロード速度を測る。
- リソース、測定時間、速度の単位をそろえ、同時にほかの速度テストをしない。
- 普段利用する夜間の時間帯にも測定し、混雑の影響を確認する。
- 通信量を記録し、帯域を使い切るテストを繰り返さない。
まず安定して使えることを優先し、そのうえで用途に合うノードを選びましょう。メインと予備のノードが、遅延ランキングの1位と2位である必要はありません。
リアルタイム音声通話やゲームに使う場合は、対象アプリでのUDP接続可否、ジッター、継続的なパケットロスも確認する必要があります。TCPing、HTTPの実接続テスト、ダウンロード速度では、これらの指標を直接評価できません。後から問題の原因を特定できるよう、測定日、ネットワーク、ノード、テスト先、成功回数、速度の単位を記録しておきましょう。次に不具合が起きたとき、ローカルネットワークの変化、接続先サイトの変化、ピーク時のノード経路の劣化を見分けやすくなります。