VMess・VLESS・Trojan・Shadowsocksの違い｜暗号化方式と用途を比較

1. プロトコル・通信方式・クライアントを区別する

VMess、VLESS、Trojan、Shadowsocksはプロキシプロトコルであり、クライアントの種類ではありません。v2rayNはデスクトップ向けクライアントで、ノードやサブスクリプションの管理、プロキシ設定、コアの起動を行います。Androidでは、v2rayNGがXrayコアを、v2flyNGがv2flyコアを使用します。画面上でノードを追加できても、現在のコアがそのノードのすべての通信方式やセキュリティ設定に対応しているとは限りません。

「どのプロトコルが最適か」を覚えるより、ノードの構成を層ごとに見るほうが役立ちます。サブスクリプションに記載されたプロトコル名は最初の要素にすぎず、アドレス、ポート、通信方式、セキュリティ層、認証情報を一式で合わせる必要があります。特にVLESSノードは、名前が同じだからといって異なるコアでそのまま使えるとは限りません。

• プロキシプロトコル：VMessやTrojanのように、ユーザーの認証、宛先アドレスの指定、プロキシリクエストのカプセル化を定めます。
• 通信方式：TCP、WebSocket、gRPCなど、プロキシのデータをどう送るかを定めます。すべてのプロトコルやコアが、あらゆる組み合わせに対応しているわけではありません。
• セキュリティ層：TLSやXrayのREALITYなどを指します。プロキシプロトコル名とは別の要素です。
• クライアントとコア：クライアントは操作画面を提供し、接続処理はコアが実行します。互換性を調べる際は、両方のバージョンを記録しましょう。

2. 4つのプロトコルの認証方式と暗号化の違い

まず「何が暗号化を担うか」を確認し、そのうえで設定の複雑さを比べます。以下の表は、現在よく使われる構成、すなわちVMess AEAD、encryption=noneを使うVLESS、標準的なTrojan、現代のShadowsocks AEADシリーズを対象としています。古い設定や追加された拡張機能には、プロトコル名だけで同じ結論を当てはめないでください。

VMess：AEADと時刻同期を確認

VMessだからといって、古い設定が必須というわけではありません。現在一般的な構成ではAEADを使い、従来のVMess設定にあるalterIdは通常0にします。接続の問題を解決するために、この値をむやみに増やさないでください。VMessの認証には時刻が関係するため、端末の時刻が大きくずれていると、UUIDが正しくても認証に失敗することがあります。まずOSの自動時刻設定を有効にし、その後にほかの項目を確認しましょう。

VLESS：「none」でも接続全体が平文とは限らない

一般的なVLESS設定のencryption=noneは、この層でペイロードを暗号化しないという意味です。外側のTLSやREALITYまで暗号化されないという意味ではありません。反対に、プロトコル層の暗号化も信頼できるセキュリティ層もない場合、VLESSという名前だけで通信が保護されていると判断してはいけません。別の暗号化拡張を使う場合は、両端の実装とバージョンを個別に確認し、noneモードの判断をそのまま適用しないでください。

TrojanとShadowsocks：パスワード欄は似ていても仕組みは異なる

Trojanの機密性はTLSに依存するため、通常の運用ではサーバー証明書を正しく検証する必要があります。一方、Shadowsocksは選択した暗号化方式でプロキシデータを直接保護し、基本構成ではドメイン証明書を必要としません。従来のAEAD方式とShadowsocks 2022では、必要な鍵が異なります。たとえば2022-blake3-aes-128-gcmには所定の長さの鍵が必要で、任意のパスワードをそのまま設定しても適切な構成にはなりません。

3. TLS・REALITY・WebSocketの組み合わせ方

「VLESS + REALITY」と「VMess + WebSocket + TLS」は、異なる層を組み合わせた構成です。REALITYはXrayが提供するセキュリティ機能で、独立したプロキシプロトコルではありません。WebSocketは通信方式であり、それ自体がTLSの代わりになるわけではありません。一般的なCDNのリバースプロキシでは、対応するHTTP系の通信方式が必要です。任意のTCPノードのアドレスをCDNのドメインに変えるだけで接続できるとは限りません。

ポート番号は待ち受け位置を示すだけです。サーバーが443ポートで動作していても、接続先のサービスと設定が合わない場合があります。別のポートでTLSを使うことも可能です。接続を確認するときはポート番号だけで判断せず、実際の設定とハンドシェイクログを確認しましょう。通常のTLSでは、接続先にIPアドレスを使う場合でも、証明書の検証に使うサーバー名を証明書と一致させる必要があります。

1. 通常のTLS：サーバー名、証明書の有効期限、証明書チェーン、端末の時刻を確認します。「安全でない接続を許可」は、通常の解決策として使わないでください。
2. WebSocket：パスとHostを確認し、リバースプロキシが該当する入口へリクエストを正しく転送しているか確かめます。パスの大文字・小文字や末尾のスラッシュの違いも、照合に影響することがあります。
3. gRPC：サービス名とサーバーのHTTP/2対応を確認します。WebSocketのパス設定をそのまま流用しないでください。
4. REALITY：サーバーが提供する公開鍵、shortId、サーバー名、関連パラメーターを確認します。UUIDが正しくても、これらの項目が自動的に正しくなるわけではありません。

VLESSのflowも、任意に指定できる高速化オプションではありません。サーバーが対応する方式を採用し、クライアントのコアと通信方式の組み合わせもサポートしている場合に限り、xtls-rprx-visionなどを設定します。必要な項目を手作業で組み立てるより、完全なサブスクリプションをインポートするほうが確実な場合が多いものの、配布元が信頼できることは確認してください。

4. 性能の比較で見るべきポイント

回線条件を無視した一律の速度ランキングはありません。同じサーバーでも、入口やリバースプロキシ、速度制限の設定によってプロトコルごとの結果が変わることがあります。地域の異なるノードを比べても、一度のダウンロード結果でプロトコルの優劣は判断できません。暗号化処理、ハンドシェイク、通信のカプセル化、ネットワークのパケットロスなどがボトルネックになる可能性があるため、実際に使う端末と回線で確認しましょう。

• 暗号化処理：AESのハードウェアアクセラレーションはAES-GCMの効率に影響します。端末によってはChaCha20-Poly1305のほうが適しています。アルゴリズム名だけで消費電力や速度を判断することはできません。
• ハンドシェイクの負荷：短時間の接続を頻繁に確立する場合は、通信の往復やTLSハンドシェイクが最初のリクエストに影響します。長時間の転送では、帯域幅、輻輳、パケットロスの影響が大きくなります。
• 追加のカプセル化：WebSocket、gRPC、リバースプロキシは処理段階を増やしますが、既存の構成要件を満たせる場合もあります。経由する段階が少なくても、必ず高速になるとは限りません。
• UDPへの対応：プロトコル、コア、サーバー、端末側のトラフィック処理がすべて対応している必要があります。ゲームや音声通話が使えない場合、Webページを開けることだけを根拠にUDPも正常だと判断しないでください。

再現性のある比較手順

1. できるだけ同じ地域・同じサーバーを使い、帯域制限もそろえます。クライアントとコアのバージョン、プロトコル構成、テスト時刻を記録してください。
2. バックグラウンドのダウンロードを停止し、同じテスト対象を使います。最初に一度ウォームアップし、その後3回測定して、最高値ではなく中央値を記録しましょう。
3. Webページの初回表示、継続的なダウンロード、リアルタイム通信を分けて確認します。クライアントの遅延テストは特定の疎通確認にすぎず、実際の用途全体を測るものではありません。
4. モバイル端末では、バックグラウンド動作の維持とバッテリー消費も確認します。ネットワークを切り替えた後は改めてテストし、無線信号の変化をプロトコルの問題と混同しないでください。

5. 自宅・モバイル回線・複数端末での選び方

ここでの「おすすめ」は、サーバー側の構成が整い、クライアントとサーバーの双方が対応している一般的なXray環境を前提としています。あらゆるネットワークに当てはまる速度ランキングではありません。安定して使えているノードがある場合は、設定一式を維持しましょう。新しい入口を構築する際に、証明書の管理、コアの互換性、端末数を踏まえて選んでください。

家庭用ネットワークでは、夜間の安定性と複数端末での同時接続を重視しましょう。モバイル回線では、ネットワークの切り替え、UDPの到達性、バックグラウンド動作も考慮が必要です。Androidの省電力設定によってプロキシのプロセスが停止することがあり、プロトコルを変えても解決しない場合があります。まず、システムにプロセスを停止されたのか、コアは動作中でも接続がタイムアウトしているのかを切り分けてください。

6. インポート後に接続できない場合の項目別チェック

プロトコルを選んだ後によくある問題は、「プロトコルの性能が悪い」ことではなく、設定の一部しか一致していないことです。元のノードを複製し、一度に変更する項目は一つだけにして、ログの時刻も記録してください。公開の場で相談する際は、サブスクリプションURL、UUID、パスワード、秘密鍵を隠しましょう。ログに実際のノードアドレスが含まれる場合も、必要に応じて伏せてください。

結論は、構成一式で考えることが大切です。プロトコルは認証とカプセル化を定め、セキュリティ層は機密性と相手の認証方法に関わり、通信方式と回線は到達性や使い勝手に影響します。クライアントを選ぶ際はクライアント比較を、DNS・ルーティング・システムプロキシの関係を知りたい場合は使い方ガイドをご覧ください。まず一つの設定を安定して動かし、その後に項目ごとに調整すると、プロトコル、コア、ルーティングを一度に変更するより問題を特定しやすくなります。