VLESSはリクエスト形式とユーザー認証、REALITYは外側のセキュアなハンドシェイク、XTLS Visionは通信を識別して転送を最適化します。ノードをインポート済みで、設定項目や性能差を理解したい方向けに、ハンドシェイク、証明書の検証、フロー制御、クライアント設定を順に解説し、接続できない場合に確認すべき項目も紹介します。性能に関する説明は仕組みと適用条件に基づくもので、プロトコル名だけで実際の通信速度を断定するものではありません。
VLESS・REALITY・Visionの役割
この3つは互いに置き換えられるプロトコルではありません。「VLESS + REALITY + Vision」は、それぞれ異なる役割を持つ一般的な組み合わせです。VLESSはプロキシのリクエストを定義し、REALITYは通信の安全性を担い、VisionはVLESSで使うフロー制御です。クライアントのノード編集画面では同じ場所に並ぶため、REALITYを選べばVisionも自動的に有効になると誤解しがちです。
| レイヤー | 主な役割 | 確認する項目 |
|---|---|---|
| VLESS | ユーザー識別情報、宛先アドレス、宛先ポート、リクエスト種別を伝送 | プロトコル、UUID、encryption |
| REALITY | 認証機能を備えたTLS形式のハンドシェイクとセキュアな通信を確立 | security、SNI、公開鍵関連パラメーター、shortId |
| XTLS Vision | 初期パディングを処理し、内側のTLSを識別。条件を満たす場合に転送を最適化 | flow = xtls-rprx-vision |
| TCP | 基盤となる信頼性の高いバイトストリームを提供 | トランスポート方式とサーバーの待ち受けポート |
VLESSのencryptionは通常noneです。ここでいう「暗号化なし」とは、VLESSプロトコル自体がペイロードを追加で暗号化しないという意味であり、通信全体が平文でネットワークを流れるわけではありません。この記事で扱う組み合わせでは、外側の通信をREALITYが保護します。また、ブラウザーでHTTPSサイトにアクセスする場合、アプリケーション側でも接続先サイトとのTLS通信が確立されます。
クライアントとコアも分けて考える必要があります。v2rayNはデスクトップクライアントで、ノードの接続には対応機能を備えたコアを選ぶ必要があります。v2rayNGはXrayコアを使用します。v2flyNGはV2Fly系のコアを使用するため、画面でVLESSを設定できるというだけで、同じREALITYとVisionの組み合わせが動作すると判断することはできません。
REALITYのハンドシェイクと「証明書を借りる」の実際
一般的なTLSプロキシでは、サーバーがドメイン証明書を提示し、クライアントが証明書チェーンとドメイン名を検証します。REALITYでは、導入方法と認証の仕組みが異なります。サーバー側で接続先サイトを設定し、クライアントはSNI、フィンガープリント、REALITYの認証に必要なパラメーターを送信します。サーバーは認証済みのクライアントと、それ以外の接続を判別します。
「証明書を借りる」は理解しやすくするための表現であり、接続先サイトの秘密鍵をプロキシサーバーにコピーするわけではありません。認証済みの接続では、REALITY独自の鍵と検証方式を使って一時証明書を生成・検証します。認証に失敗した場合などは、仕組みに応じて設定された接続先サイトへ接続を引き継ぎ、そのサイト本来のTLS動作を示すことがあります。具体的な処理はサーバー設定と実装バージョンにも左右されます。
つまり、クライアントがすべての検証を無効にして、任意の証明書を受け入れるわけではありません。クライアントが保持するサーバー公開鍵関連のパラメーターが認証に使われ、shortIdはサーバーが許可したクライアントパラメーターとの照合に使われます。SNIもサーバーが受け入れる名前と一致している必要があります。「接続先サイトの証明書のように見える」からといって「ドメインは何でもよい」と考えると、ハンドシェイクに失敗します。
REALITYの一般的な導入では、条件に合うTLS 1.3対応の接続先サイトが必要です。サーバーからそのサイトへ正常に接続できるか、SNIが許可リストに含まれているか、クライアントの時刻が大きくずれていないかが、ハンドシェイクに影響します。エラーが起きた場合は、フィンガープリントの変更を検討する前に、まずこれらの条件を確認してください。
XTLS Visionが暗号化とカプセル化の重複を減らす仕組み
ブラウザーでHTTPSサイトにアクセスすると、ブラウザーとサイトの間ですでにTLS通信が確立されています。プロキシがそのTLS暗号文をさらに別のTLSで丸ごと包むと、いわゆる「TLS over TLS」の状態になります。通信自体は可能ですが、外側のレコード処理や暗号化・復号、バッファー処理にリソースが必要です。
Visionは、どんなデータでも暗号化を省く仕組みではありません。接続開始時の通信やパディングを処理し、内側のTLSのハンドシェイクとレコードの特徴を識別します。実装側の判定で条件を満たした場合、特に直接転送に適したTLS 1.3通信では、より直接的な転送経路に切り替え、既存の暗号文に対する重複処理を減らします。
- 接続の開始時：認証、VLESSリクエスト、通信の識別は引き続き必要です。外側のハンドシェイクを完全に省略するわけではありません。
- 条件を満たすHTTPS通信：アプリケーション側のTLSがサイトのコンテンツを保護します。Visionが主に減らすのは外側の重複処理であり、ブラウザーとサイト間の通信内容を復号するわけではありません。
- 条件を満たさない通信：単純に直接転送へ切り替えることはできず、必要なセキュアなカプセル化とプロトコル処理が引き続き必要です。
- 転送処理：システムや接続条件によっては、より効率的な転送方式を利用できる場合もあります。すべてのプラットフォームや接続で同じ経路が使われるわけではありません。
この仕組みにより、CPU性能が低い環境や同時接続が多い場合、または長時間のデータ転送では、重複する暗号化処理の削減が役立つことがあります。ただし、Visionがサーバーの上り帯域を増やしたり、混雑した回線の遅延を解消したりするわけではありません。ボトルネックがネットワーク間のパケットロスや回線の輻輳であれば、端末の暗号化処理を減らしても、ダウンロード速度に目立った差が出ないことがあります。
見極め方：ハンドシェイク時間と継続的なスループットを分けて測定
比較時はサーバー、接続先サイト、測定時間帯をそろえ、最初のリクエストにかかる時間、継続的なダウンロード速度、クライアントのCPU使用率をそれぞれ記録します。スループットだけが向上し、最初のリクエスト時間にほとんど変化がない場合は、転送や暗号化の負荷が減ったと考えるのが自然です。「ネットワークの往復が1回減った」とは限りません。
設定項目：ポート、SNI、shortId、flow
ノードが動作するかどうかは、クライアントとサーバーのパラメーターが一式そろっているかに左右されます。まずサービス提供元から設定一式を入手し、クライアントへのインポート内容を確認してください。以下の数値はプロトコルや設定上の範囲を示すもので、本サイトによる性能測定の結果ではありません。443はよく使われるポートですが、REALITYで使える唯一のポートではありません。
プロトコルとトランスポート
- プロトコル
- VLESS
- encryption
- none
- トランスポート
- TCP。一部の新しい設定ではRAWと表記
- security
- reality
- flow
- xtls-rprx-vision
これらの選択肢はこの記事で扱う組み合わせを示すもので、すぐに接続できるノード設定一式ではありません。
認証とハンドシェイク
- アドレスとポート
- サービス提供元から指定された接続先を使用
- UUID
- サーバー側に設定されたVLESSユーザーに対応
- SNI
- サーバーで許可されているserverNamesと一致させる
- 公開鍵関連のパラメーター
- サーバー側のREALITY鍵設定で指定された値
- shortId
- サーバーのshortIdsに含まれる値と一致させる
公開鍵パラメーターの名称は、バージョンによって画面表示や設定項目が異なる場合があります。現在使用しているコアのドキュメントとサブスクリプション形式を確認してください。
shortIdは16進数で指定します。空でない値は文字数を偶数にし、最大16文字（8バイト）にします。空の値を使えるかどうかは、サーバーで空のshortIdが許可されているかによります。UUIDの略称ではなく、ノード名から独自に生成するものでもありません。サブスクリプションで配布された値をそのまま使うのが確実です。
SNIとサーバーアドレスも別の概念です。アドレスは実際に接続するホストを指定し、SNIはハンドシェイクでサーバー名を通知します。ノードのアドレスにはIPアドレスを指定し、SNIには設定で許可されたドメインを使う場合があります。アドレスが異なるからといってSNIをサーバーのIPアドレスに変えたり、認証パラメーターの誤りを証明書検証の無効化で隠したりしないでください。
v2rayNの設定と接続確認の手順
設定は「正しくインポートされているか」「コアが対応しているか」「ハンドシェイクが成功するか」「プロキシが機能しているか」の順に確認します。ノード一覧に遅延時間が表示されても、REALITY認証に成功したとは限りません。通常のTCP接続テストで確認できるのは、該当ポートにある程度接続できることだけです。
- ノード設定を確認する。v2rayNのノード一覧で対象ノードをダブルクリックし、プロトコルがVLESS、セキュリティがREALITY、フロー制御が
xtls-rprx-visionになっているか確認します。画面上のグループ名はバージョンによって異なる場合がありますが、各項目の意味は変わりません。 - 実行するコアを確認する。「設定」→「パラメーター設定」を開き、コア関連の項目を確認します。対象ノードがREALITYとVisionに対応するXrayコアで実行されていることを確認してください。クライアントのインストーラー名だけで機能の対応状況を判断しないでください。
- ローカルの待ち受けを確認する。同じ設定画面でローカルプロキシのポートを確認します。たとえば実際の待ち受け先が
127.0.0.1:10808の場合、外部のテストツールにもこのアドレスを指定します。ポートを変更している場合は、テストコマンドも合わせて変更してください。 - 実際の接続をテストする。ノードを選択し、ノード一覧のメニューから実接続の遅延テストを実行して、コアのログを確認します。認証エラー、公開鍵パラメーターの誤り、接続タイムアウトはそれぞれ別に対処してください。すべてを「ノードが遅い」とまとめないようにしましょう。
- アプリの通信経路を確認する。システムプロキシを有効にして、HTTPSページにアクセスします。アプリがシステムプロキシの設定を参照していない可能性を除外するには、コマンドラインでSOCKSプロキシを明示的に指定する方法もあります。
以下のコマンドは、ローカルのSOCKS接続先が実際に10808番ポートで待ち受けている場合にのみ使えます。socks5hを指定すると、ドメイン名の解決をプロキシ側で行うため、このテストでローカルのDNS結果が影響するのを防げます。レスポンスのステータスコードはリクエストが完了したかどうかの目安になりますが、指定したフロー制御で通信したことを単独で証明するものではありません。現在選択しているノードとログもあわせて確認してください。
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -I https://example.com/Androidでは、v2rayNGでもインポート後のREALITYパラメーターを確認し、VPN接続に必要な権限を有効にしてください。Xrayの拡張機能に対応したサブスクリプションの設定をv2flyNGへそのまま移しても、同じ結果になるとは限りません。サブスクリプションを読み込めることと、コアがすべての項目に対応していることは別の問題です。
性能の限界：すべての回線で速くなるとは限らない理由
「処理負荷を抑える」は仕組み上の説明ですが、「遅延が短くなる」かどうかは実測が必要です。REALITYでも基盤となる接続を確立し、安全なハンドシェイクを完了する必要があります。Visionの最適化にも、適用できる通信の条件があります。ページ表示に複数回のDNS問い合わせが必要な場合、遠隔地へのアクセス、またはサーバーでリクエストが滞留している場合は、暗号化処理の削減が全体の所要時間に占める割合は小さいかもしれません。
| 観測された状況 | まず確認する項目 | そこからすぐに結論づけてはいけないこと |
|---|---|---|
| ポートには接続できるが、実際の接続に失敗する | UUID、SNI、公開鍵関連パラメーター、shortId、システム時刻 | ポートに接続できれば認証も成功している |
| ダウンロードは速いが、最初の表示が遅い | DNS、接続確立にかかる時間、接続先サイトの応答 | 継続的なスループットが高ければ、すべてのリクエストの遅延も短い |
| 夜間にスループットが低下する | 回線の輻輳、パケットロス、サーバー負荷 | flowを変更すれば帯域のボトルネックを解消できる |
| CPU使用率は下がったが、通信速度は変わらない | 回線の上り速度制限、接続先の速度制限、ローカル回線の帯域 | 最適化が適用されていない |
比較テストでは、ダウンロード対象、接続数、プロキシルールをそろえ、最低3回繰り返して中央値を記録してください。ブラウザーのキャッシュが使われたリクエストと、キャッシュなしの初回リクエストを比較しないでください。また、異なる地域のサーバーで得た結果をフロー制御だけの効果とみなさないようにしましょう。この方法なら、プロトコル処理の負荷、経路の品質、サーバーリソースの違いを切り分けやすくなります。
よくある質問：接続できない・設定が一致しない場合の対処
REALITYを選んだのに、なぜVisionも設定する必要があるのですか？
REALITYは通信のセキュリティ設定、VisionはVLESSのフロー制御です。ノードの編集画面を開き、セキュリティ設定とflowをそれぞれ確認してください。サービス提供元がxtls-rprx-visionを指定している場合、クライアントとサーバーのユーザー設定を一致させる必要があります。flowを空欄にして代用することはできません。
TCPの遅延は表示されるのに、実接続に失敗し続けるのはなぜですか？
まずコアのログを開き、UUID、SNI、公開鍵関連パラメーター、shortIdを確認します。次に、端末の自動時刻設定が有効になっていること、サーバーから設定済みの接続先サイトにアクセスできることを確認してください。TCPの遅延テストではプロキシ認証の全工程を確認できないため、ハンドシェイクの問題がないとは判断できません。
フィンガープリントにchromeを設定すれば、本物のブラウザーと同じになりますか？
いいえ。この設定が主に影響するのはクライアントのTLSハンドシェイクの特徴であり、その後のすべてのネットワーク動作がブラウザーと同じになるわけではありません。サービス提供元が推奨し、現在のコアが対応しているフィンガープリントを使用してください。ログに非対応と表示された場合は、互換性のあるコアに更新するか、サービス提供元に確認してください。名前を手当たり次第に切り替えるのは避けましょう。
サブスクリプションを更新した後も、以前の公開鍵やshortIdを使い続けられますか？
まず新しいサブスクリプションのパラメーターを使用してください。サーバーの鍵やshortIdの一覧が変更されていると、以前の値では認証に失敗することがあります。ノードを再インポートまたは更新し、同じ名前の古いノードが残っていないか確認してください。表示名だけを変更したノードではなく、更新後の設定が選択されていることも確かめましょう。
この設定の要点は、プロキシプロトコル、外側のセキュリティ、フロー制御の役割を区別することです。まず各パラメーターとコアの対応を確認し、ハンドシェイクと実際のリクエストを観察します。接続経路を確認して初めて、VisionがCPU使用率をどれだけ下げるか、リクエスト時間を短縮するかを比較できます。