V2Rayノードの選び方｜遅延・通信量倍率・地域・プロトコルを比較

ノード一覧の見方：遅延はダウンロード速度ではない

一般にV2Rayノードとは、クライアントがサーバーへ接続するための設定一式です。アドレス、ポート、プロトコル、認証情報、転送設定などが含まれます。サブスクリプションは設定をまとめて配布し、v2rayNなどのクライアントはノードを管理してコアを使った接続を行います。一覧の名称はサブスクリプション提供元が付けたもので、「高速」「専用回線」や地域の略称がテスト結果を示すわけではありません。

ノードを選ぶ前に、テストで何を測定しているのかを確認しましょう。システムのPingは主にICMPの往復時間、TCP遅延はポートへの接続にかかる時間を測ります。実接続テストでは通常、プロキシ経由で指定されたテスト先へアクセスします。経路も処理内容も異なるため、測定方法の違う数値を同じランキングで比較することはできません。

たとえばTCP接続が60 msでも、動画が途切れず速く読み込まれるとは限りません。実接続が130 msでも、プロキシの処理や接続先への通信時間が含まれるため、ノードの性能が低いとは一概に判断できません。速度表示が5 MB/sなら、10進法で約40 Mbpsです。動画のビットレートと比べる前に単位をそろえましょう。

v2rayNでノードをテストする：条件をそろえて比較

候補を少数に絞り、同じ端末・ネットワーク・テスト先で比較しましょう。以下のメニュー名はWindowsデスクトップ版で一般的な画面を参考にしています。バージョンによって名称や場所が異なる場合があります。同じ項目が見つからないときは、使用中のバージョンのメニューと設定説明を確認し、手順書に合わせるためにサブスクリプションの認証項目を変更しないでください。

1. テスト条件を確認

   「設定」→「パラメーター設定」を開き、現在のローカル待ち受けポートとテスト関連の設定を確認します。ローカルHTTPプロキシのポートが10809なら、ブラウザーで手動プロキシを設定する際も同じポートを指定します。これは確認例であり、すべてのバージョンの初期値ではありません。

2. 候補ノードを絞り込む

   サーバー一覧から3～5個のノードを選択し、右クリックして「サーバー実接続遅延をテスト」を実行します。テスト先を統一して、失敗したノードを記録しましょう。TCP接続は成功しても実接続テストに失敗するノードは、ひとまずメイン候補から外します。

3. 実際のアクセスを確認

   候補を右クリックして「アクティブサーバーに設定」を選び、「システムプロキシ」の「システムプロキシを自動設定」が有効か確認します。実際に使うサイトを開き、クライアントのログも見て、リクエストが想定したプロキシ経由で送信されていることを確かめましょう。

4. 再テストして予備を確保

   候補ノードを繰り返しテストし、普段使う時間帯にも再確認します。メインを1つ、出口または経路の異なる予備を1つ確保しましょう。同じサーバーに別の表示名が付いているだけのノードを、別回線と誤認しないよう注意してください。

以下は実行しやすいテスト手順の例です。当サイトの実測値でも、プロトコルの性能基準でもありません。3回とも成功しても短時間利用できたことを示すにすぎず、実際の用途での確認が必要です。タイムアウトした場合は再テストし、最も良い結果だけを採用しないでください。

通信量倍率の計算方法：課金ルールを確認

通信量倍率はサービス提供元の課金ルールであり、VMessやVLESSなどのプロトコル仕様ではありません。一般的には実際の通信量に倍率を掛けて、利用可能な通信量から差し引きます。提供元がこの方式を採用している場合、倍率2倍の回線で10 GBを転送すると、20 GB分が消費されることがあります。倍率が高いからといって速度が速いとは限らず、倍率0だから品質が良いとも限りません。

• まずルールを確認：アップロードとダウンロードの両方が通信量に含まれるか、時間帯によって倍率が変わるか、管理画面でGBをどう定義しているかを確認します。
• 次に月間使用量を試算：動画の実通信量が60 GBの見込みで、倍率1.5倍の回線を使う場合、乗算方式なら通信量枠を約90 GB消費します。
• 業務利用分も見込む：システム更新、ファイル同期、速度テストの通信量も予算に含め、ブラウザーで再生する動画の分だけで計算しないようにします。
• 請求の反映先を確認：クライアントの統計は通常、端末での通信量を示します。一方、サービスの管理画面では倍率や送受信の両方向の課金、集計の遅延が反映される場合があり、両者の数値が一致するとは限りません。

平均8 Mbpsの動画を例にすると、1時間連続で再生した場合、10進法で概算約3.6 GBの通信量になります。倍率2倍なら約7.2 GB分が差し引かれます。実際の使用量は、可変ビットレートや音声トラック、バッファリングによっても変わります。通信量に余裕がない場合は、一度だけの速度テストで高い数値が出たノードより、再生に必要な速度を継続して確保できる低倍率のノードを優先しましょう。

ノードの地域の選び方：入口・出口・接続先を区別

地域表示は入口サーバーの所在地を示す場合も、最終的な出口の所在地を示す場合もあります。中継回線では両者が異なることがあります。クライアントはまず入口に接続し、接続先サイトに見えるのは通常、出口のIPアドレスです。特定地域のサービスを利用する場合は、出口と接続先プラットフォームでの判定を確認しましょう。遅延を重視する場合は、地図上の距離だけでなく通信経路全体を確認します。

物理的な距離が近くても遠回りする回線は、距離が遠くても経路が直線的な回線より遅くなる場合があります。同じ出口地域でも、IPの種類、ルーティング、サーバー負荷が同じとは限りません。サイトを利用できるかどうかは、アカウントの地域、IPアドレスのデータベース、コンテンツのライセンス、リスク管理の方針にも左右されます。地域を変えればすべての制限が解消するとは限りません。

プロトコルの選び方：まず互換性、次に回線を比較

VMessとVLESSはプロキシプロトコル、WebSocketは転送方式です。TLSとREALITYは接続のセキュリティ設定に関わり、XTLS Visionは特定のフロー制御方式です。それぞれ異なる階層の用語なので、同じ種類の選択肢として単純に順位付けすることはできません。VLESS自体にはデータ暗号化機能がないため、実際の運用では適切な転送セキュリティ設定と組み合わせる必要があります。

以下の2つのカードは、サブスクリプションに含まれる設定の組み合わせを見分けるためのもので、すぐに使えるサーバー設定ではありません。アドレス、ポート、ユーザーID、セキュリティ関連の設定はサーバー側と一致させる必要があります。特定の名称を使うためにVMessをVLESSへ変更したり、対応していないサーバーにVisionを追加したりしないでください。

デスクトップ版v2rayNでは、異なるコアの設定を管理できます。利用できる機能はインストールしたバージョンと選択中のコアによって異なります。Android版のv2rayNGはXrayを、v2flyNGはV2Flyをベースにしています。REALITYなどの設定を使う場合は、まずコアが対応しているか確認してください。プロトコル非対応による接続失敗は、回線の混雑とは別の問題です。用語の詳しい説明は詳細ガイドのプロトコル解説をご覧ください。

用途に合わせてメインと予備を決める

ノードを比較する前に、まず「許容できないこと」を決めましょう。Web閲覧では頻繁な待ち時間や突発的なタイムアウト、動画では継続的なスループット不足、リモートワークでは接続切断や出口の変化が大きな問題になります。テスト内容を実際の用途に合わせるほうが、一覧全体から最低遅延のノードを探すより効果的です。

動画視聴では、ビットレートのピークやネットワークの変動に備え、平均ビットレートを上回るスループットの余裕が必要です。ただし、すべてのサービスに当てはまる一定の倍率はありません。仕事では会議アプリがUDPを使う場合があります。ブラウザーでWebサイトが開けても、会議の通信が使えるとは限らないため、実際のアプリで音声・映像と画面共有をテストしましょう。

• メインノード：最もよく使う時間帯に動作を確認し、地域、倍率、実接続の結果、実際の使用感を記録します。
• 予備ノード：できるだけ別の回線または出口を選ぶと、メイン回線の障害時に切り替える意味があります。
• 切り替えのタイミング：まず、現在の作業を切断しても問題ないか確認します。長時間接続は通常、新しいノードへ途切れずに引き継げません。
• 定期的に再確認：サブスクリプションの更新でサーバーのアドレスや設定が変わることがあります。表示名が同じでも再テストしましょう。

どのノードも遅いときは、まずローカル環境を確認

すべての候補ノードで同時に問題が起きても、サブスクリプション全体が使えなくなったとは限りません。システムプロキシの設定は、それに従うアプリにのみ影響します。手動プロキシ、TUN、クライアントのルーティングでは、通信経路が異なることもあります。ブラウザー拡張機能、古いプロキシポート、ローカルDNSも結果に影響します。原因を調べるときは一度に1項目だけ変更し、どの設定が影響したかを特定できるようにしましょう。

1. バックグラウンドのダウンロードを一時停止し、同じネットワークでプロキシを経由しない通常の通信をテストして、ローカル回線が混雑していないか確認します。
2. アクティブサーバー、システムプロキシのアドレス、待ち受けポートを確認します。たとえば、クライアントの待ち受けが127.0.0.1:10809の場合、アプリが古いポートを参照していないか確認してください。
3. ログで接続失敗や名前解決エラーを確認し、テストリクエストが直結ルールではなくプロキシ経由になっていることを確かめます。関連するルールはルーティングと分岐設定の解説をご覧ください。
4. 特定のサイトだけ失敗する場合は、別の接続先でも試してから、そのサイトのアクセス条件を確認しましょう。すぐに設定全体を作り直す必要はありません。