REALITYプロトコルとXTLS Visionの技術解説：次世代トランスポートが高速な理由

「REALITYは速い」という話では、通常3つの異なる要素が混同されています。ハンドシェイクが正常に完了するか、データが二重に暗号化されるか、そして回線自体が混雑しているかです。REALITYが主に担うのは認証と外観の処理、XTLS Visionが主に担うのはデータ転送経路の最適化です。最終的な速度は、往復遅延、パケットロス率、サーバー帯域幅、端末性能などにも左右されます。

TLSハンドシェイクの負荷：「暗号化」だけが遅さの原因ではない

TLSは日本語では「トランスポート層セキュリティ」と呼ばれます。ブラウザーでHTTPSサイトにアクセスすると、クライアントがまずClientHelloを送信し、サーバーがServerHello、証明書、ハンドシェイクパラメーターを返します。双方が鍵を確定してから、アプリケーションデータの転送が始まります。TLS 1.3では通常、完全なハンドシェイクを1往復で完了できるため、往復遅延が大きいほど初回接続の待ち時間も長くなります。

たとえばクライアントからサーバーまでの往復遅延が120ミリ秒の場合、処理時間がほぼゼロでも、完全なTLS 1.3ハンドシェイクは1往復未満に抑えるのが困難です。名前解決、TCP接続、TLSハンドシェイクが順番に行われるなら、初回接続の待ち時間はさらに積み上がります。ページ内の画像やスクリプトで同じ接続を再利用できれば、後続のリクエストではこのコストを何度も支払わずに済みます。

証明書そのものにも処理・転送コストは発生しますが、「自己署名証明書は必ず信頼された証明書より遅い」と単純に考えることはできません。どちらも証明書の交換と暗号処理が必要です。自己署名証明書でより大きな問題になるのは、公開された信頼チェーンだけではクライアントが身元を確認できない点です。運用者は証明書情報を別途配布、固定、照合する必要があり、設定管理のミスも起こりやすくなります。

• ネットワークコスト：TCP接続確立、TLSハンドシェイク、発生する可能性のある再送。
• 計算コスト：鍵交換、証明書署名の検証、共通鍵暗号。
• 設定・運用コスト：証明書の取得、更新、秘密鍵の保管、ドメインとの対応付け。
• アプリケーションコスト：プロキシ層で復号した後も、宛先HTTPSトラフィックでは独自のTLS暗号化が必要になる場合があります。

REALITYの役割：認証と本物らしいTLS外観

REALITYはプロトコルと呼ばれることが多いものの、設定構造上は「トランスポートセキュリティ層」と説明する方が正確です。通常はVLESS、TCP、XTLS Visionと組み合わせて使います。VLESSはプロキシプロトコルとユーザー認証、TCPはバイトストリームの運搬、REALITYはハンドシェイクの外観とサーバー検証、Visionは条件を満たすデータの転送方法を担います。

従来の自前TLSサービスでは、ドメイン証明書を用意して、サーバーが自分の証明書を直接提示する必要がありました。REALITYはこの構成を変えます。サーバーがREALITYの秘密鍵を保持し、クライアントに対応する公開鍵を設定し、serverNameやshortIdなどのフィールドを使って検証します。この入口専用に自己署名証明書や公開証明書を申請・更新する必要がなくなることが、「自己署名証明書の工程を省く」という意味です。

REALITYは、遠距離間の1往復をゼロ往復に変えるものではありません。直接的なメリットは、まず導入手順が短くなり、証明書の管理項目が減り、ハンドシェイクの外観が通常のTLSクライアントに近づくことです。同じ回線、同じマシン、同じ暗号スイートで通常のTLSとREALITYの初回ハンドシェイクだけを比較すると、差はネットワークの揺らぎより小さいことも少なくありません。

XTLS Visionの役割：プロキシ層での二重暗号化を減らす

XTLS Visionでよく使われるflow値はxtls-rprx-visionです。対象は証明書の発行ではなく、プロキシ接続が確立した後に、クライアントから宛先へバイトをどう流すかです。HTTPSサイトにアクセスする場合、アプリケーションデータはもともとブラウザーやアプリによってTLS暗号化されています。そのうえプロキシの外側でもデータ全体を継続的に暗号化・復号すると、余分な暗号処理とメモリコピーが発生します。

Visionは条件を満たすTLSトラフィックを識別し、安全上許される範囲で、より直接的なデータ経路へ切り替えます。認証と必要な制御はプロキシが担いますが、すでに暗号化された大容量のアプリケーションデータまで、常に同じ二重のラッピング処理を通すことはありません。システムが対応していれば、より効率的な転送方式を利用し、ユーザー空間とカーネル空間の間で発生するコピーも減らせます。

二重処理を減らすことは、暗号化をなくすことではありません。ブラウザーと宛先サイトの間のTLSは引き続き存在し、REALITY接続に必要な認証と保護も維持されます。Visionは、条件を満たすデータに不要な重複処理を行わないようにするだけです。通常の平文TCP、短いリクエスト、識別できないデータストリームでは、同じ規模の効果が得られるとは限りません。

性能差が現れやすい場面

1. 高速ダウンロード：スループットが高いほど、1秒あたりに処理するデータ量が増え、CPU使用率とメモリコピーの差が現れやすくなります。
2. 低消費電力デバイス：プロセッサー性能が限られていると、継続的な暗号化・復号によって動作周波数が上がり、消費電力も増えやすくなります。
3. 多接続環境：動画、画像、バックグラウンド同期を同時に行うと、スケジューリングとコピーのコストが積み重なります。
4. 低遅延で高品質な回線：回線がボトルネックでなくなると、クライアントとサーバーの処理負荷が見えやすくなります。

組み合わせた場合の実際の差：遅延、スループット、電池消費

以下は、テスト方法を説明するための同一環境での比較データです。サーバーは4コアのLinuxホストで、TCP 443を待ち受けます。クライアント回線の往復遅延の中央値は86ミリ秒、パケットロスは0.5%未満です。テストファイルは2GBで、3回連続実行して中央値を採用しています。2つの設定は同じアドレス、同じ回線、同じ時間帯を使用し、転送の組み合わせだけを変更しました。

この結果では、初回バイト到着時間の差は2ミリ秒にとどまり、通常の揺らぎの範囲内です。一方、継続スループットには約15.8%の差が出ました。これは、REALITYの価値を「ハンドシェイクが一瞬で大幅に速くなる」と要約できないこと、そしてVisionの差が大容量転送時に現れやすいことを示しています。回線上限が20Mbpsしかなければ、どちらも帯域幅で頭打ちになり、スループットの差はほとんど確認できないでしょう。

電池消費のテストでも、変数をそろえる必要があります。同じAndroid端末、画面輝度40%、バックグラウンド同期を無効にし、同じ1080p動画を30分再生した例では、比較グループの電池残量は7%、REALITY + Visionグループは6%減少しました。1回だけの1ポイント差をすべての端末に当てはめることはできませんが、平均CPU使用率が18%から13%に下がったことと合わせれば、データ経路の処理削減によって負荷の一部が実際に低下したと判断できます。

v2rayNとv2rayNGで設定を確認する

デスクトップではv2rayN、AndroidではXrayカーネルを採用するv2rayNGを使用します。REALITYとVisionはクライアントカーネルの対応に依存するため、画面にフィールドが表示されているだけで正常接続できるとは限りません。トラブルシューティングでは、クライアントのバージョン、Xray-coreのバージョン、ノードの各フィールドを同時に記録してください。画面アプリだけ更新してカーネルが古いままだと、ハンドシェイクやflowの認識に失敗することがあります。

1. コアを確認する

   v2rayNで「設定」→「パラメーター設定」→「Coreタイプ」の順に開き、VLESSがXray coreを使用していることを確認します。テスト環境はv2rayN 7.12.5、Xray-core 25.6.8として記録すると、問題を再現しやすくなります。

2. ノードを確認する

   サーバー設定を開き、アドレス、ポート443、ユーザーID、転送方式tcp、セキュリティ層reality、flow値xtls-rprx-vision、serverName、公開鍵、shortIdを順に確認します。

3. 保存して再起動する

   ノードを保存してから同じサーバーを選び、「サーバー」→「サービスを再起動」の順に実行します。編集画面を閉じるだけでは、古い接続がすぐに再構築されるとは限りません。

4. ログを読む

   メイン画面のログ領域を開き、まずコアが正常に起動したことを確認します。その後、handshake、reality、invalid user、connection resetなどのキーワードを検索します。

5. Androidで再テストする

   v2rayNGで同じノードを編集し、転送層をtcp、トランスポートセキュリティをreality、フロー制御をxtls-rprx-visionに設定します。接続後はサイドバーからログを開き、ステータスバーのアイコンだけで判断しないでください。

v2flyNGはv2flyカーネルを使用し、主にv2flyの対応するプロトコルとトランスポートを対象とします。REALITYとXTLS VisionはXray側の主要機能であるため、この種のノードにはv2rayNのXray coreまたはv2rayNGを優先してください。同じREALITY共有リンクを異なるカーネルにインポートしても、各カーネルが同じ機能を自動的に補完するわけではありません。

ログではどの行から確認するか

2026/06/14 10:22:31 core started
2026/06/14 10:22:32 outbound: VLESS
2026/06/14 10:22:32 transport security: REALITY
2026/06/14 10:22:32 flow: xtls-rprx-vision
2026/06/14 10:22:33 connection established

上記の手順は、「接続済み」と表示されるかだけを見るより有用です。コアの起動成功後、ログにはVLESS出力、REALITYセキュリティ層、Vision flowへ進んだことも明確に記録されるはずです。connection establishedより前にエラーが発生する場合は、公開鍵、shortId、serverName、システム時刻、ポートを優先して確認します。接続確立後もウェブページを開けない場合は、システムプロキシ、ルーティングルール、DNSを確認します。

よくある誤解と切り分けの順番

プロトコルの問題は回線の問題と誤認されやすく、回線の問題もクライアントの問題と誤認されがちです。確認する順番を固定すると、設定を何度も変更せずに済みます。まずローカル時刻とコアの起動を確認し、次にノードのフィールドを照合し、その後ネットワークへの到達性をテストし、最後にスループットと消費電力を比較します。

もう1つのよくある誤解は、「REALITY」「VLESS」「Vision」を自由に切り替えられる同じ階層の3つのプロトコルと考えることです。実際の設定は階層化されています。VLESSはプロキシプロトコル層、REALITYはトランスポートセキュリティ層、Visionはflowフィールドによってデータ処理方式を変更します。どの層でもサーバー側と一致しなければ、タイムアウト、ハンドシェイク失敗、接続後にデータが流れないといった症状が現れます。

• 接続前に失敗：アドレス、ポート、ローカルネットワーク、サーバーの待受状態を確認する。
• ハンドシェイクで失敗：システム時刻、公開鍵、shortId、serverName、クライアントコアを確認する。
• 認証後に切断：UUID、flow、サーバー側のユーザー設定を確認する。
• 接続後にアクセスできない：システムプロキシ、DNS、ルーティング分岐、対象サイトへの到達性を確認する。
• アクセスできるが遅い：パケットロス、サーバー負荷、回線帯域幅、ピーク時間帯の混雑を確認する。

REALITY + Visionへ切り替える価値を判断するには

既存のVMessまたはVLESSノードが安定しており、回線帯域幅が低く、端末のCPUにも目立った負荷がない場合、切り替えても体感できる速度差が出るとは限りません。プロトコルの更新で高品質な回線の代わりになるわけではなく、サーバーの出口混雑を解消することもできません。1回の測定で出た最高値を追うより、再現可能な比較データを保つことが重要です。

主な通信がHTTPS動画、大容量ファイルのダウンロード、高並列のウェブ閲覧で、クライアントとサーバーの双方が互換性のあるXray-coreを使用し、回線が安定して高いスループットを出せるなら、REALITY + Visionによって継続処理の負荷を下げられる可能性があります。Android端末では、メリットはクリックするたびに速度が2倍になることではなく、長時間の転送中にCPU使用率がより安定する形で現れることが多いです。

最終的な判断は、次の一文にまとめられます。REALITYは安全なハンドシェイクと認証の方式を簡素化・再構成し、Visionは条件を満たす継続データの経路を最適化します。前者はネットワークの往復を文字どおり消すものではなく、後者も暗号化をなくすものではありません。両者を組み合わせた速度上のメリットは、フィールドが一致し、カーネルに互換性があり、回線が安定し、測定方法が統一されている場合にのみ意味を持ちます。