VMess、VLESS、Trojan、Shadowsocksは、単なる速度のランクではなく、認証・暗号化・転送の仕組みが異なるプロトコルです。既存のサブスクリプションを使う場合は、まずサーバー設定とクライアントのコアを確認しましょう。新たに接続を構成する場合は、通信方式と端末の性能を踏まえて選びます。ここではプロトコル、TLS、通信方式を分けて説明し、デスクトップとAndroidでの確認手順も紹介します。
プロトコル・通信方式・コアの違いを理解する
ノード名の「VLESS + WebSocket + TLS」には、3つの要素が含まれています。VLESSは認証とリクエストの処理を担うプロキシプロトコル、WebSocketはデータを運ぶ通信方式、TLSはこの組み合わせに暗号化された通信経路とサーバー認証を提供します。「VLESS」だけを覚えてほかの要素を見落とすと、通常は接続設定を正しく再現できません。
v2rayNはデスクトップ向けクライアントです。設定のインポートやノードの選択、システムプロキシの設定は画面上で行い、実際の接続はコアが処理します。Androidでは、v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。クライアントが共有リンクを読み込めても、現在のコアがリンク内の拡張パラメーターすべてに対応しているとは限りません。
- プロトコル：VMess、VLESS、Trojan、Shadowsocksのどれを使うかを確認します。認証情報とプロトコルの処理方法が決まります。
- 通信方式：TCP、WebSocket、gRPCなどを確認します。クライアントとサーバーの設定を一致させる必要があります。
- セキュリティ層：TLSやREALITYなどの設定を確認します。REALITYは独立した第5のプロキシプロトコルではありません。
- ルーティング：通信を直接接続、プロキシ経由、または遮断のどれにするかを決めます。ノードのプロトコルとは別の設定です。
4種類のプロトコルにおける暗号化と認証の違い
比較するときは、まず「どの層が暗号化を担うか」、次に「サーバーがユーザーをどう識別するか」を確認します。UUIDやパスワードは認証情報であり、安全な接続に必要な設定すべてを意味するものではありません。ポートを443にしても、TLSを有効にしていない接続がTLSで保護されるわけではありません。
| プロトコル | 認証・暗号化 | よくある組み合わせ | 確認する項目 |
|---|---|---|---|
| VMess | UUIDでユーザーを識別します。プロトコル独自のデータ暗号化に対応し、最新の構成ではAEAD認証方式を使用します。 | TCP、またはWebSocket + TLSなど。 | UUID、暗号化オプション、通信方式、端末のシステム時刻。 |
| VLESS | UUIDで認証します。一般的な構成ではプロトコル独自のデータ暗号化を行わず、TLSやREALITYなどで接続を保護します。 | WebSocket + TLS、または対応機能を備えたXrayの構成におけるTCP + REALITY。 | セキュリティ層、サーバー名、通信方式の設定、flow、REALITY関連のパラメーター。 |
| Trojan | パスワードで認証します。一般的な標準構成では、暗号化とサーバー認証にTLSを使用します。 | 通常はTCP + TLSを使用します。ほかの通信方式は実装によって異なります。 | パスワード、証明書の有効性、サーバー名、通信方式への対応状況。 |
| Shadowsocks | 指定された暗号化方式と鍵情報を使用します。従来のAEADとShadowsocks 2022では、形式や要件が異なります。 | TCP・UDPの通信を直接転送します。追加のカプセル化にはクライアントとサーバー双方の対応が必要です。 | method、パスワードまたは鍵の形式、UDPへの対応状況。 |
VMessのAEAD認証と、Shadowsocksで使われるAEAD暗号化方式は、同じ設定項目ではありません。古い解説にあるVMessのalterIdをそのまま設定するのも避けてください。最新のVMess AEAD構成では通常0を指定しますが、既存ノードではサーバー側の指定を優先してください。
Shadowsocksも、「パスワードが正しい」だけでは設定がそろっているとは限りません。たとえばaes-128-gcmと2022-blake3-aes-128-gcmは別の暗号化方式で、後者には専用の鍵形式要件もあります。暗号化方式を別のものに変更しても、サーバー側の設定が自動で切り替わることはありません。
名前の順位ではなく、利用条件に合わせて選ぶ
以下は、サーバーの構成を選べる場合を想定した目安です。サービス提供者が特定のプロトコルしか用意していない場合は、クライアント側で別のプロトコルに無理に変更せず、まず現在の端末で完全に動作するか確認してください。回線、設定、端末の条件を問わずに決まる速度順位はありません。
VLESS：新しい構成では対応状況を確認
おすすめサーバーがTLSまたはREALITYの設定一式を明示し、クライアントのコアが該当する組み合わせに対応している場合は、新規構成の有力候補になります。おすすめする理由は構成条件が合うためであり、あらゆるネットワークで速いという意味ではありません。
適しているケース：コアの対応状況を確認でき、指定された通信方式とセキュリティ層を使う新規接続。
VMess：実績のある構成を継続
既存のVMessサブスクリプションが安定して使えているなら、プロトコル名が古いという理由だけで変更する必要はありません。最新の認証設定を使用し、システム時刻を正確に保ち、サーバーの通信方式と一致しているか確認しましょう。
適しているケース：利用中のサブスクリプションがある方、またはサーバーがVMessを中心に構成されている方。
Trojan：既存のTLS構成を活用
サーバーに有効な証明書と明確なサーバー名が設定され、Trojanに対応している場合は、既存のTLS環境に合わせて構成できます。「TLSを使う」からといって、証明書の検証を省略してよいわけではありません。
適しているケース：サーバーがTrojanの設定一式を提供しており、既存のTLS構成を使いたい方。
Shadowsocks：暗号化方式を一致させる
設定項目が比較的シンプルで、サーバーがmethodと鍵を明示している接続に向いています。従来のAEADと2022方式のどちらを選ぶかは、クライアントとサーバー双方の対応状況で判断してください。クライアントにShadowsocksの項目が表示されるだけでは不十分です。
適しているケース：Shadowsocksサーバーを利用中の方、または端末上で暗号化方式ごとの負荷を比較したい方。
普段使い・モバイル回線・旧型端末での選び方
普段のウェブ閲覧では、回線の往復遅延、DNSの名前解決、サーバー負荷の影響を受けやすくなります。プロトコルを切り替える際に接続先の地域やサービス提供者も変えると、違いがどの要因によるものか判断できません。比較するときは、サーバー、テスト対象、ネットワーク環境をできるだけそろえましょう。
- 普段のウェブ閲覧：まずHTTPSページが継続して読み込めるか、画像も表示されるかを確認してから、大容量ファイルのダウンロードを試します。遅延テストが一度成功しても、ブラウザーのすべての通信が正常とは限りません。
- モバイル回線：Wi-Fiからモバイル回線に切り替えると、既存の接続を再確立する必要がある場合があります。まずトンネルが復旧しているか、次にDNSとUDPを確認しましょう。再接続が起きるたびに、プロトコルがモバイル端末に合わないと判断する必要はありません。
- 旧型端末：実際の負荷は、CPUの暗号化アクセラレーション、コアの実装、追加のカプセル化によって異なります。Shadowsocksが必ず最も省電力とも、VLESSの「軽量」という名前が必ず最小の負荷につながるとも言い切れません。
- 音声通話・ゲーム：UDP転送には、クライアント側の入口、プロキシプロトコルの実装、サーバー、ルーティングがすべて対応している必要があります。ウェブは使えるのに通話できない場合は、UDP経路を個別に確認してください。
クライアントで設定を確認する4つの手順
デスクトップでは、まずv2rayNで設定一式が正しく動作することを確認してから、ルーティングやアプリの通信をプロキシに通す設定を行います。以下は一般的な日本語版デスクトップ画面のメニュー例です。バージョンによって表記が異なる場合は、メニュー名ではなく機能を目安にしてください。目的の項目が見つからなくても、関係のない設定を変更する必要はありません。
-
共有リンクを省略せずにインポート
サービス提供者から受け取った共有リンク全体をコピーし、v2rayNのメイン画面でCtrl + Vを押してインポートします。サブスクリプションURLを単一ノードのリンクと取り違えたり、ノードリンクを分割して貼り付けたりしないでください。
-
ノードの設定項目を確認
ノードをダブルクリックして編集画面を開き、アドレス、ポート、ユーザーIDまたはパスワード、通信方式、TLS設定の順に確認します。WebSocketではパスとHost、REALITYではサーバー指定の公開鍵、shortId、サーバー名、flowを確認してください。
-
接続を開始してログを確認
対象のノードをアクティブサーバーに設定し、メイン画面のログ欄でコアが起動するか確認します。「サポートされていない通信方式」や設定の解析エラーが出た場合は、ローカルの待ち受けポートを何度も変更する前に、コアの互換性を確認してください。
-
アプリの通信をプロキシ経由にする
タスクトレイのアイコンを右クリックし、「システムプロキシ」→「システムプロキシを自動設定」を選んでから、ブラウザーで接続を確認します。ローカルの待ち受け設定を確認するには、「設定」→「パラメーター設定」で実際のポートを確認してください。プロキシを手動設定するアプリには、一致するアドレスとポートを入力します。
Androidでは、まず使用するコアの違いを確認してください。v2rayNGのXray機能とv2flyNGのv2fly機能を同じものとして扱うことはできません。特にVLESSの一部の拡張機能、セキュリティ層、flowは、アプリに含まれる現在のコアが対応しているか確認が必要です。インポート後は実際に接続を開始してください。ノードが一覧に表示されただけでは、リンクの解析が完了したにすぎません。
ポート・ドメイン・セキュリティ設定を混同しない
リモートポートはサーバーが接続を受け付けるポート、ローカルポートはアプリがクライアントに接続するポートです。以下の3つの数字は設定例であり、4種類のプロトコルに必須のポートでも、v2rayN共通のデフォルト値でもありません。
たとえば、クライアントが実際にそのアドレスでSOCKSサービスを提供している場合、ブラウザーのプロキシに127.0.0.1:1080を手動で指定できます。リモートノードの設定がexample.com:443でも、ブラウザー側のプロキシポートを443に変更するわけではありません。ここでのexample.comは項目の関係を示すための例です。
- サーバーアドレスとサーバー名：前者は接続先の指定に使い、後者は通常TLSのSNIや証明書の検証に使います。異なる値でも構いませんが、サーバーの構成に合っている必要があります。
- WebSocketのHostとパス：通信方式の設定項目です。UUIDとは異なり、別のノードの値をそのまま流用しないでください。
- 安全でない接続を許可：証明書の検証をスキップする設定を、通常の対処法として使わないでください。まずシステム時刻、証明書のドメインと有効期限、サーバーの証明書チェーンを確認します。
- REALITYのパラメーター：サーバーから提供された一式を使用してください。通常のTLSノードの設定項目をREALITYノードにそのままコピーしてはいけません。
プロトコル選びでよくある質問
サブスクリプションにVMessしかありません。VLESSに変更すべきですか？
プロトコル名を変えるだけなら必要ありません。まず現在のノードで接続し、通信できるか確認してください。サービス提供者がVLESSのリンクも提供している場合は、別のノードとしてインポートして比較できます。編集画面でプロトコルの種類を変更しても、サーバー側の設定は切り替わりません。
VLESSをインポートできましたが、接続開始時にエラーが出るのはなぜですか？
まずログに表示された最初の設定エラーを確認し、通信方式、セキュリティ層、flowを照合してください。Androidではv2rayNGとv2flyNGのどちらを使っているか確認し、対応するコアが必要な機能をサポートしているか調べます。リンクがvless://で始まるだけで、すべての設定項目が動作すると判断しないでください。
Trojanで証明書エラーが出ます。検証を無効にしてもよいですか？
まず端末の時刻を正確に合わせ、ノードのサーバー名が証明書の対象ドメインと一致しているか確認してください。証明書の期限切れや証明書チェーンの不備は、サーバー側で修正する必要があります。検証を無効にするとサーバーの本人確認が弱くなるため、長期的な対処法には適しません。
ウェブページは開けるのに、音声通話がつながりません。
まずアプリの通信がプロキシを通っているか確認し、次に設定のUDP対応とサーバーのファイアウォールを調べます。システムのHTTPプロキシでは、あらゆるアプリのUDP通信を処理できるとは限りません。必要に応じて、クライアントが実際に提供するTUNまたはシステムトンネル機能を使い、ルーティングルールも再確認してください。
プロトコルを変えてもタイムアウトします。次はどこを確認すればよいですか？
ローカルの待ち受け、アプリのプロキシ設定、コアのログ、リモートアドレス、サーバーへの到達性の順に確認します。まずリクエストがクライアントに届いていることを確かめてから、ハンドシェイクが失敗しているか判断してください。接続がクライアントに届いていない場合、UUIDや暗号化方式を変更しても通常は解決しません。
選択のポイントは3つです。サーバーがどの設定一式を提供しているか、端末のコアがその設定を実行できるか、実際のネットワークで安定するかを確認します。使用中のノードは残し、新しい構成は別にインポートして比較しましょう。プロトコルが合ったら、システムプロキシ、DNS、ルーティングを設定すると、問題を切り分けやすくなります。