VMess・VLESS・Trojan・Shadowsocksの違いと用途別選び方ガイド

まず比較項目を統一：プロトコルだけでは接続構成にならない

VMess、VLESS、Trojan、Shadowsocksは、まずプロキシプロトコルを指します。実際の接続には、トランスポート層、暗号化層、ドメイン名前解決、ルーティング規則、クライアントコアも関わります。ノード名に「VLESS」とあるだけでは性能を判断できず、TCP、WebSocket、gRPC、TLS、Realityなどのパラメータが一致しているかも確認が必要です。

同じプロトコルでも、組み合わせる伝送方式によって接続特性と負荷は大きく変わります。たとえばVLESS over TCP with RealityとVLESS over WebSocket with TLSは別の構成です。VMess over TCPとVMess over WebSocketも、「どちらもVMess」という理由だけで同じものとして扱えません。選ぶ前にサーバーが提供している組み合わせを確認し、クライアントが完全に対応しているかを判断しましょう。

4種のプロトコルの違いと適用範囲

VMessはV2Ray系で早くから普及したプロトコルで、ノードでは通常UUID認証を使います。システム時刻の影響を受けやすく、端末の時刻が大きくずれると認証に失敗することがあります。既存のサブスクリプションには現在もVMessノードが多数あるため、旧サーバーや旧設定との互換性を保つ選択肢として有用です。名前だけで標準の第一候補と決めるべきではありません。

VLESSはコンテンツの暗号化をTLSやRealityなど外側のセキュリティ機構に任せ、プロトコルの項目を簡潔にしています。Xrayコアでは、VLESSをTCP、gRPC、WebSocket、TLS、Realityなどと組み合わせて使うことが一般的です。メリットは完全な構成にあり、「暗号化を省くこと」自体にあるわけではありません。信頼できないネットワークで適切な外側の保護なしに通信しても、安全な構成にはなりません。

Trojanは通常TLS上で動作し、パスワードで認証します。設定ではサーバーアドレス、ポート、パスワード、SNIまたはサーバー名を正確に入力し、証明書の検証も適切に扱う必要があります。サブスクリプションでドメイン名が指定されているのに、手動でサーバーIPへ変更するとTLSの名前一致に失敗する場合があります。証明書エラーが出たら、まずシステム時刻、ドメイン、SNIを確認し、長期運用の設定として検証スキップを選ばないようにしましょう。

Shadowsocksは事前共有パスワードとAEAD暗号化方式を使い、設定項目が少ないため、性能に余裕のない端末や構成がシンプルなサーバーに適しています。複雑な偽装機能が自動で備わるわけではなく、実際の通信性能はサーバーの実装、暗号化方式、伝送方法に左右されます。古いノードをインポートする際は、クライアントコアが該当する暗号化方式に対応しているかも確認してください。

プロトコルを選ぶ前の3つの条件

• サーバー対応を最優先: クライアント側でVMessノードをVLESSに変更することはできません。プロトコル、ポート、伝送パラメータは、サーバー側でまとめて提供されている必要があります。
• コアの対応を最優先: v2rayNGはXrayコア使用時、一般的なVLESS、VMess、Trojan、Shadowsocks設定を処理できます。v2flyNGでv2flyコアを使う場合は、実際のコアが対応する最新の拡張パラメータを確認してください。
• 安定性を最優先: 同じ回線で比較する場合、1回だけ測った最高速度より、連続接続の成功率、初回データ到達までの遅延、回線切り替え後の復旧速度のほうが参考になります。

モバイル通信・家庭用回線・旧型端末での選び方

モバイル通信では、基地局の切り替え、ネットワークアドレスの変化、短時間のパケットロス、バックグラウンド制限が主な変動要因です。プロトコル名だけでこれらの問題を解消することはできません。サーバーが明確に提供し、クライアントコアが完全に対応するVLESS構成を優先して試し、Wi-Fiからモバイルデータへ切り替えた後の復旧時間を確認しましょう。切り替え後も長時間通信がない場合は、v2rayNGで接続を停止して再起動し、端末メーカーのバッテリー設定がバックグラウンド通信を制限していないか確認してください。

家庭用回線は安定性を比較しやすい環境です。テストでは同じ端末、同じ接続方法、同じ対象サイトを固定し、夜間の混雑時間帯に接続時間、継続ダウンロード、動画のシーク時の挙動をそれぞれ記録します。VLESSとTrojanが異なるサーバーにある場合、結果は主に回線の違いを示している可能性があり、プロトコルの差に直接結び付けることはできません。

旧型端末では、不要な同時接続、複雑なルーティング、高頻度の速度測定を減らしましょう。サーバー側が提供している場合、Shadowsocksは設定項目が比較的少ない軽量な選択肢になります。すでに安定しているVMessノードも、名前を変えるだけのために移行する必要はありません。性能はCPU使用率、発熱、再接続回数、実効スループットで判断してください。

用途別の結論

1. モバイル通信の主力: サーバーがVLESSと適合する安全な伝送方式を提供している場合は、まずVLESSを試し、回線切り替え後の復旧とバックグラウンド維持を確認します。
2. 家庭用回線の常用: VLESSとTrojanはいずれも安定した選択肢になり得ます。同じ回線、同じ時間帯で少なくとも3回比較してください。
3. 旧型Android端末: 安定性を確認済みのShadowsocksまたはVMessを優先して残し、必要のない同時接続や複雑なルールは有効にしません。
4. 旧サブスクリプションの移行: まず完全にインポートし、プロトコル項目を一括で手作業変更しないでください。新旧ノードの接続を確認してから、無効な設定を1つずつ整理します。

v2rayN、v2rayNG、v2flyNGでパラメータを確認

サブスクリプションをインポートしたら、すぐにノードを変更しないでください。サブスクリプションには、プロトコル、アドレス、ポート、ユーザーID、パスワード、伝送方式、パス、Host、SNI、フィンガープリント、フロー制御などが含まれる場合があります。ノード名に表示された項目を実際の設定だと思って手動変更すると、「同じように見えるのに接続できない」状態になりやすくなります。

v2rayNでは、まず「サブスクリプショングループ」→「すべてのサブスクリプションを更新」を実行し、ノードを選択して設定詳細を確認します。続いて「設定」→「パラメータ設定」を開き、ローカルSOCKSとHTTPの待ち受けポートが他のプログラムに使われていないか確認します。例として10808と10809を使う場合、システム上の他のプロキシツールが同じアドレスとポートを同時に待ち受けることはできません。

v2rayNGでは、右上の追加メニューからクリップボード内のリンクを1件インポートしたり、サブスクリプショングループにサブスクリプションアドレスを追加したりできます。接続前に現在の有効な設定を確認し、接続後はリアルタイムログを開きます。v2flyNGはv2flyコアを使用するため、新しいVLESS拡張設定をインポートする際は、提供元が示すコア要件を確認してください。異なるコアがすべての拡張項目に完全対応しているとは限りません。

確認手順
1. protocol：vmess / vless / trojan / shadowsocks
2. address：サーバーのドメイン名またはアドレス
3. port：サーバーの待ち受けポート（例: 443）
4. credential：UUID、パスワード、またはShadowsocksキー
5. transport：tcp / ws / grpc
6. security：tls / reality / サーバー指定値
7. serverName：TLSまたはRealityで使用するサーバー名
8. path または serviceName：該当する伝送方式で必要な場合のみ入力

接続エラーはログの種類ごとに確認

1. 接続タイムアウト: まずアドレス、ポート、現在のネットワーク、サーバーの状態を確認します。タイムアウトは通常、プロトコルセッションの確立前に発生します。
2. 認証失敗: UUID、パスワード、暗号化方式、端末の時刻を確認します。VMess設定では特に、最初にシステムの自動時刻合わせを有効にしてください。
3. TLSハンドシェイク失敗: ドメイン、SNI、システム時刻、証明書チェーンを確認します。Trojanだけでなく、TLSを使うVLESSやVMessでも発生する可能性があります。
4. 接続できるのに通信がない: システムプロキシ、VPN権限、DNS、ルーティング規則、アプリごとのプロキシ範囲を確認し、すぐにプロトコルを変更しないでください。
5. サブスクリプション更新後にノードが消えた: まず現在のサブスクリプショングループとフィルター条件を確認し、次に配信元が新しいノード一覧を返しているか確認します。

一度きりの最高値ではなく、再現性のあるテストで判断する

プロトコルのテストでは、回線やサーバー負荷の違いをできるだけ排除します。最も確実なのは、同じサーバー、同じ出口帯域、近い設定で比較する方法です。条件がそろわない場合は、「この具体的なノードの結果」として結論を限定し、プロトコル全体の一般論に広げないでください。

初回データ到達までの時間は、単純なネットワーク往復時間よりもブラウジング体験に近い指標です。キャッシュされていないページを3つ連続で開き、リクエスト開始から本文が表示されるまでの時間を記録します。動画や大容量ファイルでは、継続スループットと1分間の速度変動を確認します。モバイル通信では、Wi-Fiとモバイルデータを切り替えるテストも追加してください。

テスト中は他のダウンロードを停止し、DNSとルーティングモードを固定し、各回の開始前に有効なノードを確認します。少なくとも3回実施し、最高値ではなく中央値を使います。3回の結果の差が30%を超える場合は、プロトコルの違いを急いで疑わず、回線混雑、電波の変動、サーバー負荷を優先して確認します。

1. サブスクリプションを更新し、ノードのプロトコル、アドレス、ポート、伝送方式、セキュリティ層を記録する。
2. クライアント、ネットワーク、ルーティングモードを固定し、3回連続で接続して成功回数を記録する。
3. DNS名前解決、初回データ到達、継続ダウンロード、回線切り替え後の復旧状況をそれぞれ記録する。
4. ログに再試行、ハンドシェイク失敗、接続リセット、DNSタイムアウトがないか確認する。
5. 安定して動作するノードを2つ残し、1つをメイン、もう1つを障害時の切り替え用にする。

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

プロトコルに関する問題の多くは、パラメータの不一致、コアの非対応、時刻の誤り、TLS名の誤設定、ローカルルーティングの異常に分類できます。まずエラーの種類から原因を絞り、プロトコルを変更するか判断するほうが、手当たり次第にノードを替えるより効果的です。