REALITYとXTLS Visionの仕組みを解説｜VLESSの通信が速くなる理由

VLESS・REALITY・Visionの役割

ノード名にある「VLESS + TCP + REALITY + Vision」は、同じ意味の用語が4つ並んでいるわけでも、4種類の暗号化を重ねているわけでもありません。それぞれのレイヤーを分けて考えると、同じVLESS表記でも設定項目や接続時の挙動が異なる理由がわかります。

• VLESS：ユーザー情報や接続先アドレスなどを運ぶプロキシプロトコルです。ユーザーの識別にはUUIDがよく使われます。プロトコル自体はTLSのようなデータ暗号化を担いません。
• TCP：ここでは基盤となるトランスポートです。新しいXrayの設定や一部の画面ではRAWと表記されることもあります。クライアントとコアの項目名に従って確認してください。
• REALITY：Xrayエコシステムで使われる通信のセキュリティ機構です。ハンドシェイク、サーバー認証、認証に失敗した接続の処理に関わります。
• XTLS Vision：VLESSのフロー制御方式です。一般的なFlow値はxtls-rprx-visionで、通信開始時のデータ形式を調整し、条件を満たす場合は重複するカプセル化や暗号化を減らします。

v2rayNは管理用の画面で、実際の接続は起動されたコアが処理します。これらの設定を確認する際は、対応機能を備えたXrayコアが対象ノードを処理しているか確認してください。クライアント画面が開くだけでは判断できません。V2FlyとXrayの機能開発は完全に一致していないため、どちらもV2Rayの技術体系に由来するからといって、同じREALITY設定をそのまま相互に使えるとは限りません。

REALITYのハンドシェイク：アドレス・SNI・認証情報

ブラウザーでHTTPSサイトにアクセスすると、まずTLSのパラメーターを交渉し、接続先の身元を確認します。プロキシを使う場合、ブラウザーとWebサイトの間に、クライアントからプロキシサーバーまでの通信区間が加わります。REALITYが主に処理するのはこの区間であり、ブラウザーに接続先サイトの証明書を発行するものではありません。

REALITYクライアントは、サーバーから提供された公開鍵などのパラメーターを使って接続先を検証し、ハンドシェイク中に必要な認証情報を送ります。サーバー側では、設定で許可されたサーバー名やShort IDなども確認します。認証に失敗した接続は、REALITYの仕組みによりサーバーに設定された接続先サイトへ転送される場合があります。実際の挙動は設定や失敗した段階によって異なり、エラーが出れば必ずWebページが表示されるという意味ではありません。

混同しやすいアドレスが2つあります。ノードの「アドレス」は、クライアントが接続するプロキシサーバーを指定します。SNI（サーバー名）はハンドシェイクで使う名前で、通常はサーバー側で許可された名前のいずれかを指定します。SNIにノードのIPアドレスを入力したり、ノードのアドレスをSNIに対応するWebサイトのアドレスへ変更したりすると、設定が正しく機能しないことがあります。

• ノードのアドレスとポート：ノードの提供元から指定されます。443がよく使われますが、一般的なポート番号というだけで、ほかのポートが使えないわけではありません。
• サーバー名：serverNameに対応します。共有リンクではパラメーター名がsniになっていることが多いため、そのまま確認してください。
• 公開鍵：サーバーの秘密鍵と対になる必要があります。クライアントに必要なのは接続用の公開鍵情報です。サーバーの秘密鍵を求めたり入力したりしないでください。
• Short ID：サーバー側で許可された短い識別子です。UUIDの一部ではなく、自由に作成するメモでもありません。
• フィンガープリント：一般的な値はchromeです。クライアントのハンドシェイク特性を選ぶもので、アプリが実際に使うブラウザーをChromeに変更するわけではありません。

REALITYでは、このプロキシ区間のためにサイト管理者が従来方式のドメイン証明書を設定する必要はありません。ただし、サーバー側で指定する接続先サイトの選択や到達性は重要です。また、あらゆるネットワーク環境で通信を識別できなくなるわけではありません。ハンドシェイク以外にも、接続時間、パケットサイズ、アクセスの挙動はネットワーク上で観測される情報です。

XTLS Visionで通信のオーバーヘッドを抑えられる理由

一般的なTLSプロキシでHTTPS通信を中継すると、ブラウザーと接続先サイトの間ですでにTLSが使われているうえに、クライアントとプロキシサーバーの間にもTLSが重なります。これ自体に問題があるわけではありませんが、重複した処理によってCPUリソースを消費し、レコードのカプセル化やデータコピーなどの負荷も増えます。

Visionはプロキシ通信の開始時にデータを判別し、初期段階ではパディングなどを使ってデータ形式を調整します。条件に合うTLS通信、特に識別可能なTLS 1.3接続では、適切な段階でデータ処理方式を切り替え、暗号化済みのアプリケーションデータに同じ外側の暗号化を常に重ねることを避けられます。ブラウザーと接続先サイトの間のTLSは引き続き使われます。

ここでいう「速くなる」には条件があります。サーバーの暗号化処理やデータ転送がCPUの上限に近い場合、重複処理の削減による効果が期待できます。一方、ボトルネックが国際回線の混雑、サーバー側の速度制限、パケットロスにある場合、Visionに変更しても帯域が増えるわけではありません。TLS以外の通信や最適化の条件を満たさない接続に、同じ効果を期待することもできません。

v2rayNの設定項目：サーバー側の値と照合

まず完全なサブスクリプションまたは共有リンクをインポートしてから、重要な項目を確認してください。v2rayNデスクトップ版はバージョンによってメニュー名が多少異なります。一般的には、共有リンクをコピーし、「サーバー」→「クリップボードからURLを一括インポート」を選んでから、対象項目の編集画面を開きます。ノード名にREALITYとあるだけで、設定項目がすべてそろっていると判断しないでください。

VLESSのnoneは、この種の構成で該当項目に指定される一般的な値であり、通信全体が平文で送信されるという意味ではありません。通信は選択したセキュリティ機構によって保護されます。反対に、VMessでよく使われるautoへ手動で変更しても「暗号化が強くなる」わけではありません。異なるプロトコルの設定項目を混同しないようにしてください。

1. まずアドレス、実際のポート、UUIDを確認し、次にトランスポート、セキュリティ方式、Flowを照合します。これらの項目が、想定したプロトコルで接続できるかを左右します。
2. 続いてSNI・公開鍵・Short IDを一文字ずつ照合し、コピー時に空白が混入していないか確認します。Short IDを空欄にしない場合は、16進数の偶数桁で、長さは16文字以下にします。空欄が許可されるかどうかはサーバー側の設定によります。
3. 対象ノードがREALITYとVisionに対応するXrayコアで実行されていることを確認してから、アクティブサーバーに設定してください。画面上で保存できたことは、コアが対応している証拠にはなりません。
4. 「設定」→「パラメーター設定」でローカルの待ち受けポートを確認し、「システムプロキシ」→「システムプロキシを自動設定」を選択します。使用中のバージョンで表示が異なる場合は、同じ機能の項目を探してください。

性能比較：条件をそろえてからプロトコルの違いを確認

異なるサブスクリプションのノードを比較すると、プロトコルより先に回線やサーバーの性能の差が結果に表れることがよくあります。負荷の低い一般的なTLSノードが、混雑したREALITYノードより速いこともあります。Visionの効果を確かめるには、できるだけフロー制御方式だけを変更し、両方のサーバー設定が正しく動作することを確認してください。

上記はテスト方法であり、本サイトで実測した結果ではありません。速度を記録するときは単位にも注意してください。100 Mbpsは理論上約12.5 MB/sです。実際の転送速度はプロトコルのオーバーヘッドや回線状況によって変わります。ルーティングルールによってテスト対象のドメインが直結になっている場合、その結果からREALITYの性能は評価できません。

• Webページの初回表示は遅いが、その後のダウンロードは速い：DNS、ハンドシェイクの所要時間、接続先サイトの応答を確認します。
• ダウンロード速度が徐々に落ち、CPU使用率が高い：コアのリソース使用率、端末の性能、ほかのバックグラウンド処理を確認します。
• 混雑する時間帯にすべてのノードが遅い：まず回線や時間帯を比較し、公開鍵やFlowを何度も変更しないでください。

REALITYに接続できないときのよくある質問

設定の進め方：まず接続を確認し、次に最適化の効果を検証

REALITYはハンドシェイクの仕組み、Visionはデータ処理の経路に関わります。設定では、まず認証情報が一致することを確認し、次にアプリのリクエストがプロキシを通っていることを確かめてから、性能を比較します。こうすることで、ハンドシェイクの失敗、ルーティングの問題、帯域幅のボトルネックを切り分けられます。一度の確認で十数項目を同時に変更する必要はありません。

1. 完全な設定をインポート：提供元のアドレス、ユーザー情報、ハンドシェイク設定を保持し、スクリーンショットから情報を組み立てないでください。
2. コアを確認：この組み合わせに対応するXrayコアを使い、項目が認識されない場合はまずバージョンを確認します。
3. 通信経路を確認：システムプロキシ、ローカルの待ち受け、ルーティングを確認し、対象リクエストがそのノードを経由していることを確かめます。
4. 条件をそろえて比較：同じ接続先、近い時間帯、複数回のテストで効果を判断します。遅延の数値をダウンロード速度と混同しないでください。

サブスクリプションのインポートやシステムプロキシの基本操作は使い方ガイドをご覧ください。プロトコル、トランスポート、ルーティングルールの違いは詳細ガイドのプロトコル解説で確認できます。ノード名だけを見て「新しいプロトコル」を選ぶより、こうした違いを理解するほうが安定した設定につながります。