REALITYは安全なハンドシェイクと認証を担い、XTLS Visionは条件を満たすデータ転送を最適化します。両者は同じ機能ではありません。VLESSのサブスクリプションを入手し、設定項目を確認したい方向けに、まず各機能の役割を整理し、flow、サーバー名、公開鍵、shortIdを確認します。最後にログと条件をそろえたテストで原因を見極めましょう。「暗号化が1層減ったから」と速度変化をすぐに結びつけるのは避けてください。
REALITY、VLESS、Visionはそれぞれ何をする？
3つは異なる層で動作し、組み合わせて使えますが、互いに置き換えることはできません。VLESSはプロキシ要求とユーザー情報を扱いますが、ペイロード全般を暗号化する機能はありません。REALITYは安全なハンドシェイクと認証を提供し、VisionはXTLSのフロー制御方式として、TLSトラフィックの識別やパディング、その後の転送経路を最適化します。
一般的なVLESS + REALITY + Visionノードでは、TCP転送が使われます。ブラウザーからの接続はローカルプロキシに渡され、コアがプロキシサーバーへの接続を確立し、サーバーが接続先のWebサイトにアクセスします。ここには「クライアントからプロキシサーバー」と「ブラウザーからWebサイト」という少なくとも2つの異なるセキュリティコンテキストがあり、1回のハンドシェイクとして扱うことはできません。
これらの機能を実際に担うのはクライアント名ではなく、コアです。v2rayNはデスクトップ用の管理画面です。この種のノードを使う場合は、対応機能を備えたXrayコアが選択されていることを確認してください。Android版v2rayNGはXrayコアを使用します。v2flyNGはv2flyコアを使うため、VLESSをインポートできるというだけで、XrayのREALITYとVisionの組み合わせも動作すると判断しないでください。
- プロトコル層：サブスクリプションのVLESSとユーザーIDが、プロキシ要求の構成とユーザー識別を担います。
- セキュリティ層：REALITYでは、サーバーが提供する公開鍵やサーバー名などのパラメーターを使って接続を確立します。
- フロー制御層：
xtls-rprx-visionはクライアントとサーバーの両方が対応している必要があります。 - トランスポート層：一般的な設定ではTCPを使用します。画面や設定資料によってはRAWと表記されることもあるため、使用中のコアの項目に照らして判断してください。
「TLS over TLS」で余分な負荷が発生する理由
すでに暗号化されたHTTPSデータをさらに保護すると、プロキシ側の処理が増えます。ブラウザーからHTTPSサイトにアクセスする場合、アプリケーションデータはサイトとのTLSセッションですでに暗号化されています。従来のTLSプロキシトンネルでは、この暗号文をさらに外側のTLSで包みます。外側の層はWebページの内容を解読する必要はありませんが、レコードのカプセル化、暗号化と復号、バッファリング、データ転送の処理は必要です。
Visionの要点は、Webサイトの暗号化を無効にすることではありません。条件に合う内側のTLSトラフィックを識別した後、以降のデータ転送方式を切り替え、暗号化済みのデータを外側のTLSレコードで包み続けることを避けます。初期段階にはパディングなどの処理もあるため、「接続直後からすべてをそのまま転送する」と単純化することはできません。
| 比較項目 | 通常のTLSトンネル | Visionによる条件付き最適化 |
|---|---|---|
| WebサイトのHTTPS | ブラウザーとWebサイト間のTLSを維持 | ブラウザーとWebサイト間のTLSを維持 |
| プロキシ外側の処理 | 内側のデータを継続してカプセル化 | 識別条件を満たした後に転送経路を切り替え |
| データ転送 | 通常はTLS処理用のバッファーを経由 | プラットフォームによってはspliceなどを利用してコピーをさらに削減 |
| TLS以外のペイロード | トンネルによって保護 | Visionを有効にしても、外側の保護が一律に取り除かれるわけではない |
コピーの削減と暗号化の削減は同じではありません。コアの実装、OS、接続の種類によって、より直接的なデータ経路を利用できるかが変わります。Visionを使えばすべての接続でゼロコピーになるわけではありません。特に、TLS 1.3など条件を満たす内側の接続が、こうした最適化を理解するうえで重要です。すべてのUDP通信、動画、ダウンロードが同じ割合で速くなると考えるのは誤りです。
まずボトルネックを特定し、次にスループットを比較
ダウンロード中にサーバーのCPU使用率がほぼ上限に達している場合、二重暗号化を減らす効果が期待できます。一方、CPUに余裕があり、回線の混雑やパケットロスが目立つ場合は、まずネットワーク経路を確認してください。速度測定のピークを1回比較しただけでは、Visionによる性能向上を証明できません。
REALITYで独自ドメインの証明書が不要な理由
REALITYは、一般的なWebサイトの証明書を設定する方法とは異なる認証方式を使うため、通常、プロキシ接続用に独自ドメインの証明書を取得・更新する必要はありません。サーバーは秘密鍵を保持し、クライアントは対応する公開鍵などのパラメーターで接続を検証します。これは「認証がない」という意味ではなく、サーバー名を適当に入力すれば接続できるという意味でもありません。
サーバー側では接続先サイトと許可するサーバー名も設定します。認証を通過しなかった接続は、REALITYの仕組みに従って設定済みの接続先サイトへ誘導される場合があります。正規のクライアントは所定の認証を完了します。接続先サイトは導入要件を満たす必要があり、一般的な基準にはTLS 1.3とHTTP/2への対応が含まれます。ただし、ブラウザーで開けることだけでは互換性を十分に確認できません。
公開鍵は通常、エンコードされたテキストで表示されます。そのため、「32バイトだから入力欄は32文字だけ」と考えないでください。公開鍵と秘密鍵はペアで生成されます。サーバーの秘密鍵をクライアントにコピーしてはいけません。また、サブスクリプションの値を自分で生成した公開鍵に置き換えると、両者が一致しなくなります。
v2rayNでflow・公開鍵・shortIdを設定する方法
まずサブスクリプションをすべてインポートし、提供元のパラメーターと項目ごとに照合する方法が、手作業で組み立てるより確実です。v2rayNのメイン画面でノードを選び、ダブルクリックして編集画面を開き、VLESSノードのトランスポート、セキュリティ、フロー制御の各項目を確認します。画面のバージョンによって日本語の項目名が異なる場合は、名前ではなく項目の意味で判断し、関係のない設定を変更しないでください。
以下の2つのカードは、同じノードに使う2種類の設定を示したもので、接続可能なサンプルアカウントではありません。ポート443は一般的な例にすぎません。実際のポート、ユーザーID、公開鍵、shortId、サーバー名は、すべて同じサーバー設定から取得してください。
プロトコルとトランスポート
- プロトコル
- VLESS
- 暗号化
- none
- トランスポート
- TCP / RAW（画面の表記に準拠）
- Flow
xtls-rprx-vision
flowはサーバー側の設定と一致させてください。VLESSのnoneは、接続全体に保護がないという意味ではありません。
REALITYのセキュリティ設定
- セキュリティ
- reality
- サーバー名
- サーバー側で許可されたSNI
- 公開鍵
- サーバーの秘密鍵に対応するクライアント用公開鍵
- Short ID
- サーバー側で許可されたshortId
- フィンガープリント
- サブスクリプションの指定値を使用（例：chrome）
各値はセットで使う必要があります。異なるノードから項目を1つずつコピーして、新しい設定を作らないでください。
- flow：一般的な値は
xtls-rprx-visionです。綴りとハイフンを正確に入力してください。古い解説にある別のflow値に置き換えたり、Visionを使わないノードに追加したりしないでください。 - 公開鍵：共有リンクでよく使われるパラメーター名は
pbkです。コアや画面の世代によっては、対応する値の項目名がpublicKeyやpasswordなどの場合もあります。使用中のバージョンの説明を確認し、元の設定に複数の項目をやみくもに入力しないでください。 - shortId：通常は16進数の偶数桁の文字列で、最大16文字です。空欄が使えるのはサーバー側で許可されている場合に限ります。ノードのメモ欄のように自由に入力するものではありません。
- フィンガープリント：
chromeはハンドシェイクのフィンガープリント設定の1つです。該当するブラウザーでアクセスする必要はなく、ブラウザーが自動でインストールされることもありません。
保存後はノードを選び直し、コアに設定を再読み込みさせてください。ノード一覧の内容だけを変更し、実行中のアウトバウンド設定を更新していないと、ログと編集画面の内容が食い違って見えることがあります。Android版v2rayNGではノード編集画面で各項目を確認し、メイン画面のログから起動結果を確認できます。
接続できない場合と速度が変わらない場合の確認方法
まず接続がどの段階で止まっているかを確認し、その後で性能を検討してください。ハンドシェイクが完了していない状態では、Visionのスループットを期待しても意味がありません。一方、Webサイトを正常に開けるなら、速度が上がらないからといって公開鍵の誤りと決めつけるべきではありません。一度に変更する項目は1つに絞り、元に戻せるよう変更前のノード設定を残してください。
- コアが起動できるか確認：まずログに未知の項目、無効なflow、設定の解析失敗などがないか確認します。この段階ではDNSを変更するのではなく、コアの種類と設定形式を確認してください。
- アドレスとポートを確認：実際に接続しているアドレスとポートがサブスクリプションと一致しているか確認します。TCP接続が確立できても、それはネットワーク上の接続先に到達できたことを示すだけで、REALITY認証の成功を意味しません。
- 認証パラメーターを確認：ユーザーID、公開鍵、shortId、SNIを照合し、システムの日付と時刻も確認します。ハンドシェイクエラーにはさまざまな原因があるため、「接続が閉じられた」というログだけで公開鍵の誤りと断定できません。
- アプリがプロキシを経由しているか確認：ブラウザー、ターミナル、その他のアプリで同じ接続経路が使われるとは限りません。まずログに該当する宛先へのリクエストが記録されているか確認し、その後でシステムプロキシやアプリ独自のプロキシ設定を確認してください。
- 最後にルーティングと名前解決を確認：プロキシ接続は成功しているのに特定のドメインにアクセスできない場合は、DNS、ルーティングルール、接続先サイトへの到達性を確認してください。REALITYやVisionが原因とは限りません。
性能を比較する場合は、サーバー、対象ファイル、ネットワーク接続、同時接続数をそろえ、クライアントとサーバーのCPU使用率、継続的なスループット、失敗の有無をそれぞれ記録します。たとえば各条件で60秒のテストを3回実行し、開始直後の瞬間的なピークではなく、安定した中間区間を比較します。これはテスト方法の例であり、本記事で測定した結果ではありません。
手順：対応する設定同士を比較し、flowを消すだけにしない
Visionの有無を比較する場合は、サーバー側でどちらも正常に動作する2種類の設定を用意してください。クライアント側でflowだけを削除すると、双方の設定が一致しなくなるおそれがあります。接続失敗や速度変化が起きても、比較結果としては意味を持ちません。
混同しやすい設定の疑問
多くの誤解は、「機能が使えること」「認証を通過すること」「アプリがプロキシを経由すること」を混同して起きます。以下の項目を確認すると、原因を絞り込みやすくなります。ルーティングをさらに確認したい場合は、サイト内の詳細設定ガイドもご覧ください。
REALITYを有効にしたら「安全でない接続を許可」も有効にする？
REALITYの設定ミスを回避するために「安全でない接続を許可」を使わないでください。通常の検証設定を維持し、ノード編集画面で公開鍵、SNI、shortIdを確認します。この設定を変更しても、鍵の不一致は解消されません。
サブスクリプションをインポートできるのに、flowがサポートされていないと表示されるのはなぜ？
共有リンクを解析できても、実行中のコアがすべての項目に対応しているとは限りません。まず起動ログで実際に使われているコアを確認し、REALITYとVisionへの対応状況を調べてください。クライアントにVLESSのアイコンが表示されているだけで、互換性があると判断しないでください。
Visionを使うと、通常のHTTP通信はプロキシ経路全体を平文で通る？
Visionを有効にしても、すべてのペイロードが直通になるわけではありません。TLS以外の通信にも適切な外側の保護が必要です。ただし、通常のHTTPはプロキシサーバーから接続先サイトまでの区間で平文になる場合があります。アカウント情報や機密情報を扱う場合は、接続先サイトでHTTPSを使用してください。
同じノードでターミナルは接続できないのに、ブラウザーは使える場合は？
まずターミナルにプロキシの接続先が設定されているか確認し、クライアントが実際に待ち受けているポートを指定してテストします。ブラウザーが使えることは、そのリクエスト経路が動作していることを示すだけで、ターミナルもシステムプロキシを参照しているとは限りません。この場合、最初に公開鍵を変更したりflowを切り替えたりしないでください。
既存のWebSocketノードをそのままVisionに変更できる？
クライアントの項目を変更するだけでは使えません。トランスポート方式、サーバー側のインバウンド、flowのすべてが対応している必要があります。元のWebSocket経路を残したままVisionを追加するのではなく、提供元から必要な設定一式を入手してください。
ノードを選ぶときは、まず提供元の設定一式と必要なコアを確認し、次に現在のネットワーク環境に合うかを判断してください。REALITYは独自証明書の導入や更新の手間を減らし、Visionは条件を満たすTLS通信に効率的な転送経路を提供します。どちらも、信頼できるサーバー、安定したネットワーク、正確なクライアント設定の代わりにはなりません。