REALITYとXTLS Visionの仕組みを解説：VLESSの新しい通信方式はなぜ速い？

VLESS・REALITY・Vision：3つの名称と役割

ノード一覧にある「VLESS + REALITY + Vision」は、3つのプロキシプロトコルを重ねたものではありません。VLESSはプロキシプロトコル、REALITYはセキュリティ層の方式、VisionはXrayのフロー制御モードの一つで、設定値は通常xtls-rprx-visionです。さらに下位層には通信路が必要で、一般的にはTCPを使います。新しいバージョンの画面や設定では、こうした通信方式がRAWと表示される場合があります。

それぞれの役割は、「宛先をどう指定するか」「接続相手をどう認証するか」「その後のデータをどう運ぶか」に分けると理解しやすくなります。VLESSの要求にはユーザー識別情報と宛先情報が含まれますが、UUIDがすべての通信を暗号化するパスワードというわけではありません。一般的な設定のVLESS encryption=noneは、この層で追加の暗号化を行わないという意味であり、接続全体が平文で送信されるわけではありません。

ここではXrayの実装について説明します。v2rayNでは複数のコアを使用できるため、対象ノードがこの組み合わせに対応したXrayで実行されているか確認してください。v2rayNGはXrayコアを使用します。v2flyNGはV2Flyコアを使用するため、一部のVLESS情報をインポートできても、XrayのREALITYとVisionに対応しているとは限りません。サブスクリプションにノードが表示されることと、コアで接続できることは別の問題です。

TLS over TLS：暗号化の重複はどこで起こる？

ブラウザーでHTTPSサイトを開くと、ブラウザーと接続先サイトの間にTLS接続が確立されます。プロキシは通常、このHTTPSの内容を復号せずにバイト列を転送します。その通信をさらにTLSで保護されたプロキシトンネルに入れると、同じデータがサイトとの接続で暗号化された後、プロキシトンネルでも暗号化されることがあります。これが一般に「内側のTLS」と「外側のTLS」と呼ばれる状態です。

上記は各処理の役割を示すもので、すべてのハンドシェイクが厳密に順番どおり進むという意味ではありません。接続の確立時には、クライアントとプロキシサーバーがハンドシェイク情報を交換し、プロキシサーバーは接続先サイトにも接続します。重複する暗号化処理を一部省けても、通信の往復時間、サイトの応答時間、TCPのパケット損失と再送などのコストは残ります。

• 内側の保護：ブラウザーと接続先サイトの間のTLSがサイトの内容を保護します。プロキシサーバーが転送するのは、通常、暗号化されたレコードです。
• 外側の保護：ローカルクライアントとプロキシサーバーの間の安全な通信路が、プロキシ要求とトンネル内のデータを保護します。
• 追加の処理コスト：暗号化・復号の重複、レコードのカプセル化、バッファー処理、データコピーにより、CPUやスループットに負荷がかかることがあります。
• 最適化の範囲：TLS以外の通信に対して、「内側ですでに暗号化されているから、外側の処理を減らせる」と単純に判断することはできません。

そのため、Visionの性能向上は、HTTPSデータを継続的に転送し、クライアントまたはサーバーの処理能力がボトルネックになっている場面で期待しやすくなります。回線の帯域幅が小さい場合や、混雑時のパケット損失が目立つ場合は、カプセル化方式を変えても混雑は解消されません。

XTLS Vision：トラフィック識別、パディング、転送の最適化

Visionはプロキシが運ぶ内側のTLS通信を監視し、接続の初期段階で仕様に沿ったパディングを行い、その後の通信が最適化の条件を満たすか判定します。実装が識別でき、条件を満たす内側のTLS暗号化アプリケーションデータについては、専用の直接転送経路に切り替え、外側の暗号化の重複や一部のバッファー処理を減らせます。

「直接転送」は、プロキシサーバーを経由しないことでも、HTTPSを復号して平文にすることでもありません。データは引き続きクライアント、プロキシサーバー、接続先サイトの順に流れます。減らすのは不要な重複処理です。また、接続の最初のバイトからセキュリティ層を完全になくすという意味でもありません。ハンドシェイクやプロキシ要求、直接転送の条件を満たさないデータには、それぞれ適切な保護と処理が適用されます。

1. まず安全な接続を確立。クライアントとサーバーがセキュリティパラメーターを確認し、VLESS要求でユーザーと宛先の情報を伝えます。
2. 次に初期データを処理。Visionが最初のデータにパディングを施し、内側のTLSハンドシェイクとレコードを識別します。
3. 条件を満たす場合に最適化。実装要件を満たす内側の暗号化アプリケーションデータは直接転送経路に進みます。すべてのバイトが一律に同じ経路を通るわけではありません。
4. その他の通信は保護を維持。識別できない通信や条件を満たさない通信は、適用される経路で処理されます。暗号化済みのデータとして強制的に扱うことはできません。

Visionには一部のトラフィック特性を目立ちにくくする設計も含まれますが、通信を識別できなくしたり、常に利用可能にしたりするものではありません。接続先サイトの選択、ネットワーク環境、サーバー設定、コアの実装などが結果に影響します。速度と接続の可用性は分けて測定し、1回の速度測定だけで長期的な状態を判断しないでください。

REALITY：独自証明書は不要、サーバー認証は必要

一般的なTLSサーバーでは、独自ドメインに証明書を設定し、更新も行う必要があります。REALITYの一般的な構成では、プロキシサーバー自身のドメイン用に証明書を取得する必要はありません。その代わり、接続先サイトのTLS特性と追加の認証方式を組み合わせて接続を確立します。クライアント設定のサーバー公開鍵、ServerName、Short IDはいずれも役割があるため、見た目が正しそうなドメイン名だけを入力しても機能しません。

REALITYサーバーは秘密鍵を保持し、クライアントはサーバーから提供された対応する公開鍵などのパラメーターを使って接続を認証します。「あるサイトの証明書が見えた」ことだけを根拠にプロキシサーバーを信頼する仕組みではありません。認証条件を満たさない接続は、通常、設定に応じて接続先サイトへ転送されます。これは、認証済みユーザーのすべての通信がそのサイトを経由するという意味ではありません。

• アドレスとポート：実際のプロキシサーバーを指定します。サーバーが待ち受けているポートを入力してください。必ず443に変更するわけではありません。
• ServerName：画面上ではSNIと表示されることがあります。サーバーが許可している名前を指定します。ノードの接続先アドレスとは異なる場合があります。
• 公開鍵：サーバーから提供された対応する値を使用します。秘密鍵はサーバー側に保持し、クライアントの公開鍵欄に入力してはいけません。
• Short ID：サーバーが許可している値と一致させます。空欄が許可されるかどうかは実際の設定によります。
• フィンガープリント：chromeなどを指定し、TLS ClientHelloの模擬特性を選択します。クライアント全体がブラウザーに変わるわけではありません。

接続先サイトのTLS互換性、到達性、応答状況はサーバー側で確認する必要があります。ServerNameをランダムに変更しても、確実な解決策にはなりません。システム時刻も認証に影響するため、時刻のずれが大きい場合は、まず時刻の自動同期を有効にしてから再接続してください。

v2rayN・v2rayNG：名前で推測せず、設定項目を照合

まず既存のサブスクリプションからノード全体をインポートしてください。手動で編集する場合は、セキュリティ層を確認してから、Flow、通信方式、ServerName、公開鍵、Short IDを照合します。以下の2つのカードは、異なるセキュリティ層でよく使われる構成の比較です。そのままコピーして使える完全なノード設定ではありません。アドレス、ユーザー識別情報、認証パラメーターはサーバーから提供された情報に従ってください。

1. デスクトップでノードを確認。v2rayNのノード一覧で対象のVLESSノードをダブルクリックし、プロトコル、通信方式、セキュリティ層、Flowを一つずつ確認します。これらの機能に対応したXrayコアが使われていることも確認してください。バージョンによって項目名が多少異なる場合があります。
2. ローカルの接続先を確認。v2rayNの「設定」→「パラメーター設定」を開き、ローカルの待ち受けポートに関する設定を確認します。たとえばクライアントが127.0.0.1:10808で待ち受けている場合、アプリに手動でプロキシを設定する際も、対応するアドレス、ポート、プロキシ種別を指定します。ここでの10808は確認用の例であり、すべての環境で固定の値ではありません。
3. Androidで設定項目を確認。v2rayNGのノード一覧から対象ノードの編集画面を開き、通信方式、セキュリティ設定、フロー制御を確認します。保存後に対象ノードを選び直して接続を開始し、別の設定をテストしたままになっていないか確認してください。
4. 入口と出口を区別。デスクトップのシステムプロキシやAndroidのVPN接続設定は、アプリの通信がクライアントに入るかどうかを決めます。ノードのセキュリティ設定はプロキシ接続を確立できるかどうかを左右し、ルーティングルールは通信が最終的にプロキシ経由か直接接続かを決めます。

REALITYの接続エラーを解決するために、証明書検証を無効にしたり、公開鍵を削除したり、Short IDをむやみに変更したりしないでください。こうした変更は正しいサーバーパラメーターの代わりにはならず、問題の切り分けを難しくします。画面を共有する場合は、サブスクリプションのURL、ユーザー識別情報、その他の機密設定を隠してください。

速度低下と接続トラブル：比較テストで原因を切り分ける

「なぜ速くなるのか」は仕組みとして説明できますが、すべての回線での結果を保証するものではありません。Visionと別の構成を比較する場合は、できるだけ同じサーバー、近い時間帯、同じ接続先を使い、初回接続の遅延、継続ダウンロード時のスループット、CPU使用率を分けて確認してください。地域の異なる2つのノードは、プロトコル名が違っていても有効な性能比較にはなりません。

• 条件をそろえる：ネットワーク、接続先、ルーティングを統一し、バックグラウンドのダウンロードを停止します。テスト対象のアプリの通信が、実際に測定対象のノードを経由していることを先に確認してください。
• 項目を分けて記録：初回要求の所要時間はミリ秒で、継続転送のスループットはMB/sまたはMbit/sで記録し、単位も明記します。両者は約8倍異なるため、混同しないでください。
• 複数回測定：各構成で30秒間の転送を3回行い、中央値と大きな変動を記録します。これは推奨する測定方法であり、本記事で実測した結果ではありません。
• リソースを確認：クライアントとサーバーのCPU使用率を同時に確認します。CPU使用率が上限に近い場合は、重複処理を減らすことで効果が出る可能性があります。スループットが低くCPUに余裕がある場合は、回線や接続先サービスを優先して確認してください。

最後に、次の3点を分けて確認してください。安全なハンドシェイクを完了できるか、アプリの通信が正しい出口に流れているか、継続転送時の処理負荷が減っているか。REALITYは一般的な構成で必要となる独自証明書の管理を不要にし、Visionは条件を満たす内側のTLS通信で重複処理を減らし、VLESSはプロキシ要求を運びます。設定項目が正確で、コアが対応し、測定条件がそろっていれば、この組み合わせが現在のネットワークに適しているか判断できます。