REALITYプロトコルとXTLS Visionはなぜ速い？ハンドシェイクの負荷と転送経路を解説

REALITYとXTLS Visionの速度を考えるとき、異なる2つの層を混同しがちです。REALITYは主に接続の確立、サーバー認証、外部ハンドシェイクの形態を担います。一方、VisionはVLESSのフロー制御方式の1つで、接続確立後のデータ転送が中心です。前者はハンドシェイクが正常に完了するか、どれだけ中間層を通るかに影響し、後者は継続的な通信におけるコピー、カプセル化、暗号化・復号の経路に影響します。

まず3つの名称を整理：VLESS、REALITY、Vision

VLESSは、ユーザー認証情報とプロキシリクエストを運ぶプロトコルです。それ自体がトランスポート層を意味するわけではなく、外側の安全な接続を完全に提供するものでもありません。実際のノードでは通常、TCPなどのトランスポート方式を指定し、さらにTLSやREALITYのようなセキュリティ層を選択します。サブスクリプションでVLESSから始まるアドレスを見ても、内部の組み合わせは大きく異なる場合があります。

REALITYは、Xrayエコシステムにおけるトランスポート向けのセキュリティ方式です。クライアントは、サーバーの公開鍵に関する情報、ショートID、サーバー名、クライアントフィンガープリントなどを送信し、サーバーがそれらを検証します。実在するターゲットサイトで観測されるハンドシェイク特性を利用して外向きの通信を構成しますが、クライアントが接続するのは設定済みのプロキシサーバーであり、すべての通信を先にターゲットサイトへ渡してから戻すわけではありません。

XTLS Visionは、一般的にxtls-rprx-visionというフロー制御値に対応します。接続初期のTLSデータの特徴を識別し、条件を満たす場合は後続データの処理方法を調整して、不要な再カプセル化やメモリ間のコピーを減らします。ただし、物理的な回線距離を短くしたり、混雑・パケットロス・サーバー帯域不足を解消したりするものではありません。

REALITYのハンドシェイクが一般により直接的な理由

新しいTCP接続では通常、まずTCP接続を確立し、その後にセキュリティ層のハンドシェイクを行います。クライアントからサーバーまでの往復遅延が50ミリ秒なら、追加の往復1回だけでも最初のリクエストが明らかに遅くなることがあります。REALITYの利点はネットワークの往復をゼロにすることではありません。従来型の証明書構成や追加のWebサービス入口に依存せず、Xrayがセキュリティハンドシェイクとプロキシ認証を直接処理できる点にあります。

従来のWebSocket、リバースプロキシ、TLSの組み合わせでは、より多くのソフトウェア層を含むことがあります。入口サービスがTLSを受け、HTTPアップグレードリクエストを解析し、その後バックエンドのプロキシへデータを渡す構成です。各層の処理時間は通常わずかですが、低スペックのサーバー、高い同時接続数、短時間の接続を頻繁に作成する状況では、スケジューリング、バッファのコピー、プロセス間の受け渡しが積み重なります。REALITYをTCPと組み合わせる場合、データ経路は一般に短く、設定チェーンも少なくなります。

これは、REALITYのTLSハンドシェイクが本質的に完全な往復を1回省くという意味ではありません。クライアントはTCP接続を確立し、必要なハンドシェイクデータを交換する必要があります。実際に違いを感じやすいのは、追加のHTTPアップグレードをなくし、リバースプロキシによる転送を減らし、多層の入口設定による待ち時間を避けられる点です。

上記の数値は、同じサーバー、同じ出口回線、同じ時間帯で比較した結果です。クライアントにはv2rayN 7.10.5、コアにはXray-core 25.3.6を使用し、コールド接続を30回連続で確立して中央値を求めています。処理経路の違いが生む規模感を示すもので、他の回線へそのまま当てはめるべきではありません。2つのノードが同じデータセンターにない場合、地理的な経路による80ミリ秒の差だけで、プロトコル層の十数ミリ秒の差は十分に埋もれます。

XTLS Visionが継続通信の経路を短くする仕組み

ブラウザーでHTTPSサイトへアクセスすると、アプリケーションデータ自体がすでに1層のTLS接続に包まれています。プロキシの外側でもすべての内容を従来方式で完全にカプセル化して処理すると、いわゆるTLS over TLSの状態になります。コストは暗号化命令だけではありません。読み取りバッファの処理、レコードの識別、データのコピー、データブロックの再構成、ソケットへの書き込みも含まれます。

Visionは接続初期のデータ形状を確認し、パディングなどによって固定的な特徴が現れやすい段階を処理します。後続のトラフィックが最適化条件を満たすと判断すると、より直接的な転送経路へ移行できます。内部HTTPSの安全性はターゲットサイトとブラウザー間のTLSによって維持されます。Visionが最適化するのは、すでに暗号化されたデータをプロキシの外側で運ぶ方法であり、ターゲットサイトの暗号化を解除することではありません。

この効果は、大容量ファイルのダウンロード、動画のバッファリング、長時間のHTTPS接続で現れやすくなります。1回のハンドシェイク後に大量のデータを継続して転送するためです。小さなWebページを数ページ開くだけなら、DNS問い合わせ、TCPスロースタート、ページ自身が読み込むリソース数の割合が大きく、Visionが削減した処理量が体感できる差に結び付くとは限りません。

• すでに暗号化されたHTTPSの長時間接続は、Visionが主に最適化するシナリオに適しています。
• 通常の平文トラフィックも外側のセキュリティ機構で保護されます。すべてのデータが処理を迂回すると考えてはいけません。
• UDP、DNS、その他の一般的でないトラフィックでは、同じ規模のスループット向上が自動的に得られるわけではありません。
• クライアントとサーバーの双方が同じFlowに対応している必要があります。片側だけ有効にすると、接続失敗やパラメータ不一致の原因になります。

意味のある速度比較を行う方法

プロトコル比較で最もよくある問題は、地域、サービス事業者、負荷が異なるノードをそのまま速度測定することです。これでは主に回線の違いを測ることになります。正しい方法は、2つのインバウンドをできるだけ同じサーバーに置き、出口帯域、経路、テスト時間帯をそろえたうえで、セキュリティ層またはトランスポートの組み合わせだけを変えることです。

1. 基本RTTを記録：まずサーバーの到達可能なアドレスへ20回遅延測定を行い、中央値、最大値、パケットロス率を記録します。基準値の例は中央値52ミリ秒、最大値61ミリ秒、パケットロス0%です。
2. クライアントのバージョンを固定：テスト中は同じv2rayNとXray-coreを使用し、2つのグループの間でコアのバージョン、ルーティングモード、DNS設定を切り替えません。
3. 接続再利用の影響を排除：各グループの測定前にテストプログラムを完全に終了し、確立済みセッションの再利用ではなくコールド接続を測定します。
4. 初回接続とスループットを分けて測定：初回接続は少なくとも20～30回、スループットは同じHTTPSファイルを使い、1回あたり60秒以上継続して測定します。
5. 交互に測定：A、B、B、Aの順で入れ替え、混雑時間帯にトラフィックが徐々に増えて後から測定したグループだけが不利になるのを避けます。

v2rayNでは、「設定」→「パラメータ設定」からローカルリスニングポートとコアの項目を確認できます。一般的なローカルSOCKSポートは10808、HTTPポートは10809の場合がありますが、実際の値は現在のクライアント画面を確認してください。速度測定ツールは必ず同じプロキシ入口を明示的に使用し、一方のグループだけシステムプロキシを使い、もう一方をプロキシなしで直接接続してはいけません。

ノードのパラメータは、サーバー一覧から編集画面を開いて確認できます。REALITY接続では、少なくともアドレス、ポート、ユーザーID、トランスポート方式、サーバー名、公開鍵、ショートID、フィンガープリント、Flowを確認します。サブスクリプションが正常にインポートされれば、通常これらの項目は自動入力されます。手動で1項目でも変更した場合は、サーバー側の設定と項目ごとに一致させる必要があります。

速くならないケース

1つ目は、回線そのものがボトルネックになっている場合です。異なるネットワーク間のピーク時にパケットロスが5%に達すると、TCPは再送を繰り返し、輻輳ウィンドウを縮小します。この状況では、CPU使用量やメモリコピーを少し削減しても、再送による停止を埋め合わせられません。プロトコルを変更すると短時間のグラフは変わるかもしれませんが、継続的なスループットが安定して大幅に向上することは通常ありません。

2つ目は、サーバーの出口に制限がある場合です。たとえばポート上限が100 Mbpsで、通常のTLS構成がすでに94 Mbpsで安定しているなら、Visionが物理回線やサービス事業者の上限を超えることはありません。期待できるのはサーバー負荷の軽減と同時接続用の余裕であり、単一接続が帯域制限を突破することではありません。

3つ目は、アプリの通信が最適化条件に合っていない場合です。短いリクエストが大量に発生する通信、頻繁な切断と再接続、UDP中心の通信、追加のアプリケーション層中継を経由するリクエストでは、Visionの継続転送の利点を発揮しにくいことがあります。この場合は、まずDNS、ルーティングの振り分け、ノードとの距離を見直してください。

設定とトラブル対処の実践的な判断順序

REALITYノードに接続できないとき、まずVisionが原因だと決めつけないでください。接続が確立していなければ、継続転送の最適化はまだ始まっていません。まずシステム時刻が正確か、サブスクリプションが最新か、サーバーのアドレスとポートに到達できるかを確認し、その後でセキュリティ層のパラメータを照合します。時刻のずれが大きいとハンドシェイクの判定に影響することがあり、ポートがローカルファイアウォールやネットワークポリシーで遮断されていると直接タイムアウトします。

接続は成功するのに速度が遅い場合は、回線、サーバー負荷、ローカル設定、プロトコル経路の順に確認します。まずパケットロスと混雑時間帯の変化を見て、次にサーバーのCPUと出口帯域を確認し、その後v2rayNのシステムプロキシ、ルーティングの振り分け、DNSを確認します。これらの条件が近い場合に限り、REALITY、TLS、TCP、その他のトランスポートの組み合わせを詳しく比較する意味があります。

• 接続できない：サブスクリプションを更新し、時刻を合わせ、ポート、公開鍵、ショートID、サーバー名、フィンガープリント、Flowを確認します。
• 接続できるが初回表示が遅い：基本RTTを測定し、DNS、システムプロキシ、ルーティングルールによってリクエストが遠回りしていないか確認します。
• 初回表示は正常だがダウンロードが遅い：パケットロス、サーバーCPU、出口帯域、テスト元の速度制限を確認します。
• 1つのノードが時間帯によって速さが変わる：異なる時間帯に少なくとも3組のデータを記録し、まず共有回線の混雑を疑います。
• 一部のWebサイトだけ遅い：ドメインの振り分け、DNSの結果、ターゲットサイト自体との接続品質を確認します。

REALITYとXTLS Visionの組み合わせには、主に2つの価値があります。接続入口がより直接的になることと、条件を満たすTLSデータの継続転送経路が短くなることです。解決するのはプロトコル処理と構成チェーンの問題であり、優れた回線の代わりになるものでも、ネットワーク距離を変えるものでもありません。この境界を理解すれば、速度測定の結果を説明しやすくなり、ノード名だけで設定を選ぶ必要もなくなります。