VMess、VLESS、Trojan、Shadowsocksを徹底比較：用途別の選び方

まず結論：プロトコル名だけでは選べない

VMess、VLESS、Trojan、Shadowsocksはいずれもプロキシ通信を運べますが、課題への対処方法はそれぞれ異なります。VMessは認証、時刻検証、データ暗号化をプロトコル内部で処理します。VLESSはプロトコル層を軽量化し、機密性を主にTLSやREALITYなど外側のセキュリティ機構に任せます。Trojanは当初からTLS接続を前提に認証とデータ転送を構成します。Shadowsocksは構造のシンプルさ、成熟した実装、低いリソース消費が特長です。

サブスクリプションに4種類のノードが同時に表示されても、プロトコル名だけで速度を判断する必要はありません。実際の使用感は、回線帯域、往復遅延、パケットロス、伝送方式、TLSハンドシェイク、サーバー負荷、クライアントのコアにも左右されます。同じサーバーでは、プロトコル層のオーバーヘッドは通常、全体の所要時間の一部にすぎません。回線自体に180ミリ秒の遅延や継続的なパケットロスがある場合、VMessをVLESSに替えるだけで回線品質が自動的に改善するわけではありません。

実行しやすい出発点が必要なら、まずクライアントのコアで絞り込みます。v2rayNでXrayコアを使う場合は、VLESS、VMess、Trojanノードを優先して確認します。v2rayNGもXrayコアで一般的なプロトコルを処理します。v2flyNGでv2flyコアを使う場合は、現在のコアが実際にサポートするプロトコルと伝送パラメータを基準にしてください。ノードをインポートできても、拡張フィールドがすべて現在のコアで認識されるとは限りません。接続前にログも確認しましょう。

4つの観点で比較：暗号化、オーバーヘッド、伝送、互換性

VMessはユーザー識別子と時刻情報で認証し、プロトコル内部でデータ保護を処理します。システム時刻の影響を受けやすく、端末の時刻ずれが大きいと認証に失敗することがあります。VLESSはUUIDなどでユーザーを識別しますが、完全なコンテンツ暗号化を自身では担いません。そのため、安全な伝送レイヤーを離れてプロトコル名だけを見ることはできません。実際の設定では、security、flow、TLS、REALITYなどの項目も同時に確認します。

TrojanはTLS接続上で認証とデータ転送を行うため、サーバー証明書、ドメインの一致、システム時刻がハンドシェイクに影響します。Shadowsocksは事前共有パスワードと指定した暗号化方式を使います。現在の設定ではAEADまたはShadowsocks 2022系の方式を選び、クライアントとサーバーの暗号化方式名を完全に一致させる必要があります。古い方式が過去の設定に残っていても、新規導入の標準としては推奨できません。

デスクトップ、モバイル、低スペック端末の選び方

デスクトップでの作業では、ブラウザー、同期ツール、メッセンジャーを同時に使うことが多く、接続時間も長くなります。短時間の速度測定より安定性が重要です。サブスクリプションにTLSまたはREALITY対応のVLESSがあり、v2rayNがXrayコアで動作しているなら、まず主接続として試してください。同じ回線上で比較できるよう、VMessまたはTrojanノードも1つ残しておきます。切り替え時にサーバー地域、伝送方式、プロトコルを同時に変えると、どの変更が結果に影響したか判断できません。

Android端末はWi-Fiとモバイル通信を頻繁に切り替えるため、瞬間的な最高速度より、再接続の速さ、消費電力、UDPの利用可否が重要です。v2rayNGは一般的なXrayノードを処理でき、VLESS、VMess、Trojanを含む統合サブスクリプションに適しています。v2flyNGを使う場合は、サブスクリプション内でv2flyコアの機能に合うノードを選んでください。両端で同じサブスクリプションを使えばノード一覧は同期できますが、ルーティング規則、アプリ別プロキシ、ローカルポートはクライアント側の設定であり、自動的に移行されません。

低スペック端末や、多数の小さな接続を同時に処理する環境では、まずShadowsocksを試すとよいでしょう。基本設定は通常、サーバー、ポート、パスワード、暗号化方式だけなので、問題の切り分けが短く済みます。複雑なルーティング、特定のフロー制御、REALITYが必要な場合は、対応するXray構成へ移行してください。項目を減らすために、適合しないプロトコルを無理に使うべきではありません。

1. 作業用のメイン接続：VLESSとTrojanの長時間接続の安定性を優先して比較し、VMessノードを互換性用の予備にする。
2. ネットワークを頻繁に切り替える場合：切り替え後に最初に復旧するまでの時間を記録し、UDPアプリが正常に動作するか確認する。
3. 低スペック端末：まずShadowsocksのCPU使用率と継続的なスループットを測り、より複雑な伝送レイヤーが必要か判断する。
4. 既存のサブスクリプション：安定したVMessノードは、プロトコルが古いという理由だけで急いで置き換えず、回線とサーバーの保守状況を先に評価する。

1回の速度測定ではなく、再現可能なテストを行う

プロトコルをテストするときは、サーバー、出口回線、対象ファイル、時間帯を固定します。実行しやすい基本条件は、クライアントからサーバーまでの往復遅延を約50ミリ秒、アイドル時のパケットロスを1%未満、ローカル接続帯域を100 Mbpsとし、各ノードを3回連続で測定することです。測定前にバックグラウンドの同期タスクも終了させます。以下の数値は記録方法の例であり、異なるネットワークでの固定順位を示すものではありません。

テスト結果には少なくとも、初回接続にかかった時間、継続ダウンロード速度、10分間の再接続回数、UDPの利用可否の4項目を記録します。最高速度は一瞬の状態しか示さず、ネットワーク切り替え時や弱い回線での安定性は分かりません。4種類のノードが同じサーバーにない場合は、結果を「回線を含む総合性能」として記録し、プロトコル自体の性能だと断定しないでください。

簡単なクロスチェックも有効です。まずVLESS、VMess、Trojan、Shadowsocksの順に測定し、次に逆順でもう一度繰り返します。最初に測ったノードがいつも速いなら、バックグラウンドタスク、サーバーの短時間負荷、ネットワーク混雑が変化している可能性があります。正順と逆順の結果が近い場合に限り、平均値を比較するのが適切です。

• 速度差が8%未満：再接続が少なく、ログがきれいなノードを優先する。
• 遅延差が30ミリ秒超：まずサーバー地域と回線を確認し、プロトコルが原因だと決めつけない。
• パケットロスが5%超：先にネットワーク品質を改善し、暗号化方式の微調整は後回しにする。
• UDPだけ失敗する：ノードがUDPに対応しているか、クライアントで転送が有効か、ルーティング規則が遮断していないか確認する。

v2rayNとAndroidクライアントでプロトコルパラメータを確認する

v2rayNでは、まずサーバー一覧の種類欄でノードがVMess、VLESS、Trojan、Shadowsocksのどれかを確認し、対応するサーバー設定を開きます。VLESSではアドレス、ポート、ユーザーID、伝送プロトコル、TLSまたはREALITY、セキュリティ、フロー制御を重点的に確認します。VMessではユーザーID、伝送方式、セキュリティ設定を確認します。Trojanではパスワード、サーバー名、証明書関連の項目を確認します。Shadowsocksではパスワードと暗号化方式を確認します。

ローカルプロキシポートも、ブラウザーやシステム設定と一致させる必要があります。一般的な設定ではSOCKSポートに10808、HTTPポートに10809を使いますが、これらの番号は変更できるため、すべての環境で固定とは限りません。アプリがインターネットに接続できない場合は、「設定」→「パラメータ設定」を開いて現在のローカル待受ポートを確認し、アプリ側のプロキシアドレスと1項目ずつ照合してください。

• VMessの認証に失敗する：まずシステム時刻を同期し、UUIDがサーバー側と一致しているか確認する。
• VLESSでハンドシェイクできない：実際に設定されているsecurity、flow、serverName、publicKey、shortIdなどの項目を確認する。
• TrojanでTLSエラーが表示される：端末の時刻、サーバー名、ポート、証明書のドメインが対応しているか確認する。
• Shadowsocksで接続後に通信がない：クライアントとサーバーが完全に同じ暗号化方式とパスワードを使っているか確認する。
• サブスクリプションのインポート後に種類がおかしい：サブスクリプションを更新し、元のノードで旧コアが拡張パラメータを無視していないか確認する。

Android端末でも確認手順はほぼ同じです。v2rayNGではまずノード編集画面を開いてプロトコル項目を確認し、次に実行ログでDNS、ハンドシェイク、接続エラーを確認します。v2flyNGでは、ノードが現在のv2flyコアの機能範囲に含まれるかも確認してください。同じサブスクリプションがデスクトップでは使えてAndroidでは使えない場合、すぐにサーバー障害と判断せず、両端のコアとノード項目を比較します。

よくある誤解と最終チェックリスト

「VLESSは必ずVMessより速い」というのは、最もよくある単純化された判断です。VLESSはプロトコル層が軽量ですが、実際の接続ではTLS、伝送のカプセル化、ネットワークの往復、サーバー負荷のほうが大きな割合を占めることがあります。別の誤解は、Trojanを通常のWebトラフィックと同一視することです。確かにTLS上で動作しますが、実際のネットワーク上の特徴はハンドシェイクパラメータ、伝送挙動、導入方法にも左右され、プロトコル名だけで絶対的な結論は出せません。

Shadowsocksも、シンプルなWeb閲覧専用という意味ではありません。UDP、同時接続、特定のルーティングに対応できるかは、クライアント、サーバー、設定の組み合わせで決まります。逆に、設定項目が多いからといって接続が自然に安定するわけでもありません。どのプロトコルでも、正しいサーバーパラメータ、利用可能な回線、対応するコアが必要です。

最終的な選択は3段階にまとめられます。第1に、現在のクライアントとコアがノードのフィールドを完全にサポートしているか確認します。第2に、固定した回線で接続、再接続、UDPをテストします。第3に、異なるプロトコルの予備ノードを1つ残します。デスクトップの主力にはXrayコアと組み合わせたVLESSを優先的に評価でき、既存の安定したVMessノードは継続利用できます。TLSの導入条件が整っていればTrojan、低スペック端末やシンプルな接続環境ならShadowsocksを優先して試せます。

プロトコルは一度決めたら永久に固定する設定ではありません。サブスクリプション提供元のサーバー変更、クライアントコアの更新、ネットワーク環境の変化によって、以前の最適な組み合わせが変わることがあります。テスト記録を残し、同じ条件で再測定するほうが、単一のプロトコル名を追い続けるより確実です。