プロトコル名だけでは、速度や安全性、電池消費は決まりません。まずプロトコル・通信方式・セキュリティ層の違いを整理し、4種類の設定項目を比較したうえで、デスクワーク・通勤中・弱い回線での選び方を紹介します。サブスクリプションを入手済みで、メインのノードを選びたい方に向けた内容です。サーバー設定と実際の接続状況をもとに選べるようになります。
プロトコル・通信方式・セキュリティ層：接続全体を把握する
v2rayNはデスクトップ用クライアントであり、プロトコルではありません。サブスクリプションを管理して設定を生成し、コアを使って接続を実行します。Android向けのv2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。名前が似ていても、対応する設定が同じとは限りません。特にVLESSの拡張機能やREALITYを使う場合は、クライアントに含まれるコアが対応しているか、項目ごとに確認してください。
ノードの設定は通常、3つの層で構成されます。プロキシプロトコルが認証とデータの扱い方を決め、通信方式がデータの運び方を定め、セキュリティ層が接続を暗号化・認証します。たとえば「VLESS + TCP + REALITY」と「VLESS + WebSocket + TLS」は、どちらもVLESSですが、ハンドシェイクの流れ、サーバー側の構成、問題が起きる箇所は異なります。
- プロキシプロトコル：VMess、VLESS、Trojan、Shadowsocks。クライアントとサーバーで、対応する実装を使う必要があります。
- 通信方式：TCP、WebSocketなど。クライアント側だけで自由に変更することはできず、サーバー側の設定と一致させる必要があります。
- 接続のセキュリティ：TLS、REALITY、またはプロトコル自体の暗号化機能です。どのプロトコルにも同じセキュリティ層を追加する必要があるわけではありません。
- ルーティングルール：接続をプロキシ経由にするか、直接接続するか、遮断するかを決めます。ノードのプロトコルとは別の設定です。
4種類のプロトコルを比較：開発の背景・暗号化・設定項目
Shadowsocksは、軽量な暗号化プロキシとして早くから使われ、後にAEADや2022シリーズの方式が登場しました。VMessはV2Rayプロジェクトで開発され、認証とデータ暗号化を組み合わせています。VLESSはよりシンプルな設計で、接続の保護を外部のセキュリティ層に委ねる構成が一般的です。TrojanはTLS接続でプロキシ通信を行うため、証明書の検証とサーバー設定が正しく行われている必要があります。
| プロトコル | 認証・暗号化のポイント | インポート後に確認する項目 | よくある誤解 |
|---|---|---|---|
| VMess | UUIDでユーザーを識別します。最新の設定ではAEAD認証を使い、対応するデータ暗号化方式を選択できます。 | UUID、暗号化オプション、alterId、通信方式、TLS設定。 | 古い設定のゼロ以外のalterIdを、そのまま新しいサーバーに設定する。 |
| VLESS | UUIDで認証します。一般的なencryption=none設定では、ペイロード自体は暗号化されません。通常はTLSまたはREALITYと組み合わせます。 | UUID、flow、セキュリティ層のほか、REALITYで必要となる公開鍵やshortIdなどのパラメーター。 | noneなら接続全体が必ず平文になると思い込む、または逆にセキュリティ層を確認しない。 |
| Trojan | 通常はパスワードで認証し、TLSで接続を保護します。 | パスワード、サーバー名、ポート、証明書の検証設定。 | 「安全でない接続を許可する」を有効にして、証明書エラーを恒常的に回避する。 |
| Shadowsocks | 選択した暗号化方式によって、鍵とデータの保護方法が決まります。方式ごとに鍵の形式要件は異なります。 | 暗号化方式、パスワードまたは鍵、ポート、追加のトランスポートプラグインが必要かどうか。 | 2022方式の鍵を、任意の読み取り可能なパスワードとして入力する。 |
ここでのVLESSの説明は、一般的なencryption=none構成を対象としています。すべてのコアのバージョンや後続の拡張機能が、この形式だけに限られるわけではありません。ShadowsocksのAEADと2022シリーズも、名称を変えるだけで相互接続できるものではありません。クライアントのコア、サーバー実装、鍵の形式を一致させる必要があります。
ポート番号は設定を識別するための情報であり、使用中のプロトコルや接続の安全性を示すものではありません。443番ポートでもTLSを使わないサービスを動かせます。同様に、正しく設定されたTLSサービスが別のポートを使うこともあります。必ずサブスクリプションに記載された設定一式を確認してください。
ハンドシェイクと速度：4種類のプロトコルに一律の順位を付けられない理由
Webページを最初に開く際は、DNS問い合わせ、サーバーへの接続、セキュリティハンドシェイク、プロキシリクエスト、接続先サイトの応答が待ち時間に影響します。WebSocketでは通常、アップグレードリクエストも発生します。中継を経由する構成なら、通信経路も変わります。そのため、「プロトコルヘッダーが短いから初回表示が必ず速い」とは限りません。
継続的なダウンロードでは、また別の要因が影響します。接続確立後は、出口の帯域幅、回線の混雑やパケットロス、サーバー負荷、端末の暗号化性能が重要になることが多くあります。VMessにTLSを重ねると追加の処理が生じる場合はありますが、実効速度が必ずVLESSより遅いとは断定できません。地域やサービス提供元の異なるノードを、1回の速度測定だけで比較しても、プロトコルの優劣は判断できません。
- テスト条件をそろえる：できるだけ同じデータセンター、近い出口、同じ通信方式とセキュリティ層の候補を選びます。条件をそろえられない場合は「ノードの比較」とし、「プロトコルの比較」とは区別してください。
- 2種類の指標を記録する：短時間の接続では初回利用までの時間と失敗回数を、長時間の接続ではダウンロード中の切断の有無と速度の安定性を記録します。
- 候補ごとに3回テストする：同じ接続先と時間帯を使い、候補を交互に試します。数分間の混雑をプロトコルの差と誤認しないためです。
- 最後は実際の用途で判断する：デスクワークではWebサービスへのログインや会議の再接続、通勤中はネットワーク切り替え後の復旧を確認します。一度の最高速度を記録したスクリーンショットだけで判断しないでください。
結論：回線の違いを除いてからプロトコルの負荷を比較する
同じサーバー上の比較可能な設定を用意できない場合は、ノードごとの接続成功率や実際の用途での使いやすさを基準に選んでください。出口の異なる2つの速度測定結果を、VMessやVLESSの差だと決めつけないようにしましょう。
デスクワーク向けのプロトコル選び：動作確認済みの構成を優先
仕事で大切なのは、安定して接続でき、問題の原因を特定しやすいことです。すでに安定したサブスクリプションがあるなら、プロトコル名を変えるために構成を作り直す必要はありません。新規構築でクライアントとサーバーの双方が対応している場合は、適切なセキュリティ層を組み合わせたVLESSを優先的に検討できます。既存のサービスがVMess、Trojan、Shadowsocksに依存しているなら、互換性や保守体制も含めて判断してください。
VLESS + TLS または REALITY
推奨新規構築で優先的に検討できる構成です。ただし、クライアントとサーバーが同じパラメーターに対応していることが前提です。TLSでは証明書を正しく検証してください。REALITYでは公開鍵、サーバー名、shortId、対応するflowを確認し、別のノードの情報を混ぜないようにしましょう。
向いている環境：サーバー設定を確認でき、対応コアを使うデスクワーク
Trojan + TLS
ドメインと証明書の管理体制がすでにある環境では、保守に組み込みやすい構成です。設定項目は通常、パスワードとTLS関連が中心ですが、パスワードが単純だからといって証明書の検証を省略してよいわけではありません。
向いている環境：信頼できるTLSサービスと証明書の保守体制がある環境
VMess
既存のサブスクリプション設定が正しく、クライアントで安定して使えているなら、そのまま利用できます。接続に失敗した場合は、すぐにプロトコルを変えるのではなく、まずシステム時刻、UUID、通信方式を確認してください。
向いている環境：既存のVMessサブスクリプションとの互換性を保ちたい場合
Shadowsocks AEAD または 2022シリーズ
直接運用する場合、比較的設定項目を絞れます。まず両端が同じ暗号化方式に対応しているかを確認し、次に鍵を照合してください。サーバー側でプラグインを使う場合は、クライアントが対応しているかも個別に確認が必要です。
向いている環境：構成が明確で、追加の通信レイヤーを減らしたい場合
v2rayNでは、まず「設定」→「パラメーター設定」でローカルの待ち受けポートを確認し、メイン画面でシステムプロキシの状態を確認できます。バージョンによって項目の分類が異なる場合があるため、実際の画面に合わせてください。システムプロキシの影響を受けるのは、その設定に従うアプリだけです。特定のアプリが直接接続していても、プロトコルが動作していないとは限りません。
通勤中のスマホ利用と弱い回線：再接続・UDP・電池消費を確認
スマホの電池消費をプロトコルだけで順位付けすることはできません。画面の明るさ、モバイル回線の電波状況、バックグラウンドアプリ、ルーティング範囲、接続維持の設定も影響します。電波が弱い場所では、頻繁な再接続によってプロトコルの暗号化処理以上に電池を消費することがあります。そのため、テスト条件を示さずに「VLESSなら何％省電力」といった数値を断定するのは適切ではありません。
弱い回線でも、プロトコルを変えるだけでパケットロスがなくなるわけではありません。4種類のプロトコル名は、4種類の輻輳制御アルゴリズムを意味しません。外側の通信にTCPなど何を使うか、サーバーがUDP転送に対応するか、アプリ自体がどの通信方式を使うかを分けて考える必要があります。Webページが表示できても、音声通話に必要なUDP経路が使えるとは限りません。
接続方法を比較：固定回線とモバイル回線を分けて検証
デスクトップ：v2rayN
- 候補ノードを1つ決め、ログイン、ファイルのアップロード、会議への接続を確認します。
- 同じルーティングルールを維持し、直接接続とプロキシ接続を同じテストに混在させないようにします。
- 各テストで失敗回数を記録し、動作確認済みの予備ノードを1つ残します。
Android：v2rayNG
- Wi-Fiとモバイル回線でそれぞれテストし、ネットワークを切り替えた後の再接続も確認します。
- 必要に応じてアプリごとのプロキシを設定し、不要なバックグラウンド接続を減らします。
- 画面の明るさと利用内容をそろえ、同じ時間使ったときの電池消費をシステムのバッテリー統計で比較します。
一度に変更するのはノードかルーティングのどちらか1項目だけにします。両端で同じサブスクリプションを使えても、コアの互換性とインポート結果はそれぞれ確認してください。
v2flyNGを選ぶ場合は、付属するv2flyコアの実際の対応状況に合わせてノードを選んでください。特に、Xray固有の機能向けに生成された設定を、汎用設定として扱わないようにしましょう。モバイル端末では、安定して再接続でき、必要なアプリが使え、同じ用途での電池消費が許容範囲に収まることが重要です。
インポート後に接続できない場合：問題の層ごとに切り分ける
トラブルシューティングでは、まず「サーバーへの接続失敗」と「ローカルアプリがプロキシを使っていない状態」を区別します。ノードのアドレスとポートに到達できるかを確認し、次に認証・通信方式・セキュリティ層を確認します。最後に、ローカルのシステムプロキシ、DNS、ルーティングを調べてください。ログの接続タイムアウト、認証失敗、証明書エラーはそれぞれ原因が異なります。複数の設定を同時に変更するのは避けましょう。
VMessをインポートできても接続に失敗し続ける場合は？
まずシステム時刻を同期し、UUID、alterId、サーバー側の要件を確認します。現在のAEAD設定では通常alterId=0を使用します。続いてWebSocketのパス、Host、TLSの状態を確認してください。インポートできたということは設定を読み込めたというだけで、サーバー側のパラメーターが一致しているとは限りません。
VLESSノードにUUIDがあるのに認証に失敗するのはなぜ？
UUIDだけでは不十分です。セキュリティ方式がTLSかREALITYかを確認し、flow、サーバー名、公開鍵、shortIdを項目ごとに照合してください。flowを自己判断で別の値に変更せず、サーバー側と一致する設定一式を入手しましょう。
Trojanで証明書エラーが出た場合、検証をそのままスキップしてもいい？
検証のスキップを恒久的な対処にしないでください。まず端末の時刻とサーバー名を確認し、サーバー管理者に証明書の有効期限、証明書チェーン、ドメインとの一致を確認してもらいましょう。IPアドレスで接続する場合も、正しいTLSサーバー名と検証設定が必要です。
Shadowsocksのパスワードが正しいのに接続できないのはなぜ？
暗号化方式とポートも確認してください。2022シリーズでは、指定された長さと形式の鍵が必要です。一般的なパスワードで代用することはできません。Webページは使えるのに通話ができない場合は、サーバーのUDP転送、ファイアウォール、アプリごとのルーティングルールも確認してください。
速度測定では使えるのに、ブラウザーでページが開かないのはなぜ？
v2rayNのメイン画面でシステムプロキシの状態を確認し、「設定」→「パラメーター設定」でローカルポートを確認してください。プロキシを手動設定したアプリでも、同じポートを指定する必要があります。次にDNSとルーティングの適用状況を確認し、まずは接続できているノードのプロトコルを変更しないでください。
最終チェックリスト：プロトコル名を検証可能な条件に置き換える
一般のユーザーにとって実用的な選び方は、クライアントが必要な機能に完全対応していること、サーバー設定が明確であること、実際の用途で安定して使えることを順に確認し、最後に細かな性能差を比べることです。プロトコルが機能の範囲を定める一方、実際の使い心地には回線と構成も大きく影響します。両方を合わせて判断しましょう。
- 使用中のサブスクリプションがある：名称を新しくするためにプロトコルを変更せず、安定したノードを優先してください。
- デスクトップで新規接続する：まず互換性のあるVLESSとセキュリティ層の組み合わせを検討します。既存の証明書やサーバー環境に応じてTrojanを選ぶ方法もあります。
- 通勤中にスマホを使う：ネットワーク切り替え後の復旧と実際の電池消費を比較し、Androidクライアントに含まれるコアがすべての設定に対応しているか確認してください。
- 弱い回線を使う：回線のパケットロス、再接続、アプリに必要なUDP経路を確認し、異なる回線の予備ノードを確保してください。
- サポートを依頼する：クライアントとコアのバージョン、通信方式、機密情報を伏せたログを共有してください。サブスクリプションのURL、UUID、パスワード、秘密鍵は公開しないでください。