REALITYとXTLS Visionの仕組みを解説｜自己署名証明書なしのハンドシェイクと二重暗号化の軽減

プロトコルの階層：VLESS、REALITY、Vision

まず結論です。一般的な「VLESS + TCP + REALITY + Vision」は複数の階層を組み合わせた構成で、4つの名前は相互に置き換えられるプロトコルではありません。VLESSはプロキシ要求の形式とユーザー認証情報を扱い、TCPは接続を運びます。REALITYは認証機能を備えたセキュアな接続を確立し、Visionは特定のトランスポートとの組み合わせで使われるXrayのフロー制御モードです。

VLESS自体はペイロードを暗号化しません。そのため、クライアントのVLESS暗号化欄がnoneでも、通信が平文で送られているとは限りません。外側でREALITYまたはTLSが有効か、アプリ自体がHTTPSを使っているかも確認してください。VMessはプロトコルの仕組みが異なるため、VLESSの項目をそのままVMessの設定に移すことはできません。

REALITYのハンドシェイクと自己署名証明書が不要な理由

「自己署名証明書が不要」とは、プロキシサーバーが通常、自身のプロキシ用ドメインに対して従来のTLS運用のように証明書を取得・更新したり、ユーザーに自己署名証明書を手動で信頼させたりする必要がないという意味です。認証が省略されるわけでも、証明書関連の検証を無効にしてよいという意味でもありません。REALITY独自の認証方式を使用するため、クライアントには正しいサーバー公開鍵などのパラメーターが必要です。

サーバー側では、ハンドシェイク先として実在するTLSサイトを設定します。REALITYはそのサイトに関連するハンドシェイク動作を利用し、外部からは通常のTLSサービスにできるだけ近く見えるようにします。正しい認証情報を持つクライアントはプロキシ処理に進みます。認証条件を満たさない接続は、実装や設定に応じて対象サイトへ転送されることがありますが、プロキシの利用権が与えられるわけではありません。「実在サイトのハンドシェイクを利用する」という説明は概要であり、サイトの秘密鍵を複製することではありません。

混同しやすいアドレスが2つあります。クライアントが接続するのはプロキシサーバーのアドレスです。serverNameはハンドシェイクで使う名前で、サーバー側で許可された設定に合っている必要があります。よく知っているサイトのドメイン名に適当に変更しても、接続できるようにはなりません。また、実在の接続先サイトはプロキシサーバーの代わりではありません。認証後のプロキシ通信は通常、プロキシサーバーが目的のサービスへ接続するもので、そのサイトが汎用トラフィックの中継を担うわけではありません。

Visionのフロー制御と二重暗号化

HTTPSサイトを開くと、ブラウザーとサイトの間にはすでにTLS接続があります。この暗号化通信がさらにTLS系のプロキシトンネルに入ると、「暗号化されたデータを外側でもう一度暗号化する」構造になります。追加のレコード処理やバッファリング、暗号化・復号処理はCPU負荷を増やす可能性があり、外側から観測できる通信の特徴にも影響することがあります。

Visionはトンネル内のTLSハンドシェイクとデータの段階を識別し、初期段階ではパディングなどの処理を行います。条件を満たすTLS 1.3の内側通信では、直接コピーなどの最適化経路に切り替え、外側での重複処理を減らせます。すべての接続を平文にする機能でも、ブラウザーとサイトのHTTPSを復号する機能でもありません。アプリとサイト間のエンドツーエンドTLSはそのまま維持されます。

• 条件を満たすHTTPS通信：二重暗号化を抑える経路が使われる場合があります。実際の効果はカーネルのバージョン、プラットフォーム、接続形態にも左右されます。
• 通常の平文通信：「もともとHTTPSで保護されている」という前提は当てはまりません。引き続き外側のセキュリティ機構で保護する必要があります。
• UDPなどの通信：TCP内のTLSに関する最適化の説明をそのまま適用できません。UDPの伝送と転送への対応は別途確認してください。
• WebSocketなどとの組み合わせ：既存ノードにVisionの項目を追加するだけで動作するとは限りません。使用するカーネルがサポートする組み合わせ全体を確認してください。

したがって、「Visionは二重暗号化を軽減する」と表現するのが正確で、「Visionは暗号化しない」ではありません。すべての接続やデータが同じ最適化経路を通るわけではありません。フロー制御の名称を正しく設定することは機能を有効にするための条件ですが、帯域幅の向上を保証するものではありません。

主要な数値とクライアント設定項目

以下の数値はプロトコルや設定を理解するためのもので、速度測定の結果ではありません。443はよく使われるポートですが、REALITYで必須ではありません。サーバーが別のポートで待ち受けている場合、クライアント側も同じポートに変更する必要があります。shortIdは16進数で指定し、カーネルの要件に合う長さで、サーバーが許可する値と一致していなければなりません。

従来の項目を使うXray REALITY設定では、shortIdは最大8バイト、つまり16個の16進数文字で、文字数は偶数である必要があります。空欄を許可するかどうかはサーバーの設定次第です。画面上で空欄にできても、サブスクリプションに値がある場合は削除しないでください。クライアント画面の公開鍵欄は「Public key」など、カーネルの更新に伴って名称が変わる場合があります。サブスクリプションの形式と現在のカーネルのドキュメントを照らし合わせて確認してください。

v2rayNでは、まず該当の組み合わせに対応するXrayカーネルを使っているか確認してから、VLESSサーバーの該当項目を編集してください。v2rayNGもXrayカーネルを使用しますが、ノードの項目一式が正しく設定されている必要があります。v2flyNGはV2Flyカーネルを使用します。画面からVLESSをインポートできるからといって、XrayのREALITYとVisionにも対応しているとは限りません。クライアントのバージョン、カーネルの機能、サブスクリプションの解析対応は、それぞれ個別に確認が必要です。

速度・遅延・安定性の限界

REALITYの主な目的は地理的な距離を縮めることではなく、Visionもサーバーの帯域幅を増やすものではありません。ボトルネックが混雑、地域をまたぐ回線、サーバー側の上り帯域制限にある場合、暗号化処理を一部減らしても大きな変化はないかもしれません。CPUがほぼ飽和しており、通信の大半が条件を満たすHTTPSの長時間接続である場合に、Visionによるリソース削減の効果が現れやすくなります。

1. 比較条件をそろえる：同じ端末、ネットワーク、テストファイルを使い、時間帯も近づけます。サーバーから比較可能な設定を2つ提供されている場合に限り、プロトコルを比較してください。
2. 測定項目を分ける：接続遅延、Webページの最初の1バイトが届くまでの時間、継続ダウンロード時のスループットは別の指標です。測定方法を記録し、クライアントで一度表示された遅延を総合的な性能とみなさないでください。
3. 端末の負荷を記録する：測定中のCPU使用率とクライアントログを確認し、端末の発熱による性能低下やバックグラウンドダウンロードの影響をプロトコルの差と取り違えないようにします。
4. 複数回テストする：各設定で少なくとも3回測定し、失敗やタイムアウトも記録してください。最速の1回だけを選ぶと、誤った判断につながりやすくなります。

安定性は、サーバーからハンドシェイク先への到達性、対象サイトのTLS動作、システム時刻、両端の実装の互換性にも左右されます。REALITYで接続の見え方を変えることはできますが、どのネットワーク環境でも常に利用できるとは限りません。接続先サイトの選定はサーバー運用側で行う作業です。サブスクリプション利用者がローカルのserverNameだけを変えて「回線を直す」ことは避けてください。

接続のトラブルシューティングとよくある質問

確認しやすい項目から順に調べます。アドレスとポート、ユーザーID、トランスポート方式、セキュリティ層、フロー制御、公開鍵、shortId、ハンドシェイク名を確認し、最後にルーティングとDNSを調べてください。一度に変更するのは1項目にとどめ、変更のたびに再接続します。比較できるよう、元のサブスクリプション設定を残しておきましょう。ログを共有する前に、サブスクリプションURL、ユーザーID、サーバーの機密情報を削除してください。

設定の選び方と操作手順

利用可能なサブスクリプションがある場合は、まずサーバーから提供された組み合わせをそのまま使ってください。ノードが適しているかどうかは、名前にREALITYやVisionが含まれるかだけで判断できません。クライアントが必要な機能をすべてサポートしているか、接続が安定するか、普段使うアプリが正常に動くか、実際の回線が用途に合っているかを確認しましょう。

• まずカーネルを確認：REALITYとVisionはXrayの対応状況を踏まえて選んでください。Project V、V2Fly、Xrayという系統名だけで完全な互換性があると判断することはできません。
• 次に必要な設定一式をインポート：信頼できるサブスクリプションを使い、異なるノードの公開鍵、ユーザーID、ハンドシェイク名を混在させないでください。
• 最後に通信経路を確認：まずHTTPSサイト1つでテストし、その後システムプロキシ、Tun、DNS、ルーティングによる振り分けを確認してください。

ルールの適用順を確認するには詳細設定をご覧ください。サブスクリプションの追加方法や接続の基本手順は、入門ガイドのサブスクリプション解説をご覧ください。再現性のある基準状態を作ってから項目を一つずつ調整すると、複数のプロトコル設定を一度に変更するより問題を特定しやすくなります。