VLESSはプロキシプロトコル、REALITYは接続時のセキュアなハンドシェイク、XTLS Visionは特定の通信を効率よく転送する仕組みです。ノードをインポートしたものの、Flowや公開鍵、SNIの役割が分からない方に向けて解説します。読み終えると、性能向上の仕組みと回線のボトルネックを切り分け、サーバー設定に照らしてv2rayNの設定を確認できるようになります。
VLESS・REALITY・Visionはそれぞれどのレイヤーを担う？
ノード名の「VLESS + TCP + REALITY + Vision」は、互いに置き換えられる4種類のプロトコルを意味するものではありません。1つのプロキシ接続における、それぞれ異なる設定を示しています。VLESSはユーザー情報と接続先アドレスを伝え、TCPはバイトストリームを運びます。REALITYは安全なハンドシェイクと認証を担い、VisionはVLESSのフロー制御方式の1つとして、条件を満たす場合に後続のデータ転送を最適化します。
| 名称 | 主な役割 | 確認する項目 |
|---|---|---|
| VLESS | プロキシ要求、ユーザー情報、接続先情報 | アドレス、ポート、UUID |
| TCP / RAW | 接続データを順序どおりに運ぶバイトストリーム | 通信方式。画面上の名称はバージョンによって異なる場合があります |
| REALITY | セキュアなハンドシェイクとサーバー認証 | SNI、公開鍵などの認証情報、Short ID |
| XTLS Vision | 通信を判別して転送経路を選択 | xtls-rprx-vision |
VLESS自体は、一般的な意味でのペイロード暗号化を行いません。一般的な設定にあるencryption=noneも、接続全体が平文で送信されるという意味ではありません。REALITYを使う場合、通信の保護は外側の仕組みが担います。「セキュリティ強化」のために、VLESSの暗号化項目を別プロトコルの設定に変更しないでください。
この記事では、XrayのVLESS + REALITY + Vision構成を取り上げます。v2rayNはノードを管理し、コアを呼び出すクライアントであり、この構成そのものではありません。接続できるかどうかは、実際に起動するコアと生成された設定で判断し、ソフト名だけで決めないでください。
HTTPS通信をプロキシ経由にすると、どこで暗号化が重複する？
ブラウザーでHTTPSサイトにアクセスすると、接続先サイトとの間でTLSセッションが確立されます。プロキシは通常、暗号化済みのデータを中継するだけで、ウェブページの内容を復号しません。プロキシ経路でもTLSを使う場合、クライアントは内側のTLSデータをさらに外側で包んで暗号化し、プロキシサーバーへ送ることがあります。サーバー側では外側の暗号化を解除します。
ここには、異なる2つのセキュリティ上の接続があります。内側はブラウザーとウェブサイト間の通信内容を保護し、外側はクライアントとプロキシサーバー間の通信を保護します。どちらにも役割がありますが、すでに暗号化された大容量データをさらに暗号化すると、CPU処理、バッファー処理、データコピーなどのコストが増えます。高スループットが求められる環境や処理能力の低い機器では、これらがボトルネックになりやすくなります。
すべてのリクエストがこの仕組みに当てはまるわけではありません。通常のHTTPにはウェブサイト側のTLSレイヤーがなく、UDP通信もHTTPSのバイトストリームと同じ処理経路をそのまま適用できません。そのため、「二重暗号化の削減」がすべてのアプリで一定の速度向上につながるわけではありません。
XTLS Visionはデータ転送経路をどう最適化する？
Visionは接続開始時に保護をただちに無効化するわけではありません。まずプロトコルヘッダーと初期データを処理し、内側のTLSの状態を判別します。条件を満たすTLS 1.3通信では、適切な段階で最適化されたデータ経路に切り替え、暗号化済みのアプリケーションデータに外側の暗号化を重ねる不要な処理を避けます。
- まず接続を確立。クライアントとサーバーが外側のセキュアなハンドシェイクを完了し、VLESSのユーザー情報と接続先アドレスをやり取りします。
- 次に通信を判別。Visionは内側のTLSハンドシェイクとレコードの特徴を確認します。初期段階では、パディングによって初期データパケットの特徴を調整します。
- 条件を満たした場合のみ切り替え。最適化に適したTLS 1.3通信では、直接転送経路に移行し、ウェブサイトのデータは引き続き内側のTLSで保護されます。
- それ以外の通信は適切に処理。条件を満たさない場合、外側の暗号化がなくなったと決めつけてはいけません。実際の経路はコアが判断します。
「直接転送」は、特定のOSレベルのゼロコピー処理が必ず有効になるという意味ではありません。コピーをさらに減らせるかどうかは、OS、接続の形式、コアの実装によって異なります。設定にxtls-rprx-visionとあっても、フロー制御が有効になっていることを示すだけで、すべての接続が同じ高速経路を通るとは限りません。
確認ポイント：まずCPUがボトルネックかどうかを確認
同じ回線でダウンロード速度がすでに帯域の上限に達し、CPUにも余裕がある場合、Visionを有効にしても速度はほとんど変わらないことがあります。クライアントまたはサーバーの単一コアが継続的に高負荷なら、同じファイルを同じ時間帯にダウンロードし、スループットとCPU使用率を比較してください。
REALITYでサーバー証明書の用意が不要になる仕組み
一般的なTLSサーバーでは、自分のドメイン用の証明書と秘密鍵を設定します。REALITYは異なるハンドシェイクと認証方式を採用し、接続先サイトのTLSハンドシェイクの特徴を利用します。そのため、プロキシサーバーでは通常の方法でプロキシ用ドメインの公開証明書を取得・更新する必要がありません。接続先サイトの証明書をコピーしてサーバーに置く仕組みではありません。
クライアント側では、引き続き接続の正当性を検証します。一般的な構成では、サーバーで生成したX25519鍵ペアを使います。秘密鍵はサーバーだけに保管し、公開鍵をクライアントに配布します。クライアント側では、SNIやShort IDなどの設定も正しく指定する必要があります。Short IDは接続の識別に使われますが、鍵認証の代わりにはならず、唯一のログインパスワードでもありません。
- SNI：サーバーが許可するサーバー名と一致させる必要があります。接続先アドレスにはIPアドレスを指定できますが、SNIには通常ドメイン名を指定します。両者は別の項目です。
- 公開鍵：接続先ノードのサーバー設定で配布された値を使います。接続先サイトの証明書の公開鍵を使ったり、別のノードの値を流用したりしないでください。
- Short ID：サーバーで許可された値と一致させます。16進数で表記し、長さにも設定上の制約があります。まずはサブスクリプションに含まれる値をそのまま使ってください。
- フィンガープリント：クライアントでよく使われる選択肢は
chromeです。対応するハンドシェイクの特徴を再現するための設定であり、実際にそのブラウザーを使う必要があるという意味ではありません。 - 時刻：端末のシステム時刻を正確に保ってください。サーバーに時刻差の制限がある場合、大きな時刻のずれによって認証に失敗することがあります。
サーバー側では、ハンドシェイク先も設定します。設定項目名はtarget、または古いバージョンではdestの場合があります。接続先サイトが適切なTLSに対応し、サーバーから到達できる必要があります。接続先の選択を誤るとハンドシェイクに影響します。認証に失敗した接続を接続先サイトへ転送する場合もありますが、どのネットワーク環境でもプロキシを識別できなくなるという意味ではありません。
v2rayNの設定：ノード名ではなく項目ごとに確認
まずサービス提供元から受け取った完全なサブスクリプションまたは共有リンクをインポートし、ノードの編集画面を開きます。以下の2つのカードは、同じ接続の設定項目を確認するための例で、実際に使えるノード設定ではありません。ポート443は一般的な構成例にすぎず、実際の値はサーバー側の設定に従ってください。
VLESSと通信方式の設定
- プロトコル
- VLESS
- サーバーポート
- 443（例）
- 通信方式
- TCP / RAW
- 暗号化
- none
- Flow
- xtls-rprx-vision
アドレスとUUIDはノードの元の値を使い、Flowはサーバーの対応状況を確認してください。
REALITYの認証設定
- セキュリティ方式
- reality
- SNI
- サーバーで許可されたドメイン名
- 公開鍵
- サーバーから配布された公開鍵
- Short ID
- サーバー設定と一致する16進数の値
- フィンガープリント
- chrome（よく使われる設定）
画面上の項目名はコアやクライアントのバージョンによって異なる場合があります。インポート後も設定を確認してください。
v2rayNで「設定」→「パラメータ設定」を開き、ローカルの待ち受けポートを確認します。次に、現在のノードで実際に使われているコアを確認してください。メニューの細部はバージョンによって異なりますが、ローカルポートとリモートポートは別のものです。ブラウザーはローカルプロキシの入口に接続し、コアがノードのリモートポートに接続します。
Androidでv2rayNGを使う場合も、VLESS、REALITY、Flowの各項目と、コアの対応状況を確認してください。v2flyNGはv2flyコアを使うため、この記事で扱うXray専用の構成をそのまま適用できるとは限りません。ノードが一覧に表示されても、現在のコアがすべての機能を実行できるとは限りません。
遅延の数字だけに頼らず、速度向上を確かめる方法
プロトコルを比較する際は、できるだけ同じサーバー、出口、テスト先を使います。異なる地域にあるサーバー同士を比較すると、回線の違いをプロトコルの効果と誤認する可能性があります。通常のTCP接続テストで確認できるのは、特定のポートに接続できることだけです。REALITY認証の成功も、Visionによる最適化経路への切り替えも証明できません。
- 条件をそろえる：クライアントとコアのバージョン、ノードのアドレス、通信方式、Flow、システムプロキシの状態を記録し、ほかのダウンロードは停止します。
- 実際にプロキシ経由か確認：ログで接続先とルーティング結果を確認し、速度測定先のドメインが直接接続のルールに一致していないか調べます。
- 指標を分けて記録：ウェブページの初回応答時間、継続ダウンロード速度、クライアントとサーバーのCPU使用率を記録します。1回の遅延測定だけで総合評価しないでください。
- 複数回測定：各条件で60秒間の測定を3回行い、中央値を比較します。これは測定方法の提案であり、この記事での実測結果ではありません。
- 異常値の原因を確認：速度が低下した場合は、パケットロス、サーバー負荷、出口の速度制限も確認します。CPU使用率が下がっても速度が変わらない場合、帯域幅が上限になっている可能性があります。
選び方：安定して使える構成を保ち、最適化の効果を検証
まずサーバーとクライアントの設定を完全に一致させてから、Visionの効果を測定してください。Flow、通信方式、ルーティングモードを同時に変更せず、1回の検証で変更する項目を1つに絞ると、性能の変化がどの設定によるものか特定できます。
REALITYとVisionで接続できないときによくある質問
ポートには接続できるのに、ウェブページが開かないのはなぜ？
まずコアのログでハンドシェイクが完了しているか確認し、UUID、SNI、公開鍵、Short IDを順に照合します。ポートに到達できることが分かるのはTCPレイヤーの状態だけです。ハンドシェイクが成功してもウェブページが開かない場合は、DNSとルーティングを確認します。v2rayNのトレイメニューでシステムプロキシが設定されているか確認し、ブラウザー側に別のプロキシ設定がないかも調べてください。
FlowをVisionに変えるだけで速くなる？
クライアント側の設定だけを変更しても解決しません。ノードの編集画面を開き、Flowをサーバー設定と照合してください。サーバーで対応するフロー制御が有効でない場合、クライアント側だけにxtls-rprx-visionを設定すると接続に失敗することがあります。サブスクリプションのノードでは、サービス提供元が設定した値をそのまま使ってください。
REALITYのSNIを、よく使われるウェブサイトのものに変更できる？
まずサーバーで許可されている名前を確認し、任意の値に変更しないでください。接続先アドレス、SNI、サーバーのハンドシェイク先はそれぞれ役割が異なります。サブスクリプションの元の値に戻して接続を再起動してください。それでも失敗する場合は、サーバー管理者に接続先への到達性とシステム時刻を確認してもらいましょう。
クライアントの更新後に設定項目が認識されない。どの項目を削除すればいい？
まずクライアントと実際に使われているコアのバージョンを記録し、ログに示された項目を確認してから、サブスクリプション全体を再インポートしてください。新旧のコアでは項目名が異なる場合があります。認証項目を削除したり、検証を無効にしたりしないでください。デスクトップ版では、そのノードがこの構成に対応するXrayコアを使っているかを確認します。
切り分けは順番に進めます。ローカルの入口、リモートポート、認証設定、コアの互換性、DNSとルーティングを確認し、最後に性能を比較してください。REALITYの導入方法とVisionの転送最適化によって特定の処理負荷は軽減できますが、接続の可否は通信経路全体で決まります。