REALITYとXTLS Visionはなぜ速いのか：ハンドシェイクの再利用とフロー制御を解説

TLSハンドシェイクが最初のデータ到着時間に与える影響

プロキシ接続の「速さ」には、接続確立までの時間、継続転送時のスループット、各パケットの処理に必要なCPUコストという、少なくとも3つの指標があります。REALITYは主にハンドシェイクと外観上の特徴を変え、XTLS Visionは安定した転送に入った後のデータ経路を最適化します。両者を単純に「帯域幅を増やす機能」と捉えるのは正確ではありません。

TCP上のTLS 1.3を例にすると、クライアントはまずTCPの3ウェイハンドシェイクを完了し、続いてClientHelloを送信します。サーバーはServerHello、証明書関連のメッセージ、ハンドシェイク完了メッセージを返します。TLS 1.3の完全なハンドシェイクでは、通常1往復で保護されたアプリケーションデータを送信できます。クライアントとサーバー間の往復遅延が大きい場合、このメッセージ交換が最初のWebリクエストやアプリ接続の待ち時間にそのまま表れます。

TLS 1.2の完全なハンドシェイクでは通常さらに多くの往復が必要なため、TLS 1.3では起動時のコストがすでに削減されています。ただし、プロキシ経路では外側のTLS内にブラウザー自身のHTTPSを通す場合があります。外側の保護はプロキシ経路を、内側の保護はアクセス先サイトを守ります。プロキシ層が暗号化済みのTLSレコードに対して汎用暗号化、コピー、カプセル化を続けると、CPU処理やメモリ操作が重複する可能性があります。

REALITYが実際に処理するもの

REALITYは、Xrayで認証付きのTLS風接続を確立するためのセキュリティ層で、VLESSやTCPと組み合わせて使われることが多い機能です。クライアントはClientHelloにREALITYのパラメータから生成された認証情報を含め、サーバーは秘密鍵と公開鍵の関係、shortId、時間範囲などを基に接続の正当性を判定します。認証に成功すると、接続はVLESSと後続のフロー制御処理へ進みます。

「実在サイトの証明書を借用する」という表現は、対象サイトの秘密鍵をコピーするのではなく、TLSの外観とハンドシェイクのコンテキストを再利用すると理解するのが適切です。REALITYサーバーが対象サイトの証明書秘密鍵を保持する必要はありません。設定のserverNameはサーバーで許可された名前と一致させ、クライアントでは正しいpublicKey、shortId、fingerprintを使用します。これらのフィールドのいずれか1つでも一致しなければ、ハンドシェイクで失敗する可能性があります。

サーバー側では通常、アクセス可能なターゲットアドレスも設定します。REALITY認証に合格しない通常の探索接続は、設定に応じてターゲットサイトへ転送できるため、外部から見える応答を一般的なTLSサービスに近づけられます。この仕組みが解決するのはハンドシェイクの形態と認証の問題であり、サーバーの混雑、ネットワーク間のパケットロス、通信事業者による迂回経路を自動的に解消するものではありません。

XTLS Visionが重複処理を減らす仕組み

VLESS自体はアプリケーションデータに汎用的な内容暗号化を追加せず、セキュリティはREALITYやTLSなどの外部セキュリティ層が提供します。XTLS VisionはXrayのフロー制御方式で、設定値は通常xtls-rprx-visionと記述します。接続中のTLS特性を監視し、必要なハンドシェイクと認証が完了した後、条件に合うデータにはより直接的な転送経路を適用します。

ブラウザーでHTTPSサイトにアクセスすると、ブラウザーと対象サイトの間にはすでにエンドツーエンドのTLSが形成されています。従来のプロキシ用セキュリティ経路が内側のTLSデータ全体を通常のペイロードとして継続的に暗号化すると、「TLSデータを別のセキュリティ経路内で処理する」構造になります。Visionの重点は対象サイトのHTTPSを無効にすることではなく、すでに暗号化されたデータストリームを識別し、外側での重複暗号化、バッファリング、メモリコピーを減らすことです。

この最適化は、大容量ファイルの転送、HTTPS接続の同時実行数が多い場合、サーバーのCPUに余裕がない場合に観察しやすくなります。短い接続では、DNS、TCP接続確立、ネットワーク往復が総時間の大部分を占めることがあります。低速回線では、先に帯域幅の制限を受ける可能性があります。Visionは対象サイトTLSの証明書検証結果も変更せず、ブラウザーと対象サイト間のセキュリティ境界は維持されます。

• 短いWebリクエスト：往復遅延、DNS、初回ハンドシェイクの影響を受けやすく、スループットの差がはっきり出ない場合があります。
• 継続的なダウンロード：メモリコピー、暗号処理、サーバーCPUの違いを観察しやすくなります。
• 高同時接続：Xrayのログ、プロセスCPU、システムの接続数を同時に確認し、単一接続だけで判断しないでください。
• パケットロスの多いネットワーク：TCPの再送と輻輳制御が主因になりやすく、Visionで基盤レベルの再送を回避することはできません。

REALITYとVisionがよく併用される理由

REALITYとVisionは、同じ接続の異なる段階を処理します。REALITYは特定のTLS外観と認証機能を備えた経路を確立し、Visionは経路確立後に条件に合うデータストリームを最適化します。そのため、一般的な組み合わせではVLESSがユーザーとリクエストを表現し、REALITYがセキュリティハンドシェイクを担い、Visionがフロー制御を行い、TCPが信頼性のある転送を担当します。

この組み合わせでは、クライアントとサーバーのパラメータを正確に一致させる必要があります。クライアントが持つのはpublicKeyであり、サーバーのprivateKeyではありません。shortIdはサーバーの許可リストに含まれる値を使い、serverNameはサーバー設定と一致させ、Flowはxtls-rprx-visionに設定します。通常のTLSノードのドメインやポートをREALITYのフィールドにそのまま入れても、利用可能な接続にはなりません。

v2rayNでサブスクリプションからインポートすると、これらの値は通常サーバー設定に自動入力されます。手動で確認する場合は、「サーバー」→「サーバーを編集」を開き、アドレス、ポート、ユーザーID、Flow、トランスポートプロトコル、セキュリティ方式、SNI、フィンガープリント、公開鍵、shortIdを確認します。続いて「設定」→「パラメータ設定」で、現在のCoreタイプがこの組み合わせに対応するXrayコアであることを確認します。

プロトコル：VLESS
トランスポート：TCP
セキュリティ：REALITY
Flow：xtls-rprx-vision
SNI：サーバー側のserverNamesと一致
Fingerprint：chrome
Public key：サーバーの公開鍵から生成
Short ID：サーバーの許可値と完全一致

1. まずサブスクリプションを更新して、該当するサーバーを選び直します。古いpublicKeyやshortIdを使い続けないようにしてください。
2. v2rayNのサーバー編集画面を開き、VLESS、TCP、REALITY、Visionを項目ごとに確認します。アドレスとポートだけを確認して終わらせないでください。
3. 保存して接続を開始し、「ヘルプ」→「ログを表示」でXrayの起動、ハンドシェイク、送信側のエラーを確認します。
4. システムプロキシを有効にして通常のHTTPSページへアクセスし、その後に継続的なダウンロードをテストして、ハンドシェイク段階と転送段階を分けて判断します。
5. 端末上のアプリが手動でプロキシを使用する場合は、v2rayNが現在待ち受けているポートを指定していることを確認します。一般的なローカル混合プロキシポートは10808ですが、「設定」→「パラメータ設定」に表示される実際の値を優先してください。

適した環境と、解消できないボトルネック

VLESS、REALITY、Visionの組み合わせは、クライアントとサーバーの双方でXrayコアを安定して利用できる環境に適しています。特にHTTPSの利用が中心で、継続的な転送が多く、重複処理を減らしたいデスクトップやAndroidの接続に向いています。v2rayNはWindows、macOS、Linuxのデスクトップ環境で利用できます。Androidでこの組み合わせを使う場合は、Xrayコアを採用し、対応パラメータをサポートするv2rayNGを使用してください。

v2flyNGはv2flyコアを使用するため、設定機能はそのコアが実際にサポートする範囲で判断してください。REALITYやVisionを含むサブスクリプション項目を受け取っても、インポートに成功しただけで接続できると判断してはいけません。クライアント画面にフィールドが表示されても、現在のコアが対応するハンドシェイクやフロー制御を実装しているとは限りません。

回線そのものの品質が、依然として性能の上限を決めます。サーバーの出口帯域が固定されている場合、Visionで制限を超えることはできません。地域をまたぐ経路でパケットロスが続けば、TCPは速度を落として再送します。サーバーの時刻が大きくずれている場合は、REALITY認証が失敗することもあります。プロトコルは、ログ、ネットワーク経路、リソース使用率を総合的に観察したうえで選択してください。

性能向上の要因を見分ける方法

現在のネットワークにプロトコルが適しているか判断するには、まず再現可能な比較条件を作ります。同じサーバーアドレス、同じ出口ポート、同じテストファイルを使い、安全層またはFlowだけを変更します。各条件を少なくとも3回実行し、テスト前に毎回接続を再確立してください。そうしないと、DNSキャッシュ、サーバー負荷、ネットワーク変動が実際の差を隠してしまいます。

最初のデータ到着が遅く継続ダウンロードが正常なら、まずネットワーク往復、DNS、ハンドシェイクを確認します。最初のデータ到着は正常でも長時間接続でCPU使用率が高い場合は、重複暗号化やコピー処理のコストが疑われます。スループットが周期的に低下し、TCP再送を伴うなら、先にパケットロスへ対処してください。ログのハンドシェイク失敗は設定問題であり、性能問題と混同して分析してはいけません。

• v2rayNまたはv2rayNGで接続をクリックしてから、コアが利用可能と報告するまでの時間を記録します。
• 同じHTTPSリソースを少なくとも60秒間継続転送し、一時的なピーク値ではなく安定時の状態を観察します。
• デスクトップOSのタスクマネージャーまたはシステム監視ツールで、XrayプロセスのCPU使用率を記録します。
• 直接接続ルールとプロキシルールを分けてテストし、ルーティングによってテスト対象が誤った出口へ送られていないことを確認します。
• コアのログにハンドシェイクタイムアウト、接続リセット、ポート競合、DNS名前解決エラーがないか確認します。

つまり、REALITYとXTLS Visionの利点は、単独の「高速化スイッチ」から生まれるものではありません。REALITYは検証可能なパラメータで、対象TLSの外観に沿った接続を確立します。Visionはセキュリティ経路内で暗号化済みのアプリケーション通信を識別し、重複処理を減らします。パラメータが一致し、コアに互換性があり、ルーティングが正しく、回線のボトルネックにも余裕がある場合に限り、起動時の待ち時間短縮、リソース使用量の削減、継続転送の安定化として効果が表れます。