比較の前提：四方式は何を解決するプロトコルか
いわゆる「プロキシ用の転送プロトコル」は、大きく分けてペイロードの暗号化と転送形式を規定するものです。利用者が体感する速度や安定性は、プロトコル名だけで決まるのではなく、サーバ側の実装品質、物理距離、輻輳状況、DNS の扱い、ルール分流など、周辺要素の影響がはるかに大きくなりがちです。したがって本稿では、スペック表のような単純ランキングは避け、設計思想とトレードオフを軸に説明します。
また、これらのプロトコルは多くの場合、TLS（HTTPS と同系統の暗号化トランスポート）の内側や外側と組み合わせて使われます。検閲環境では「暗号化された中身」よりもトラフィックの見え方（TLS の指紋、パターン、タイミング）が議論になる場面がありますが、その効き方は環境依存が極めて大きいため、断定的な一般化は慎重に行う必要があります。
Shadowsocks：軽量で実装が広い「古典的」な柱
Shadowsocksは、比較的シンプルなフレーム形式とストリーム暗号（または AEAD）を用いてペイロードを包み、TCP／UDP の両方を転送できる設計として広く普及しました。実装が軽く、組み込み機器や低スペック VPS でも扱いやすいこと、クライアントエコシステムが成熟していることが強みです。バージョンや暗号スイートの選定は運用ポリシーと直結するため、古い方式をそのまま使い続けない、という点は継続的な注意が必要です。
TLS を別レイヤーで被せる構成（例：TLS 上に Shadowsocks を載せる）もよく見られます。このとき、外側の TLS が「HTTPS らしい振る舞い」をするかどうかは、サーバ設定とクライアント実装の組み合わせ次第です。Clash／Mihomo では長らく現実的な選択肢の一つとして扱われてきました。
VMess：状態と ID を前提にしたマルチユーザー向けの枠組み
VMessは、接続にユーザー識別子やタイムベースの要素を絡め、複数利用者を同一ポートで捌きやすいように設計されたプロトコル群の代表です。フレーム構造が相対的にリッチで、実装によってはオーバーヘッドが Shadowsocks 系より目立つこともあります。一方で、運用面では「誰のトラフィックか」をプロトコル層で分けやすい、といった長所も語られてきました。
近年は、VMess 単体よりもTLS や WebSocket、gRPC などのトランスポートとセットで語られることが多く、クライアント設定項目が増える傾向があります。設定画面でオプションが並ぶほど、ミスマッチ（ALPN、SNI、パス、ホストヘッダなど）による接続不全が起きやすい点は、導入コストとして押さえておく価値があります。
Trojan：TLS の上に「普通の HTTPS」として載せる発想
Trojan系の考え方は、要するに正当な TLS セッションの中にプロキシトラフィックを載せることで、外から見た目をウェブトラフィックに近づける、というものです。サーバ側で実際のウェブサイトと同居させる構成も説明上よく挙げられます。理屈としては「TLS が成立している以上、中身までは簡単には判別されない」という安全側の議論があり、実務上は証明書運用、フォールバックサイト、ポート・パスの整合が安定運用の鍵になります。
クライアントから見ると、設定はシンプルに見えても、裏側の実サーバの挙動と整合した SNI／証明書チェーンが崩れると即つながらない、というタイプのトラブルが起きやすい分野でもあります。ルール分流と DNS の組み合わせが悪いと、意図せず別経路で名前解決してしまい、証明書とホスト名が噛み合わない、という形で現れることもあります。
VLESS：ミニマルな認証と拡張トランスポートの土台
VLESSは、プロトコルコアを比較的ミニマルに保ちつつ、XTLSや現行のREALITYなど、暗号化の終端や偽装の仕方を発展させる拡張と組み合わせて語られることが多い方式です。「VLESS 単体で何がすごい」というより、どのトランスポート／TLS フロントと結線するかで性格が大きく変わる、と捉えると実務のイメージがつかみやすいです。
仕様や実装は更新頻度が高い領域でもあるため、クライアントとサーバのバージョン整合が他方式以上に重要になります。新しいオプションを有効にした直後にだけ不安定、というのは、まずバージョン差と ALPN／フロー指定を疑うと早いです。上流の議論やソースは、必要に応じてXray-core のリポジトリで追うと整理しやすいでしょう。インストールパッケージの入手先としては、GUI の更新機能や当サイトのダウンロード導線を優先し、GitHub は仕様確認用と切り分けるのがおすすめです。
観点別に見たざっくり比較
同一マシン・同一ルート上で測った「絶対速度」より、現場では次のような軸で揉めやすいです。以下は傾向の整理であり、個別環境での計測結果と矛盾しても不思議ではありません。
| 観点 | Shadowsocks | VMess | Trojan | VLESS |
|---|---|---|---|---|
| 実装の軽さ | 一般的に軽めの実装が多い | 機能分岐が多く重くなりがち | TLS 処理に依存 | コアは軽いが拡張で差が出る |
| 設定の複雑さ | 比較的シンプルなことも | トランスポート込みで項目が増えやすい | TLS まわりの整合が鍵 | 拡張オプションの理解が必要なことも |
| UDP／リアルタイム系 | 実装次第で扱いやすい | 構成によってはチューニング要 | TLS とアプリ要件の兼ね合い | フロー指定と相性確認が重要 |
| 外から見たトラフィック | TLS 被せ次第 | TLS＋上位プロトコル次第 | HTTPS 様への寄せが説明されやすい | REALITY 等の選択で議論が分かれる |
Clash／Mihomo で選ぶときの現実的な指針
クライアント側では、利用可能なプロトコルは同梱コアのバージョンと、購読が提供するノード形式に制約されます。Mihomo 系は新しいトランスポートの追従が速い一方、サーバが古いとクライアントだけ新しくしても意味がない、という齟齬が起きます。クライアントを入手したあとは、設定画面でコアの版と、ノードのタイプが想定どおり認識されているかを確認する習慣があるとトラブルが減ります。
ルール分流や DNS を含めた全体設計については、当サイトのドキュメント／チュートリアルとあわせて読むと、プロトコル以外のボトルネック（名前解決や TUN の境界）を切り分けやすくなります。
ではどれを選べばよいのか
実務的には次の順で考えると迷いが少ないです。第一に、購読または自前サーバが安定提供している方式に寄せる。第二に、利用デバイス（PC／モバイル）とクライアントの対応を確認する。第三に、UDP を多用する用途があるなら、そのプロトコル＋トランスポートで実アプリを試す。第四に、接続が不安定な環境では、TLS まわりが複雑な構成より、まず最小構成で通る経路を確保してから段階的に寄せる。
名称だけ見て「新しいから VLESS」「ステルスだから Trojan」のように一択に寄せるより、自分の回線で再現性よく通る組み合わせを基準にするほうが、長期運用では結果的に楽です。プロトコルは手段であり、最終的に効くのはルールと DNS とサーバ品質の三位一体だと心得ておくとよいでしょう。
法令順守と利用上の注意
本稿はネットワーク技術の一般解説を目的としています。各国・各組織の法令、契約、利用規約を遵守し、許可された範囲でのみネットワーク構成を変更してください。社内ポリシーや教育機関のルールがある場合は、それらを最優先で確認してください。
まとめ
Shadowsocks は軽量で遍在し、VMess はマルチユーザー運用の文脈で育ってきた方式、Trojan は TLS 上の見え方を重視する発想、VLESS はミニマルな土台に最新のトランスポート拡張を載せやすい、という整理が実務では扱いやすいです。いずれも「名前を変えるだけで劇的に快適になる」というより、整合した設定と健全なサーバがそろったときに初めて実力が出ます。
同種ツールのなかでも Clash 系は、ルール表現とクライアントの選択肢が豊富で、複数プロトコルを同一のポリシーグループで扱いやすいのが魅力です。まずは手元の購読で動く方式から試し、ログと体感の両方でボトルネックを特定していく進め方がもっとも確実です。