VMessとVLESSはどちらもユーザーIDを使いますが、認証の仕組みと暗号化の役割は異なります。UUID、alterId、security、flowを取り上げ、ノード編集画面の各項目がプロトコルとトランスポートのどちらに属するかを解説し、v2rayNでの確認手順も紹介します。サブスクリプションを入手し、ノード設定を手動で確認したい方向けの記事です。
VMessとVLESSを比較:プロトコル・トランスポート・セキュリティ層を区別する
ノード名の「VMess + WebSocket + TLS」は、同じ階層に並ぶ3つのプロトコルではありません。VMessはプロキシプロトコルの認証とデータのカプセル化を担い、WebSocketはトランスポート方式、TLSは外側の接続を保護します。VLESSも同じ3つの階層に分けて理解する必要があります。編集画面でプロトコルだけをVMessからVLESSに変更し、ほかの項目をそのままにしても、サーバーに接続できるとは限りません。
以下の表は、一般的なVMess AEADと、従来型のencryption: "none"を使うVLESS設定を対象としています。新しいコアでは項目や機能が拡張されている場合があります。実際の接続では、サーバーから提示された設定一式と、双方のコアが対応している機能を確認してください。
| 比較項目 | VMess | VLESS |
|---|---|---|
| ユーザー認証 | ユーザーIDを使用。通常はUUID形式 | 同じく通常はUUIDを使用するが、通信上の認証手順は異なる |
| alterId | 旧式の設定項目。現在のAEAD設定では通常0 | この項目はない。VMessの設定からコピーしない |
| プロトコル層の暗号化 | securityでデータの暗号化方式を選択できる。例:auto | 一般的な設定はencryption: "none"。外側のTLSまたはREALITYで接続を保護 |
| 時刻に関する要件 | 認証で時刻の許容範囲を使用するため、クライアントとサーバーの時計を同期する | 基本認証ではVMessと同様の時刻許容範囲を使用しないが、証明書やセキュリティ層によっては正確な時刻が必要 |
| 一般的な組み合わせ | TCP、WebSocketなど。TLSとの併用も可能 | TCP + TLS、WebSocket + TLS、TCP + REALITYなど。コアの対応状況による |
| flow | VLESS Visionのflowは設定しない | サーバーで指定され、組み合わせが対応している場合のみ設定。例:xtls-rprx-vision |
要点:プロトコル名だけでノードを変更せず、サーバー指定の組み合わせを使う
まずプロトコル、トランスポート、セキュリティ層を確認し、その後UUIDや任意項目を確認します。VLESSに変えただけで回線が速くなるわけではありません。実際の使用感は、接続先の出口、混雑状況、サーバー負荷にも左右されます。
UUIDとalterId:認証情報は暗号化強度を示すものではない
UUIDは、ユーザーを識別するためによく使われる形式です。例:9d34742b-7f0c-4ca6-9f51-bb35d8a6d127。通常は16進数の文字とハイフンで構成され、標準形式では合計36文字です。サーバーは設定されたユーザー情報を使って接続を識別するため、クライアントには一致するIDを入力します。サーバーアドレスやTLS証明書とは別のものです。
alterIdは、旧来の日本語UIでは「追加ID」と表記されることがあります。初期のVMess認証方式に由来する項目で、「アカウントを追加で作る」機能でも、値を大きくすれば安全性が高まる設定でもありません。現在のVMessでは通常AEADを使用し、0を設定します。新しいバージョンのコアでは、旧式の認証方式が使えない場合もあります。古い解説にある64を見かけたら、汎用的な推奨値と考えず、ノード提供元にサーバーの設定方式を確認してください。
- 新しいVMessノードを入手した場合:サブスクリプションに記載されたIDと認証設定を維持し、AEADが使われているか確認します。
- VLESSノードを入手した場合:指定されたユーザーIDを入力し、
alterIdは追加しません。TLSまたはREALITY関連の項目も確認してください。 - UUIDを自分で生成する場合:サーバーとクライアントの両方を同じ値に変更してください。クライアントだけ変更すると認証に失敗します。
- 他の人に相談する場合:完全なID、サブスクリプションURL、共有リンクは隠してください。これらの情報だけでノードを利用できる可能性があります。
どちらのプロトコルにもUUIDが表示されるからといって、同じUUIDをプロトコル間で共通して使えるとは限りません。サーバーに同じ文字列を設定していても、VMessとVLESSではパケット形式が異なります。対応するインバウンドのポートとプロトコルに接続してください。
暗号化方式の選び方:security、encryption、TLSは別の階層
「VLESSの暗号化がnoneなら、通信内容は平文なの?」という疑問は、接続全体の構成で判断します。従来型のVLESS設定でencryption: "none"とするのは、このプロトコル層でペイロードを追加暗号化しないという意味です。外側でTLSまたはREALITYが正しく設定されていれば、クライアントから該当サーバーまでの接続は暗号化されます。外側にもセキュリティ層がない場合、VLESS自体を機密性のある通信路として扱うことはできません。
VMessのユーザー設定では、security: "auto"、aes-128-gcm、chacha20-poly1305などが指定されることがあります。ここでのsecurityとstreamSettings.securityは別の項目です。前者はVMessのユーザー設定、後者はトランスポートのセキュリティ層を表します。以下は設定項目の位置を示す例であり、そのまま接続できる完全な設定ではありません。
{
"protocol": "vmess",
"settings": {
"vnext": [
{
"address": "example.net",
"port": 443,
"users": [
{
"id": "9d34742b-7f0c-4ca6-9f51-bb35d8a6d127",
"alterId": 0,
"security": "auto"
}
]
}
]
},
"streamSettings": {
"network": "ws",
"security": "tls",
"tlsSettings": {
"serverName": "example.net"
},
"wsSettings": {
"path": "/proxy"
}
}
}
VLESSのユーザー設定では、通常"encryption": "none"と記述します。サーバーがVisionを明示的に使用し、現在のトランスポート構成とコアが対応している場合に限り、"flow": "xtls-rprx-vision"を追加します。一般的なVLESS + WebSocket + TLSノードでは、このflowは通常設定しません。画面に選択肢があるという理由だけで有効にしないでください。
- ノードで指定された外側のセキュリティ方式(TLS、REALITY、または未設定)を確認します。
- TLSでは
serverName、証明書のドメイン名、検証結果を確認します。証明書検証を無効にして解決する方法を常用しないでください。 - REALITYでは、サーバー指定の公開鍵、
shortId、serverName、fingerprintを確認します。各項目は相互に置き換えられません。 - 最後にプロトコル内部の項目を確認します。VMessならsecurity、VLESSならencryptionと任意のflowです。
クライアントとコアの選び方:名称ではなく、ノードの機能に合わせる
v2rayNはデスクトップ用クライアントです。GUIでノード、サブスクリプション、システムプロキシを管理し、実際のプロトコル接続は選択したコアが処理します。Android版のv2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。クライアント名が似ていても、バージョンごとに対応するトランスポート方式や拡張機能が同じとは限りません。
Xrayコアを使う場合
推奨VLESS + REALITYやXTLS Visionを使う場合は、該当機能に対応したXrayのバージョンを選び、クライアントとコアの設定機能を合わせてください。デスクトップではv2rayN、Androidではv2rayNGを利用できます。
適した構成:サーバーからREALITYまたはVisionの設定が明示されたノード
V2Flyコアを使う場合
既存のVMessノードがあり、提供元がV2Fly向けに設定を管理している場合は、対応するバージョンを引き続き利用できます。デスクトップではv2rayNのコア選択を確認し、Androidではv2flyNGを利用できます。Xray独自の拡張項目をそのまま流用しないでください。
適した構成:既存のVMess設定、またはV2Fly向けと明示された環境
安定して使えているVMessサブスクリプションがあるなら、プロトコルを変えるためだけに環境を作り直す必要はありません。同じ提供元からVMessとVLESSの両方が提供されている場合は、サーバーの地域、テスト対象、測定時間帯をそろえて、接続成功率とダウンロード速度を比べてください。出口が異なるノード間の速度差だけでは、プロトコル自体の性能差を証明できません。
2種類のノードを確認する手順
VMess + WebSocket + TLS
- IDと現在のAEAD設定を確認します。alterIdは通常0です。
- サーバーポート、WebSocket path、必要なHostを確認します。
- TLSのserverNameと証明書検証を確認します。
- VLESSのVision flowは追加しないでください。
VLESS + TCP + REALITY
- IDとencryptionの値を確認します。
- サーバー指定の公開鍵、shortId、serverNameを設定します。
- 互換性のあるfingerprintを設定します。
- サーバーがVisionを要求する場合に限り、flowを合わせます。
それぞれの設定を個別に確認します。プロトコルのプルダウンを切り替えるだけでは相互変換できません。
v2rayNでの確認手順:ノードの読み込みからプロキシ経由の通信確認まで
画面を見ながら手入力するのではなく、提供元の完全な共有リンクまたはサブスクリプションを読み込んでください。共有リンクのvmess://とvless://は、それぞれ異なるプロトコルを示します。先頭の文字列を置き換えても、内部のデータ構造は変換されません。サブスクリプションの更新で手動変更が上書きされる場合もあります。切り分ける際は、元の記録とテスト用設定が混ざらないよう、まずノードを複製してください。
- ノードを読み込む:共有リンク全体をコピーし、v2rayNで「サーバー」→「クリップボードからURLを一括インポート」を選びます。メニュー名はバージョンによって異なる場合があるため、現在の画面にある同等のインポート機能を使用してください。
- 主要な設定を確認する:読み込んだノードをダブルクリックし、プロトコル、アドレス、ポート、ユーザーIDを確認します。次に、トランスポートとTLSまたはREALITYの設定を確認してください。VMessでは追加ID、VLESSではflowに注意します。
- 使用するノードを確認する:保存後にアクティブなサーバーとして設定し、コアのログで未対応項目、ポートの競合、起動失敗がないか確認します。
- ローカルの接続先を確認する:「設定」→「パラメーター設定」で実際の待ち受けポートを確認します。たとえば、ローカルSOCKSの接続先は
127.0.0.1:10808の場合がありますが、画面に表示された値を使ってください。他の端末のポートをそのまま使わないでください。 - 新しい通信を開始する:利用方法に応じてシステムプロキシを有効にするか、アプリ側にプロキシを設定し、テストサイトを開きます。既存の接続はノードを切り替えてもすぐに変わらない場合があるため、必要に応じてアプリを終了して再起動してください。
TCPingで疎通を確認できても、宛先ポートへのTCP接続が応答したことしか分かりません。UUID、TLS、flow、プロキシ出口が正しいとは限りません。「ポートには接続できるが、実際の接続に失敗する」場合は、まず認証とハンドシェイクのログを確認してください。コアの接続は正常なのに一部のサイトだけ開けない場合は、DNSとroutingを確認します。UUIDをやみくもに変更しないでください。
よくある質問:設定を変更する前に、問題の発生箇所を見極める
VMessのalterIdを0にしても接続できないのはなぜですか?
0は、現在のAEAD設定で満たす条件のひとつにすぎません。ノード編集画面でID、ポート、トランスポート、path、TLSのserverNameを続けて確認し、システム時刻も同期してください。古いノード情報を使っている場合は、16、32、64を繰り返し試すのではなく、サーバーが旧式の認証方式を使っているか提供元に確認します。
VLESSの暗号化がnoneと表示されます。autoに変更すべきですか?
従来型のVLESSノードでは、提供元が指定したencryptionの値を維持し、VMessのautoを流用しないでください。次に、トランスポートのセキュリティ設定がTLSまたはREALITYかを確認し、関連項目を照合します。プロトコル層のnoneと、接続全体が暗号化されていないことは別の話です。
同じUUIDなら、VMessをそのままVLESSに変更できますか?
クライアントの設定だけを変更しても接続できません。サーバー側にも対応するVLESSインバウンドが必要で、正しいポートとセキュリティ設定が必要です。新しい完全な共有リンクを入手して読み込み、プロトコルを確認してください。元のVMess設定にあるalterIdやsecurityのユーザー項目を残さないでください。
flowの選択肢がある場合、xtls-rprx-visionを選べばよいですか?
まず提供元のノード設定を確認してください。一般的なWebSocket + TLSノードでは空欄のままにします。Visionが明示されたノードに限り指定値を設定し、対応するコアを使用してください。変更後に保存してコアを再読み込みし、新しい通信で動作を確認します。
VLESSに変えたら遅延が大きくなりました。プロトコルが遅いのでしょうか?
まず、出口、測定対象、測定方法が同じか確認します。2つのノードで実際の接続テストを複数回行い、失敗回数と中央値を記録してください。その後、同じリソースを使ってスループットを測定します。TCPingとプロキシ経由の実通信では測定対象の区間が異なるため、結果を直接比較できません。
選択手順は、まずサーバーのプロトコル要件とコアの対応機能を満たし、認証とトランスポートの設定をすべて一致させ、最後に実際の通信結果を比較することです。一般ユーザーにとっては、元のサブスクリプションを追跡できる形で残し、確認済みの項目だけを変更するほうが、どのプロトコルが「新しい」かを覚えるより役立ちます。