サブスクリプションをすでに読み込んだものの、数十個のノードからどれを選べばよいか迷っている方に向けた内容です。まず接続できないノードを除外し、次に実測遅延と安定性を比較します。その後、通信量倍率と接続先地域を確認し、最後にプロトコルを判断します。v2rayNとv2rayNGでの絞り込み手順、実測値の見方、普段使いの予備構成も紹介します。
まず実測接続遅延を測る。ノード名だけで判断しない
ノード名にある「低遅延」「高速」といった表記は、単なるグループ名にすぎず、現在のネットワーク環境での実性能を示すものではありません。家庭用回線、モバイル回線、夜間の混雑、入口回線によって結果は変わります。同じノードでも、午前中は86 ms、夜には240 msになることがあります。一方、「通常回線」と表示されたノードが、長時間120 ms前後を維持する場合もあります。
選ぶ前に、実際の接続を使った遅延テストを行いましょう。現在のノード経由でプロキシ接続を確立し、クライアントに設定されたテスト先へアクセスします。この値には通常、DNS、プロトコルのハンドシェイク、トランスポート層の確立、接続先サイトの応答時間が含まれるため、単純なICMP往復時間よりも普段のウェブ閲覧に近い目安になります。ただし短時間のテストなので、継続的なダウンロード速度だけを判断することはできません。
サブスクリプションを更新
v2rayNのメイン画面で「サブスクリプショングループ」を開き、まず「すべてのサブスクリプションを更新」を実行します。古い一覧の無効なノードが並び替えを乱すため、更新してからテストを始めてください。
コアを確認
「設定」→「パラメーター設定」→「Core タイプ」を開き、現在のノードで使うプロトコルに対応するコアがあることを確認します。v2rayN 7.12.5を例にすると、VLESS、VMess、Trojanは通常Xrayコアで利用できます。
一括テスト
サーバー一覧で同じ地域の候補ノードを選択し、右クリックメニューから「サーバーの実接続遅延をテスト」を実行します。数十個を同時に接続すると数値に影響するため、まずは少数の候補に絞ってテストします。
3回再テスト
20〜30秒間隔で3回テストします。中央値を記録し、タイムアウトの有無も確認してください。1回が72 msでも2回タイムアウトするノードより、3回とも125〜140 msに収まるノードを優先すべきです。
アクティブに設定
結果が安定したノードを選び、アクティブサーバーに設定してからシステムプロキシを有効にします。ローカルのSOCKSポートが10808の場合は、コアのログにポート競合が出ていないかも確認してください。
低遅延でも帯域幅が高いとは限らない
実測接続遅延が主に示すのは、接続確立と短いリクエストへの応答です。500 MBのファイルをダウンロードするなら、継続スループット、パケットロス、混雑状況にも注目してください。あるノードは実測接続遅延が95 msでも、夜間は3 MB/sしか維持できないことがあります。別のノードは150 msでも、12 MB/sを安定して維持できるかもしれません。ウェブ閲覧では前者が軽快でも、大容量ファイルの転送には後者が向いています。
数十ミリ秒の差を重視しすぎる必要もありません。103 msと116 msでは、通常、体感できるほどの差はありません。見るべきなのは変動幅です。98、105、111 msと連続した結果のノードは、62、190、420 msと大きく揺れるノードより、デフォルトに適しています。
| 3回の測定値 | 判断 | 対処 |
|---|---|---|
| 88 / 96 / 101 ms | 遅延が低く変動も小さい | 普段使いの主力候補にする |
| 145 / 162 / 151 ms | 測定値が安定 | ウェブ閲覧や動画視聴に適する |
| 75 / 340 / タイムアウト | 回線の変動が大きい | 様子見で残し、自動選択にはしない |
| 620 / 710 / タイムアウト | 現在のネットワークでは利用不可 | 入口または地域を切り替える |
倍率は通信量の消費量を決める。速度が倍になるわけではない
サブスクリプション名にある0.5x、1x、1.5x、2xは、通常、通信量の課金倍率を示します。10 GBをダウンロードした場合、0.5xノードでは5 GB、2xノードでは20 GBが容量から差し引かれることがあります。具体的な計算ルールはサブスクリプションサービス側が定めます。クライアントはノード名を表示するだけで、容量を自動的に補正することはありません。
倍率は速度と同じ意味ではありません。2xノードがよりよい入口や余裕のある回線を使う場合もあれば、単に課金グループが異なるだけの場合もあります。0.5xノードだからといって、必ず混雑しているわけでもありません。倍率はコスト条件として捉え、3回の遅延測定と実際のスループットを合わせて判断してください。
1xの安定ノード
おすすめ遅延が100〜180 msで、3回の測定における変動が40 ms未満、通信量が通常倍率で計算されるノードです。デフォルトのアクティブサーバーに適しています。
適した用途:ウェブ閲覧、動画、リモートワークなど日常的な通信
0.5xノード
サブスクリプション容量の節約を優先できます。遅延が安定し、必要なダウンロード速度を満たすなら、システム更新、ファイル同期、長時間の動画視聴に向いています。
適した用途:通信量が多く、即時応答への要求が比較的低い用途
2xの高品質回線
実測遅延、パケットロス、夜間のスループットが1xノードより明らかに優れている場合に限り、長期利用する価値があります。倍率だけで品質を推測しないでください。
適した用途:一時的な会議、変動の少ない接続、重要な作業
実際の用途で倍率コストを計算する
月間利用可能容量が200 GBで、普段の動画視聴とダウンロードに120 GB使うとします。すべて2xノードを使うと約240 GBとして計上され、早く上限に達する可能性があります。0.5xノードに替えれば約60 GBです。現実的には、用途を明確にした3本を用意します。1xをデフォルト、0.5xを大容量通信、2xを通常回線が混雑したときだけ使う構成です。
- ノード名に倍率と地域が同時に含まれる場合は、まず倍率の表記を把握します。例:「JP-02 | 0.5x」。
- サブスクリプションの更新後に名前が変わることがあるため、倍率の情報を手動の名前変更だけで保存しないでください。
- クライアントの通信量統計とサービス側の差し引き値には、更新の遅れが生じる場合があります。サブスクリプションアカウントに表示される残り容量を基準にしてください。
- 複数の端末で同じサブスクリプションを使う場合、デスクトップでのダウンロードもAndroid端末での動画視聴も、同じ容量から差し引かれます。
地域はアクセス先で選ぶ。近さは出発点にすぎない
地域は通常、地理的に近い接続先から試しますが、最寄りの都市を機械的に選ぶべきではありません。ネットワーク経路は直線ではなく、入口事業者、国際回線、接続先データセンター間の相互接続が最終結果に影響します。遠くても経路が安定したノードのほうが、近くても迂回を繰り返すノードより速いことがあります。
普段の閲覧では、まず近隣の3地域をテストし、各地域から2本ずつ候補を残します。地域判定のあるサービスにアクセスする場合、接続先の場所はコンテンツ、言語、通貨、ログイン時のリスク警告にも影響します。大きく離れた地域を頻繁に切り替えると、サービスで追加認証を求められることがあるため、主力ノードの地域はできるだけ固定してください。
おすすめ構成:デスクトップとAndroidで同じ候補グループを保持
デスクトップ(v2rayN)
- サブスクリプショングループで同じ地域を絞り込む
- 各地域から安定したノードを2本残す
- 実接続遅延で3回再テストする
- デフォルトでは1xの主力ノードを使う
Android端末(v2rayNG)
- 同じサブスクリプションURLで更新する
- 設定一覧から実接続テストを実行する
- モバイル回線とWi-Fiを分けてテストする
- 異なる地域の予備ノードを1本残す
ノード名は統一して構いませんが、両端末の遅延結果をそのまま流用することはできません。接続回線、DNS、端末の省電力設定によって接続状況は変わります。
用途に合わせて地域の優先順位を決める
主な用途が通常のウェブ閲覧やドキュメント同期なら、「変動の少ない近隣地域 → 安定した次点の地域 → 遠隔地域の予備」の順で保存できます。長時間の動画視聴が必要なら、5分以上の連続再生を行い、バッファリングが繰り返されないか確認してください。一度だけ90 msだった遅延から、夜間の継続帯域を判断することはできません。
- 近隣地域の主力:3回の中央値が180 ms未満で、タイムアウトがなく、倍率も許容できる。
- 同地域の予備:主力とは異なるノード番号を選び、1本のメンテナンスで完全に使えなくなる事態を避ける。
- 別地域の予備:遅延は多少高くても構いませんが、接続が安定していることが条件です。地域全体の回線が不安定なときに切り替えます。
- 高倍率の一時利用ノード:会議、リモート接続、主力回線の混雑時だけ有効にし、使用後は通常ノードへ戻す。
プロトコルは利用可能性を確認した後で判断する
VMess、VLESS、Trojan、Shadowsocksは異なるプロキシプロトコルです。プロトコル名だけでノードの速さを決めることはできません。実際の使い勝手は、トランスポート層、TLS設定、サーバー負荷、入口回線、クライアントコアにも左右されます。設定が正しく回線が安定したVMessノードが、混雑した回線上のVLESSノードを上回ることもあります。
まずクライアントが設定を正しく読み込めることを確認し、その後に接続性と安定性をテストします。v2rayNのデスクトップ版は通常、XrayコアでVLESS、VMess、Trojanを処理します。v2rayNG 1.10.31はXrayコアで対応する設定を処理します。v2flyコア環境が必要な場合、Android端末ではv2flyNGを選べます。サブスクリプションに必要なパラメーターがそろっているなら、特定のプロトコル名にこだわってUUID、トランスポート方式、TLS項目を手動変更しないでください。
| プロトコルタイプ | よくある設定の組み合わせ | 選ぶ際のポイント |
|---|---|---|
| VLESS | TCP、WebSocket、gRPC。TLSまたはRealityと組み合わせ可能 | flow、トランスポート層、安全設定が完全に一致しているか確認する |
| VMess | TCPまたはWebSocket。TLSと組み合わせることが多い | ユーザー識別子、alterId、トランスポートパラメーターを確認する |
| Trojan | TCPとTLSの組み合わせ | パスワード、サーバー名、証明書関連の設定を確認する |
| Shadowsocks | 独立した暗号化方式とパスワード | クライアントコアが、サブスクリプションで指定された暗号化方式に対応しているか確認する |
プロトコル関連のエラーが出たら、まずログを確認する
ノードの遅延が負の値になる、テストがすぐ失敗する、起動後も通信がまったく発生しない場合は、v2rayNのログパネルを開きます。ログに未対応の設定項目が表示されたら、まずクライアントとコアを更新してください。ローカルの待受に失敗した場合は、SOCKSポート10808またはHTTPポート10809が他のプログラムに使用されていないか確認します。ポート番号は「設定」→「パラメーター設定」で確認できますが、実際の値は現在の設定を基準にしてください。
接続は確立しているのにウェブページを開けない場合、プロトコル自体に問題があるとは限りません。システムプロキシが自動設定またはグローバルモードに切り替わっているか、ブラウザーに別のプロキシが個別設定されていないか、ルーティングルールが対象ドメインを誤って直接接続へ送っていないかも確認してください。
- サブスクリプションの読み込みに成功した後は、トランスポート層を手動で置き換えないでください。サーバー側とクライアント側のパラメーターは一致している必要があります。
- 同じノードのTCP設定とWebSocket設定は、別々の候補として扱い、それぞれテストしてください。
- プロトコルが正常に接続できるなら、まず遅延の変動、倍率、地域を比較し、プロトコル名だけで並べ替えないでください。
- コアの更新後に古い設定が使えなくなった場合は、まずサブスクリプションを再更新し、その後ログにある具体的な項目を確認してください。
選別結果を主力・予備・大容量通信の3グループに固定する
ノード選びは一度で終わる作業ではありません。サブスクリプション一覧、入口の負荷、ローカルネットワークは変化します。手間を減らすには、候補を3種類に絞ります。普段使いの主力を1本、異なる回線の予備を1本、低倍率で大容量通信に使うノードを1本です。サブスクリプションを更新するたびにこの数本だけ再テストすれば、数十個の名前を何度も切り替える必要はありません。
v2rayNでは、まずサブスクリプショングループでノードを表示し、次に実接続遅延の列で並べ替えます。自動選択を有効にしたまま結果を確認しないのは避けてください。1回だけ最小になった遅延は、偶然の測定値かもしれません。v2rayNGでも現在の接続ネットワークで再テストします。Wi-Fiで110 msだった値が、モバイル回線に切り替えると260 msになることがあります。
遅延が最も低いノードなのに、なぜ動作が重いのか
実測接続遅延がカバーするのは短時間の接続だけです。連続再生やダウンロードが途切れる場合は、同じ地域の2本のノードで5分間のタスクをそれぞれ実行し、平均速度と中断回数を記録します。単発の最低値ではなく、継続スループットが安定するほうを選んでください。
0.5xノードは必ず遅いのか
必ずしもそうではありません。倍率は通信量の差し引きルールであり、速度制限を示すものではありません。0.5xと1xのノードをそれぞれ3回実測接続テストし、同じファイルで継続速度も測って、結果に応じて用途を決めてください。
サブスクリプションのノードが多すぎる場合はどう絞るか
まず地域で6本以内に絞り、3回のテストで2回タイムアウトしたノードを除外します。次に倍率で3本を残し、主力、予備、大容量通信用に割り当てます。
デスクトップでは速いのに、Android端末では遅いのはなぜか
まず両方を同じネットワークに接続し、同じサブスクリプションを更新してから、それぞれテストします。v2rayNGの省電力制限、アプリごとのプロキシ、ルーティング設定を確認し、v2rayNの遅延結果をそのまま当てはめないでください。
プロトコルの異なるノードへ切り替えるべきタイミングは
現在の設定でハンドシェイクに失敗し続ける、コアのログに互換性のない項目が明確に示される、または同じ回線で別プロトコルのノードが明らかに安定している場合に切り替えます。正常に接続できているなら、プロトコル名だけを理由に移行する必要はありません。
最終的に判断するおすすめの順番
- サブスクリプションを更新し、接続不能、設定ミス、頻繁なタイムアウトがあるノードを除外する。
- 同じネットワークで3回の実接続遅延テストを行い、中央値と変動を優先して見る。
- 0.5x、1x、2xなどの倍率を確認し、月間容量に応じて用途を割り当てる。
- アクセス先に合わせて接続先地域を比較的固定し、別地域の予備も残す。
- プロトコルとコアの互換性を確認し、問題があればログに基づいて対処する。むやみにパラメーターを変更しない。
- 実際のウェブ閲覧、動画、ダウンロードを5分以上行って確認し、その後デフォルトノードに設定する。