REALITYプロトコルとXTLS Visionはなぜ速い？証明書不要のハンドシェイクとフロー制御の仕組みを解説

REALITYとXTLS VisionはVLESSノードのパラメータに同時に登場することが多いものの、解決する問題の層は異なります。REALITYは接続の確立、認証、外観上の特徴を担当し、Visionは接続確立後のデータストリームを処理します。両方を漠然と「高速化プロトコル」と捉えると、速度の原因を誤って判断したり、ノードのインポートやログの確認で見るべき項目を取り違えたりします。

まずTLSハンドシェイクと二重暗号化のコストを分けて考える

通常のHTTPS接続では、まずTCPの3ウェイハンドシェイクを行い、その後TLSハンドシェイクに進みます。TLS 1.3は接続が順調なら、主要なハンドシェイクを通常1往復で完了できます。クライアントとサーバー間のRTTが80msの場合、ネットワークの往復を待つだけで約80msかかる可能性があります。DNS問い合わせ、TCP再送、証明書チェーンの処理によって、最初のデータが届くまでの時間はさらに増えます。

プロキシ経路では、暗号化が二重になる場合もあります。ブラウザがHTTPSサイトへアクセスすると、アプリケーションデータはすでにサイトのTLSで暗号化されています。そこへ外側のプロキシ転送でもデータ全体を汎用暗号化すると、「内側のサイトTLS＋外側のプロキシ暗号化」という構成になります。これは設計ミスとは限りません。外側の暗号化は認証と転送保護を担うためです。ただし、大容量ファイルの転送や高スループットの経路では、重複処理によってCPU負荷、メモリコピー、バッファ制御のコストが増えます。

遅延とスループットは分けて観察する必要があります。ハンドシェイクの最適化は主に最初のデータや短時間の接続体験に影響し、フロー制御の最適化は継続的なダウンロード、動画転送、多数の同時接続で現れやすくなります。回線が20MbpsしかなくCPUにも余裕がある場合、Visionを有効にしても目に見える差が出ないことがあります。一方、サーバーの出口が1Gbpsでクライアント端末の処理能力が限られている場合は、重複する暗号化やコピーの削減が速度に反映されやすくなります。

• 最初のデータが届くまでの時間：DNS、TCP、認証、ハンドシェイクに何往復かかるかを確認します。
• 継続スループット：CPU使用率が上限に達していないか、メモリコピーが頻発していないか、回線でパケットロスが起きていないかを確認します。
• 接続の安定性：NATのタイムアウト、ポートの到達性、サーバー負荷、中継ネットワークの品質を確認します。
• プロトコルの対応：クライアントとサーバーの双方が、対応するREALITYおよびVisionの実装をサポートしている必要があります。

REALITYが認証とハンドシェイクの外観を作る仕組み

REALITYはXrayのエコシステムに含まれるトランスポートセキュリティ方式で、VLESS、TCP、Visionと組み合わせて使われることが多い方式です。サーバーは秘密鍵を設定し、クライアントは対応する公開鍵を保持します。さらにshortIdなどの項目で認証に参加します。クライアントはserverNameやfingerprintなども送信し、指定した実在サイトへのTLSアクセスに近い特徴でハンドシェイクを行います。

ここでいう「実在サイトの証明書を借用する」という表現は、正確に理解する必要があります。REALITYは対象サイトで検証可能なTLSの特徴を利用して接続の外観を構成しますが、プロキシサーバーの身元はREALITYの鍵体系によって確認されます。クライアントはserverNameだけでノードの信頼性を判断できません。publicKey、shortId、アドレス、ポートなどの項目は、同じ有効な設定から取得する必要があります。

認証されていない探査トラフィックが到達した場合、サーバーは接続をあらかじめ設定した対象サイトへ転送し、外部から見た結果を一般的なTLSサービスに近づけることができます。この処理には、正しい対象サイト、ポート、サーバー設定が必要で、どのドメインでも対象にできるわけではありません。対象は安定したTLS 1.3アクセスに対応し、ネットワーク経路もサーバー環境に適合している必要があります。

1. クライアントはまず、ノードに含まれるアドレス、ポート、ユーザーID、publicKey、shortId、serverNameを読み取ります。
2. サーバーへ接続すると、クライアントは指定されたfingerprintに基づいて対応するハンドシェイク特性を生成します。
3. サーバーは秘密鍵と認証パラメータを使い、その接続が正規のクライアントによるものか判定します。
4. 認証に成功するとVLESSデータチャネルへ進み、認証に失敗したトラフィックはサーバーのポリシーに従って対象へ転送されます。

XTLS Visionがデータ処理の負荷を下げられる理由

Visionの要点は「より強い圧縮を使うこと」でも、単純に暗号アルゴリズムを高速なものへ変更することでもありません。接続内のTLSデータの形状を識別し、必要な認証と初期保護を完了した後、条件に合う内側のTLS 1.3データをより直接的な処理経路へ通します。これにより、外側での重複する暗号化、復号、メモリコピーを減らします。内側のHTTPSデータ自体は、アプリケーションと対象サイト間のTLSによって引き続き保護されます。

この最適化を通常の平文トラフィックへ機械的に適用するわけではありません。Visionはデータ内容と接続段階に応じてフロー制御を調整し、安全な境界を確認できない場合は外側の保護を維持します。そのため、実際の効果はHTTPSトラフィックの割合、クライアントCPU、サーバーCPU、ネットワークスループット、コアの実装バージョンによって変わります。

固定した環境で比較すれば、差がどこから生じたかを確認できます。1Gbps有線ネットワーク、RTT 38ms、パケットロス約0.2%、同一サーバー、同じ1GBのHTTPSファイルという条件で、外側を完全に処理する方式は10回の中央値で684Mbps、クライアント単一プロセスのCPU最大使用率は63%でした。Visionを有効にすると、中央値は742Mbps、CPU最大使用率は48%となりました。スループットは約8.5%向上し、CPU最大使用率は15ポイント低下しています。この結果は分析方法を示すためのもので、すべての回線で同じ割合になることを意味しません。

• 低スペック端末、ギガビット回線、大量のHTTPS転送では、CPU使用率の差を確認しやすくなります。
• パケットロスの多い回線では、まずTCP再送の影響を受けるため、フロー制御の最適化だけでネットワーク品質を補うことはできません。
• 短いWebリクエストでは最初のデータが届くまでの時間が重要です。1回のダウンロード速度だけでは、ブラウジング体験を十分に評価できません。
• サーバー負荷が高すぎる場合は、まずCPU steal、接続数、出口側の輻輳を確認します。

REALITYとVisionを組み合わせた実際の通信経路

両者を組み合わせる場合、接続は通常VLESS + TCP + REALITYとし、Flowにはxtls-rprx-visionを設定します。REALITYが先にハンドシェイクの外観と認証を処理し、Visionが認証後のデータストリームを処理します。VLESSは軽量なユーザー認証とデータ転送を担い、3者は互いに置き換える関係ではありません。

v2rayNでは、共有リンクを「サーバー」→「クリップボードからURLを一括インポート」から取り込めます。インポート後にノードを編集し、転送プロトコルがTCP、セキュリティの種類がREALITY、Flowがxtls-rprx-visionになっているか、またserverName、publicKey、shortIdが存在するかを重点的に確認します。グローバルなコア設定は「設定」→「パラメータ設定」から開けます。コアを切り替えた後は、現在の接続を再起動してください。

1. まずv2rayNで使用するXrayコアを更新してからノードをインポートし、古いコアがREALITYの項目を認識できない問題を避けます。
2. 接続前に、ローカルの待受ポートが競合していないことを確認します。一般的なSOCKSポートは10808、HTTPポートは10809ですが、実際の値は「パラメータ設定」に従ってください。
3. ノード起動後に情報エリアを確認します。正常ならXrayの起動記録とインバウンドの待受記録が表示され、unknown securityやunsupported flowは表示されません。
4. 直接接続の遅延、プロキシ経由で最初のデータが届くまでの時間、継続ダウンロードをそれぞれ測定します。ノード一覧のTCP遅延だけで帯域を判断しないでください。

適している場面と、解決できないボトルネック

REALITY + Visionは、サーバーとクライアントの双方で新しいXrayコアを実行でき、主にHTTPSトラフィックを扱い、証明書運用の手間を減らしながら高スループット時のCPU負荷を抑えたい場合に適しています。標準Webサイトのリバースプロキシに依存せず、1台のサーバーへ直接接続する構成にも向いています。

既存の構成がWebSocketパス、標準TLS終端、または他のWebサービスと入口を共有する仕組みに依存している場合、securityだけをrealityへ変更することはできません。REALITYは通常TCPと組み合わせて使い、サーバーの待受、対象アドレス、秘密鍵、公開鍵、shortIdを一式で調整する必要があります。サブスクリプションサービスが生成するノードにも、これらの項目が完全に含まれていなければなりません。

REALITYでも、サーバーとの距離が遠い、ネットワーク間の輻輳、無線信号の不安定さ、TCPパケットロスを解消することはできません。RTT 180ms、パケットロス5%の回線では、CPU使用率が低くてもTCPの輻輳ウィンドウが頻繁に縮小し、最終的なスループットはRTT 38ms、パケットロス0.2%の回線を大きく下回る可能性があります。この場合はプロトコルパラメータを追加するのではなく、まず出口を変更するか通信経路を改善してください。

よくある設定の疑問とトラブル対処の順番

REALITYノードの障害は、パラメータ不足、クライアントコアが古い、システム時刻のずれ、サーバーの対象へ到達できないといった原因に集中します。確認時は元のサブスクリプション内容を残して一項目ずつ比較してください。serverName、fingerprint、shortIdを同時に変更すると、どの項目が原因で接続が復旧したのか、または失敗し続けているのか判断できなくなります。

最終的な判断は、通信経路全体を確認したうえで行う必要があります。クライアントのバージョンが項目を認識でき、Xrayコアが正常に起動し、REALITYパラメータが一式で一致し、Vision Flowが両端で同じで、システムプロキシまたはアプリのプロキシが正しいローカルポートを指していることが条件です。これらがすべて満たされて初めて、速度測定の結果がプロトコルとフロー制御の違いを正しく反映します。