VMessとVLESSはプロキシプロトコルであり、クライアントでも速度のランクでもありません。一般的なVMess設定ではプロトコル層で暗号化されます。一方、VLESSではTLSやREALITYが通信を保護する構成がよく使われます。まずはサブスクリプションの設定をそのまま使い、クライアントのコアが対応していることを確認してから、同じネットワークで実際の接続状況を比べましょう。VMessノードが安定して使えているなら、プロトコル名だけを理由に切り替える必要はありません。
1分でわかる:プロトコル・トランスポート・セキュリティ層
v2rayNでVMess、VLESS、WebSocket、TLSを見かけたら、まずそれぞれを分けて考えましょう。VMessとVLESSは、クライアントとサーバー間のユーザー認証やプロキシリクエストの伝送方法を定めます。WebSocketなどのトランスポートはデータの運び方を決め、TLSやREALITYは接続の保護に関わります。これらは同じ階層の設定ではないため、名前を一つ見ただけで接続全体を判断することはできません。
たとえば「VLESS + WebSocket + TLS」は、3つの層を組み合わせた設定です。VMessノードの編集画面でプロトコルをVLESSに変えただけでは、サーバー側は切り替わりません。サーバーの待ち受けプロトコル、ユーザーID、トランスポート、セキュリティ設定を一致させる必要があります。サブスクリプションに記載された組み合わせを、まずはそのままインポートしましょう。
| 比較項目 | VMess | VLESS |
|---|---|---|
| ユーザー識別 | 通常はUUIDでユーザーを識別 | 通常はUUIDでユーザーを識別 |
| 一般的な暗号化方式 | プロトコル層でペイロードを暗号化し、TLSを重ねることも可能 | 一般的な設定ではTLSまたはREALITYで通信を保護 |
| 時刻の影響 | 認証に時間枠の確認が含まれ、時刻のずれで失敗することがある | 基本的なユーザー認証ではVMessと同じ時刻認証方式を使わないが、ほかのセキュリティ層は時刻の影響を受ける場合がある |
| 設定時の確認項目 | UUID、暗号化方式、トランスポート、セキュリティ層 | UUID、トランスポート、セキュリティ層、サーバーが要求するflowなどの設定 |
| 選ぶ際の基準 | 既存サーバーとの互換性があり、安定して接続できるならそのまま使う | クライアントのコアが対応し、必要なセキュリティ設定がそろっていることを確認して選ぶ |
UUIDは接続用の認証情報であり、暗号化強度を示すものではありません。どちらのプロトコルでも、サブスクリプションURLやノード設定は慎重に管理してください。設定全体のスクリーンショットを公開グループに投稿すると、サーバーアドレスやポート、認証情報まで漏れるおそれがあります。
暗号化の違い:VLESSのnoneとは
VMessはプロトコル層でペイロードを暗号化でき、一般的なアルゴリズムにはAES-128-GCMやChaCha20-Poly1305があります。クライアントの自動選択は、通常、実装や実行環境に応じてアルゴリズムを選ぶ機能です。どの設定でも同じという意味ではなく、外側のTLSを自由に削除してよいという意味でもありません。サブスクリプションを使う場合は、提供元の設定をそのまま使いましょう。
一般的なVLESS設定でencryption: noneとある場合、このプロトコル項目ではVMessのようなペイロード暗号化を行わないことを意味します。接続全体が平文という意味ではありません。外側にTLSまたはREALITYが正しく設定されていれば、クライアントとプロキシサーバー間の通信はそれらによって保護されます。反対に、そのようなセキュリティ層も、ほかの明確な保護手段もない接続を、「VLESS」という名前だけで安全だと判断することはできません。
- TLSが設定されている場合:サーバー名、証明書の検証、トランスポート設定を確認しましょう。ドメイン名や証明書の誤りを隠すために、証明書検証の無効化を常用しないでください。
- REALITYが設定されている場合:サブスクリプションに記載されたサーバー名や公開鍵、shortIdなどをそのまま使い、別のノードの値を流用しないでください。
- Visionが設定されている場合:通常はVLESSのflow設定として指定されます。たとえば
xtls-rprx-visionの場合、クライアント、サーバー、トランスポートのすべてが対応している必要があります。 - ポート443が設定されている場合:確認できるのは接続先ポートだけです。ポート番号だけでTLSが有効だとは判断できません。
時刻認証:VMessで失敗したら、まずシステム時刻を同期
VMessの認証には時刻に関する確認が含まれます。端末の時刻が実際の時刻から大きくずれていると、クライアントとサーバーの認証に失敗することがあります。遅延テストに応答があっても、認証が正常とは限りません。TCP接続の成功とプロキシリクエストの成功は別の段階です。
VLESSなら「時刻を気にしなくてよい」というわけではありません。基本的なVLESSユーザー認証の時刻確認方式はVMessとは異なりますが、TLS証明書の有効期間の判定には正確な時刻が必要です。セキュリティ機能によっては、個別の時刻要件がある場合もあります。PCの長時間スリープ、システム時刻の手動変更、ルーターの時刻未同期などは、トラブルの原因を特定しにくくします。
- Windows 11で「設定」→「時刻と言語」→「日付と時刻」を開きます。
- 「時刻を自動的に設定する」をオンにし、日付が正しいことを確認してから「今すぐ同期」をクリックします。自動同期できない場合は、まずWindows Timeサービスとネットワーク接続を確認してください。
- 同期後、クライアントの接続をやり直し、新しく記録されたコアのログを確認します。同じWebページを何度も再読み込みするだけでは解決しません。
- 複数のVMessノードが同時に失敗し、ほかの接続は正常な場合は、端末の時刻を同期済みであることをサービス提供元に伝え、サーバーの時刻と認証設定を確認してもらいましょう。
タイムゾーンの表示が異なっていても、システムの実時刻が誤っているとは限りません。重要なのは、端末に記録された実際の時刻が正確であることです。「プロトコルに合わせる」ために時計を進めたり遅らせたりしないでください。証明書の検証やほかのプログラムに影響します。
性能の違い:プロトコルより先に回線を比較
VLESSは軽量な設計ですが、すべてのVLESSノードがVMessより速いわけではありません。実際の速度は、サーバーの負荷、帯域幅、ネットワークの往復時間、パケットロス、トランスポート、端末の性能にも左右されます。地域や事業者が異なるノード同士の速度差を、プロトコルだけの違いとして判断することはできません。
VMessの暗号化処理は計算リソースを使いますが、最新端末のハードウェアアクセラレーションや実装方式、外側のカプセル化によって負荷は変わります。低消費電力の端末では影響が出やすい一方、デスクトップPCでは回線が先にボトルネックになることもあります。同じ条件で測定しない限り、一定の速度向上をうたうべきではありません。
- 測定環境をそろえる:同じ端末、同じネットワーク、同じテスト先を使い、帯域幅を消費しているダウンロードは停止します。
- まず接続可否を確認:候補の各ノードでクライアントの実接続テストを行い、実際に対象のWebページを開きます。TCPの応答時間だけでは、リクエスト全体が使えるとは判断できません。
- 3回ずつ測定:近い時間帯に2つのノードを交互にテストし、接続時間、継続的なダウンロード速度、切断の有無を記録します。一度だけ出た最高速度を結論にしないでください。
- 結論を使い分ける:サーバーやトランスポートが異なる場合、「現在のネットワークではこのノードのほうが適している」とはいえますが、特定のプロトコルが必ず速いとはいえません。
結論:安定して使えることを最優先
まず3回のテストで繰り返し接続に失敗したノードを除外し、残ったノードの速度を比較しましょう。どちらも安定していて使用感に差がないなら、プロトコル名だけを理由に設定を変えるより、現在使えている設定を維持するほうが安全です。
サブスクリプションに両方のノードがある場合の選び方
一般ユーザーが最初からサーバー設定を調べる必要はありません。まずクライアントがサブスクリプション内のプロトコル構成を認識できることを確認し、接続をテストしましょう。v2rayNはデスクトップクライアントで、実際に利用できるプロトコルは選択したコアとそのバージョンによって異なります。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。クライアント名、コア名、プロトコル名を混同しないでください。
REALITYや特定のflowを使う場合は、コアの対応状況を特に確認してください。メニューに「VLESS」と表示されていても、サブスクリプション内のすべての拡張設定に対応しているとは限りません。更新後に一部のノードが表示されない場合も、ノードが無効になったのではなく、形式や機能の互換性が原因のことがあります。
必要な設定がそろい、対応コアで使えるノード
おすすめサブスクリプションからそのままインポートし、セキュリティ層を確認してから実際のリクエストで接続をテストしましょう。VMessでもVLESSでもかまいません。重要なのは、目的のサイトに安定してアクセスできることです。
対象:サブスクリプションを初めてインポートし、まず日常的に使える接続を確保したい方。
現在使っているVMessノード
既存の設定に問題がなく、目的のWebサイトに安定してアクセスできるなら、そのまま使い続けましょう。認証に何度も失敗する場合は、まず時刻を同期してサブスクリプションを更新し、次にサーバーの状態を確認してください。
対象:安定した設定をすでに使っており、不要な変更を避けたい方。
VLESS + TLSまたはREALITYのノード
クライアントのコアが該当する構成に対応していることを確認し、UUID、サーバー名、セキュリティ設定、flowを維持してください。不明な項目を削除して無理にインポートしないでください。
対象:提供元から必要な設定一式が案内され、クライアントもその構成に対応している方。
設定手順:デスクトップとAndroidでそれぞれ確認
デスクトップ:v2rayN
- 「サブスクリプショングループ」→「サブスクリプショングループの設定」でサブスクリプションURLを追加し、「サブスクリプションを更新」を実行します。バージョンによって表示名が多少異なる場合があります。
- ノードを選択し、実際に起動しているコアを確認します。接続テストを済ませてから、必要に応じてシステムプロキシを設定してください。
- ローカルの待ち受けアドレスを確認します。
127.0.0.1:10808と表示される場合、これは端末内の接続先であり、サーバーアドレスではありません。
Android:v2rayNG
- 「サブスクリプショングループの設定」を開き、URLを追加して保存してから、サブスクリプションを更新します。
- 同じノードを選択して接続を開始し、AndroidのVPN接続許可を確認します。
- モバイルネットワークとWi-Fiの両方で接続を確認しましょう。デスクトップで使えても、スマートフォンの現在のネットワークで同じように接続できるとは限りません。
同じサブスクリプションから同じ設定を取得できても、両方の端末で接続できるかどうかは、コアの対応状況、ネットワーク環境、サブスクリプションの端末利用制限によって異なります。
よくある質問:接続できないときの確認項目
「サブスクリプションが最新か」「コアが対応しているか」「セキュリティ設定がそろっているか」「通信がクライアントを経由しているか」の順に確認します。一度に変更するのは1項目だけにし、変更前の設定を保存してください。プロトコル、ポート、サーバー名を同時に変えると、ログを比較しにくくなります。
VMessのリンクをそのままVLESSに変更できますか?
リンクのプレフィックスや編集画面のプロトコル名を変えるだけでは使えません。提供元から対応するVLESS設定を入手して、サブスクリプションを更新してください。サーバー側でも、プロトコル、ユーザー認証情報、トランスポート、セキュリティ設定を一致させる必要があります。
VLESSにnoneと表示されます。autoに変更すべきですか?
VMessの暗号化設定をそのまま適用しないでください。まず、そのノードにTLSまたはREALITYが設定されているかを確認し、提供元の説明を参照しましょう。一般的なVLESS設定にあるnoneには明確な意味があり、値を変えるとコアが設定を拒否する場合があります。
VMessが突然すべて接続できなくなりました。まずプロトコルを変更すべきですか?
まずシステムの日付と時刻の設定で時刻を同期し、サブスクリプションを更新して再試行してください。それでも失敗する場合は、ログで認証エラー、接続タイムアウト、証明書エラーを確認します。エラーの種類と発生時刻を提供元に伝え、UUIDとサブスクリプションURL全体は伏せてください。
VLESSでflowがサポートされていないと表示されます。どうすればよいですか?
実際に使われているコアとバージョンを確認し、提供元の要件に合わせて対応するコアへ更新してください。警告を回避するためにxtls-rprx-visionを削除しないでください。現在のクライアントが対応できない場合は、サブスクリプション内で互換性が明記された別のノードを選びましょう。
テストは成功するのに、ブラウザーでWebページが開きません。
まずv2rayNのシステムプロキシが有効か確認し、ブラウザーがシステムプロキシを使用しているかも確認してください。ブラウザーで手動プロキシを設定できる場合は、クライアントに表示されたHTTPまたはSOCKSの待ち受けポートを入力する方法もあります。すべてのアプリが自動的にシステムプロキシを使うわけではありません。必要に応じてTUNや通信の取り込みに関する説明も確認してください。
プロトコルの選択は、接続経路の一要素にすぎません。基本設定を確認するには、まずサブスクリプションのインポート手順をご覧ください。「ノードは正常なのにアプリがプロキシを経由しない」場合は、システムプロキシの説明を確認しましょう。まず設定を一致させ、次に通信経路を確認し、最後に性能を比較してください。