REALITYとXTLS Visionの仕組みを解説：暗号化を1層減らすと速くなる理由

まず整理したい3つの名称：VLESS、REALITY、Vision

v2rayNやv2rayNGでよく使われるノード構成は「VLESS + REALITY + XTLS Vision」です。これらは互いに置き換えられる3つのプロトコルではありません。VLESSはユーザー情報や接続先アドレスを含むプロキシ要求を定義し、REALITYは接続時の外側のハンドシェイクと認証を担います。VisionはXrayのフロー制御機能で、トンネル内のデータ処理方法を決めます。それぞれの役割を分けて考えると、エラー時にどの項目を確認すべきか判断しやすくなります。

VLESSのencryptionで一般的な値はnoneです。これはVLESS自体がペイロード暗号化を追加しないという意味で、接続全体が平文になるわけではありません。REALITYを使う場合も接続確立にはセキュリティレイヤーが関わります。また、ブラウザーでHTTPSサイトにアクセスする際は、アプリケーション側のTLS暗号化も維持されます。

HTTPS通信をプロキシ経由にすると、なぜ暗号化が2層になるのか

ブラウザーでHTTPSサイトを開くと、まず接続先サイトとTLSハンドシェイクを行います。その後、ウェブページの内容やログイン情報、応答データはアプリケーション層のTLS暗号文になります。プロキシはこの接続を接続先サイトまで中継するだけで、サイトとの通信を復号する鍵を得るわけではありません。

プロキシトンネル自体にもTLSを使う場合、ブラウザーが生成した暗号文は、さらにプロキシ接続のTLSレコードに包まれます。クライアントが外側を暗号化し、サーバーが外側を復号してから、内側の暗号文をサイトへ転送します。この「二重のラッピング」は一般的で、実用上の意味もありますが、大量の通信では追加の暗号化・復号、バッファー処理、データコピーのコストが発生します。

Visionの目的はHTTPSを無効にすることではありません。内部TLSの段階を識別し、条件を満たす場合に後続データの転送方法を変えます。TLS 1.3の通信を識別できた場合は、適切な段階から直接転送モードに移行し、暗号化済みのアプリケーションデータに外側のTLS暗号化・復号を重ねずに済むことがあります。初期ハンドシェイクや必要なプロキシ情報は引き続き保護されるため、接続成立後にすべてのデータを無防備に送るわけではありません。

• 接続先サイトの暗号化は維持：ブラウザーは引き続きサイトの証明書を検証します。サイト証明書の検証を無効にするようユーザーに求めるべきではありません。
• 最適化には識別条件がある：すべてのTCP通信やTLSバージョンが同じ最適化経路を使えるわけではありません。
• 通常のHTTPがHTTPSになるわけではない：Visionがアプリケーションに代わって接続先サイトとのエンドツーエンド暗号化を追加することはありません。
• ハンドシェイク中にはパディングがある：Visionは初期段階のデータにパディングを加えます。「すべてのパケットが小さくなる」とは言えません。

REALITYが実在サイトのハンドシェイクを利用する仕組み

一般的なTLSプロキシサービスでは、独自ドメインと証明書を用意する必要があります。REALITYは異なる仕組みを採用しており、サーバー側で適切な実在のTLS接続先を設定し、クライアントは合意された認証情報を添えてハンドシェイクを開始します。認証に成功すると、クライアントとREALITYサーバーの間にプロキシ経路が確立されます。認証されなかった接続は、設定された接続先へ転送し、実在サイトとの通常のTLS通信のように見せることができます。

「実在サイトを利用する」は理解しやすくするための表現であり、そのサイトの秘密鍵を取得することでも、プロキシ通信のすべてがいったんそのサイトを経由することでもありません。認証後のプロキシデータは、サーバーが接続先アドレスに応じて転送します。設定された実在サイトは、主にハンドシェイクの外観や未認証接続の処理などに関わります。また、クライアントがREALITYサーバーを信頼する根拠は、接続先サイトの公開証明書をそのままローカルにコピーすることではありません。

接続先アドレス、SNI、実際の接続先は別の項目

• サーバーアドレス：クライアントが実際に接続するプロキシサーバーのIPアドレスまたはドメイン名です。ハンドシェイク先のサイトに置き換えてはいけません。
• SNI / Server Name：ハンドシェイクでクライアントが使用する名前で、サーバーが許可する値と一致している必要があります。アドレスに接続できても、この項目が正しいとは限りません。
• サーバー側の実際の接続先：サーバーの管理者が選択します。TLS 1.3やHTTP/2などの対応条件に加え、サーバーから接続先への遅延や到達性も確認が必要です。
• クライアントフィンガープリント：chromeなど、ClientHelloの構成に影響します。正しい鍵、SNI、認証情報の代わりにはならず、実際のブラウザーと完全に同じ挙動を保証するものでもありません。

v2rayN・v2rayNGで確認する設定項目

まず信頼できるサブスクリプションからノード情報をまとめてインポートし、ノード編集画面で項目を確認します。クライアントのバージョンによってメニュー名は異なりますが、プロトコル、トランスポート、セキュリティレイヤー、Flowの意味は変わりません。以下の2つのカードは、同じ接続のクライアント側とサーバー側の対応を示したもので、そのまま使えるノード設定一式ではありません。ポート443はよくある例にすぎず、実際にサーバーが待ち受けているポートを使ってください。

REALITYの鍵情報は、クライアント画面やXrayの設定バージョンによって項目名が異なる場合があります。古い設定ではpublicKey、新しい設定ではpasswordが使われることがあります。項目名だけを見てJSONを手作業で移し替えず、実際に動作しているコアのドキュメントとクライアントのインポート仕様に従ってください。サーバーの秘密鍵を一般ユーザーに渡してはいけません。

Short IDには16進文字列を使います。空でない場合、文字数は偶数で、最大16文字です。空欄を許可するかどうかはサーバー設定によります。ユーザーIDや適当なメモではありません。サブスクリプションにShort IDが記載されている場合は、その値を変更しないでください。1文字変えるだけでも認証に失敗することがあります。

暗号化を1層減らすと速くなる理由、速くなるとは限らない理由

暗号化だけが処理負荷の原因ではありませんが、高スループットの接続では大きな負荷になることがあります。Visionは条件に合うデータの二重暗号化・復号を減らし、実装が対応していれば効率的な転送経路を使うことで、CPU使用率とデータコピーの負担を抑えます。サーバーで大容量通信を複数処理する場合、短いウェブリクエストより効果が表れやすくなります。

ボトルネックがモバイル回線のパケットロス、サーバーのアップリンク帯域、通信事業者の混雑、接続先サイトの速度制限にある場合、暗号化を1層減らしてもダウンロード速度は変わらないかもしれません。TCPの輻輳制御はそのまま働き、REALITYが回線の物理帯域を増やすこともありません。あるノードが速かったからといって、「REALITYのノードはすべて他の構成より速い」とは言えません。

条件をそろえて比較テストを行う方法

1. 同じ端末、ネットワーク、サーバー、ダウンロード先を使い、他の大容量通信を停止します。Wi-Fiの電波状況の変化を、プロトコルの効果と誤認しないようにしましょう。
2. サーバーが明確に対応している2種類のテスト設定を使います。比較のためにFlowを単純に空欄にせず、クライアントとサーバーの設定を一致させてください。
3. 各設定で60秒間連続してダウンロードし、3回繰り返します。平均スループット、クライアントとサーバーのCPU使用率、接続エラーを記録してください。
4. 大容量ファイルのダウンロードとウェブページの初回表示をそれぞれテストします。CPU使用率だけが下がり、スループットが変わらない場合、最適化は機能していても、速度のボトルネックは別の場所にある可能性があります。

接続できない場合は、ハンドシェイクの段階ごとに確認

「ハンドシェイク失敗」はセキュアな接続が完了しなかったことを示すだけで、証明書の問題とは限りません。REALITYの認証情報の不一致、許可されていないSNI、サーバー側の接続先に到達できないこと、端末の時刻ずれなども接続失敗の原因になります。まずTCP接続が確立できるかを確認し、次にREALITYの認証、最後にVLESSのユーザー情報とFlowを調べましょう。暗号化の設定を何度も切り替えるより、効率的に原因を絞り込めます。

1. まず接続先アドレスを確認：クライアントがハンドシェイク先ではなく、プロキシサーバーに接続していることを確認します。ログにタイムアウトや接続拒否がある場合は、待ち受けポート、ファイアウォール、ネットワークからの到達性を調べてください。
2. 次にシステム時刻を確認：Windowsの「設定」→「時刻と言語」→「日付と時刻」で、自動時刻設定と同期状態を確認します。Androidでも日付と時刻の自動設定を有効にしてください。REALITYではサーバーのポリシーにより時刻のずれが制限されることがあります。
3. 認証情報を照合：SNI、クライアントの認証鍵情報、Short IDを1項目ずつ比較します。サーバーで鍵が更新されると、アドレスが同じでも古いサブスクリプションでは接続できない場合があります。
4. ユーザー情報とFlowを確認：VLESSのユーザーIDがサーバーに登録されていることと、クライアント・サーバーのVision設定に互換性があることを確認します。REALITYのセキュリティ設定とFlowの項目を混同しないでください。
5. 実際に使われているコアを確認：v2rayNで、現在選択されているXrayコアがこの組み合わせに対応しているか確認します。画面上でノードを保存できても、選択中のコアがすべての項目を受け付けるとは限りません。
6. 最後に接続先と転送を確認：ハンドシェイクに成功してもページを開けない場合は、サーバーのDNS、アウトバウンドルーティング、接続先への到達性、クライアントが対象の通信をプロキシ経由にしているかを調べます。