REALITY・XTLS Visionの仕組みを解説｜TLSハンドシェイクの偽装と二重暗号化の軽減

VLESS・REALITY・Visionの役割を整理する

「VLESS + TCP + REALITY + Vision」は4つの層に分けて考えられます。VLESSはユーザー識別情報やリクエスト先などを扱うプロキシプロトコルで、それ自体は通信を暗号化しません。TCPは接続を運ぶトランスポート方式、REALITYは安全なハンドシェイクと認証の仕組み、Visionはプロキシデータのカプセル化と転送を制御するXTLSのフロー制御モードです。

つまり、REALITYだけでインポートできる完全なノードになるわけではなく、Visionもサーバーアドレスを変えるだけで有効になる高速化スイッチではありません。クライアントとサーバーの双方が同じ構成に対応している必要があります。XrayとV2Rayは別のコアであり、名前が似ているからといって設定項目をそのまま相互利用できるわけではありません。

この流れは論理的な処理順序を示したもので、各段階でネットワークの往復待ちが必ず発生するという意味ではありません。「ルーティングで出力先を選択」とは、リクエストを直接接続するか、特定のプロキシノードに送るかをクライアントが判断することです。そのノードを経由する通信にのみ、ノードのREALITYとVisionの設定が使われます。直接接続したサイトの速度から、そのノードのプロトコル性能を判断することはできません。

REALITYの「ハンドシェイクを借りる」とは

先に結論を述べると、実在サイトの秘密鍵を借りたり、そのサイトにプロキシサーバーの通信を復号させたりする仕組みではありません。「借りる」とは、ハンドシェイクの見え方と転送の仕組みを平易に表したものです。理解するには、正しい認証情報を持つクライアント接続と、通常のアクセスまたは認証に失敗した接続を区別する必要があります。

1. クライアントがハンドシェイクを開始します。クライアントはプロキシサーバーのアドレスとポートに接続し、設定に従ってTLS ClientHelloを送信します。SNIはハンドシェイクで通知するサーバー名を示し、クライアントフィンガープリントはハンドシェイクメッセージの生成方法に影響します。
2. REALITYサーバーが認証情報を確認します。正規のクライアントは設定された公開鍵などのパラメーターを使って認証と鍵交換を行い、サーバーは対応する秘密鍵でハンドシェイクを処理します。Short IDは照合に使う別のパラメーターであり、ユーザー識別情報の代わりになるパスワードではありません。
3. 認証に成功するとプロキシ処理に進みます。保護された接続を確立した後、VLESSリクエストを処理します。ブラウザーが最終的にアクセスするサイトは、ハンドシェイクで通知したサーバー名と異なる場合があります。
4. 認証されなかった接続は、接続先サイトに転送されることがあります。サーバーは設定に応じて、その通信を実在するTLSサイトに転送し、通常のサイトとして応答させます。実際の挙動は実装、接続先サイト、ネットワーク状況によって異なります。

通常、サーバーはこの名前に対する公開証明書や秘密鍵を保有する必要はありませんが、REALITY用の鍵ペアは正しく設定する必要があります。クライアントに渡すのは公開鍵であり、サーバーの秘密鍵をサブスクリプションに記載してはいけません。実在する接続先サイトのハンドシェイク動作が変わると接続に影響する可能性もあるため、この仕組みを永続的に固定された見え方と捉えることはできません。

ポート番号は待ち受け位置を示すもので、プロトコルの証明にはなりません。ノードのポートが443でも、必ずREALITYを使っているとは限りません。実在サイトがTLS 1.3に対応していても、あらゆるサーバー構成で接続先として適切とは限りません。サブスクリプションを利用する場合は、提供元の設定を維持し、接続先サイトを独自に変更して試行錯誤しないでください。

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

ブラウザーでHTTPSサイトにアクセスすると、ブラウザーとサイトの間ですでにTLS暗号化が行われています。この暗号化済みデータをプロキシの外側のTLSで丸ごと包むと、追加のカプセル化と処理が発生します。この「TLS over TLS」は正常に動作しますが、計算、データコピー、記録処理のコストが増えます。

Visionは内側のTLS通信を識別し、条件を満たす場合に、より直接的な転送経路へ切り替えて、暗号化済みのアプリケーションデータに対する外側のTLS処理を減らします。また、初期データにパディングを加え、特定のデータ長が特徴として現れるのを抑えます。ブラウザーのHTTPSを無効にする機能ではなく、Webページの内容を平文で送信するものでもありません。

この処理を「すべてのデータで暗号化が1回減る」とまとめることはできません。最適化経路を使えるかどうかは、内側のプロトコルと実装の判定によります。TLS以外のデータが、内側のTLSで保護されたデータに変わるわけではありません。直接転送でOSの低コピー機能を活用できるかどうかも、プラットフォーム、カーネル、接続条件によって異なります。Flowを設定すれば必ずゼロコピーになるわけではありません。

クライアントで確認する設定項目

デスクトップでは、まずv2rayNのノード一覧で対象ノードを選び、右クリックして「編集」を開きます。プロトコル、トランスポート、安全性の種類、Flowを確認してください。バージョンによって編集画面の項目分類は異なる場合があるため、ノード名だけでなく項目名を確認しましょう。Androidでは、v2rayNGのノードカードにある編集アイコンをタップして該当項目を確認します。サブスクリプションのノードは、まず更新して設定を取得してください。手動で変更する前に、比較用のコピーを作成しましょう。

• アドレスとポート：接続先のサーバーを指定します。ドメイン名を使う場合はDNSによる名前解決も必要です。SNIはサーバーアドレスの代わりにはなりません。
• サーバー名：SNIまたはServer Nameとして表示されることがあります。サーバーで許可されている値を指定してください。ブラウザーで開けるドメインだからといって、現在のノードでも使えるとは限りません。
• 公開鍵とShort ID：サブスクリプションに記載された値をそのまま使い、コピー時に文字が欠けないようにしてください。Short IDとUUIDは別の項目です。入れ替えると正常に認証できません。
• フィンガープリント：たとえばchromeはハンドシェイクフィンガープリントの選択肢であり、そのブラウザーを使う必要があるという意味ではありません。プロキシクライアントが送信するハンドシェイクに影響する設定で、ブラウザー拡張機能の設定ではありません。
• Flow：サーバー側が対応するフロー制御を使っている場合にのみ、xtls-rprx-visionを設定します。VMessノードにこの値を追加したり、WSのパスをFlowとして指定したりしないでください。

カーネルも確認が必要です。v2rayNGはXrayカーネルを使用するため、対応する構成で利用できます。v2flyNGはv2flyカーネルを使用しており、REALITYとVisionのノードを同等に実行できる環境ではありません。v2rayNで複数のカーネルを設定できる場合は、クライアントが起動しているかだけでなく、対象ノードが該当パラメーターに対応するXrayカーネルで実行されているか確認してください。

REALITYとVisionを使っても速くならない理由

この2つの機能でプロバイダーの帯域を増やしたり、ネットワーク間の混雑を解消したりすることはできません。長距離回線の往復時間、夜間のパケットロス、サーバー負荷、ノードの速度制限、端末の処理能力は、二重暗号化の処理コストより大きく影響する場合があります。ボトルネックが出口の帯域なら、暗号化処理を減らしても、その上限を超えてダウンロードできるわけではありません。

1. テスト条件をそろえます。同じ端末、同じ接続ネットワーク、同じダウンロード対象を使い、ほかのダウンロードは停止してください。地域や通信事業者が異なる2つのノードを比較しても、特定のフロー制御が速いことの証明にはなりません。
2. 通信がプロキシを経由しているか確認します。v2rayNのメイン画面にある「システムプロキシ」で「システムプロキシを自動設定」を選び、ルーティングモードも確認してください。システムプロキシが影響するのはその設定に従うアプリであり、すべてのプログラムの通信が自動的にプロキシ経由になるわけではありません。
3. 遅延とスループットを分けて確認します。接続が安定して確立するか、継続的なダウンロード速度が変動するか、ログに再接続が繰り返し記録されるかを確認してください。遅延が低ければ待ち時間が短い可能性はありますが、ダウンロード帯域が広いとは限りません。
4. 変更は一度に1項目だけにします。比較する場合は、サーバー側で明確に対応している2つの設定を使ってください。クライアントでFlowを削除した結果、認証に失敗したことを性能低下として扱わないでください。

ハンドシェイクエラーとよくある誤解

ログのエラーはトラブルシューティングの手がかりであり、原因を一つに断定するものではありません。EOF、タイムアウト、接続リセットが発生した場合は、どの段階で起きたかを確認してください。まずサーバーに接続できているか、次にハンドシェイクが成功したか、最後にプロキシリクエストが完了したかを調べます。ログを共有する前に、サブスクリプションのURL、ユーザー識別情報、その他の認証情報を隠してください。