3つの名前、実は3種類の「偽装の考え方」
まず VMess について。これは V2Ray プロジェクトが最初に設計した専用プロトコルで、通信の暗号化機能を標準搭載しており、タイムスタンプに基づく認証情報でユーザーの身分を識別します——これがほぼすべての VMess クライアントがシステム時刻の正確さを要求する理由です。デバイスの時刻が90秒を超えてズレると、サーバー側は接続を拒否します。長所は成熟度が高くエコシステムが最も広いことで、ほぼすべての V2Ray 系クライアントがネイティブに対応しています。短所は、プロトコル自体の通信特徴が比較的識別しやすく、通信検査が厳しい環境では後述の2つより検知回避能力が弱いことです。
VLESS は VMess の「軽量版」と考えることができます。プロトコル自体は暗号化を行わず、暗号化を外層の伝送層(例えばTLS)に完全に委ねることで、二重の暗号化オーバーヘッドを減らし、理論上パフォーマンスの損失がより低くなります。特に性能の低いサーバーでその差が顕著に現れます。本当の必殺の組み合わせは Reality です。この仕組みはプロキシ通信を正常な HTTPS サイトへのアクセスに偽装でき、識別可能な特徴がほとんどなく、現在最も検知回避能力が高い組み合わせの一つです。
Trojan になると、考え方はさらにシンプルになります。プロトコル自体はほとんど「特別な処理」を行わず、有効な TLS 証明書と組み合わせることで、通信の特徴が正常な HTTPS サイトへのアクセスとほぼ同じになり、単独で識別することが非常に難しくなります。サーバー側の要件は低く、クライアント側の設定もシンプルで、通常はアドレス、ポート、パスワードの3つの情報だけで接続できます。極限のパフォーマンスより「シンプルで確実」を重視するなら、Trojan は非常に安心できる選択です。
4つの観点、一つの表で違いが分かる
長々と説明しましたが、実際に選ぶ際に見るべきポイントは4つ——暗号化のオーバーヘッド、検知回避能力、設定の複雑さ、そして実際に手元にあるノードがどのプロトコルかということです。表にまとめると分かりやすくなります:
| 観点 | VMess | VLESS | Trojan |
|---|---|---|---|
| 暗号化方式 | プロトコル自体が暗号化を搭載 | 暗号化なし、外層のTLSに依存 | TLSに依存、通常のHTTPSに近い形態 |
| パフォーマンスへの影響 | やや高い(プロトコル内暗号化が一層多い) | 最も低い | VLESSに近い |
| 検知回避能力 | 厳しい通信検査環境では比較的識別されやすい | Reality と組み合わせると最強クラス | 本物のドメイン証明書と組み合わせても同様に強い |
| 設定の複雑さ | v2rayN / v2rayNG / v2flyNG のいずれも「ノードリンクを貼り付ければ自動識別」で、日常の使用感に差はない | ||
まとめると:サービス提供元が複数のプロトコルのノードを選択肢として提供している場合は、まず VLESS + Reality を試してみてください。それがなければ Trojan も良い代替候補です。VMess ノードしかない場合でも、通常の使用には全く問題なく、システム時刻を正確に保つことだけ気をつければ十分です。
プロトコルだけに注目しない:速度はほとんどノード側の問題
ここでよくある誤解を指摘しておきます。多くの人が「プロトコルを変えれば速くなる」と誤解していますが、実際には接続速度と安定性を決める要因はプロトコル自体よりもはるかに多いです——サーバーの帯域が過剰販売されているか、データセンターの回線品質、物理的な距離などは、しばしばプロトコル選択より大きな影響を与えます。プロトコルの本質的な価値は検知回避能力と暗号化効率にあり、通信速度そのものではありません。速度が遅いと感じたら、まずノードとネットワーク環境を確認し、その上でプロトコルを変更すべきか考えましょう。
「3種類のプロトコルを混在させて使っても問題ないか」と悩む必要もありません——これらは互いに干渉しないため、同じクライアント内に VMess、VLESS、Trojan など異なるプロトコルのノードを同時に保存でき、速度テストの結果が良いものをその都度使えばよく、自分をあえて1種類のプロトコルに限定する必要はありません。
最初の疑問に戻りましょう。見慣れないノード情報を受け取ったら、まずそれがどのプロトコルとして表示されているかを確認し、上の表で大まかな予想を立てておけば、残りはクライアントの自動識別に任せて構いません——これは v2rayN、v2rayNG、v2flyNG 3つのクライアント共通の設計思想で、手動でプロトコルの種類を選ぶ必要はありません。