Shadowsocks・VMess・Trojan・Hysteria2、どれを選ぶべき？プロキシプロトコル徹底比較

まず全体像から

4つのプロトコルに絶対的な「最良」はなく、あるのは「今の通信環境に合っているかどうか」だけです。全体的な傾向はこうなります。

Shadowsocks：軽量で歴史があり、安定性で選ばれる

Shadowsocksの実装は十分にシンプルで、ほぼ全てのプラットフォームに成熟したクライアントが存在し、暗号化・復号のオーバーヘッドも小さいため、遅延の面では常に良好な結果を出します。弱点は、長年の利用の中で通信特徴が広く研究されている点で、制限の厳しい回線環境では単純なShadowsocks接続の方が識別されやすく、多くの場合obfsのような難読化プラグインを組み合わせて使う必要があります。

VMess：柔軟だが、設定の手間は増える

VMessが生まれた目的の一つはShadowsocksの認証方式や通信特徴の問題を解決することで、WebSocketやmKCPなど複数のトランスポート層に対応し、TLSを重ねることもできます。柔軟性の代償として設定項目が明確に増えます。サーバーアドレス、ポート、UUID、alterId、暗号化方式、トランスポート方式、TLS関連パラメータをすべて正しく一致させる必要があり、一つでもサーバー側とずれていると接続に失敗するため、Shadowsocksよりトラブルシューティングの手間がかかります。

Trojan：普通のWebサイトになりすまし、通信規制への耐性が高い

Trojanの設計思想はシンプルです。標準的なTLSを強制し、プロキシ通信を一般的なHTTPSサイトへの通常アクセスに偽装することで、通信の特徴だけから実際のWebサイトと区別することを難しくします。その代わり導入のハードルは上がります。実在のドメインと有効な証明書が必要で、sniは証明書のドメインと一致していなければならず、そうでなければ識別されたり接続に失敗したりします。エンドユーザーからすれば、ノード提供元がこの部分をきちんと整えてくれていれば、使用感は他のプロトコルと大きく変わりません。

Hysteria2：新しいプロトコルで、回線品質が悪い環境に強い

Hysteria2はQUIC（UDP）をベースに実装されており、前方誤り訂正や輻輳制御の最適化を標準で備えています。パケットロス率が高く遅延も大きい通信環境（例えば国際間の長距離回線）では、従来のTCP系プロトコルよりも快適に感じられることが多いです。注意点として、一部の公共ネットワークや企業ネットワークではUDP通信が制限・降格される場合があり、利用している回線がUDPに不向きだとHysteria2の優位性は発揮できません。そうした場合はTrojanのようなTCP系プロトコルに戻す方が安定します。

どう選ぶか

• 制限の厳しい回線環境で、長時間安定して使い続けたい —— Trojanが第一候補；
• 設定の柔軟性やトランスポート方式のカスタマイズを重視したい —— VMessが選択肢になる；
• シンプルで軽量な方式が欲しく、回線環境も比較的緩やか —— Shadowsocksで十分；
• 回線の遅延やパケットロスが目立ち、UDPが制限されていない —— Hysteria2を試すと速度面で有利になることが多い。

実際には多くのサブスクリプションが複数プロトコルのノードを同時に提供しているため、「1種類だけを使う」ことにこだわる必要はありません。まとめて同じプロキシグループに入れて、クライアントに自動で速度を測らせて選ばせればよいのです。

1つに絞るより、混在させる方が実用的

4つのプロトコルの中から「唯一の正解」を探すよりも、それらを同じ工具箱に入っている選択肢として扱う方が実用に近い考え方です。信頼できるサブスクリプション提供元の多くは複数プロトコルのノードを同時に用意しているので、クライアント側ではそれらを混在させて同じurl-testプロキシグループに入れ、測定の仕組みに今の通信環境で最も遅延が低く安定しているものを自動的に選ばせることができます。ユーザーが手動でどのプロトコルに切り替えるべきか判断する必要はありません。

利用している通信環境が頻繁に変わる場合（日中は会社、夜は自宅、週末は外でモバイル回線を使うなど）、混在編成の意味はさらに大きくなります。ネットワークごとにプロトコルへの相性は異なり、会社のネットワークはUDPを厳しく制限していることがあり、その場合Hysteria2の性能は落ちますが、モバイル回線は標準的なTLS通信（Trojan）に対して比較的寛容な傾向があります。クライアントに自動で測定・切り替えさせておけば、手動で判断するより手間がかからず、「環境が変わったのに切り替え忘れて接続できない」という事態も避けられます。

プロトコルを変更する実際のコスト

プロトコル間の切り替えは、本質的にはノード情報を入れ替えるだけで、ルール・プロキシグループ・DNSといった論理層の設定には影響しません。そのため見た目より低コストです。多くの場合はクライアント側でサブスクリプションを更新するだけで済みます（提供元が複数プロトコルのノードを用意していれば、通常は同じサブスクリプションにまとめて入っています）。もしくはproxiesリストのノード情報を手動で置き換えるだけでよく、プロキシグループやルールはそのまま維持できます。むしろ慎重にテストすべきなのは、切り替え後のノード自体の安定性や速度であり、プロトコル自体の互換性ではありません。各プロトコルをconfig.yamlにどう書くか具体的に知りたい方は、上級者向けドキュメントのプロトコルパラメータの解説をご覧ください。