REALITYプロトコルとXTLS Vision解説：ハンドシェイクの仕組みと性能メリット

まずREALITY、VLESS、XTLS Visionの違いを整理

サブスクリプションでよく見かける構成は「VLESS + TCP + REALITY + XTLS Vision」です。この4つは同じ階層のプロトコル名ではありません。VLESSはクライアントとサーバー間のユーザー識別とプロキシリクエスト形式を担当し、TCPはデータを運ぶ通信方式、REALITYは外側のハンドシェイク、サーバー認証、トラフィックの外観を担います。XTLS Visionはフロー制御の方式で、アプリケーション層TLSで暗号化済みのデータを識別し、転送経路を調整します。

したがって、REALITYはVLESSに代わる独立したプロキシプロトコルではなく、Xrayコアにおけるトランスポートセキュリティの仕組みと考えるのが正確です。サーバー自身のドメインに公開証明書を取得したり、専用ドメインをサーバーへ向けて名前解決したりする必要はありません。クライアントはpublicKey、shortId、serverNameなどのパラメータで接続先サーバーを識別し、サーバーは設定済みの実在サイトをハンドシェイクの外観とフォールバック先として利用します。

XTLS Visionも新しい暗号アルゴリズムではありません。Webアクセス自体が通常HTTPSで暗号化されているため、従来の外側TLSでこの暗号文をもう一度完全に処理すると、「TLSの中にTLSを重ねる」データ経路になります。Visionは接続特性を確認した後、この転送処理を最適化し、重複処理とメモリコピーを減らしながら、接続開始時に必要なパディングとハンドシェイク保護を維持します。

REALITYは実在サイトの特性をどう利用するのか

通常のTLSサーバーでは、自身のドメインに対応する公開証明書をサーバーから送信します。REALITYは異なる方式を採用します。クライアントは一般的なブラウザーに近いClientHelloを生成し、設定済みのserverNameをSNIに入れます。サーバーは秘密鍵と公開鍵の対応関係、shortIdなどを使って有効なクライアントからの接続かを判定し、適切な認証処理を行います。

有効な認証情報を持たない接続は、サーバーの設定に従ってあらかじめ指定した対象サイトへハンドシェイクを転送できます。外部から見えるSNI、TLSバージョン、暗号スイート、対象サイトの応答が一貫した文脈になるため、プロキシ専用に用意した自己署名証明書を露呈しません。ここでいう「利用」は、対象サイトの公開ハンドシェイク特性とフォールバック動作を再利用することであり、対象サイトの秘密鍵をコピーしたり正規証明書を偽造したりすることではありません。

1. 挨拶を生成：クライアントはfingerprintパラメータに従ってTLS ClientHelloを構成します。一般的な値はchromeです。
2. 対象名を付加：serverNameはSNIに入り、サーバーが許可した名称の範囲に含まれ、サーバー設定とも一致している必要があります。
3. 認証を完了：クライアントのpublicKeyはサーバーのprivateKeyに対応し、shortIdもサーバーの許可値に一致する必要があります。
4. 接続を振り分け：認証に成功するとVLESSセッションへ進み、認証に失敗した通常のTLSトラフィックはサーバー設定に従って対象サイトへ転送されます。
5. プロキシを開始：VLESSが宛先アドレスを解析し、その後のデータを通常処理するか最適化転送するかをVisionが判断します。

XTLS Visionが重複する暗号化処理の負荷を減らす仕組み

HTTPSサイトを開く場合、ブラウザーはまず対象サイトとTLS接続を確立します。さらにプロキシ経路の外側で標準TLSを使うと、プロキシコアは暗号化済みのアプリケーションデータを継続的に処理する必要があります。2つの暗号化層は論理上それぞれ異なる経路を保護しますが、大きく圧縮できないTLS暗号文が汎用の暗号化・復号とバッファ処理を繰り返し通過すると、CPU使用率、メモリコピー、スケジューリング回数が増加します。

Visionは接続初期のデータを観察し、内側のTLSハンドシェイクとレコード境界を識別します。条件を満たすと、後続の暗号化済みデータをより直接的な転送経路へ移せます。安全層を取り除くのではなく、エンドツーエンド暗号化の特性をすでに備えた大容量データに不要な重複処理を施さないことが最適化の要点です。通常の平文接続や識別できないデータは、コアが対応するルールに従って処理します。

接続前半の処理も重要です。Visionは初期データに必要なパディングと形状調整を施し、固定パケット長や初回パケットの特徴が目立ちすぎることを抑えます。プロトコル状態、通信方向、データ種別が確認されると、より効率的なコピー方式へ切り替わります。そのため、長時間接続、大容量ファイルのダウンロード、高画質動画ではスループットのメリットが現れやすく、少量データの短時間接続では差が小さいのが一般的です。

• HTTPSの大容量通信：内側のデータがすでに暗号化されているため、Visionは最適化経路へ移行しやすくなります。
• 短いWebリクエスト：DNS、TCP接続確立、サーバー応答の占める割合が大きく、速度差は数ミリ秒程度にとどまることがあります。
• 高帯域幅サーバー：CPUやメモリコピーがボトルネックになる場合、スループットの向上がより明確に現れます。
• パケットロスの多い回線：再送と輻輳制御は引き続きTCPが担うため、Visionで回線自体のパケットロスを解消することはできません。

遅延、スループット、CPU使用率の見方

以下は差を把握するための同一環境での比較データです。サーバーは2コアの仮想マシン、クライアントはギガビット有線接続、往復遅延は約42ms、テストファイルは1GBです。3回連続で実行し、中央値を採用しています。標準のVLESS + TCP + TLSとVLESS + REALITY + Visionには同じサーバーと出口を使用しました。データは典型的な傾向を示すもので、すべての回線に固定的に当てはまる結果ではありません。

結論：大容量通信はスループット、短いリクエストは回線を確認

主な問題がWebページの初回表示の遅さなら、まずDNS、ノードまでの距離、パケットロスを確認してください。ダウンロード中にサーバーCPUが長時間80%を超える場合は、同じ回線でREALITY + Visionへ切り替えることで改善が見込めます。

テスト中にノード、対象サイト、プロトコルを同時に変更しないでください。どの要素による改善か判断できなくなります。より確実な方法は、他のダウンロードを停止し、同じテストファイルを固定して3回ずつ実行し、中央値とCPUピークを比較することです。ブラウザーに表示される瞬間速度は変動が大きいため、30秒以上継続した転送結果のほうが参考になります。

クライアントへのインポート後に確認すべきパラメータ

v2rayNのデスクトップ版とv2rayNGのAndroid版では、通常サブスクリプションからREALITYノードをインポートできます。インポートに成功しても、パラメータが完全とは限りません。特にサブスクリプションの変換や手動編集を行った場合、flow、serverName、fingerprint、publicKey、shortIdが失われることがあります。v2flyNGはV2Flyコアを使用するため、XrayのREALITYとVisionに依存するノードには適していません。サブスクリプションが要求するコアに対応したクライアントを選んでください。

互換性を確認する際は、Xray-core v1.8.0をREALITYのやや保守的な基準として利用できます。ただし実際には、使用中のクライアントに付属する現行の安定版コアを優先してください。古いコアがrealitySettingsやxtls-rprx-visionを認識しない場合、ノードを起動できない、設定チェックに失敗する、ログに未知のフィールドが表示されるといった症状がよく見られます。

1. まずサブスクリプションを更新してノード編集画面を開き、プロトコルがVLESS、通信方式がTCPになっていることを確認します。
2. アドレスとポートを確認します。ポートは443が一般的ですが、必ずサブスクリプションの実際の値に従ってください。
3. セキュリティの種類がREALITYで、serverNameが完全なドメイン名になっているか確認します。
4. fingerprintの一般的な値がchromeになっていること、publicKeyとshortIdが途中で切れていないことを確認します。
5. flowがxtls-rprx-visionになっているか確認します。サーバー側で有効にしていない場合は、自分で追加しないでください。
6. 保存後にコアを再起動し、ログにハンドシェイク、認証、未知のフィールドに関するエラーがないか確認します。

よくある疑問とハンドシェイク失敗の対処

REALITYの接続問題は通常、クライアント設定のインポート漏れ、クライアントとサーバーのコア機能の不一致、ネットワークからサーバーの待受ポートへ到達できないことの3箇所で発生します。まずコアが起動できることを確認し、次にTCP接続、最後にREALITYハンドシェイクを調べてください。この順番なら、ポート到達不能を公開鍵の誤りと取り違えずに済みます。

トラブル対処の順番：起動、ポート、ハンドシェイク、プロキシ

まずコアが正常に動作しているか確認し、次にサーバーのポートへ接続できるかを調べ、その後REALITYの認証パラメータ、最後にシステムプロキシとルーティングを確認します。一度に1項目だけ変更して再テストすると、実際の障害箇所を特定しやすくなります。

選択の観点では、REALITY + VisionはXrayコアを使用し、証明書の設定手順を減らしながらHTTPSの大容量通信を最適化したい場面に適しています。ただし、ノードまでの距離、出口の混雑、TCPのパケットロスを自動的に解決するものではありません。クライアントのバージョン、完全なサブスクリプションパラメータ、安定したサーバー回線の3つがそろって初めて、ハンドシェイクの外観とデータ経路の最適化が体感できる接続品質につながります。