VMess・VLESS・Trojan・Shadowsocksの選び方｜4つのプロキシプロトコルを比較

プロトコル・トランスポート・セキュリティ層

VMess、VLESS、Trojan、Shadowsocksはプロキシプロトコルの名称です。v2rayNはデスクトップ用クライアントであり、5つ目のプロトコルではありません。クライアントは接続先やサブスクリプション、システムプロキシ、ルーティングを管理し、実際の接続はコアが処理します。Android向けのv2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。画面が似ていても、対応機能が同じとは限りません。

接続先の詳細を確認するときは、3つの層をあわせて見ましょう。プロトコルは認証とプロキシ要求の処理を定め、トランスポートはTCPやWebSocketなどデータの運び方を決めます。セキュリティ層はTLSなどで通信を保護します。REALITYはXrayのセキュリティ機能で、VMessと並ぶプロキシプロトコルではありません。また、どの接続先にも追加できるワンタッチ高速化機能でもありません。

• プロトコル：VMess、VLESS、Trojan、Shadowsocksのいずれかを確認し、サーバー側の設定と一致させます。
• トランスポート：TCPやWebSocketなどの種類を確認します。WebSocketを使う場合は、パスとHostも照合してください。
• セキュリティ：TLS、サーバー名、証明書の検証を確認します。REALITYでは、サーバーから指定された公開鍵などのパラメーターも必要です。
• クライアント設定：システムプロキシやTUNは、どの通信をコアに通すかを決める設定です。接続先のプロトコルを別の種類に変えるものではありません。

4つのプロトコルの背景と暗号化の範囲

VMessはV2Rayプロジェクトから生まれ、ユーザー認証とデータ保護の仕組みを備えています。VLESSは当初、よりシンプルな設計で重複処理を減らすことを目指し、一般的な構成ではTLSやREALITYに通信経路の保護を任せます。TrojanはTLSトンネル上でプロキシ要求を運びます。Shadowsocksは比較的シンプルな暗号化プロキシとして設計されており、具体的な機能は使用する方式と実装によって異なります。

「VLESSは暗号化されない」という説明が当てはまるのは、一般的なencryption: noneのようなプロトコル層の設定に限られます。接続全体が暗号化されているかどうかは、それだけでは判断できません。逆に、TLSを有効にしていても、パラメーターを任意に設定してよいわけではありません。サーバー名、証明書チェーン、サーバー側の設定が一致している必要があります。設定ミスを隠すために証明書の検証を無効にしないでください。

ハンドシェイクの負荷：初回接続と継続通信を分けて考える

ハンドシェイクの負荷は接続確立時の待ち時間に影響しますが、ダウンロード帯域とは別のものです。TCPとTLS 1.3で新規接続する場合、通常はTCP接続に1往復、完全なTLSハンドシェイクにさらに1往復かかります。DNS、プロキシ要求、接続先サーバーへの接続は別途必要です。TLSセッション再開や接続の再利用、ネットワークのパケットロスによって実際の結果は変わるため、往復回数を単純に足してページ表示時間とみなすことはできません。

• VMess：プロトコル認証とペイロード保護の処理が必要です。さらにTLSやWebSocketを重ねる場合は、それぞれの処理負荷と通信オーバーヘッドが加わります。
• VLESS：リクエストヘッダーがシンプルでも、接続全体のハンドシェイクがなくなるわけではありません。TLS、REALITY、トランスポート方式、flowの組み合わせによって接続経路は変わります。
• Trojan：一般的な構成では、まずTLSトンネルを確立してからプロキシ要求を送信します。TLSセッションを再開できるかどうかは、実装と接続条件によります。
• Shadowsocks：一般的なAEADのTCP接続では、TLSハンドシェイクを別途行わずに暗号化した要求データを送信できます。ただし、TCP接続の確立は必要であり、エンドツーエンドの遅延が必ず小さくなるわけではありません。

WebSocketではHTTPアップグレードの処理が加わります。接続を再利用すれば複数の論理接続で下層の接続を共有できますが、輻輳や障害の影響範囲も変わります。そのため、「VMess＋WebSocket＋TLS」と「ShadowsocksのTCP直結」を比べる場合、比較対象はプロトコルヘッダーの大きさだけではなく、接続設定全体です。

モバイル端末のバッテリー消費：プロトコル名より無線通信の起動が重要

信頼できる「最も省電力なプロトコル」の統一ランキングはありません。暗号化にはCPUを使いますが、端末のAESハードウェアアクセラレーション、ChaCha20の実装、通信量によって結果は変わります。モバイル回線では、無線モジュールの頻繁な起動、接続の維持、電波が弱いときの再送、アプリのバックグラウンド同期も、主な電力消費要因になり得ます。

TUNで取り込む通信は、通常、単一アプリのプロキシより広範囲に及びます。DNS要求やUDP、バックグラウンド通信もコアを通る場合があります。そのため、消費電力の変化をすべてVLESSやTrojanのせいにすることはできません。テストでは詳細ログ、頻繁な速度測定、大量の接続先チェックを同時に実行しないでください。追加タスクの消費電力まで測定してしまいます。

1. 端末、ネットワークの種類、画面の明るさを固定し、テスト開始前のバッテリー残量、電波状態、バックグラウンドアプリを記録します。
2. 各回で同じ20分間の操作を行います。たとえば、ブラウジング10分、同じ画質の動画再生5分、画面を消して待機5分です。これはテスト手順の例であり、本サイトによる実測結果ではありません。
3. TUNまたはアプリプロキシの方式、DNS、ルーティングルールを統一します。各回で変更するプロトコル設定は1つだけにし、実際の通信量を記録してください。
4. 候補ごとに3回繰り返し、システムのバッテリー使用量とコアのログで再接続の有無を確認します。バッテリー残量の表示精度を下回る差から、結論を出さないでください。

利用中の接続先とクライアントに合わせた選び方

以下の「おすすめ」は、対応するサーバーパラメーターがそろっており、互換性のあるXrayコアで日常的に接続する場合を対象としています。プロトコルの順位を示すものではありません。サブスクリプションで利用可能なプロトコルが1種類だけなら、検証済みの設定をそのまま使いましょう。名称を変えるために接続全体を組み直す必要はありません。

v2rayNで接続先を選択し、編集画面でプロトコルとトランスポートの設定を確認します。画面上の項目はバージョンによって異なる場合があります。Androidでv2rayNGまたはv2flyNGを使う場合は、まずコアがプロトコル、暗号化方式、セキュリティ拡張に対応しているか確認してください。同じサブスクリプションでも、2種類のコアで必ず同じ動作になるとは限りません。

同じ条件で検証：Tcpingの結果だけで判断しない

Tcpingで主に確認できるのは、指定ポートへのTCP到達性と接続確立までの時間です。UUIDやパスワード、TLSのサーバー名、プロキシ要求が正しいかは検証できず、UDPが使えるかどうかも分かりません。実際の接続テストはプロキシ要求に近い結果を得られますが、接続先、DNS、ルーティング、接続の再利用状況にも左右されます。

1. 接続元を統一：v2rayNでシステムプロキシまたはTUNの状態をそろえ、ローカルの待ち受けポートがアプリ側の設定と一致しているか確認します。たとえばローカルポートを10808に設定した場合、アプリが古いポートを参照していないか確認してください。これは設定例であり、すべてのバージョンのデフォルト値ではありません。
2. ルールの適用先を確認：テスト通信が選択したプロキシ経由のアウトバウンドに流れていることを確認します。ルーティングルールで対象が直接接続に設定されていると、テスト結果からその接続先の性能は判断できません。
3. 項目ごとに測定：初回のリクエスト、連続リクエスト、大容量ファイルの転送、UDPを使うアプリをそれぞれ記録し、異なる結果を1つのスコアにまとめないでください。
4. 交互に再テスト：A、B、A、Bの順に試し、各候補で少なくとも5回リクエストを実行します。中央値と失敗回数を記録し、時間帯によるネットワークの変化を抑えましょう。

プロトコル選びでよくある質問