ノードの選び方：遅延・倍率、地域とプロトコル種別の優先順位

まず順序を決める：地域 → プロトコル種別 → 倍率 → 遅延

ノード一覧には多くの項目がありますが、実際の使い勝手を左右するのは4つだけです。ノードの所在地域、プロトコルと転送方式の組み合わせ、通信量倍率、そして前の2つと手元の回線によって決まる遅延です。この4つを同じ土俵で比べ続けても、迷いが消えることはありません。

より有効なのは、先に除外してから並べ替える方法です。地域は往復時間の物理的な下限を決め、プロトコルの組み合わせは混雑時に妨害を受けやすいかどうかを決め、倍率はその通信量に対して支払うコストを決めます。遅延は、前の3つが今のネットワーク環境に落とし込まれた結果にすぎません。

4つの軸でそのまま使える参考値を以下に示します。各項目は後半で詳しく解説します。

地域：遅延の下限を決め、回線品質も決める

物理的な距離は避けられません。パケットが手元の出口から相手側のデータセンターまで往復する間、光ファイバー内の往復時間だけで遅延の下限が決まってしまいます。プロトコル側の最適化は、この値を土台に上乗せするしかありません。

下表は一般的なデータセンター立地ごとにまとめた経験的なレンジです。実際の数値は手元のブロードバンド回線の出口、事業者の国際回線、夜のピーク時間帯の混雑状況によって変動します。同じ地域でも回線によっては、地域をまたぐ差より大きい開きが出ることがあります。

地域の役割は候補を絞ることであり、最終的な選択を直接決めるものではありません。まず物理的な距離で候補を近距離・中距離・遠距離の3グループに分け、その中で個別の回線を比べると、比較の効率が大きく上がります。

プロトコル種別：まず転送層、次にセキュリティ層を見る

クライアントの一覧に表示されるノード名には、通常3つの情報が含まれます。プロトコル、転送方式、セキュリティ層です。たとえば VLESS + TCP + Reality、あるいは VMess + WebSocket + TLS といった形です。プロトコルは認証と暗号化の方式を決め、転送方式はパケットがネットワーク上でどのような姿になるかを決めます。

一般ユーザーは各組み合わせの実装詳細まで理解する必要はありません。判断すべきは3点だけです。その回線に独自ドメインが必要か、TLS 証明書に依存するか、普段使っているクライアントで問題なく読み込めるかです。

3つの組み合わせの速度差は、正常なネットワークでは通常10%未満です。実際に差がつくのは、夜のピーク時間帯やネットワークをまたぐときの回線の安定性です。プロトコル種別は明らかに不適切な組み合わせを除外するために使い、細かな選別には向きません。

あるノードがどの組み合わせに属するかは、サブスクリプション内の共有リンクのパラメータを見るのが最短です。

• security：セキュリティ層。値は none / tls / reality で、ハンドシェイク方式を決めます。
• type：転送方式。値は tcp / ws / grpc / http です。
• flow：フロー制御方式。xtls-rprx-vision は VLESS + TCP + Reality または VLESS + TCP + TLS でのみ有効です。
• sni：ハンドシェイク時に使う接続先ドメイン。Reality と TLS のどちらもこれに依存します。
• path と host：WebSocket、HTTP 転送専用の項目で、欠けていると接続はできても通信が転送されない状態になります。

倍率：通信量コストを計算してから並べ替える

倍率はサーバー側が通信量を課金する際の係数です。1.0× なら実際に 1 GB 転送するとプランから 1 GB が差し引かれ、2.0× なら同じ 1 GB の転送で 2 GB が差し引かれます。倍率と速度に必然的な関係はなく、倍率が高い回線が必ず速いわけではありません。

倍率を日常の利用量に掛けて考えると、判断がぐっと分かりやすくなります。毎月の上り下り合計を 60 GB と仮定すると：

• 1.0× の回線：プランの通信量を 60 GB 消費。
• 1.5× の回線：プランの通信量を 90 GB 消費。
• 2.0× の回線：プランの通信量を 120 GB 消費。
• 3.0× の回線：プランの通信量を 180 GB 消費。

結論として、倍率 2.0× 以上のノードは緊急時の予備とし、日常のメインは 1.0×〜1.5× に留めます。動画視聴や大きなファイルのダウンロードなど通信量の多い用途では低倍率を優先し、Web 閲覧やメッセージングなど通信量の少ない用途では倍率の差はほとんど無視できます。

遅延：何を測り、何回測り、どの程度の変動を異常とみなすか

クライアントで測定できる遅延には2種類あります。1つは TCP ハンドシェイク遅延で、ノードサーバーのポートに到達できるかだけを確認します。もう1つは実接続遅延で、ノード上で実際にリクエストを1回発行し、その結果を返します。前者は数値が小さく出ますが、実際の体感に近いのは後者なので、ノード選びでは後者を基準にしてください。

v2rayN では、ノードを選択して右クリックから「実接続遅延をテスト」を選ぶと、メイン画面が結果に従って並べ替えられます。v2rayNG では、右上の ⋮ をタップして「すべての構成の遅延をテスト」を選ぶと、リストの右側に数値が順に反映されます。海外サーバーへの回線ではデフォルトのタイムアウトが短めに設定されていることがあるため、「設定」→「パラメータ設定」→「基本設定」で値を大きくしてから再測定してください。

1回の結果をそのまま信用しないでください。同じノードを続けて3回測定し、中央値を取ってから近いノードと比較します。判断は以下の4つの基準で行うとよいでしょう。

1. 3回の結果がすべて 80 ms 以内：日常のメイン回線として問題ありません。
2. 3回の結果の変動が 30% を超える、または途中で1回タイムアウトした：回線が不安定なため、予備に降格します。
3. 実接続遅延が TCP 遅延より明らかに高い（たとえば2倍以上）：ノードサーバーの負荷が高いか復路が迂回しているため、同じ地域の別ノードに切り替えます。
4. すべてのノードが同時に遅くなる：原因は通常ノード側ではなく、まずプロキシをオフにして手元のネットワーク自体が正常か確認し、それから再測定します。

もう1つ、個別に記録しておく価値のあるケースがあります。日中の安定しているノードが、夜のピーク時間帯に必ず不安定になる場合です。これはノードの故障ではなく回線の混雑によるものなので、削除するより予備グループに残しておくほうが役立ちます。

実践：デスクトップと Android で同じ選定結果を使い回す

デスクトップ版と Android 版で同じサブスクリプションリンクを使えば、ノード一覧・グループ・並び順が揃うため、選定は一度で済みます。両者の違いは主にテストの入口と日常的な使い方にあります。

この順序を習慣にしてしまいましょう。新しいサブスクリプションを読み込んだら、まず地域ごとにグループを分け、倍率 2.0× 以上のノードを除外し、残った各ノードの実接続遅延を3回測って中央値で並べ替え、上位3件を常用ノードにします。以降はサブスクリプションを更新するたびに再測定すれば十分です。

補足しておくと、ノードの品質は時間とともに変化するため、一度の選定結果が長期的な結論になるわけではありません。同じデータセンターでも時間帯によって挙動がまったく異なることがあり、一度だけ丁寧に選ぶより定期的に再測定するほうが意味があります。