サブスクリプションに含まれるノードの種類はさまざまです——ss、vmess、trojan、hysteria2……多くの人はサービス提供元のデフォルト設定をそのまま使っていて、実はプロトコル同士の違いをよく理解していません。この記事では「速度」「耐検知性」「設定の複雑さ」の3つの観点から横断的に比較し、選び方の参考にしていただきます。
まずは全体像の一覧表
| プロトコル | トランスポート層 | 耐検知性 | 典型的な用途 |
|---|---|---|---|
| Shadowsocks | TCP/UDP | 普通、特徴が比較的識別されやすい | 軽量で導入しやすい、老舗プロトコル |
| VMess | TCP + WS/gRPC | やや良好（CDN偽装との併用） | 正常なHTTPS通信を偽装したい場合 |
| VLESS | TCP + WS/gRPC/XTLS | 良好、VMessより性能が優れる | 性能と耐検知性の両方を求める場合 |
| Trojan | TLS | 良好、通信特徴が正常なHTTPSに近い | シンプルで信頼性の高い偽装を求める場合 |
| Hysteria2 | QUIC (UDP) | 強力、弱いネットワーク環境への最適化が良好 | 高遅延・パケットロス環境で速度を重視する場合 |
| TUIC | QUIC (UDP) | 強力、接続開始が高速 | モバイル通信、頻繁なネットワーク切替環境 |
Shadowsocks：シンプルで信頼性の高い老舗プロトコル
Shadowsocks（SS）は最も早くから普及した暗号化プロキシプロトコルの一つで、設定はシンプルです。server、port、cipher、password の4つのコアフィールドだけで済みます。欠点は通信特徴が比較的固定的であることで、特徴識別が厳しいネットワーク環境では狙われて制限や遮断を受けやすくなります。
VMess／VLESS：CDNと組み合わせた偽装能力
VMessとその後継であるVLESSは、通常WebSocketまたはgRPCのトランスポート層と組み合わせ、さらにTLSを重ねることで通信を普通のHTTPSリクエストのように見せかけ、CDNを経由させることも可能です。VLESSはVMessより暗号化のオーバーヘッドが少なく、XTLSと組み合わせるとより高い性能を発揮します。
Trojan：「普通のウェブサイト」に偽装する
Trojanの設計思想は明快です。接続全体が標準的なHTTPSリクエストのように見え、探知されても普通のサイトのコンテンツを返すことで「カバー」にできます。設定項目も比較的シンプルで、シンプルさと偽装能力のバランスを求める場合の定番の選択肢です。
Hysteria2／TUIC：QUICベースの新世代プロトコル
両者ともQUIC（UDPベース）の上に構築されており、より優れた輻輳制御と接続移行能力を備えています。高遅延・弱いネットワーク・頻繁なネットワーク切替（モバイル通信がWiFiと4G/5Gの間を切り替わる場合など）の場面では、従来のTCP系プロトコルよりも体感が良いことが多いです。
接続の多重化が実際の体感に与える影響
プロトコル自体に加えて、トランスポート層の接続多重化方式も体感速度に大きく影響します。VMess/VLESSと組み合わされるgRPCトランスポートは、1本の物理接続上で複数の論理ストリームを多重化でき、接続の再確立にかかるオーバーヘッドを減らせます。これは弱いネットワークや高遅延の経路で特に効果が顕著です。一方、リクエストごとに新しい接続を確立する方式は、ページ内で多数の小さなリソース（画像、スクリプトなど）を同時に読み込む際に、目に見えるカクつきが出やすくなります。同じノードでもウェブ閲覧と大容量ファイルのダウンロードで体感差が大きい場合、多くはトランスポート層の多重化戦略に関係していて、単純な帯域幅の問題ではないことが多いです。
同じプロトコルでもサービス提供元によって体感が大きく異なる理由
多くの人が「結局どのプロトコルが一番速いのか」で悩みますが、実際にテストしてみると、同じTrojanプロトコルでもサービス提供元によってノードの速度が数倍違うことがあります。これは、最終的な体感に影響する変数がプロトコル種別だけではないためです。サーバー自体の帯域出口の品質、あなたの地域からの物理的な距離、中継経路が最適化されているか、さらには同時刻にサーバーを利用している同時接続数まで、すべてが重なり合って結果に影響します。プロトコルが決めるのは「トランスポート層でどうデータを包装するか」だけで、速度の上限を実際に決めるのは基盤となるネットワークインフラです。
ノードの本当の速度をどうテストするか
プロキシグループに表示される遅延の数字（ms）だけでは、実際の体感を完全には反映できません。それは通常、1回のTCP/HTTPプローブの往復時間であり、遅延を反映しているだけで帯域幅は反映していないからです。より包括的なテスト方法は、まず url-test の遅延ランキングで一次選別を行い、候補となる2〜3のノードでそれぞれ適度なサイズのテストファイルをダウンロードし、瞬間的なピークだけでなく実際のダウンロード速度曲線が安定しているかを観察することです。あるノードの遅延が非常に低いのにダウンロード速度が不安定（速かったり遅かったり）な場合、多くはサーバー側の同時接続負荷が高いか、出口帯域が限られていることが原因です。
実践アドバイス：どう選ぶか
- とにかく安定して使いたい：サービス提供元が渡すプロトコルをそのまま使えば十分です。Clashクライアントが自動で識別・処理してくれるので、悩む必要はありません。
- ネットワーク環境の検閲が厳しい：TrojanやVLESSのような、通信特徴が正常なHTTPSに近いプロトコルを優先しましょう。
- ネットワーク品質が悪い（高遅延・高パケットロス）：Hysteria2やTUICを優先的に試してみてください。QUICのパケットロス耐性は通常より優れています。
- 複数プロトコルのノードがある：同じ
url-testポリシーグループに入れておけば、クライアントが現在のネットワークで最も遅延の低いものを自動で選んでくれます。
プロトコルは「陳腐化」するか
更新や進化はありますが、「古いプロトコルがいつか使えなくなる」と焦る必要はありません。Shadowsocksは何年も使われ続けてなお現役であり、シンプルで信頼性の高い方式にはそれ自体の生命力があることを示しています。新しいプロトコル（Hysteria2、TUICなど）は、特定の場面（弱いネットワーク、より高い耐検知性の要求）でより良い選択肢を提供しているだけで、古いプロトコルを完全に淘汰するものではありません。実際の使用でより注目すべきは、ノード提供元が継続的にメンテナンスを続けているかどうかであって、プロトコル自体の新旧ではありません——長期間メンテナンスされていない新プロトコルのノードは、よくメンテナンスされている古いプロトコルのノードより体感が悪いこともあります。
まとめ
プロトコルに絶対的な「最良」はなく、「現在のネットワーク環境で最も適したもの」があるだけです。サブスクリプションに複数プロトコルのノードが用意されているなら、すべて残して自動速度テストのポリシーグループに入れ、Clashに実際のネットワーク状況に応じて自動選択させるほうが、1つのプロトコルにこだわるより気楽です。