VMess と VLESS の違い：一般ユーザーが知っておくべき4つのポイント

認証：同じ UUID でも、VMess は alterId が1つ多い

どちらのプロトコルも UUID でユーザーを識別します。サーバー側は clients 配列に UUID を固定で記述し、クライアント設定の id は1文字まで完全に一致させる必要があり、1文字でも違えば認証に失敗します。この点だけを見れば、VMess と VLESS に違いはありません。

違いは、VMess の初期バージョンにあった alterId フィールドから生じます。UUID から一時的な識別子を派生させ、タイムスタンプと組み合わせてリプレイ攻撃に対抗する仕組みで、旧バージョンの既定値は64でした。その代償として、クライアントとサーバーの時刻差を90秒以内に収める必要があり、システム時計のずれやタイムゾーンをまたぐ利用では接続できないことがよくありました。

2022年1月にリリースされた V2Ray v4.35 で alterId は非推奨となり、v5 ではこのフィールド自体が削除されました。現在 v2rayN 6.x で VMess ノードを新規作成すると alterId は既定で 0 になり、AEAD 認証で動作するためタイムスタンプの検証も行われません。両端とも 0 にしておけば、この違いはほぼ解消されます。

VLESS は設計当初から alterId を持たず、リプレイ対策はトランスポート層に任せ、サーバー側でセッション状態を保持する必要もなく、プロトコルヘッダーも短くなっています。つまり1点目はこうまとめられます。新バージョンでは両者とも同じようにシンプルで、alterId が 0 以外の古いノードに当たったときだけ時刻同期に注意が必要です。

トランスポート層への依存：VLESS は二重暗号化をしない

VMess プロトコルは暗号化層を内蔵しています。TLS を被せなくても VMess の通信自体が暗号化され、設定の security フィールドには auto、aes-128-gcm、chacha20-poly1305、none を指定できます。そのため TCP をそのまま流すことも、TLS に依存しない mKCP などのトランスポートと組み合わせることも可能です。

VLESS は逆で、プロトコル自体は認証と転送のみを行い、1バイトも暗号化しません。設定には "encryption": "none" を固定で記述し、ペイロードは平文のままトランスポート層に渡します。TCP をそのまま流す VLESS は平文通信と同じなので、実際の運用では TLS、XTLS、REALITY のいずれかを必ず被せます。

{
  "outbounds": [{
    "protocol": "vless",
    "settings": {
      "vnext": [{
        "address": "node.example.com",
        "port": 443,
        "users": [{
          "id": "b831381d-6324-4d53-ad4f-8cda48b30811",
          "encryption": "none",
          "flow": "xtls-rprx-vision"
        }]
      }]
    },
    "streamSettings": {
      "network": "tcp",
      "security": "reality"
    }
  }] // VLESS アウトバウンド：暗号化は REALITY トランスポート層に任せる
}

よくある VLESS の構成は次の3種類です。

• VLESS + TCP + TLS：ポート443、最もシンプルな構成、独自ドメインと証明書が必要
• VLESS + XTLS Vision + REALITY：Xray コアが対応、独自ドメインと証明書は不要
• VLESS + WebSocket + TLS：CDN 経由の中継で使用、VMess の同種の組み合わせと同じ構造

REALITY と XTLS Vision は現在 VLESS にしか実装がなく、VMess にはありません。ノード情報に flow: xtls-rprx-vision や security: reality があれば、それは必ず VLESS です。

暗号化のオーバーヘッド：二重と一重の実際の差

違いを CPU 負荷に置き換えると分かりやすくなります。VMess を TLS 経由で使う場合は暗号化・復号が二重で、外側の TLS が1回、プロトコル内蔵の暗号化が1回です。VLESS は外側の TLS 1回だけです。暗号化・復号のたびに CPU サイクルを消費するため、接続数が増えるほど差がはっきり現れます。

この差はどんな機器で体感できるのでしょうか。デスクトップの最新プロセッサではまず計測できません。シングルコアの低スペックサーバー、旧型スマートフォン、ルーターなどでは、VLESS が削減する1層分の負荷が接続数やスループットに表れます。

クライアント互換性：VLESS が使えるかはコアのバージョンで決まる

VLESS が使えるかどうかは、クライアントに内蔵されたコアのバージョンで決まります。v2rayN 6.x は既定で Xray コアを使用し、VMess と VLESS のすべてに対応します。v2rayNG も同じく Xray コアベースです。v2flyNG は v2fly コアを使用し、v4.27 以降で VLESS に対応しますが、REALITY には対応していません。

バージョン番号は越えられない壁です。V2Ray コア v4.26 以前は vless:// リンクを認識せず、サブスクリプションに VLESS ノードが混ざっているとインポートがそのまま失敗します。確認方法は、v2rayN のメイン画面で「設定」→「パラメータ設定」→「Core: 基本設定」を開きます。Xray コアのバージョン番号は 1.x、v2fly コアは 4.x または 5.x です。

共有リンクの接頭辞でも見分けられます。vmess:// の後ろは base64 でエンコードされた JSON、vless:// は URI クエリ文字列の形式で、vless://uuid@アドレス:ポート?パラメータ#備考 のようになります。1つのサブスクリプションに両方のリンクを混在させることができ、クライアントは接頭辞ごとに解析するため、ノード一覧の項目が数行増えるだけです。

どんなときに注意が必要か

4つの比較ポイントを日常利用に当てはめると、プロトコルの違いを本当に気にする必要がある場面は3つだけです。

残り2つの判断はもっと単純です。機器の性能が厳しいときは暗号化・復号が1層少ない VLESS を優先します。CDN 経由の中継が必要な場合や古いクライアントとの互換性が必要な場合は、VMess + WebSocket + TLS のほうが適用範囲が広くなります。

プロトコルはサーバーとクライアントの間の取り決めであり、気軽に切り替えられるスイッチではありません。この4つの違いを押さえておけば、日常のノード利用と接続トラブルの切り分けには十分です。