REALITYとXTLS Visionの仕組みを解説：VLESSのフロー制御で暗号化の重複を抑える方法

TLSハンドシェイクとプロキシトンネル：暗号化が重複する階層

HTTPSサイトにアクセスすると、まずブラウザーと接続先サイトの間でTLSをネゴシエートします。ハンドシェイクではプロトコルのパラメーターを決め、サイトの正当性を確認してセッション鍵を確立します。その後のHTTPリクエストとレスポンスはTLSレコード層で暗号化されます。プロキシ経由でも、このサイトとのTLS接続は通常、ブラウザーとサイトの間でエンドツーエンドに維持されます。

プロキシクライアントとプロキシサーバーの間にもTLSトンネルを確立すると、ブラウザーが生成したTLS暗号文は外側のトンネルのペイロードになります。クライアントは暗号化済みのデータをさらに暗号化し、サーバーは外側を復号してから内側の暗号文をサイトへ転送します。これが一般に「TLS over TLS」と呼ばれる状態です。ただし、2つのTLS層が保護する接続はそれぞれ異なります。

暗号化の重複は、暗号処理やレコードのカプセル化、メモリー間のデータ移動を増やします。ただし、それが接続の遅さの主な原因とは限りません。Webページの初回表示には、DNS名前解決、ネットワーク経路の往復時間、パケットロス、サーバーの処理待ちも影響します。Visionが最適化するのは特定のデータ経路であり、これらのコストすべてを取り除くものではありません。

• 内側のTLS：ブラウザーと接続先サイト間の暗号化です。通常、プロキシサーバーはサイトとのセッション鍵を持ちません。
• 外側のセキュアな通信：クライアントとプロキシの接続先との間を保護します。REALITYが扱うのは、この側のハンドシェイクと認証です。
• VLESS：プロキシリクエストでユーザーの識別情報や接続先アドレスなどを扱います。アプリケーションデータを暗号化する方式そのものではありません。

REALITY：実在サイトの証明書とクライアント認証

REALITYはXrayの通信セキュリティ機構です。一般的な設定では実在するTLS接続先を指定し、そのサイトに適合するサーバー名やハンドシェイクの特徴を選びます。接続先サイトの実際のハンドシェイク情報や証明書の外観を利用して、入口が通常のTLSサービスに近い動作をする一方、事前設定されたクライアントには専用の認証経路を提供します。

「証明書を借りる」といっても、証明書をダウンロードすれば任意のサイトになりすませるわけではありません。また、プロキシサーバーが接続先サイトの秘密鍵を入手するわけでもありません。REALITYクライアントはTLSハンドシェイクを処理するだけでなく、事前設定された公開鍵などを使って対応するREALITYサーバーを検証します。実在サイトの証明書は、ユーザーが設定する公開鍵の代わりにはなりません。

認証されなかった接続は、REALITYの設定や実装に応じて接続先サイトへ転送される場合があります。ただし、どのようなプローブでもまったく同じ応答になるとは限りません。接続先サイトへの到達性、TLSの互換性、入口アドレスやネットワーク経路の特徴が結果に影響します。接続先の選択が誤っている場合、クライアントのフィンガープリントだけを変更しても解決しないことがあります。

XTLS Vision：暗号化の重複を減らせる条件

Visionで一般的に使われるflowの値はxtls-rprx-visionです。単なる設定ラベルではなく、接続初期のデータの識別やパディング、その後の転送方法も含みます。クライアントとサーバーの両方がこの動作に対応し、正しく設定されている必要があります。クライアント側の項目だけを変更すると、接続できなくなることがあります。

条件を満たし、内側のTLS 1.3トラフィックとして識別できる場合、Visionはハンドシェイク後にデータ処理経路を切り替え、内側のTLSで保護済みのアプリケーションデータに外側のTLSレコード暗号化を重ねずに転送できます。接続先サイトとのTLSはそのまま維持され、ブラウザーによる証明書検証も引き続き行われます。減らせるのは、プロキシ層での暗号文の重複処理です。

1. 外側の接続を確立：クライアントはまずプロキシサーバーとのセキュアな接続と認証を完了します。REALITYの設定項目も必ず確認してください。
2. プロキシリクエストを送信：VLESSでユーザー情報と接続先を伝え、Visionが初期データを処理しながら内側のプロトコルの特徴を確認します。
3. 条件を満たすか判定：識別され、要件を満たしたTLSトラフィックのみ、外側の暗号化を減らす経路を利用できる可能性があります。
4. 以降のデータを転送：内側のTLS暗号文はそのまま転送されます。条件を満たさないトラフィックが「平文で直接送信される」わけではありません。

通常のHTTP、識別できないトラフィック、UDP、およびQUICが使うUDP経路には、「TLS 1.3の暗号文をそのまま転送する」という説明をそのまま当てはめられません。TLS 1.2でも同じ最適化効果が得られるとは限りません。効率的な経路が使われるかどうかは、実際のコア実装、トランスポートの組み合わせ、OSにも左右されます。

プロトコルの数値：TLSバージョン、443番ポート、性能の限界

以下の数値はプロトコルや一般的な構成に関するもので、この記事で測定した速度ではありません。「接続入口の種類」と「データの処理方法」を区別する参考にはなりますが、特定のサブスクリプションノードの実速度を示すものではありません。

大容量ファイルの転送でクライアントまたはサーバーのCPU使用率が上限に達している場合、暗号化の重複を減らすことでCPU負荷が下がり、利用可能なスループットが向上することがあります。環境によっては、より効率的なデータ転送方式を利用できる場合もあります。ただし、Macのデスクトップクライアントとサーバーではシステムの機能が異なるため、あるプラットフォームでのゼロコピーの効果をすべてのデバイスに当てはめることはできません。

遅延の改善にも条件があります。高負荷時は処理負荷を減らすことで待ち時間が短くなる可能性がありますが、アイドル状態の接続で行う小さなリクエストでは、ネットワークの往復時間が引き続き支配的なことが多いです。Visionは圧縮方式ではなく、プロキシサーバーから接続先サイトまでの物理的な距離を縮めるものでもありません。

• CPU負荷を比較するときは、クライアントとサーバーの両方を確認してください。ローカルの負荷低下だけを見て、サーバー側がボトルネックになっていることを見落とさないようにします。
• スループットを比較するときは、同じ入口、接続先のデータ、ルーティングルール、同時接続数にそろえます。各条件で少なくとも3回測定し、結果を記録してください。
• Webページの遅延を比べるときは、初回接続と再利用接続を分けて考えます。DNSキャッシュや接続の再利用によって結果は大きく変わります。
• 比較のためにflowをそのまま削除しないでください。サーバー側がそれぞれに対応した設定を提供している必要があります。そうでなければ、比較しているのは正常な接続と設定ミスの状態です。

v2rayNとv2rayNG：サブスクリプション追加後に確認する設定項目

デスクトップでv2rayNを使う場合は、まずサブスクリプションを追加してグループを更新し、対象ノードの編集画面で各項目を確認します。Androidのv2rayNGではXrayコアを使用し、同じ設定項目を確認できます。v2flyNGはv2flyコアを使用します。一部のVLESSリンクを読み込めるからといって、XrayのREALITYとVisionの組み合わせにも対応しているとは限りません。

編集画面や翻訳、内部項目の名称はバージョンによって変わることがあるため、以下では特定バージョンのメニュー名ではなく、設定の意味に沿って確認項目をまとめます。共有リンクでよく見かけるpbkはREALITYの公開鍵情報に対応します。画面上では別のラベルで表示される場合もあるため、使用中のコアの要件を確認してください。

共有リンクではencryption=noneもよく使われます。これはVLESSプロトコル層の設定を表すもので、接続全体が暗号化されないという意味ではありません。外側のセキュアな通信はREALITYが担い、HTTPSの通信には内側のTLSもあります。設定を「より安全に」見せるために、プロトコルがサポートしていない値へ勝手に変更しないでください。

ハンドシェイク失敗や接続後にサイトを開けない場合の切り分け

トラブル時は、接続入口のTCPに到達できるか、REALITY認証が成功するか、アプリケーションの通信がプロキシに流れているかの3段階に分けて確認します。一度に変更する項目は1つにし、対応するログを記録してください。SNI、ポート、flow、フィンガープリントを次々と変更すると、原因を特定しにくくなります。

ログにTCP接続のタイムアウトが表示される場合は、まずネットワーク経路、入口の待ち受け状態、ファイアウォールを確認してください。認証完了後に特定のサイトだけで問題が起きる場合は、そのサイトの名前解決結果、接続先への疎通、ルーティングルールを調べます。すべての接続エラーをREALITYの問題と決めつけず、設定ミスを覆い隠すために全般モードを何度も切り替えることも避けてください。