VMessはプロトコル層で暗号化と認証を行い、VLESSは暗号化をTLSやRealityなど外部のセキュリティ機構に委ねるため、構造がより軽量です。速度はプロトコル名で判断せず、サブスクリプションで提供され、実測の接続遅延が安定したノードを優先しましょう。プロトコル、通信方式、セキュリティ層、サーバー設定が完全に一致していることも重要です。
1分で結論：違いは主に暗号化の位置
VMessとVLESSはいずれも、クライアントとプロキシサーバー間で使われるプロトコルです。認証方法、データのカプセル化、安全機能をどの層が提供するかを決めます。通信地域や速度テストのランクではありません。ノード名に「香港 VLESS」「香港 VMess」とあっても、サーバー、回線事業者、負荷分散の方針がまったく異なる場合があります。
VMessはプロトコル内部で認証を行い、プロトコル層の暗号化にも対応します。現在のVMess設定では通常AEAD方式を使い、旧来の設定にあるalterIdは実運用から段階的に姿を消しています。VLESSはよりシンプルな設計で、コンテンツ自体の暗号化は担わず、通常はTLSやRealityなどのセキュリティ層と組み合わせます。VLESSノードを確認するときは、「VLESS」というラベルだけでなく、security、通信方式、ドメイン、公鍵、短い識別子などの項目も合わせて確認してください。
設定が完全なVLESSノード
おすすめプロトコルのカプセル化が軽く、TLSやRealityと組み合わせることが一般的です。サーバーとクライアントの項目が一致していれば、日常利用の第一候補に適しています。
適しているケース：サブスクリプションから直接配布され、クライアントのコアが対応し、実測接続テストが安定している
安定稼働しているVMessノード
プロトコル内部に認証と暗号化の機能があり、既存のサブスクリプションや古い構成でも広く使われています。名称が古いという理由だけで、積極的に置き換える必要はありません。
適しているケース：既存ノードが安定し、サーバー側で継続的に保守され、端末との互換性にも問題がない
手作業で組み立てたプロトコルパラメータ
プロトコル名が正しくても、設定が利用できるとは限りません。通信方式、セキュリティ層、ポート、サーバー設定のいずれか1つでも一致しなければ、接続に失敗します。
適しているケース：サーバー設定を正確に把握し、コアのログを確認できる
結論：既存のサブスクリプションではプロトコルを手動変更しない
VMessとVLESSは自由に切り替えられる選択肢ではありません。サブスクリプションで配布されたプロトコルを、元の項目のまま使って接続してください。VMessノードをそのままVLESSに変更しても、同じサーバーの「アップグレード版」にはならず、ハンドシェイクの不一致を招くだけです。
暗号化、オーバーヘッド、サーバー依存を理解する
ユーザーの視点で最も重要なのは、暗号技術の用語ではなく「安全機能がどこにあるか」です。VMessは認証とプロトコル層の暗号化を自身の構造に組み込み、外側にTLSを重ねる場合でも、VMess独自のプロトコル処理が存在します。一方、VLESSはプロトコル内部の処理を減らし、通信内容の秘匿を外部のセキュリティ機構に委ねます。そのため、VLESSをTLSで設定する場合は、証明書、ドメイン、サーバー時刻などの条件に依存します。Realityの場合は、対応する公鍵、短い識別子、サーバー名、フィンガープリントのパラメータにも依存します。
| 比較項目 | VMess | VLESS |
|---|---|---|
| プロトコル層の暗号化 | 認証と暗号化に関する処理を含む | コンテンツの暗号化は行わず、外部のセキュリティ機構に依存 |
| 一般的な認証情報 | UUID、旧設定ではalterIdが使われる場合もある | UUID、一部の組み合わせではflowも使用 |
| 一般的なセキュリティ構成 | 単独でも使用でき、TLSと組み合わせることも多い | TLSまたはRealityと組み合わせることが多い |
| 設定時に注意が必要な項目 | ユーザー識別子、暗号化方式、時刻、通信パラメータ | ユーザー識別子、セキュリティ層、flow、ドメインまたはRealityのパラメータ |
| ユーザーが体感する結果 | 成熟した構成では互換性の範囲が広い | カプセル化はよりシンプルだが、外部設定全体への依存度が高い |
「VLESSはオーバーヘッドが小さい」というのは、プロトコル構造についての説明であり、すべてのVLESSノードがVMessより速いという意味ではありません。ウェブページの読み込み速度は、物理的な距離、回線の混雑、パケットロス、サーバー負荷、TLSハンドシェイク、通信方式、アクセス先の応答速度にも左右されます。同じサーバー、同じ回線、近い通信条件なら、軽量なカプセル化によって処理負荷が一部減る可能性があります。しかし異なるサーバーを比較する場合、この差は通常、回線品質の違いに埋もれます。
サブスクリプションにVMessとVLESSが同時にある場合の選び方
サブスクリプションで2種類のプロトコルが提供されるのは珍しくありません。サービス提供者が同じ地域に複数の入口を用意している場合もあれば、異なるクライアントコア向けに別の構成を残している場合もあります。ノード名は識別しやすくするためのラベルにすぎず、接続結果を決めるのはアドレス、ポート、UUID、通信方式、セキュリティ層、追加パラメータです。どちらも「日本」と表示されているからといって、同じ回線を使っているとは限りません。
選ぶときは、まず利用できないノードを除外し、その後で利用可能なノードを比較します。v2rayNの実測接続遅延は、プロキシプロトコルのハンドシェイクを経てテスト先へアクセスするため、単純なICMP応答より日常の利用条件に近い測定です。1回の結果は一時的な混雑に左右されるため、同じ時間帯に3回続けて測定し、最低値だけでなく安定性を確認しましょう。
- サブスクリプションを更新したら、まず配布された元の項目を保持し、プロトコル、セキュリティ層、通信方式を変更しないでください。
- v2rayNのノード一覧でVMessノードとVLESSノードをそれぞれ選び、実測接続遅延テストを実行します。
- 3回続けて測定します。たとえばVLESSノードが86、91、89ミリ秒、VMessノードが74、210、タイムアウトだった場合、前者は最低値こそ高いものの、安定性では優れています。
- 普段使うウェブページを開くか、実際にダウンロードして、初回表示の応答、継続速度、接続切れを確認します。測定対象は同じものにそろえてください。
- 最終的には用途で選びます。ウェブ閲覧では応答の安定性、大容量ファイルの転送では持続帯域、地域を頻繁に切り替える場合はノード負荷も重視します。
結論：プロトコル名は識別用、判断は実測で
同じサブスクリプション内でノードを比較する場合は、まず3回の実測接続テストにおける成功率と変動を確認し、その後で実際のアクセス結果を見ます。1回だけ低かった遅延を安定性の判断材料にせず、プロトコルの種類を回線品質の順位とみなさないでください。
同じ地域なのにVLESSのほうが遅い理由
プロトコルが占めるのは、完全な通信経路の一部にすぎません。同じ地域のノードでも、異なるデータセンターに置かれていたり、別の入口回線を経由したり、異なる人数のユーザーで共有されていたりします。VLESSノードが異なるネットワークを迂回していたり、サーバー負荷が高かったり、現在のネットワークに合わない通信パラメータを使っていたりすれば、実測遅延はVMessより高くなることがあります。逆に、VMessノードの経路がより直接的なら、より安定した結果になることも十分あります。
- 遅延は高いが安定している：物理的な距離や回線の迂回が原因である可能性が高く、プロトコルを切り替えても改善するとは限りません。
- 遅延が大きく変動する：まず混雑、パケットロス、サーバー負荷を確認します。
- 継続的にタイムアウトする：設定項目、コアの対応状況、セキュリティ層、サーバーの状態を確認します。
- 測定は正常なのにウェブページが開けない：システムプロキシ、ルーティングの振り分け、DNS、ブラウザのプロキシ設定を引き続き確認します。
v2rayNとAndroidクライアントでプロトコルを確認する方法
v2rayNでは、サブスクリプションの更新が完了すると、通常はノード一覧に種類が表示されます。具体的な項目を確認するには、対象サーバーの編集画面を開き、アドレス、ポート、ユーザー識別子、通信方式、セキュリティ設定を確認します。v2rayN 7.xはマイナーバージョンによってメニュー表記が多少異なる場合がありますが、種類を手動で変更してノードを「変換」することはできません。
ローカルの待受ポートとリモートのプロトコルは別の概念です。v2rayNでよく使われるローカルSOCKSポートは10808、HTTPポートは10809です。ブラウザなどのアプリがこれらのローカルポートに接続すると、クライアントコアが選択したノードのVMessまたはVLESSプロトコルを使ってリモートサーバーへアクセスします。ローカルポートを変更しても、VMessがVLESSに変わることはありません。
- ノードを更新： 「サブスクリプショングループ」→「すべてのサブスクリプションを更新（プロキシを使用しない）」を開きます。現在のネットワークで既存ノードが必要な場合は、プロキシ経由で更新する対応操作を選択してください。
- ローカル設定を確認： 「設定」→「パラメータ設定」を開き、ローカル待受ポート、システムプロキシ、コア関連の項目を確認します。
- ノードを確認： サーバー一覧でノードの編集画面を開き、プロトコルの種類、アドレス、ポート、UUID、通信方式、セキュリティ層を確認します。
- 接続を検証： ノードを選択して実測接続遅延テストを実行し、その後システムプロキシを有効にして実際のアクセス先を開きます。
- 失敗した場合： コアのログを開き、タイムアウト、接続拒否、ドメイン名の解決失敗、証明書名の不一致、未対応パラメータなどの情報を優先的に確認します。
サブスクリプションリンクをインポートした後、何を入力する必要がある？
正常なサブスクリプションでは、ノードに必要な項目がまとめて配布されるため、通常は更新、ノード選択、テストだけで利用できます。インポート後にアドレス、ポート、セキュリティパラメータが不足している場合は、まずサブスクリプションを再更新し、内容がブラウザによって改行されたり途中で切り詰められたりしていないか確認してください。手動で項目を補う意味があるのは、サーバー設定とパラメータの出所が明確な場合だけです。
- VMessでは、UUID、暗号化方式、通信方式、Host、パス、TLSの状態を重点的に確認します。
- VLESSでは、UUID、通信方式、security、flow、およびTLSまたはRealityに対応する項目を重点的に確認します。
- WebSocketのパスで大文字と小文字が区別される場合、クライアントとサーバーで完全に一致させる必要があります。
- ドメイン名のノードでTLSを有効にした場合、サーバー名はサーバー側の証明書設定と一致している必要があります。
- ノードは利用可能と表示されるのに特定のウェブサイトだけ開けない場合は、ルーティング規則によって対象が誤って直接接続または遮断用の出口に振り分けられていないか確認します。
よくある問題：エラーから設定を逆算する
プロトコル選択の問題は、「ノードに遅延はあるのに使えない」「同じサブスクリプションでもクライアントによって結果が違う」といった形で現れます。前者はテスト方法が基本的な疎通しか確認していない可能性があり、後者は通常、クライアントコアのバージョン、対応項目、ルーティングモード、DNS設定に関係します。対処時はまず1つのノードと1つのテスト対象に固定し、プロトコル、地域、ネットワークを同時に変更しないでください。
VMessノードのalterIdは大きく変更すべき？
必要ありません。現在のVMess AEAD設定では通常alterId 0を使用します。サブスクリプションで0が配布されている場合はそのままにしてください。古いサーバーに特殊な設定が残っている場合も、サーバー側が指定した数値を厳密に使い、経験則で増やしてはいけません。
VLESSにはプロトコル層の暗号化がないが、使えない？
VLESS自体だけを見て判断してはいけません。ノードにTLSやRealityなどのセキュリティ層が設定されているかを確認し、関連するドメイン、公鍵、短い識別子、サーバー名がそろっていることを確認してください。セキュリティ層が欠けている、または項目が一致しない場合は、推測で補わず設定提供者に確認します。
VLESSの実測接続テストがずっとタイムアウトする場合は？
まずコアのログを確認し、アドレスの名前解決、ポートへの到達性、コアの対応状況、セキュリティ項目の4方向から確認します。Realityノードでは、公鍵、shortId、serverName、fingerprintも確認してください。どれか1つでもサーバー側と一致しなければ、ハンドシェイクに失敗する可能性があります。
VMessをそのままVLESSに変更できる？
できません。2つのプロトコルではサーバー側のインバウンド設定が異なります。サーバーが対応するVLESSインバウンドと完全なパラメータを同時に提供している場合に限り、クライアントで新しいVLESSノードを作成できます。クライアント側の種類だけを変更しても、有効な接続は確立できません。
2つのプロトコルの速度がほぼ同じなら、どちらを残すべき？
3回続けて測定した後、普段使うウェブページとダウンロードで再確認します。成功率、遅延の変動、持続速度が近い場合は、サブスクリプション提供者が現在保守しているノードを優先して残し、もう一方を同じ地域の予備として保持するとよいでしょう。
ログにリモートへの接続タイムアウトが表示される場合は、ネットワーク経路とサーバーの状態を重点的に確認します。接続確立直後に認証失敗で切断される場合は、UUID、プロトコルの種類、サーバー側のユーザー設定を確認します。セキュアなハンドシェイク関連のエラーが出る場合は、ドメイン、システム時刻、TLSまたはRealityのパラメータを確認してください。問題の層によって対処は異なり、ローカルSOCKSポートを何度も変更しても、リモートのハンドシェイク失敗は通常解決しません。
最終判断：プロトコル名より安定した接続を優先
一般ユーザーは、VMessを「プロトコル内部でより多くの認証と暗号化を担うもの」、VLESSを「プロトコルは軽量で、安全機能の大部分を外部の組み合わせで提供するもの」と考えると理解しやすいでしょう。これで、VLESSの設定項目が多く見える理由や、RealityまたはTLSのパラメータが1つ欠けただけで接続できなくなる理由も説明できます。
ノード選びに、環境を無視した固定的な正解はありません。既存のVMessノードが安定して接続でき、用途に十分な速度が出ているなら、プロトコル名だけを理由に変更する必要はありません。サブスクリプションに設定のそろったVLESSノードがあり、現在のクライアントコアが対応しているなら、実測接続遅延と実際のアクセス結果で比較できます。プロトコル構造が機能の範囲を決め、日常的な使用感の大部分は回線とサーバーの状態が左右します。
- すぐに使いたい：サブスクリプションを更新し、元の項目を保持したままテストして、安定したノードを選びます。
- 障害を切り分けたい：プロトコル、通信方式、セキュリティ層、ルーティング、ローカルプロキシの状態を順に確認します。
- 手動設定を行う：まずサーバー側の完全なパラメータを入手し、ノード名から項目を推測しないでください。
- 複数ノードの性能が近い：異なるプロトコルの利用可能なノードを残し、障害時の切り替え先として使います。