REALITYとXTLS Visionの仕組みを解説：次世代トランスポートが高速な理由

TLSハンドシェイクと重複暗号化はなぜ発生するのか

通常のHTTPSサイトへアクセスすると、クライアントはまずサーバーとTCP接続を確立し、その後TLSハンドシェイクを開始します。ハンドシェイクではTLSバージョン、暗号スイート、サーバー名、一時鍵をネゴシエートし、サーバーが提示する証明書を検証します。完了後、ブラウザーが送信するHTTPデータは暗号化された通信路に入ります。新しいTCP接続とTLS接続には通常、複数回のネットワーク往復が必要なため、経路の遅延が大きいほどページを最初に開くまでの待ち時間も長くなります。

プロキシプロトコルの外側にさらにTLSを重ね、アプリケーション自体もHTTPSの場合、「内側のHTTPSデータを外側の暗号化通信路に入れる」構造になります。単純に2回暗号化されるという意味ではありませんが、外側でもレコードのカプセル化、暗号化・復号、バッファーコピー、接続状態の管理が必要です。大容量ダウンロード、性能の低い端末、多数の同時接続では、こうした追加処理がCPU使用率や速度差として現れやすくなります。

従来のVLESS + TCP + TLSでは、サーバーがドメインに一致する証明書を保持し、証明書の更新や名前解決を正しく処理する必要があります。VLESS + REALITYもTLSに似たハンドシェイクを行いますが、認証方式と導入モデルが異なります。XTLS Visionはデータ転送層に位置し、直接転送に適した暗号化トラフィックを識別します。両者は別の機能であり、REALITYを単純な「高速化スイッチ」と考えることはできません。

REALITYはハンドシェイクと認証をどう行うのか

REALITYはXrayのエコシステムにおけるトランスポートセキュリティ方式で、VLESS、TCP、Visionと組み合わせて使われることが多い方式です。サーバー自身の公開ドメイン証明書を用意する必要はなく、サーバー所在地から安定してアクセスでき、適切なTLS特性を持つ実在のターゲットサイトを選びます。クライアントがハンドシェイクパラメータを送信すると、サーバーはREALITYの秘密鍵、クライアントに設定された公開鍵、Short ID、時刻情報に基づいてリクエストの正当性を判断します。

1. クライアントがハンドシェイクを構成：設定されたServer Name、REALITY公開鍵、Short ID、ブラウザフィンガープリントからリクエストを生成し、サブスクリプションで指定されたサーバーアドレスとポートへ接続します。
2. サーバーが認証を実行：サーバーは秘密鍵でクライアントパラメータを検証します。公開鍵と秘密鍵は対応している必要があり、Short IDはサーバーで許可された値でなければなりません。
3. TLSらしい外観を形成：ハンドシェイクの動作はターゲットサイトのTLS特性を参考にするため、ネットワーク側から見える接続形態は通常のTLSアクセスに近くなります。
4. VLESSセッションへ移行：認証に成功すると接続はVLESSデータを運び、xtls-rprx-visionが設定されている場合は、続くトラフィックをVisionが処理します。
5. 想定外のリクエストを処理：REALITYの認証条件を満たさない接続はプロキシセッションに入らず、サーバーは設定に従ってターゲットサイトへの接続として処理します。

「実在サイトのハンドシェイクを借用する」とは、ハンドシェイクの特性とターゲットの選択を指しており、ターゲットサイトの秘密鍵を取得することでも、プロキシサーバーがそのHTTPS内容を復号することでもありません。クライアントが最終的に信頼するのは、REALITY公開鍵に対応するサーバーの身元です。Server Nameだけをコピーし、正しい公開鍵やShort IDがなければ接続は失敗します。

XTLS Visionが追加処理を減らせる理由

XTLS VisionはVLESSのFlowモードで、設定値はxtls-rprx-visionです。プロキシ接続の確立後、どのデータを外側のレコードとして完全にカプセル化し続けるか、どのTLSトラフィックを条件に応じてより直接的な転送経路へ通せるかを判断します。一般的なWeb閲覧、動画、ダウンロードの多くはHTTPSを使うため、これらがVisionの主な最適化対象です。

VisionがHTTPS暗号化を無効にしたり、アプリケーションデータを平文でインターネット上に流したりすることはありません。ブラウザーとターゲットサイト間のTLS保護は維持され、REALITYによるハンドシェイク認証も残ります。最適化されるのはデータ経路とカプセル化方式で、すでに暗号化された連続データへの不要な重複処理を避けることが目的です。

すべての接続がすぐに直接転送経路へ入るわけではありません。Visionは初期データを確認し、TLSレコードを識別し、独自のフロー制御を適用します。通常の平文TCP、識別できないペイロード、条件を満たさない接続は従来どおり転送されます。そのため、結果は用途に大きく左右されます。数十KBの短いリクエストより、大容量HTTPSファイルのダウンロードのほうが差が現れやすくなります。

遅延とスループットのメリットをどう理解するか

REALITYとVisionの組み合わせによる体感上のメリットは、主に3つあります。導入側では証明書チェーンの運用変数を減らし、ハンドシェイクの形態を通常のTLSに近づけ、Visionが大容量通信時の重複カプセル化とデータコピーを削減します。ただし、混雑、迂回経路、大きなパケットロス、サーバーの外向き帯域不足は解決できません。比較時はサーバー、経路、対象ファイル、テスト時間をそろえる必要があります。

上記の数値はテスト方法を示すための例であり、すべての回線で再現する固定的な結論ではありません。条件は同一の4コアサーバー、同一ルート、2GBのHTTPSファイル1つ、5回連続測定した中央値です。Vision構成の中央値は36MB/s、通常のVLESS + TCP + TLSは31MB/sでした。一方、アイドル時のRTTはいずれも約38msで、スループットの向上がネットワーク往復時間の低下を意味しないことが分かります。

• Webページの初回表示が遅い：TCP接続、TLSハンドシェイク、最初の1バイトまでの時間を記録します。すべてが遅い場合は、まず経路距離、DNS、サーバー負荷を確認してください。
• ダウンロードの最初だけ速く、その後遅い：サーバーの外向き回線が上限に達していないか確認し、ローカルCPUの単一コア使用率、省電力モード、無線ネットワークの変動も確認します。
• 速度差がほとんどない：低帯域の回線や短い接続では、外側の処理が主なボトルネックではありません。5%以内の変動はネットワークの揺らぎにすぎない可能性があります。
• 夜間に大きく低下する：同じノードを異なる時間帯に測定し、RTTとパケットロスが同時に増えている場合、プロトコルを変更しても混雑は回避できません。
• 複数接続は正常だが、単一接続だけ遅い：TCP輻輳制御、経路MTU、中間ネットワークの品質を確認し、集計型の速度測定だけでプロトコル性能を判断しないでください。

クライアントパラメータの確認方法

サブスクリプションでは通常、アドレス、ポート、ユーザーID、Flow、トランスポート方式、REALITY公開鍵、Short ID、Server Name、フィンガープリントがまとめて提供されます。どれか1つでもサーバー側と一致しないと、タイムアウト、即時切断、ログ上の認証失敗が発生する可能性があります。サブスクリプション更新後に手動で1項目だけ上書きすることは、パラメータ不一致の代表的な原因です。

v2rayNGはXrayコアを使用するため、REALITYとVisionをそのまま利用するのに適しています。v2flyNGはv2flyコアを使用し、対応範囲はv2flyコアのサポート状況に依存します。画面上の項目が似ているからといって、Xray専用の構成が動作すると判断しないでください。サブスクリプションにREALITYノードが含まれる場合は、使用するクライアントとコアが対象パラメータを明確にサポートしているか、先に確認します。

プロトコル：VLESS
トランスポート：TCP
セキュリティ：REALITY
Flow：xtls-rprx-vision
サーバーポート：443
フィンガープリント：chrome
一致必須：ユーザーID、公開鍵、Short ID、Server Name

よくある疑問と設定の境界

REALITY、Vision、VLESSは同じノード情報に登場することが多いものの、それぞれ役割が異なります。VLESSはプロキシプロトコル、REALITYはトランスポートの安全性とサーバー認証、VisionはVLESSのフロー制御モードです。3つを分けて理解すれば、問題がハンドシェイク、認証、転送、クライアントによる引き継ぎのどこにあるか特定できます。

構成を選ぶときに確認する条件

• サーバーとクライアントの両方がREALITYとVisionに対応するXrayコアを使用し、機能バージョンも設定要件を満たしていること。
• ノードにVLESS、TCP、REALITY、xtls-rprx-visionが明記されていること。別のプロトコル構成から項目をつぎはぎしないでください。
• サブスクリプションで配布されたパラメータを基準にし、更新後はまず元の設定をテストしてから、ルーティングやシステムプロキシを調整します。
• 切り分けが必要な場合は並行して変更する要素をなくし、一度に1項目だけ変更し、その時点のコアログを保存してください。
• 速度を判断するときはRTT、パケットロス、CPU、サーバーの外向き回線を同時に確認し、1回のWeb速度測定だけで結論を出さないでください。

総合すると、REALITYは証明書の導入方式とハンドシェイク認証の問題を解決し、XTLS Visionは特定のデータフローにおける追加処理の問題を解決します。組み合わせによるメリットは、安定した回線、高帯域の転送、継続的なHTTPS通信で現れやすくなります。ボトルネックが混雑、パケットロス、誤ったルーティングにある場合は、プロトコル名を変えるより先にネットワークと設定を直すほうが効果的です。