すでにサブスクリプションを利用している場合は、必要なパラメーターがそろい、クライアントとサーバーの両方のコアが対応するノードを優先しましょう。サーバーを自分で設定する場合は、認証方式やセキュリティ層、トランスポートの組み合わせも比較します。この記事では、プロトコルとコアの関係を整理し、4種類の実用上の違いを比較したうえで、デスクトップとAndroidでの確認手順を紹介します。VMessを使い続ける場合、VLESS + REALITYを選ぶ場合、TrojanやShadowsocksが適する条件がわかります。
プロトコル・トランスポート・セキュリティ層・クライアントの違い
ノード名の「VLESS + TCP + REALITY」は、同じ種類の設定を3つ並べたものではありません。VLESSはプロキシのリクエストとユーザー認証を担当し、TCPは下位のトランスポート、REALITYは接続時のセキュアなハンドシェイクや認証関連の仕組みを担います。これらの層を混同すると、「VLESSを選んだのに接続できない」「ポートを443に変えればTLSが有効になる」といった誤解につながります。
v2rayN、v2rayNG、v2flyNGはGUIクライアントであり、4種類のプロトコルの別名ではありません。v2rayNで利用できる機能は、選択したコアとそのバージョンによって異なります。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。画面に項目が表示されていても、古いコアがその組み合わせに対応しているとは限りません。サブスクリプションをインポートできても、すべてのパラメーターが正しく引き継がれるとは限りません。
- プロキシプロトコル：VMess、VLESS、Trojan、Shadowsocks。リクエスト形式と認証方式を定めます。
- トランスポート：TCP、WebSocket、gRPCなど。通信経路でプロキシデータをどう運ぶかを定めます。対応状況は実装によって異なります。
- セキュリティ機構：TLS、REALITY、またはプロトコル自体の暗号化です。ノード名だけで判断しないでください。
- 接続方式とルーティング：システムプロキシ、TUN、ルールによって、どのアプリや宛先をノード経由にするかを決めます。ノードのプロトコルが自動的に変わるわけではありません。
4種類のプロトコルを比較：暗号化・認証・REALITY
以下では、現在も使われている一般的な設定を取り上げます。VMessは現行のAEAD設定、Shadowsocksは従来のAEAD方式と2022シリーズを区別して説明します。同じプロトコル名でも、アルゴリズムや実装バージョンによって互換性が異なる場合があります。
| プロトコル | 認証・暗号化 | 主なトランスポート | REALITYとの関係 | 主な確認項目 |
|---|---|---|---|---|
| VMess | ユーザーIDで認証。通常はAEADでデータを暗号化し、TLSを重ねることも可能 | TCP、WebSocket + TLSなど | 一般的なREALITY構成の選択肢ではない | UUID、暗号化オプション、トランスポート設定、システム時刻 |
| VLESS | 一般的な設定ではUUIDで認証。従来の設定はデータを暗号化しないため、外側の保護が必要 | TCP + TLS、TCP + REALITY、WebSocket + TLSなど | Xrayでよく使われる組み合わせ。クライアントとサーバー双方の対応確認が必要 | UUID、flow、セキュリティ層、サービス名、公開鍵関連のパラメーター |
| Trojan | パスワードで認証。標準的な構成ではTLSでデータを保護 | 通常はTCP + TLS。ほかのトランスポートは実装による | 一部のXray設定で組み合わせ可能。名前だけで互換性を判断しない | パスワード、TLSサービス名、証明書、トランスポート方式 |
| Shadowsocks | アルゴリズムと鍵の組み合わせで互換性が決まる。一般的にはAEADまたは2022シリーズ | 標準でTCP、UDPに対応。追加のカプセル化は別途確認 | プロトコル標準の機能ではない。VLESSのパラメーターをそのまま流用しない | method、パスワードまたは鍵の形式、UDP対応 |
VMessのautoは実装側が提供する暗号化方式の選択ロジックであり、独立したプロトコルではありません。現行の設定では通常AEAD認証ヘッダーを使います。古い情報への互換性を期待して、安易にalterIdを追加しないでください。時刻を利用する認証では端末の時計も正確である必要があります。UUIDを何度も変更するより、まずシステムの自動時刻合わせを有効にしましょう。
VLESSでよく使われるencryption=noneは、セキュリティ層と切り離して解釈できません。接続全体が必ず平文になるという意味でも、VLESSが自動で暗号化するという意味でもありません。外側にTLSやREALITYを使う場合は、それぞれの仕組みが通信を保護します。新しいバージョンで追加された拡張機能は個別に確認してください。拡張フィールドをすべてのコアに共通する基本機能として扱わないようにしましょう。
Shadowsocksのaes-128-gcmと2022-blake3-aes-128-gcmは、互換性のある表記ではありません。2022シリーズには独自の鍵長とエンコード要件があります。128ビット鍵は16バイト、256ビット鍵は32バイトで、設定に応じた形式にエンコードします。任意の短いパスワードを入力すれば、クライアントが正しい鍵に変換してくれるわけではありません。
ハンドシェイクと速度：プロトコル名だけで順位を付けられない理由
初回接続にかかる時間には、名前解決、ノードまでのネットワーク往復、セキュアなハンドシェイク、プロキシリクエスト、宛先サイトからの応答が含まれます。TCPingでわかるのは、通常ノードのポートにTCP接続できるかどうかまでです。UUID、パスワード、証明書、REALITYのパラメーターは検証されないため、これだけでプロトコル全体の接続が速いとは判断できません。
一般的なTCP接続では、新しいTCP接続に通常1往復が必要です。TLS 1.3の完全なハンドシェイクでは、さらに1往復が必要になるのが一般的ですが、処理の重複やセッション再開、接続の再利用は実装によって異なります。WebSocketのアップグレードリクエストや追加のHTTP層も、初回接続の時間を増やすことがあります。パケットロスがあると影響は大きくなりますが、こうした時間を機械的に足し合わせても、あらゆる環境に当てはまる遅延の計算式にはなりません。
上記の数値はポートの用途を示すもので、速度測定の結果ではありません。サーバーのポートが443でも、ブラウザーが検証できる証明書を備えているとは限りません。ローカルSOCKSに1080を使っても、リモート側で同じポートを使うわけではありません。ローカルの待ち受けポートとリモートの接続先ポートを区別すれば、ローカル接続の問題をプロトコル性能の問題と取り違えずに済みます。
- 比較条件をそろえる：できるだけ同じサーバー、同じ回線、同じ時間帯で測定します。地域の異なるノード同士を比べても、プロトコルの優劣はわかりません。
- 応答速度と転送速度を分けて測る：まず実際の接続遅延を測り、次に同じファイルを使って速度を測定します。5回続けて実施し、中央値と失敗回数を記録します。
- 端末の状態も記録する：CPU使用率、温度、バッテリー消費を確認します。Androidでダウンロードを続けたときの発熱は、数十ミリ秒のハンドシェイク差より使い勝手に影響する場合があります。
- 一度に変更するのは1項目だけ：まず接続の再利用、ルーティング、DNS設定を固定し、トランスポートとセキュリティ層を比較します。複数の項目を同時に変えると、差が生じた原因を特定できません。
サーバーの条件から選ぶ：4種類の適用範囲
サーバーの回線や設定管理、ローカルコアの条件を問わず最適なプロトコルはありません。以下は、サーバーを管理し、継続してメンテナンスできることを前提にしています。サブスクリプションを利用するだけの場合は、サービス提供元が案内する設定一式に従いましょう。名前が新しいという理由だけでパラメーターを手動で組み合わせないでください。
VLESS + REALITY
おすすめクライアントとサーバーの両方で互換性のあるXrayコアを使い、サーバー側の設定を管理できる場合は、優先的に検証する選択肢です。一般的なVision構成を使う場合は、xtls-rprx-vision、サービス名、公開鍵関連のパラメーター、shortIdを確認してください。UUIDだけをコピーしても接続できません。
適した環境：サーバーを管理でき、デスクトップとAndroidの設定をそろえて保守できる場合。
Trojan + TLS
ドメイン、証明書、更新手順がすでに整っている場合は、構成を把握しやすい方法です。証明書の信頼性、サービス名、パスワードを分けて確認できるため、問題の切り分けにも役立ちます。証明書の期限切れやSNIの不一致は、プロキシリクエストを送る前に接続を妨げることがあります。
適した環境：TLSの運用基盤があり、標準的な証明書検証の手順を使いたい場合。
VMess + WebSocket + TLS
利用可能なリバースプロキシとVMessノードがすでにある場合は、そのまま使い続けられます。CDNを経由する場合は、WebSocketの転送、ポート、トラフィックの用途に対応しているか確認してください。パス、Host、TLSサービス名はそれぞれ別の項目です。
適した環境：既存のサブスクリプションやサービス構成で、VMessを安定して利用している場合。
Shadowsocks AEAD / 2022
標準的な設定項目は比較的少なく、主にアドレス、ポート、アルゴリズム、鍵を確認します。対応アルゴリズム、UDP転送、追加のカプセル化はそれぞれ確認が必要です。「設定項目が少ない」ことを、あらゆるネットワークでより安定するという意味に捉えないでください。
適した環境：サーバーが該当するアルゴリズムを明示しており、標準のTCP・UDP転送を確認したい場合。
v2rayN・v2rayNG：インポート後に項目を確認
サブスクリプションはノード設定を配布する方法であり、5つ目のプロキシプロトコルではありません。同じサブスクリプションを2つのクライアントに読み込み、ノード名が同じに表示されても、flowやトランスポート経路、セキュリティ層が正しく読み込まれたとは限りません。初回インポート後はノードの編集画面を開き、サービス提供元の情報と項目ごとに照合してください。
確認方法：同じノードをデスクトップとAndroidで個別に検証
デスクトップ：v2rayN
- 画面に表示されるバージョンだけでなく、実際に使用中のコアとそのバージョンを確認します。
- ノードの編集画面を開き、プロトコル、アドレス、リモートポート、セキュリティ層を確認します。
- 実際のローカルポート経由で接続をテストし、用途に応じてシステムプロキシまたはTUNが設定されているか確認します。
- 接続に失敗した場合は実行ログを確認し、タイムアウト、認証エラー、証明書エラーを切り分けます。
Android：v2rayNG
- 内蔵Xrayのバージョンが、サーバー側で指定された設定の組み合わせに対応しているか確認します。
- ノードのトランスポート、TLSまたはREALITYの設定、サービス名を確認します。
- 接続を開始し、システムのVPN権限が許可されていることを確認します。
- テスト対象のアプリがプロキシを経由しない事態を避けるため、アプリ別の除外ルールを一時的に無効にします。
サブスクリプションの更新で同期されるのは、サブスクリプションに含まれるノード項目だけです。ローカルのルーティング、DNS、システムプロキシ、アプリ別の設定は、それぞれ個別に確認してください。
VLESS + REALITYでは、サービス名、公開鍵関連のパラメーター、shortId、flowが抜けやすい項目です。VMess + WebSocketではパスとHost、Trojanではパスワードや証明書のサービス名、Shadowsocksではmethodと鍵の形式をまず確認します。項目名はクライアントのバージョンによって変わる場合があるため、画面上の位置ではなく項目の意味に基づいて照合してください。
- 接続先とサービス名を分ける：接続先にはサーバーのIPアドレスを指定できますが、TLSサービス名は通常、証明書またはサーバーが許可する名前に一致させます。常にIPアドレスを入力するわけではありません。
- 証明書の検証を維持する：証明書エラーが発生した場合は、時刻、サービス名、信頼チェーン、有効期限を確認します。検証を無効にする方法を恒久的な対策にしないでください。
- UDPは個別に検証する：Webページが開けてもUDPが使えるとは限りません。プロトコルの実装、サーバー側の転送、ファイアウォール、クライアントの接続方式も確認してください。
- 認証情報は機密情報として扱う：サブスクリプションURL、UUID、パスワード、鍵、共有リンク全体を公開スクリーンショットに載せないでください。
プロトコル選びでよくある質問
VLESSはVMessより必ず速い？
必ずしもそうではありません。一般的なVLESS設定ではプロトコル自体のデータ暗号化処理が少ないものの、TLSやREALITYを使う場合もあります。サーバーと測定対象を固定し、実際の接続テストとダウンロードテストをそれぞれ5回行って、中央値、失敗率、CPU使用率を比較しましょう。回線が異なる場合、結果をプロトコル名だけに結びつけることはできません。
ノードにREALITYとあるのに、インポート後にタイムアウトするのはなぜ？
まずサーバーアドレスとリモートポートに到達できることを確認し、ノードの編集画面でサービス名、公開鍵関連のパラメーター、shortId、flowを照合します。続いてクライアントとサーバーのXrayのバージョンを確認してください。TCPingでわかるのはポートへの接続までで、REALITYのハンドシェイク成功は確認できません。ログにハンドシェイクエラーがある場合は、実際のパラメーターを確認して対処します。
ShadowsocksでWebページは開けるのに、ゲームが接続できない場合は？
まずゲームの通信がプロキシを経由していることを確認し、次にサーバーとクライアントの両方でUDPが有効になっており、対応しているか確認します。ブラウザーやシステムのHTTPプロキシを設定しただけでは、ゲームのUDP通信を通常は経由させられません。プロトコルがUDPに対応していても、サーバーのファイアウォールや現在のネットワークが通信を遮断している可能性があります。
v2flyNGで同じREALITYノードをそのまま使えますか？
サブスクリプションをインポートできるだけで、使用可能と判断しないでください。v2flyNGはv2flyコアを使用しますが、この記事で取り上げる一般的なREALITY構成はXrayの実装を前提としています。この種のノードを使う場合は、まずコアの対応状況を確認してください。Androidではv2rayNGを使ってサービス提供元の設定を検証できます。ノード名を変更しても互換性は得られません。
Trojanに変更すると、以前のルーティングルールは使えますか？
ルールが変更されていない出口タグを参照し、新しいノードがその出口に正しく割り当てられていれば、引き続き使えます。ルールがノード名、グループ、特定の出口に依存している場合は、設定を確認し直してください。直結するはずの宛先とプロキシ経由にする宛先を1つずつテストし、ログで実際の出口を確認しましょう。クライアントに「接続済み」と表示されるだけでは判断できません。