REALITYとXTLS Visionの技術解説：ハンドシェイクと転送経路が高速な理由

REALITYが解決するハンドシェイクと認証の課題

REALITYはXrayエコシステムの転送セキュリティ機構で、通常はVLESS、TCP、XTLS Visionと組み合わせて使われます。クライアントがサーバーを確認する方法、サーバーが許可されたクライアントを識別する方法、外部から見たTLSハンドシェイクの特徴を扱います。独立したプロキシプロトコルではなく、VLESSのユーザー識別情報やアウトバウンド設定を置き換えるものでもありません。

従来のTLSサービスでは、サーバーがドメイン証明書を保持し、クライアントが証明書チェーン、ドメイン名、有効期限を確認してサーバーを検証します。REALITYは異なる認証情報を使います。サーバーはX25519秘密鍵を保持し、クライアントは対応する公開鍵に加えて、サーバー名、Short ID、クライアントフィンガープリントなどを指定します。項目が一致し、認証に成功した接続だけがプロキシ処理へ進みます。

設定上のサーバー名はserverNameまたはSNIと表示されることが多く、サーバーで許可された名前と一致させる必要があります。公開鍵はpublicKeyと表示されることが多く、新しい一部の画面ではPasswordと表記されます。Short IDは16進数文字列です。これら3項目はクライアント側で推測できず、サーバー設定またはサブスクリプションから取得する必要があります。

「サイト証明書を保持しない」ことは、本人確認を省略する意味ではありません。クライアントはREALITYの公開鍵で接続先サーバーを確認し、サーバーもクライアントから送られた認証情報を検査します。公開鍵の誤り、Short IDの長さの不一致、許可リストにないSNIの場合、通常はハンドシェイク段階で接続が終了し、アプリケーション層のリクエストはまだVLESSのルーティングに到達しません。

• アドレスとポート：TCP接続の送信先を決めます。一般的な待受ポートは443ですが、サーバー側で別のポートを使うこともできます。
• UUID：VLESSのユーザー認証情報であり、REALITYの公開鍵で代用することはできません。
• SNI：ノード設定の値を使用し、サーバーIPをもとに任意の値を入力してはいけません。
• フィンガープリント：一般的な値はchromeで、対応するクライアントのハンドシェイク特性を生成するために使われます。
• SpiderX：通常は/です。別のパスが必要かどうかはサーバー設定によって決まります。

XTLS Visionがデータ転送経路を短縮できる理由

XTLS VisionはVLESSのフロー制御値xtls-rprx-visionに対応します。初回の本人認証ではなく、接続確立後のデータ転送方法に関わる機能です。多くのWebサイトやアプリはもともとTLSを使用しています。プロキシの転送層がさらに全データを汎用的な暗号化ラッパーで包むと、バッファリング、データコピー、暗号化・復号処理のスケジューリングが増加します。

Visionは接続中のデータ段階を分析し、条件を満たす場合はより直接的な転送方式を使って、すでに暗号化されたトラフィックへの重複処理を減らします。ここでいう「削減」は、すべてのデータがセキュリティ層を迂回するという意味ではありません。また、すべてのOSが同じゼロコピー実装を採用するわけでもありません。ハンドシェイクデータ、制御情報、識別条件に合わないデータ、プロトコル上必要なパディングは、引き続き規則に従って処理されます。

最初のデータには、Visionによるパディングや形式の調整も関わります。目的の一つは、接続初期にあまりにも固定的な構造が現れるのを避けることです。安定した転送段階に入ってから、処理負荷の低い経路へ切り替わる可能性があります。そのため、短時間の接続ではハンドシェイク時間の影響を受けやすく、大容量ダウンロード、動画の分割配信、長時間の転送ではデータ経路の違いが表れやすくなります。

Visionの効果は、コアとシステムのネットワークスタックにも左右されます。回線が10 Mbpsしかない場合、CPU負荷の削減が速度の明確な向上として現れるとは限りません。数百Mbpsの継続的な転送では、データコピーや処理スケジューリングのコストが制限要因になりやすくなります。ボトルネックが混雑時間帯の輻輳、経路の迂回、5%以上のパケットロスであれば、Flowを変更しても物理回線は改善しません。

遅延、スループット、CPU使用率を比較する方法

クライアントのノード一覧に表示される遅延だけでは、Visionが高速かどうかを判断できません。遅延テストは通常、TCP接続、コアのプローブ、指定URLへの応答時間などであり、DNS、接続先の処理、回線の揺らぎが含まれる場合があります。プロトコルの違いは、同じサーバー、同じ出口、同じテストファイル、近い時間帯で比較し、少なくとも5回繰り返してください。

この記事の管理された記録では、Windows 11 24H2、ギガビット有線LAN、同一のリモートサーバー、同一のインターネット回線を使用しました。テストファイルは1 GiBで、5回連続実行して中央値を採用しています。2つのノードは転送セキュリティとFlowだけを変更し、待受ポートはいずれも443です。この数値は測定方法を示すためのもので、他の回線で同じ結果になることを意味しません。

この記録では、初回リクエストよりもスループットの差が明確でした。長時間接続ほど転送経路の違いが表れやすいという予想に沿った結果です。ただし、322 Mbpsはプロトコルの上限ではなく、モバイル回線の結果を推測する根拠にもなりません。テスト中にバックグラウンド更新、ブラウザーキャッシュ、サーバーのディスク読み出し、システムプロキシモードが異なると、結論は変わります。

1. 他のダウンロードやクラウド同期を停止し、有線接続または同じ無線の場所に固定します。
2. 2つのノードで同じサーバーアドレス、ポート、アウトバウンド回線を使用します。
3. それぞれ5回以上実行し、中央値を記録します。単発の最高速度を結果の代わりにしないでください。
4. コアのログ、タスクマネージャーのCPU使用率、失敗回数、テスト時間帯も同時に確認します。
5. 遅延とスループットを分けて記録し、ノードのプローブ値をWebページ全体の読み込み時間と混同しないでください。

v2rayNとv2rayNGで設定項目を確認する場所

v2rayNでは、サブスクリプションまたは共有リンクからノードをインポートした後、ノードをダブルクリックして編集画面を開きます。確認する項目は、アドレス、ポート、ユーザーID、Flow、転送プロトコル、転送層セキュリティ、SNI、フィンガープリント、公開鍵、Short ID、SpiderXです。画面のバージョンによって項目の並び順は変わることがありますが、意味は変わりません。

全般設定は「設定」→「パラメータ設定」にあります。コアにはREALITYとVisionに対応するXrayコアを選択してください。コアを変更した後はクライアントを再起動し、ログで実際に読み込まれたコアを確認します。ノードの転送プロトコルは通常TCP、セキュリティ方式はreality、Flowはxtls-rprx-visionを指定します。

v2rayNGでは、設定一覧を開いて対象ノードをタップし、編集画面で「転送プロトコル」「転送層セキュリティ」「Flow」「SNI」「Fingerprint」「Public Key」「Short ID」などを確認します。v2rayNGはXrayコアでこの組み合わせを処理します。サブスクリプション更新後は通常、項目が自動入力されます。手動編集は主に、サブスクリプション変換で項目が欠落した場合の確認に使います。

v2flyNGはv2flyコアを使用しており、Xrayコアとは対応するプロトコルが異なります。REALITYとXTLS VisionはXrayの機能を必要とする設定なので、このタイプのノードにはv2rayNのXrayコアまたはv2rayNGを使用してください。セキュリティ方式の文字列だけをrealityに変更して、他のコアでも接続できると考えてはいけません。

接続に失敗したらハンドシェイク層、プロキシ層、システム層を切り分ける

REALITYノードでエラーが出た場合は、まずどの層で失敗したかを確認するのが最も効果的です。TCP接続のタイムアウトは、アドレス、ポート、ファイアウォール、回線を示すことが多くあります。REALITY authentication failedやinvalid responseなどは、公開鍵、Short ID、SNI、フィンガープリント、システム時刻が原因であることが多いです。ハンドシェイクに成功したのにWebページを開けない場合は、システムプロキシ、TUNモード、DNS、ルーティング規則を確認します。

PCでは、クライアントが起動していることと、システムの通信が実際にクライアントを経由していることを区別する必要があります。v2rayNでコアを起動しても、ブラウザーがプロキシを通るかどうかは、システムプロキシ、TUNモード、アプリ自身のプロキシ設定によって決まります。システムプロキシを使う場合は、現在のモードが有効になっていることを確認します。TUNモードの場合は、仮想ネットワークアダプターの作成ログと管理者権限に関するメッセージを確認してください。

ローカルポートの競合も、「ノードが使えない」という誤解を生むことがあります。たとえばクライアントが10808で待ち受ける予定でも、そのポートを別のプロセスが使用していると、コアが正常に起動できない場合があります。ログから使用中のプロセスを特定するか、パラメータ設定でローカルポートを変更してください。ノードのテストを繰り返すだけでは待受の失敗は解決しません。

• ステップ1：サーバーアドレスを名前解決でき、TCPポートに接続できることを確認します。
• ステップ2：UUID、公開鍵、Short ID、SNI、フィンガープリント、Flowを確認します。
• ステップ3：コアのログで、ハンドシェイク成功後の接続先への接続記録を確認します。
• ステップ4：システムプロキシ、TUNモード、ローカルポート、DNS設定を確認します。
• ステップ5：複雑なルーティング規則を一時的に無効にし、直接接続のルールセットで最小構成のテストを行います。

選定ではプロトコル名だけでなく対応範囲を確認する

VLESS + REALITY + XTLS Visionは、クライアントとサーバーの双方で互換性のあるXrayコアを動かせ、証明書導入の手間を減らしながら長時間接続の転送を最適化したい場合に適しています。通常のVLESS + TCPより設定項目が多く、サブスクリプションの生成・変換経路でも関連パラメータを完全に保持する必要があります。

既存サービスで標準TLS証明書を安定して使っている場合や、REALITYに対応しないコアと連携する必要がある場合は、VLESS + TCP + TLSを継続したほうが保守しやすいことがあります。プロトコル選定は単純な新旧の置き換えではありません。互換性、サーバーの管理権限、サブスクリプション形式、クライアントコア、回線品質を総合的に判断してください。

VMess、Trojan、Shadowsocksにはそれぞれ導入や互換性の面で適した場面がありますが、Flowを入力しただけでVisionの動作方式を得られるわけではありません。xtls-rprx-visionは特定の組み合わせで使う設定値であり、任意のプロトコルに追加できる汎用的な高速化スイッチではありません。

最終的な判断は3点にまとめられます。REALITYはハンドシェイクと双方の認証を担当し、Visionは条件を満たすデータ転送を最適化し、VLESSはユーザー情報とプロキシ接続情報を運びます。クライアントの項目、サーバーのインバウンド設定、コアの機能が一致して初めて、この組み合わせは想定どおりに動作します。