プロキシプロトコルが解決する本質的な課題は、トラフィックをどのように偽装・暗号化して、ネットワーク経路上の検知を回避しつつ、伝送効率を維持するかという点です。各プロトコルは「安全性」「速度」「検閲耐性」の間で異なるトレードオフをしており、絶対的な「最良」は存在せず、「今の状況に合っているか」がすべてです。
5つのプロトコルをざっと比較
| プロトコル | 基盤トランスポート | 特徴 |
|---|---|---|
| Shadowsocks | TCP / UDP + シンプルな暗号化 | 最も歴史が長く、軽量な実装で速度が速い一方、トラフィックの特徴が比較的識別されやすい |
| VMess | TCP / WebSocket / mKCP | V2Rayエコシステムのネイティブプロトコルで、トラフィック偽装に対応、設定項目が多め |
| VLESS | TCP + TLS、XTLSとの併用が多い | VMessよりも軽量で、内蔵暗号化を排除(外側のTLSに依存)。XTLSと組み合わせるとパフォーマンス面の優位性が顕著 |
| Trojan | TCP + TLS | 通常のHTTPS通信に偽装し、識別の難易度が高い。実際のドメイン証明書に依存する |
| Hysteria2 | QUIC(UDP)ベース | パケットロスや不安定な通信環境への耐性が高く、コールドスタートが速い |
速度と検閲耐性のバランスをどう考えるか
一般的に、プロトコルスタックが「軽い」ほど(暗号化やカプセル化の工程が少ないほど)速度は速くなりますが、その分トラフィック分析ツールに特徴を検知されやすくなります。逆に偽装が「重い」プロトコル(HTTPSハンドシェイクを完全に模倣するなど)ほど検閲耐性は高くなりますが、余分なパフォーマンスコストがかかります。
- Shadowsocksは軽量級で速度面の優位性が明確。厳しい検閲がないネットワーク環境に向いています。
- VMess / VLESSはエコシステムが成熟しており、WebSocketやTLSなどのトランスポートと組み合わせることでさらに偽装でき、柔軟性が高いです。
- Trojanは「通常のウェブサイトへのアクセスと全く同じに見える」ことを目指した設計で、検査が厳しいネットワーク環境でも安定して動作します。
- Hysteria2はQUICベースでパケットロス耐性を標準で備えており、モバイル通信で基地局を頻繁に切り替えるような不安定な環境では、TCPベースのプロトコルより明らかに快適です。
プロトコルは「どう伝送するか」というレイヤーに過ぎません。安定して使えるかどうかを実際に左右するのは、多くの場合サーバー側のネットワーク経路の質とノード数です。プロトコル選定は「上限」を引き上げるものであり、「下限」を決めるのは経路品質です。
Clash / Mihomoはすべて対応している?
上記5つのプロトコルはすべて、Mihomoコア(現在のClashエコシステムが使用する中核)がネイティブに対応しており、追加プラグインは不要です。サブスクリプションリンクを取り込めば、クライアントが各ノードのプロトコルを自動的に識別します。気にする必要があるのはノードが使えるか、遅延が許容範囲かだけで、プロトコル面の細かい部分はすでにプロバイダー側で処理済みです。
自分でサーバーを構築する場合(プロバイダーのサブスクリプションを使わない場合)は、自分の用途に合わせてプロトコルを選ぶ必要があります。速度重視ならShadowsocksまたはVLESS + XTLS、検閲耐性重視ならTrojanまたはHysteria2、ネットワークが不安定ならHysteria2を優先的に検討しましょう。
一般ユーザーはどこまで気にすればいい?
プロバイダーが提供するサブスクリプションを利用しているだけなら、各プロトコルの実装の細部まで理解する必要はありません──プロバイダー側であらかじめ適切なプロトコルと経路の組み合わせが選ばれています。気にする価値があるのは、同じプロバイダーが複数のプロトコルのノードを提供している場合、ネットワーク環境が悪いときにHysteria2のような不安定な通信への耐性が高いプロトコルに切り替えてみることです。体感できるほどの違いが出ることが多いです。
サブスクリプション内のノードがどのプロトコルを使っているか確認する方法
サブスクリプションリンクをClashに取り込むと、ノード名にプロトコルや経路のヒントが含まれることが多いですが、最も確実な方法は設定ファイルを直接開く(またはクライアントのノード詳細を見る)ことです。Mihomoの設定フォーマットを例にすると、各ノードにはtypeフィールドがあり、値はss、vmess、vless、trojan、hysteria2のいずれかです。一目でそのノードが使っている具体的なプロトコルが分かります。
- name: HK-01
type: trojan
server: example.com
port: 443
サブスクリプションリンクしか持っていない、解析済みの平文設定がないという場合は、まずサブスクリプションをクライアントに取り込み、ノード一覧で詳細を確認すればOKです。ほとんどのGUIクライアントは各ノードのプロトコル種別を表示するので、手動でサブスクリプションの内容をデコードする必要はありません。
偽装とトランスポート層のカムフラージュは併用できる?
前述の「検閲耐性」は主にプロトコル自体のトラフィック特徴によって決まりますが、実際の運用ではプロトコルに加えて追加のトランスポート層カムフラージュを併用し、識別される確率をさらに下げることが一般的です。
- WebSocket + TLS:外部から見ると通常のWeb WebSocket接続に見えるようにする方法で、CDN経由のVMess / VLESSでよく使われます。
- gRPC トランスポート:トラフィックをgRPC呼び出しのように見せる、同様によく使われる偽装手段で、設定やトラブルシューティングの考え方はWebSocketと似ています。
- XTLS:VLESS専用に設計されたトランスポート最適化方式で、TLSによる偽装を維持しつつ余分な暗号化オーバーヘッドを削減します。現時点でVLESSと組み合わせる最良のパフォーマンスの一つです。
一般ユーザーにとって、これらのトランスポート層の詳細もすでにプロバイダー側で処理されているため、自分で設定する必要はありません。これらの用語を知っておく意味は、ノード名に「WS」「gRPC」「XTLS」といった表記を見たときに、それがトランスポート層のカムフラージュ方式に対応するものであり、全く別のプロトコルではないと理解できることです。
どのプロトコルを選べばいいか分からないときは
今の通信環境にどのプロトコルが適しているかすぐに判断できない場合、理論上の優劣にこだわるよりも、実際にテストしてみるのが最も現実的です。同じプロバイダーであれば複数のプロトコルのノード組み合わせを提供していることが多いので、それぞれurl-testプロキシグループで速度を測って遅延と安定性を比較すれば、資料を調べ続けるより効率的に、数分で直感的な結論が得られます。