REALITYとXTLS Visionの仕組みを解説｜VLESS通信が速くなる理由

VLESS・Vision・REALITYの違いを整理

ノード名に「VLESS + TCP + REALITY + Vision」とまとめて書かれていることがありますが、4つの競合するプロトコルという意味ではありません。VLESSはプロキシ要求の認証とカプセル化を定義し、TCPは信頼性のあるバイトストリームを提供します。REALITYは外側のセキュアな接続を処理し、VisionはXrayのフロー制御モードの一つとして、処理に適した内側のTLS通信を識別して最適化します。

この流れは各機能の役割を示したもので、実装上の処理がすべて厳密に順番に実行されるという意味ではありません。まずセキュアなハンドシェイクで接続を確立し、その後プロキシ要求とデータを送受信します。HTTPSサイトにアクセスすると、ブラウザーとサイトの間にもTLS接続が確立されます。外側の接続はクライアントからプロキシサーバーまでを保護し、内側の接続はブラウザーから接続先サイトまでの通信を保護します。

• VLESS：UUIDなどのパラメーターでユーザーを識別します。VMessのようなペイロード暗号化層は備えておらず、通常はTLSまたはREALITYと組み合わせて使います。
• XTLS Vision：flow: "xtls-rprx-vision"に対応する設定であり、TCPやWebSocketと自由に置き換えられる伝送方式の名称ではありません。
• REALITY：streamSettings.security: "reality"に対応し、通常の"tls"とは異なるセキュリティ設定です。
• Xray：これらの機能を実装するコアです。クライアントの画面でVLESSを設定できても、実行中のコアがREALITYとVisionに対応しているとは限りません。

Visionが二重暗号化を抑える仕組み

ブラウザーでHTTPSサイトにアクセスする場合を考えてみましょう。アプリのデータはまずサイトのTLSで暗号化され、その後プロキシトンネルに入ります。外側のトンネルでもデータを1バイトずつ暗号化すると、「暗号化済みデータをさらに暗号化」することになります。必ずしも目立った遅延が発生するわけではありませんが、暗号処理やデータ処理の負荷は増えます。サーバーのCPU負荷が高い場合や、通信量が多い場合、端末の性能が限られる場合には、その影響が表れやすくなります。

Visionは内側のTLS通信の段階を確認し、開始部分を適切にカプセル化してパディングします。実装条件を満たし、内部TLS 1.3の暗号化データ段階に入ったことを確認できる場合は、最適化されたデータ転送経路に切り替え、暗号化済みペイロードに対する外側での重複処理を抑えます。環境によっては、より効率的なデータ転送方式を利用できますが、有効になるかどうかはOS、接続方式、コアの実装に左右されます。

つまり、「VLESSのほうが速い」というのは簡略化した表現です。より正確には、回線とリソースが同じ条件なら、VLESS、Vision、セキュアな伝送方式を適切に組み合わせることで、カプセル化や二重暗号化が多い構成より処理負荷を抑えられる可能性があります。ボトルネックが夜間の混雑、サーバー側の速度制限、ネットワーク間のパケットロスであれば、プロトコル名を変えても効果はほとんど期待できません。

REALITYのハンドシェイクと認証の仕組み

REALITYはTLS 1.3の仕組みを基にセキュアな接続を確立し、特定の認証情報をハンドシェイクに組み込みます。クライアント側では、サーバーに対応する公開鍵情報、許可されたサーバー名、shortIdなどのパラメーターが必要です。通常のTLS環境のように、ノード管理者がノードのドメイン用に公的に信頼された証明書を取得・維持する必要はありません。ただし、接続先サイトとサーバー側のパラメーターは正しく設定する必要があります。

条件に合うクライアントをサーバーが認識すると、プロキシ接続が確立されます。該当する認証を通過できない接続は、REALITYの設計に従って設定された接続先サイトへ転送されます。この接続先はハンドシェイクの外観やフォールバック動作に関係するもので、一般的なCDN中継を意味するわけではありません。また、通常のプロキシ通信が常に接続先サイトを経由するという意味でもありません。

shortIdはサーバーの許可リストに登録された短い識別子で、UUIDや公開鍵ではありません。空でない値は16進数で構成し、文字数は偶数かつ16文字以下にします。クライアント側の値は、サーバーの許可リストにある値と一致させてください。空の値を使えるかどうかもサーバーの設定によるため、問題の切り分け時に安易に空欄にしないでください。

仕組みをconfig.jsonの設定項目に対応させる

問題を切り分ける際は、「プロキシプロトコルの設定」と「伝送セキュリティの設定」を分けて確認します。一般的なXrayのVLESSアウトバウンド構成では、flowはユーザーオブジェクトに属し、securityはstreamSettingsに属します。この2つを同じ階層に記述したり、VLESSのencryptionにrealityを指定したりしても、正しい設定にはなりません。

以下は設定項目の位置を示す抜粋であり、ノード設定全体ではなく、単独で起動することもできません。1つ目はVLESSユーザーオブジェクト内のフロー制御項目、2つ目は伝送セキュリティのオブジェクトを示しています。実際の設定には、サーバーアドレス、ポート、ユーザー情報、REALITYの認証パラメーターも必要です。

{
  "encryption": "none",
  "flow": "xtls-rprx-vision"
}

{
  "security": "reality",
  "realitySettings": {
    "fingerprint": "chrome"
  }
}

• 項目名はコアの更新に伴い変わります：古い設定では公開鍵の項目名にpublicKeyが使われていましたが、新しいコアのドキュメントやクライアントではpasswordという名前が使われる場合があります。使用するコアに合わせてクライアントで設定を生成し、項目名だけを頼りに複数の手順をつなぎ合わせないでください。
• 伝送方式の名称もバージョンによって異なります：従来の設定ではnetwork: "tcp"が一般的ですが、新しい設定ではrawと表示される場合があります。画面上の名称が変わっても、他の伝送方式を自由に重ねて使えるわけではありません。
• fingerprintとサーバー名は別の項目です：fingerprintはクライアントのハンドシェイク特性を指定し、serverNameはSNIに対応します。互いに入れ替えて設定することはできません。
• 公開鍵と秘密鍵を混同しないでください：クライアントにはサーバーの公開鍵に対応する情報を設定します。サーバーの秘密鍵はサーバー側に保管し、共有リンクやスクリーンショットに含めないでください。

オブジェクトの階層を確認する場合は、設定リファレンスをご覧ください。サブスクリプションを利用している場合は、まず提供元から完全なノード設定を再インポートし、エクスポートした有効な設定と照合するのがおすすめです。生成ファイルを直接編集するより確実です。クライアントの次回起動時に、生成ファイルが上書きされることがあります。

v2rayNとAndroid版クライアントで項目を確認

デスクトップ版v2rayNでは、ノードがREALITYとVisionに対応したXrayコアで実際に動作しているか、まず確認してください。Android版のv2rayNGはXrayコアを使用しますが、インストール済みのバージョンがサブスクリプション内の設定項目に対応しているかも確認が必要です。v2flyNGはv2flyコアを使用するため、VLESSを認識するからといって、Xray専用の設定も実行できるとは限りません。

1. インポート結果を確認する。v2rayNのメイン画面でノードを選択し、右クリックして「編集」を開き、アドレス、ポート、UUID、フロー制御、伝送セキュリティを確認します。画面上の項目名はバージョンによって異なることがあります。最終的にはエクスポートした項目と値を確認してください。
2. 外側のセキュリティ設定を確認する。REALITYノードではsecurity=reality、Visionノードではフロー制御にxtls-rprx-visionを設定します。「TLS」のチェック項目を、あらゆるセキュリティ方式に共通する代替設定として扱わないでください。
3. プロキシの適用方法を確認する。v2rayNのトレイメニューで「システムプロキシ」→「システムプロキシを自動設定」を選び、システムプロキシを使用するブラウザーでテストします。v2rayNGでは、システムVPN接続の許可と起動を確認してください。
4. ローカルポートを確認する。たとえばローカルプロキシが127.0.0.1:10808の場合、アプリ側のポートとプロキシの種類は実際の受け入れ設定に合わせる必要があります。10808は例です。現在の設定値を確認してください。
5. ログは必要最小限にする。まずWebページへのアクセスを1回テストし、時刻とエラー情報を記録してから、設定項目を1つずつ変更します。ログを共有する前に、UUID、サブスクリプションURL、認証パラメーターを隠してください。

「速さ」を正しく比較する方法

プロトコルを比較する場合は、条件をそろえる必要があります。地域や事業者が異なる2つのノードで速度を測っても、主に分かるのは回線の違いであり、Visionの処理負荷ではありません。できれば同じサーバー、同じ帯域制限、近い経路を使い、比較したい伝送方式だけを切り替えてください。条件をそろえられない場合は「ノードの使用感の比較」として扱い、プロトコルの効果だと結論づけないでください。

1. 端末、ネットワーク、テスト先、時間帯をそろえ、バックグラウンドのダウンロードを停止します。各方式を3回ずつ測定し、中央値を記録してください。
2. 同じ100 MiBのテストファイルを使い、最初の1バイトを受信するまでの時間と、安定したダウンロード速度を記録します。一時的なピーク速度だけで判断しないでください。
3. サーバーのCPU使用率と送信帯域を同時に確認します。送信帯域が上限に達してCPU負荷が低い場合、暗号処理の負荷を減らしてもスループットはほとんど上がりません。
4. 連続ダウンロードによる接続先サイトの速度制限を避けるため、測定の間隔を空けてください。その後、よく使うWebページもテストし、大容量ファイルの結果で操作時の遅延が見えなくなっていないか確認します。

たとえば、100 MiBのファイルを10秒でダウンロードした場合、平均速度は約10 MiB/s、換算すると約83.9 Mbpsです。これは単位換算の例であり、この記事での実測値ではありません。クライアントの表示がMB/s、速度測定サイトの表示がMbpsの場合は、まず単位をそろえてから差を判断してください。プロキシのカプセル化、接続確立、計測範囲も数値に影響します。

REALITYとVisionに関するよくある質問