VMessとVLESSはプロキシプロトコルであり、クライアント名ではありません。ノードが使えるかどうかは、プロトコルだけでなく、通信方式・セキュリティ層・コアの対応状況をあわせて確認する必要があります。サブスクリプションの導入には慣れていても、暗号化設定やノードの違いがわからない方に向けて、各層の役割、設定の互換性、切り替えを判断するための再現可能なテスト方法を解説します。
1. VMessとVLESSの設計上の違い
VMessは、V2Rayエコシステムで早くから使われてきたプロキシプロトコルです。ユーザー認証、リクエストのカプセル化、任意のデータ暗号化をプロトコル設計に含みます。現在の設定では、過去の解説にある旧式の認証方式ではなく、VMess AEADを確認しましょう。VMess自体は通信方式を指すものではなく、TCPやWebSocketなどと組み合わせられ、さらに外側にTLSを適用することもできます。
VLESSは後から登場した、よりシンプルな基本設計のプロトコルです。認証と転送のカプセル化はプロキシ層で行い、通信の保護は主に外部の仕組みに任せます。従来のVLESS設定では、encryption=noneとし、TLSまたはREALITYを組み合わせるのが一般的です。ここではこの一般的な設定について説明します。新しい暗号化拡張を使う場合は、両方のコアのバージョンと対応フィールドを別途確認してください。従来の設定に関する説明をそのまま当てはめることはできません。
| 比較項目 | VMess | VLESSの一般的な設定 |
|---|---|---|
| 認証とカプセル化 | 現在の構成ではAEAD認証方式を使用 | UUIDでユーザーを識別し、基本的なカプセル化はシンプル |
| データ暗号化 | AES-GCM、ChaCha20-Poly1305などに対応 | 従来の設定ではnoneを指定し、外側のセキュリティ機構で保護 |
| 一般的な組み合わせ | VMess + WebSocket + TLS | VLESS + TLS、またはXray対応のREALITY構成 |
| 主な確認項目 | UUID、セキュリティ設定、時刻、通信パラメーター | UUID、flow、セキュリティ層、通信パラメーター |
つまり、「VMessは古いプロトコルだから使えない」「VLESSは新しい名前だから速い」という判断は適切ではありません。接続できるかどうかは設定が一致しているかで決まり、使い心地はサーバーの負荷、ネットワーク経路、端末側のプロキシ設定にも左右されます。
2. 暗号化の仕組み：none・TLS・REALITYの役割
プロキシ接続は、3つの層に分けて考えるとわかりやすくなります。プロキシプロトコルは認証とリクエストのカプセル化、通信方式はデータの転送、セキュリティ層は接続の保護を担います。VMessとVLESSはプロキシプロトコル、WebSocketは通信方式、TLSはセキュリティ層です。これらを混同して比較すると、実際の問題を見落としかねません。
- VMessのsecurity：VMessのデータ部分に使う暗号化方式を指定します。
autoは通常、実装がプラットフォームの性能に応じて選択します。TLSの有効・無効を切り替える設定ではなく、証明書の検証を代替するものでもありません。 - VLESSのencryption：従来の設定で
noneを指定すると、プロトコル層ではデータを暗号化しません。外側のTLSやREALITYが機能していないという意味ではありません。 - TLS：クライアントでは、正しいサーバー名と信頼できる証明書が必要です。サーバーアドレスにIPアドレスを指定する場合でも、TLSのserverNameには通常、証明書に対応するドメイン名を設定します。
- REALITY：Xrayエコシステムのセキュリティ機構であり、VMessやVLESSの別名ではありません。クライアントが対応実装を備えていることに加え、サーバーから指定された公開鍵関連のパラメーター、serverName、shortIdなどを一致させる必要があります。
- flow：
xtls-rprx-visionなど、特定の構成で使うフロー制御オプションです。汎用的な高速化スイッチではないため、すべてのVLESSノードに設定できるわけではありません。
同様に、VMessにデータ暗号化機能があるからといって、ハンドシェイク情報や通信の特徴まですべて自動的に隠されるわけではありません。TLSが必要か、どの通信方式を使うかは、構成全体に応じて決まります。サブスクリプションを受け取った一般ユーザーは、特定の設定名だけを見て「最適化」するのではなく、サービス提供元のパラメーターをそのまま使いましょう。
3. 通信速度の違い：プロトコルのオーバーヘッドと回線速度は別
VLESSは基本プロトコルの処理を一部簡素化していますが、実際の接続ではTCP接続、TLSハンドシェイク、通信のカプセル化、プロキシ認証などが発生する場合があります。VMess AEADも、過去の旧式認証方式のオーバーヘッドをもとに評価すべきではありません。接続を再利用するか、リバースプロキシを経由するか、サーバーのCPUがハードウェアアクセラレーションに対応しているかなどによっても、結果は変わります。
特に、最初のリクエストが返るまでの時間と、継続的なダウンロード速度は分けて考えましょう。ハンドシェイクの最適化で短時間の接続が速くなっても、大容量ファイルのダウンロード速度が上がるとは限りません。VMessとVLESSのノードを比較しても、設置場所が異なる場合があります。その比較でわかるのは個々のノードの使い心地であり、プロトコル自体の優劣ではありません。
- 条件をそろえる：できるだけ同じサーバー、同じ出口、同じ時間帯を使い、ルーティングとDNSの設定も統一します。条件をそろえられない場合は、ノード同士の比較として記録してください。
- 項目ごとに記録する：接続失敗の回数、最初の応答までの時間、継続的な転送速度をそれぞれ記録します。信頼できる同一のテスト先を使い、クライアント一覧に表示される一度の遅延測定だけで使い心地を判断しないでください。
- 繰り返しテストする：各構成を続けて3回テストし、時間帯を変えて再度確認します。この回数はテスト方法の目安であり、特定のノードでの実測結果ではありません。
- リソースを確認する：帯域に余裕があるのにコアのプロセスが高いCPU使用率を維持する場合は、暗号化アルゴリズム、カプセル化方式、端末の性能を確認します。どちらの設定も夜だけ遅くなる場合は、まず回線の混雑を調べましょう。
判断のポイント：安定したノードを維持し、条件をそろえて比較
現在のVMessノードで安定してアクセスできるなら、プロトコル名だけを理由に切り替える必要はありません。VLESS設定を追加したら、元のノードを上書きせずに単独でテストしましょう。同じ使い方で安定した改善が確認できた場合に限り、デフォルトの接続先を変更します。
4. クライアントの互換性：コアと設定の組み合わせを確認
v2rayNはデスクトップクライアント、v2rayNGはXrayコアを使うAndroidクライアント、v2flyNGはv2flyコアを使うAndroidクライアントです。クライアントの画面では設定を管理してコアを起動しますが、実際に使えるプロトコル機能はコアの実装とバージョンに左右されます。リンクをインポートできても、すべての拡張機能が動作するとは限りません。
設定全体に合わせてコアを選ぶ
おすすめREALITYやVisionなどXray固有の機能を使う場合は、これらのフィールドに対応するXrayコアが実際に選択されているか、まず確認しましょう。デスクトップではv2rayNで使用中のコアを、Androidではv2rayNGの設定と実行ログを確認します。
おすすめのケース：VLESSノードを新しく追加する場合、拡張パラメーターを使う接続
動作確認済みのVMess設定を維持する
VMess + WebSocket + TLSのノードをすでに使っている場合は、v2rayN、v2rayNG、v2flyNGのいずれでも、対応するコアとインポート結果を確認しましょう。VMessと表示されているだけで、Host、パス、セキュリティ設定の確認を省略してはいけません。
おすすめのケース：安定したサブスクリプションを使っていて、設定の一貫性を優先する場合
確認手順：デスクトップとAndroidで実行中の設定を個別に確認
デスクトップ：v2rayN
- ノード一覧から対象ノードを編集し、プロトコル、ポート、通信方式、TLSの設定を確認します。
- 「設定」→「パラメーター設定」でローカルのリスニング設定を確認します。項目名や分類は画面のバージョンによって異なります。
- 起動後、ログに表示される実際のコア名と設定エラーを確認します。ノードの備考欄だけで判断しないでください。
Android：v2rayNG / v2flyNG
- ノードを編集し、元のパラメーターと照らし合わせながらUUID、通信パス、サーバー名を確認します。
- v2rayNGのXray拡張設定を、同じ意味だと決めつけてv2flyNGにそのまま適用しないでください。
- 初回起動時にシステムのVPN許可を確認し、権限の問題とプロトコルの接続失敗を切り分けます。
同じサブスクリプションでも、配布される構成は異なる場合があります。両方のクライアントで更新できても、すべてのノードが同じ条件で使えるとは限りません。
5. インポート後に接続できない場合：設定項目を順に確認
VMessの共有リンクは、vmess://で始まるエンコード済みの文字列、VLESSの共有リンクは、vless://で始まるURIが一般的です。先頭の文字列を置き換えるだけで相互変換することはできません。サーバー側に、該当するプロトコルの受け入れ設定が必要です。アドレスとUUIDが同じでも、別のプロトコルが有効とは限りません。
- まず接続先を確認：サーバーアドレス、サーバーポート、UUIDを確認します。例でサーバーのポートが443の場合、ローカルプロキシ用の10808を誤って入力しないようにしてください。この2つのポートは用途が異なります。
- 次に通信方式を確認：WebSocketのHostとpathは、サーバーまたはリバースプロキシの要件に合わせる必要があります。
/wsと/proxyは別のパスです。経験だけを頼りに置き換えないでください。 - セキュリティ設定を確認：TLSではserverNameと証明書、REALITYではサービス提供元から指定されたパラメーターを確認します。flowを設定する場合は、その構成で本当に必要な値かどうかも確認してください。
- システム時刻を確認：VMess認証は時刻に依存するため、大きなずれがあると接続に失敗する場合があります。システムの日付と時刻を自動設定にしてから再接続してください。セキュリティ設定を無効にして回避しないでください。
- 最後に通信の振り分けを確認：コアは正常に起動しているのにブラウザーがプロキシを経由しない場合は、デスクトップではシステムプロキシ、AndroidではVPNの許可とアプリごとの対象設定を確認します。その後、DNSとルーティングルールを確認してください。
VMessをVLESSに変更したら、接続できなくなったのはなぜ？
まず元のノードに戻し、独立した設定を新しく作成します。VLESSの接続先、UUID、セキュリティ層、通信パラメーターをサービス提供元に確認してください。クライアントでプロトコルの種類を変えても、サーバー側に対応する接続先が自動で追加されるわけではありません。
VLESSの暗号化がnoneと表示されます。変更が必要ですか？
従来のVLESS設定では、通常この値を使います。まずTLSまたはREALITYの設定がサーバー側と一致しているか確認してください。VMessのAES設定を流用してはいけません。サブスクリプションで新しい暗号化拡張を使うと明記されている場合は、両端で必要なバージョンを確認します。
ノードのテストは成功するのに、ウェブページが開かないのはなぜ？
まずログを確認し、テスト接続と実際のウェブリクエストの両方がコアに届いているか調べます。デスクトップではシステムプロキシ、Androidではブラウザーがアプリごとのルールで除外されていないか確認します。その後、ドメイン名の解決と対象ドメインのルーティング先を確認してください。
ログにローカルポートが使用中と表示されます。プロトコルの互換性が原因ですか？
通常は違います。手動設定したローカルのリスニングポートが10808の場合、そのポートを使用している古いプロセスを終了するか、空いているポートに変更してください。そのポートを使うアプリのプロキシ設定もあわせて変更します。これを理由にサーバー側の443など、リモート側の設定を変更しないでください。
6. ノードの選び方：まず互換性を確認し、使い心地を比較
一般的なサブスクリプション利用者にとって、実用的な選び方の順番は、サービス提供元が指定する設定一式、現在のクライアントが対応する構成、自分のネットワークで安定して使えるかどうかです。VMessとVLESSだけで速度が保証されるわけではなく、正しいTLS、REALITY、DNS、ルーティング設定の代わりにもなりません。
- 安定して使えるVMessがある：利用できる基準として維持し、最新の認証設定を使っているか確認します。プロトコル名が新しいという理由だけで無理に変更する必要はありません。
- VLESSを新しく使う：サブスクリプションのパラメーターをすべて維持し、コアの対応を確認してから、ウェブ閲覧、継続的なデータ転送、スリープ復帰後の再接続をテストします。
- 複数の端末で使う：端末ごとに利用可能なノードを確認し、異なるコアに同じ拡張設定を無理に適用しないでください。
- 設定項目について詳しく知りたい場合：プロトコルガイドを参照してください。インポートやシステムプロキシの具体的な手順はチュートリアルで確認できます。
トラブルの記録を保存するときは、プロトコルの組み合わせ、エラーの種類、必要な設定差分だけを記録してください。サブスクリプションURL、UUID、共有リンク全体には認証情報が含まれる場合があります。他の人に相談する前に、これらを削除してください。