REALITYとXTLS Visionの仕組みを解説：VLESSで二重暗号化を防ぐ

VLESS・REALITY・Visionの役割

ノード名にある「VLESS + REALITY + Vision」は、3つの同列のプロトコルを意味するものではありません。VLESSはプロキシプロトコル層で動作し、UUIDなどでユーザーを識別して接続先のアドレスを伝えます。VMessのようなデータ暗号化機能は備えていないため、インターネット経由で使う場合は、適切なセキュアなトランスポートで接続を保護する必要があります。VLESSのencryptionをnoneにしても、通信全体が平文になるわけではありません。

REALITYはXrayエコシステムのセキュアなトランスポート機能です。TLSハンドシェイクの特徴、サーバー鍵、クライアント認証情報を組み合わせて保護された接続を確立します。XTLS Visionはflowの指定に応じて初期トラフィックを処理し、パディングを行い、条件を満たした場合に転送を最適化します。V2Rayという名前のクライアントでも、使用するコアがこの設定に対応しているとは限りません。ここではXrayコアでの実装について説明します。

このフローは各機能の論理的な順序を示すもので、各段階で別々のネットワーク接続を新たに確立するという意味ではありません。実際の接続では、認証、ハンドシェイク、トラフィック処理が連続して行われます。トラブル時は、まず失敗した層を特定しましょう。ポートに接続できない場合は接続の問題、公開鍵が一致しない場合はセキュアなハンドシェイクの問題、UUIDが一致しない場合はプロキシ認証の問題です。Webサイトへの振り分けが誤っている場合は、通常routingを確認します。

TLSハンドシェイクから見るREALITYの役割

ブラウザーがHTTPSサイトにアクセスすると、最初にClientHelloを送信し、対応するTLSバージョンや暗号スイート、拡張機能などを伝えます。サーバーはハンドシェイクメッセージを返し、双方で鍵をネゴシエートします。従来のプロキシでも外側のTLS接続で同様の処理が必要です。さらに内側でブラウザーとWebサイト間のHTTPS通信を行うと、「プロキシTLSの中にWebサイトのTLSがある」構造になります。

REALITYは、有名なドメイン名を適当に入力すれば同じハンドシェイクを再現できるように設計されているわけではありません。サーバーには適切な接続先サイトと許可するサービス名を設定する必要があります。クライアント側にも、サーバー設定に対応する公開鍵やshortIdなどが必要です。正規のクライアントはこれらの情報を使ってサーバーを認証し、接続を確立します。接続先サイトの通常の証明書検証だけに依存するわけではありません。

• 接続先アドレス：クライアントが実際に接続するサーバーのIPアドレスまたはドメイン名です。serverNameとは異なる場合があります。
• serverName：ハンドシェイクで使用するサービス名で、通常は画面上のSNIに相当します。サーバーで許可された設定と一致させる必要があります。
• 公開鍵：サーバーの秘密鍵と対になり、REALITYの認証に使用します。秘密鍵はサーバー上で管理してください。
• shortId：サーバーが認識する短い識別子です。16進数の文字列で表されることが多く、UUIDの略称ではありません。

所定の認証を通過しなかった接続は、REALITYによって設定済みの接続先サイトへ転送される場合があります。これにより、外部から見た挙動を実在サイトに近づけられます。ただし、この「利用」は、認証済みのプロキシ通信がすべてそのサイトを経由するという意味でも、接続先サイトがプロキシサーバーの代わりにユーザーデータを転送するという意味でもありません。接続先の選定、到達性、ハンドシェイクの互換性は、引き続き構築結果に影響します。

XTLS VisionがTLS in TLSを減らす仕組み

一般的な暗号化プロキシでHTTPS通信を転送すると、ブラウザーがアプリケーションデータをTLSレコードとして暗号化したうえで、プロキシの外側でもう一度暗号化します。トンネルを保護できる一方、暗号化・復号やカプセル化の処理が増え、観測可能な多重構造のトラフィック特性が生じる場合もあります。Visionの目的の一つは、条件に合う内側のTLSトラフィックを判別し、適切な条件下で、すでに暗号化されたペイロードに同じ外側の暗号化処理を重ねずに転送することです。

Visionは接続初期のデータを処理してパディングを行い、検出したTLSの状態に応じて後続の転送経路を決定します。対応していて識別可能なTLS 1.3トラフィックが実装上の条件を満たせば、最適化された転送に移行できます。すべてのバイト列やプロトコル、接続が最初から直接転送されるわけではありません。TLS以外のトラフィックや条件を満たさない接続には、引き続きトンネルによる保護が必要です。

Visionはブラウザーと接続先サイト間のHTTPSコンテンツを復号する必要はありません。サイト証明書の検証は引き続きブラウザーが行い、内側のTLSによるエンドツーエンドの関係も維持されます。REALITYはクライアントからプロキシサーバーまでの接続を保護・認証し、サイトのTLSはブラウザーから接続先サイトまでのアプリケーションデータを保護します。この2つの保護範囲を混同しないでください。

flowとfingerprint：クライアント設定の確認項目

v2rayNでは、まず現在のノードがXrayコアで動作していることを確認し、既存のVLESSノードを編集します。一般的な画面ではノードを選択して右クリックし、「サーバーを編集」を選びます。手動追加の場合は通常、「サーバー」メニュー内のVLESS追加項目を使います。バージョンによってメニュー名が異なる場合があるため、ノード名だけで判断せず、編集画面のプロトコル、トランスポート、セキュリティ、flowの各項目を確認してください。

flowはフロー制御方式を指定する項目で、暗号化アルゴリズムの選択欄ではありません。サーバー側のユーザー設定とクライアントの設定に互換性が必要です。サーバーでVisionが必須の場合、クライアント側を空欄にすると認証またはフロー制御の検証に失敗することがあります。古い資料にある別のXTLSフロー制御値をxtls-rprx-visionにそのまま置き換えることはできません。

fingerprintはクライアントのTLS ClientHelloで模擬する特徴を指定します。一般的な値はchromeですが、プロキシプログラムがブラウザーになるわけではなく、接続が識別されないことを保証するものでもありません。任意の文字列を指定するとコアに拒否される場合があります。また、fingerprintを頻繁に切り替えても、公開鍵の誤りは解決しません。明確な互換性の問題がない限り、ノードに指定された設定を維持してください。

{
  "flow": "xtls-rprx-vision"
}

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

以下は、各フィールドの位置を示す2つのJSON抜粋であり、完全な設定ではありません。そのまま結合して実行することはできません。1つ目ではflowがVLESSのアウトバウンドユーザーオブジェクト内にあります。2つ目のセキュリティ設定はstreamSettingsにあります。実際の設定には、サーバーアドレス、UUID、サービス名、鍵に関する項目も必要です。公開鍵のフィールド名は、画面や共有リンク、コアのバージョンによって異なる場合があります。クライアントで生成された設定を使い、異なるバージョンの設定を機械的に転記しないでください。

ポート・コア・ログ：順番に接続を確認する

トラブルシューティングの前に、リモートポートとローカルの接続口を区別しましょう。ノードが使用するリモートポートはサーバー側で決まり、443はよく使われる設定にすぎず、REALITYで必須ではありません。ローカルのプロキシ待ち受けポートはクライアント側で決まります。アプリが誤ったローカルポートに接続していると、リモートノードの設定が正しくても、リクエストは想定したアウトバウンドに送られません。

1. 現在の設定を記録する。ノードのアドレス、リモートポート、UUID、flow、SNI、公開鍵、shortIdの値を保存してください。スクリーンショットを共有する場合は認証情報を隠し、サブスクリプションURL全体を公開しないでください。
2. 実際に使用中のコアを確認する。起動ログに記録されたコア名とバージョンを確認します。v2rayNでは複数のコアを管理できます。画面のバージョンを更新しても、実行中のコアが切り替わったとは限りません。Android版のv2rayNGはXrayコアを使用します。V2Flyコアを使用するv2flyNGを、REALITY設定に対応する同等の選択肢と見なさないでください。
3. TCPの到達性を確認する。接続がタイムアウトする、または拒否される場合は、リモート側の待ち受け、ファイアウォール、アドレス解決を確認します。TCPingの成功が示すのはTCP接続を確立できたことだけであり、REALITY認証の成功ではありません。
4. ハンドシェイクと認証を確認する。ポートに到達できるのにリクエストが失敗する場合は、サービス名、公開鍵、shortId、UUID、flowを一つずつ照合し、両端のシステム時刻を同期してください。鍵のエラーはルーティングルールでは解決できません。
5. 新しいリクエストで再テストする。設定を保存してノードを再読み込みし、新たにWebリクエストを送信します。ブラウザーが既存の接続を再利用している場合があります。ログのアウトバウンドタグも確認し、リクエストが実際に対象のプロキシへ送られていることを確かめてください。

コアが起動し、ノードテストも成功するのに一部のWebサイトだけ開けない場合は、DNSとroutingを確認してください。ドメイン名に直結ルールが先に適用される、アプリがシステムプロキシを使っていない、UDPリクエストがプロキシを経由していない、といった原因が考えられます。この場合、REALITYの公開鍵を何度も変更すると、新たな変数が増えるだけです。各フィールドの意味は設定リファレンス、初回接続の手順は使い方ガイドを確認してください。

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