VLESSはプロキシリクエストを処理し、Visionは条件を満たすTLSトラフィックの転送を最適化、REALITYはプロキシ接続のセキュリティと認証を担います。3つを組み合わせるメリットは、回線帯域を増やすことではなく、不要なカプセル化や重複した暗号化処理を減らせる点にあります。VLESSのサブスクリプションを入手し、v2rayNまたはv2rayNGで設定を確認したい方に向けて、各レイヤーの役割、設定項目やログの見方、比較テストによる問題の切り分け方を解説します。
1. VLESS、Vision、REALITYの役割
まず結論から説明します。一般に「VLESS + REALITY + Vision」と呼ばれる構成は、3つのプロキシプロトコルを並列に使うものではなく、役割の異なる機能を組み合わせたものです。VLESSはクライアントが接続先のアドレスと認証情報を送る方法を定義し、XTLS VisionはXrayのフロー制御方式、REALITYは接続のセキュリティ層にあたります。正しい名称を設定していても、項目を誤った欄に入力すると、想定どおりに接続できません。
| レイヤー | 主な項目と値 | 主な役割 |
|---|---|---|
| プロキシプロトコル | protocol: vless | ユーザー情報、接続先アドレス、プロキシリクエストを伝送します。 |
| フロー制御 | flow: xtls-rprx-vision | 条件を満たすTLSデータを識別し、転送を最適化します。 |
| トランスポート | TCP(新しいバージョンの一部画面ではRAW) | クライアントとサーバー間でバイトストリームを伝送します。 |
| 接続セキュリティ | security: reality | 保護された接続を確立し、サーバーを認証します。 |
VLESS自体には、完全な通信暗号化機能はありません。一般的な設定画面でVLESSのencryptionをnoneにしても、通信全体が平文になるわけではありません。外側の通信はREALITYによって保護されます。また、このVLESSの項目をVMessの暗号化設定と同じものとして扱わないでください。2つのプロトコルは設計が異なります。
この記事では、XrayのVLESS、Vision、REALITYを組み合わせた構成を解説します。「V2Ray」はプロジェクトやエコシステムの名称であり、すべてのコアがこれらの項目に対応しているわけではありません。対応状況はクライアント名に「v2ray」が含まれるかではなく、実際に動作するコアで確認してください。
2. XTLS Visionで処理負荷を抑えられる理由
HTTPSサイトにアクセスすると、ブラウザーと接続先サイトの間ですでにTLS通信が確立されています。プロキシトンネルでも同じデータを継続的に外側から暗号化すると、いわゆる「TLS over TLS」の状態になります。通信自体は可能ですが、暗号化処理やレコードのカプセル化、データのコピーなどの負荷が増えます。低消費電力の端末、高スループットの接続、CPU性能が上限に近い環境では、こうした負荷が表れやすくなります。
Visionは、プロキシ接続内のTLSハンドシェイクとデータ転送の段階を識別し、ハンドシェイク時にはパディングなどの処理を行います。条件を満たす場合は、接続先のTLSですでに保護されているデータに対する、外側の重複した暗号化処理を省きます。接続先サイトとブラウザー間のエンドツーエンドTLSが解読・解除されることはなく、プロキシがHTTPSの本文を取得することもありません。
- 最適化の対象には条件があります:対象となるのは識別可能で要件を満たすTLSトラフィックです。すべてのTCPデータが同じように最適化されるわけではありません。
- TLS以外のデータも保護されます:Visionを有効にしても、通常の平文アプリ通信がそのまま送信されることはありません。
- 転送経路によって効果は変わります:OSやコアの実装、接続状態によってコピーや転送の効率が異なるため、どの環境でも同じ効果が得られるとは限りません。
- 帯域の上限は変わりません:サーバーの速度制限、ネットワーク混雑、パケットロスは残るため、フロー制御でこうした物理的な制約を回避することはできません。
そのため、「Visionはどの方式よりも必ず速い」とは言えません。ボトルネックがサーバー側の限られた帯域なら、端末のCPU負荷を抑えてもダウンロード速度は変わらないことがあります。一方、端末の暗号化処理能力がボトルネックであれば、スループットの向上やCPU使用率の低下が見られる可能性があります。
3. REALITYのハンドシェイクと証明書の違い
REALITYの主な目的は接続の認証と通信の外観設計であり、すべてのハンドシェイクを省略するものではありません。クライアントはサーバーから提供された公開鍵情報を保持し、serverNameやshortIdなどのパラメーターと組み合わせて接続を検証します。サーバーは設定した接続先サイトを利用し、認証条件を満たさない接続に通常のTLSサービスに近い応答を返すことができます。ただし、認証済みユーザーの通信がすべてその接続先サイトを経由するという意味ではありません。
通常のTLS証明書を自分で導入する方法と比べると、この構成ではプロキシサーバーの入口用に、一般的なドメイン証明書を発行・更新する手順が不要な場合がほとんどです。ただし、鍵、許可されたserverName、接続先サイトの条件、クライアント側のパラメーターは正しく設定する必要があります。serverNameに任意の有名サイトを指定したり、アドレス欄に表示されるサーバーIPをそのままserverNameに設定したりしないでください。
注意:ポート番号や名称だけで設定を推測しないでください
サブスクリプションを入手したら、アドレス、ポート、serverName、公開鍵情報、shortIdを1つずつ確認してください。接続には、提供元から明示された値だけを使用します。443は一般的なポートですが、REALITYで必須というわけではありません。
「ハンドシェイクの簡略化」は、より正確には、一般的なTCP構成でWebSocketのHTTP Upgradeなどのアプリケーション層の処理を追加せずに済み、サーバー側の通常の証明書管理も減らせるという意味です。TCP接続、接続のセキュリティネゴシエーション、接続先サイトへの接続には引き続き時間がかかります。「ハンドシェイクが不要」や「必ず何ミリ秒短縮できる」とは言えません。
4. クライアントとコアの選び方
デスクトップではv2rayN、Androidではv2rayNGを利用できます。どちらも設定とコアの実行を行うクライアントで、REALITYやVisionのパラメーターを実際に処理するのはコアです。クライアントを更新した後は、実行中のコアも更新されているか、対象ノードがどのコアを使っているかを確認してください。
Xrayコア
おすすめこの記事で扱う構成は、Xrayでの実装を前提としています。デスクトップではv2rayNで対象のVLESSノードがXrayを使っていることを確認してください。Androidではv2rayNGを使用し、内蔵コアがインポートした設定に対応しているか確認します。
おすすめの用途:VLESS + REALITY + Visionの設定、Xrayコアのログを使ったトラブルシューティング。
V2Flyコア
v2flyNGはV2Flyコア向けのクライアントです。名称が似ているからといって、REALITYやVisionを含むXrayの設定をそのまま適用することはできません。使用するコアに明確に対応したノード設定を選んでください。
おすすめの用途:V2Fly向けと明記されたVMessなどの設定。この記事の構成を使う代替クライアントではありません。
サブスクリプションには、対応する形式に制約があります。リンクをインポートできても、すべての拡張項目が保持されるとは限りません。インポート後はノードの編集画面を開き、セキュリティ方式、フロー制御、SNI、フィンガープリント、shortIdを確認してください。ノード名が一覧に表示されたかどうかだけで判断しないでください。「互換性を高める」ためにセキュリティ方式をREALITYから通常のTLSに変更すると、接続方式そのものが変わります。
5. v2rayNで設定を1つずつ確認する
以下では、Windows版v2rayN 6.xの従来型画面をメニュー名の参照に使います。最低バージョンを示すものではありません。クロスプラットフォーム版や後続バージョンでは項目の配置が異なる場合があるため、項目の意味に合わせて操作してください。長いパラメーターを手入力するより、提供元の完全なサブスクリプションまたは共有リンクを使うことをおすすめします。
-
ノードをインポートする
共有リンク全体をコピーし、メイン画面で「サーバー」→「クリップボードから一括URLインポート」を選択します。手動で追加する場合は「サーバー」→「[VLESS]サーバーを追加」を開き、プロトコルにVLESSを選択してください。
-
コアを確認する
「設定」→「パラメーター設定」→「Coreタイプ」を開き、VLESSにXrayが設定されていることを確認します。使用中のバージョンでコアの選択項目がノードやグループの設定にある場合は、実際に適用される項目を確認してください。起動後、ログでも実行中のコアを確認します。
-
トランスポートを確認する
ノードをダブルクリックして編集画面を開き、提供元の設定に従ってアドレス、ポート、ユーザーIDを入力します。この構成ではトランスポートにTCPを選択します。新しいバージョンの一部ではRAWと表示されます。VLESS encryptionは通常
noneです。 -
セキュリティ設定を確認する
フロー制御を
xtls-rprx-vision、トランスポート層のセキュリティをrealityに設定します。SNI、Fingerprint、PublicKey、ShortIdをそれぞれ照合してください。公開鍵情報の項目名はバージョンによって異なる場合があります。独自に生成した値で置き換えないでください。 -
起動して確認する
設定を保存してノードを選択し、メイン画面の「システムプロキシ」を「システムプロキシを自動設定」にします。その後、通常のHTTPSページにアクセスしてください。まずコアが正常に起動したかを確認し、次に接続ログを確認します。TUNを使う場合は、トラフィックの取り込みとルーティングも別途確認してください。
FingerprintはTLSクライアントのフィンガープリント設定です。サーバーの公開鍵ではなく、ブラウザーのバージョン番号を自由入力する項目でもありません。画面でサポートされている選択肢から、ノードの要件に合う値を選んでください。「フィンガープリント名を端末のブラウザーに合わせればよい」という意味ではなく、実際の認証には対応する鍵情報やほかのパラメーターも必要です。
サブスクリプション全体、ユーザーID、サーバーの秘密鍵を公開しないでください。トラブルシューティングでは、項目名、個人情報を伏せたエラーの種類、コアのバージョンだけを記録すれば十分です。クライアントに必要なのはサーバーから提供された公開鍵情報であり、サーバーの秘密鍵ではありません。
6. 速度向上の要因を見分ける方法
まず、遅延、スループット、端末への負荷を分けて考えます。TCPの遅延テストでわかるのは、サーバーポートに接続できるかどうかであり、REALITYの認証成功を示すものではありません。Webページを開けても、Visionが想定どおりのデータ処理経路で動作しているとは限りません。速度を評価する際は、同じ回線と近い負荷条件で比較してください。
- 条件をそろえる:同じ端末、ネットワーク、ダウンロード先、プロキシの適用方法で測定します。比較するノードは、回線の違いを排除しやすいよう、できれば同じサーバーにしてください。
- 繰り返し測定する:設定ごとに3回、各30秒間測定して中央値を記録します。最速の結果だけを残さず、接続失敗の回数も記録してください。
- 指標を分けて記録する:スループットはMB/s、遅延はmsで記録し、CPU使用率も確認します。MbpsとMB/sを混同しないでください。両者は8倍の関係です。
- 変数を一定にする:測定中はサブスクリプションの更新、大容量ファイルの同期、ほかのダウンロードを一時停止します。ルーティング、DNS、コアを同時に変更すると、結果をVisionの効果と判断できません。
速度がほぼ同じでもCPU使用率が下がっていれば、最適化の効果が出ている可能性があります。最初のページだけ表示が速い場合は、DNSキャッシュや接続の再利用が原因かもしれません。環境に依存しない速度向上率を示すことはできません。一度の速度測定のスクリーンショットより、再現できる記録をもとに設定を判断しましょう。
7. REALITYとVisionでよくある接続トラブル
ポートへの遅延は正常なのに、Webページが開けないのはなぜですか?
ポートに接続できることが示すのは、TCP接続が確立したという点だけです。ノードをダブルクリックし、まずREALITYのserverName、公開鍵情報、shortIdを確認してから、コアのログで認証やハンドシェイクのエラーを確認してください。端末の日付、時刻、タイムゾーンが正しいかも確認します。
ログにflowが未対応と表示されます。空欄に変更すればよいですか?
まず、ノードが実際にXrayで動作しているかを確認し、次にコアのバージョンとサーバー側の要件を確認してください。サーバーがxtls-rprx-visionを要求している場合、フロー制御を安易に空欄にする方法は、どの環境でも使える解決策ではありません。対応するコアに更新するか、正しい設定を再インポートしてください。
リンクをコピーしたのにVLESSしか表示されません。REALITYの設定はどこですか?
ノードの編集画面を開き、セキュリティ方式と関連項目を確認してください。項目がない場合は、共有リンク全体を再度コピーし、チャットツールによるクエリパラメーターの切り詰めを避けます。それでも表示されない場合は、クライアントを更新し、共有形式が現在のバージョンに対応しているか提供元に確認してください。
Visionを有効にしても速度が変わりません。設定を間違えていますか?
必ずしもそうとは限りません。前述の方法でスループットを3回測定し、CPU使用率も確認してください。主なボトルネックが出口帯域やパケットロスであれば、プロトコルの最適化で大きく速度が上がるとは限りません。接続が途切れる場合は、サーバー側のフロー制御設定とコアのログを確認してください。
ブラウザーは正常なのに、ほかのソフトがプロキシを経由しないのはなぜですか?
まず、そのソフトがシステムプロキシの設定を参照しているか確認してください。v2rayNの「システムプロキシを自動設定」は、すべてのアプリの通信を取り込む機能ではありません。より広い範囲の通信を取り込む必要がある場合はTUNを検討し、ルーティングルールも確認してください。REALITYの設定を変えても、アプリ側のプロキシ接続方式は変わりません。
トラブルシューティングは、コアが起動するか、サーバーポートに接続できるか、REALITYの認証が通るか、VLESSとフロー制御の設定が一致しているか、アプリの通信がプロキシに届いているか、の順に進めてください。まず失敗しているレイヤーを特定し、該当する設定を変更します。プロトコル、DNS、ルーティングを同時に切り替えるより、通常はこの方法が効果的です。