▶プロトコル解説:6種類のプロトコルと3世代カーネルの選び方

プロトコル全景:6つの主要プロトコルはどこから来て、何を解決するのか

まず一本の軸を押さえておきましょう。プロキシプロトコルの進化史とは、「暗号化・偽装・速度の3つの間でバランスを取り続けてきた歴史」そのものです。クライアントのサブスクリプションでよく見る6種類のプロトコル——Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC——は3つの世代に分かれ、それぞれが前世代の弱点への直接的な回答になっています。各プロトコルの出発点を理解しておけば、以降の比較表もすんなり読めるようになります。

Shadowsocks:軽量暗号化の出発点

Shadowsocks(略称 SS)は6つの中で最も古株のプロトコルです。設計目標はひと言で言えば「できるだけ少ないオーバーヘッドでTCPトラフィックに対称暗号を一枚かぶせる」こと。ハンドシェイクによる交渉やセッションの概念を持たず、クライアントとサーバーが事前に同じパスワードと暗号方式を約束しておき、接続確立後は暗号文をそのまま送るだけです。メリットは明快で、実装が極めてシンプル、CPU負荷が低く、ほぼすべてのプラットフォームに成熟した実装があります。一方で欠点も明確で、トラフィックの特徴が比較的固定的で、メタデータレベルの偽装能力に欠けます。その後コミュニティがAEAD暗号スイート(aes-128-gcm、chacha20-ietf-poly1305など)を追加し、初期のストリーム暗号にあった完全性の欠陥を修正しました。これが現在の設定でAEAD方式のみが推奨される理由です。

VMess と VLESS:セッション層を持つ2世代のプロトコル

VMessはV2Rayプロジェクトに由来し、SSより一歩進んだ発想を持っています。ユーザーID(UUID)、タイムスタンプ検証、動的メタデータを導入し、接続ごとにヘッダーが異なる仕組みで、WebSocketやgRPCなど複数のトランスポート層への対応もサポートします。柔軟性が最大の売りですが、複雑さも最大の負担です。プロトコルヘッダーの計算量が大きく、タイムスタンプ機構によりクライアントとサーバーの時刻ずれが大きすぎるとつながらなくなる——これはVMessの典型的な障害パターンです。VLESSは同じコミュニティによるVMessの「軽量版」で、組み込みの暗号化とタイムスタンプ検証を廃し、暗号化の責務を丸ごと下位のTLSに委ねることで、プロトコル本体には識別情報とルーティング情報だけを残しました。結果としてヘッダーが小さくなり転送が速くなりますが、必ずTLS(またはREALITYのような派生方式)と組み合わせて使う必要があり、素のVLESSには秘匿性が一切ありません。

Trojan:HTTPSの人波に紛れ込む

Trojanは発想を変えました。新しい暗号形式を発明するよりも、プロキシトラフィックの見た目を通常のHTTPSと完全に一致させる方向を選んだのです。標準のTLSハンドシェイクをそのまま利用し、サーバー側には実在の証明書を設定、認証に失敗したアクセスは通常のウェブサイトへフォールバックされます。観察者の視点では、Trojanの接続と通常のウェブブラウジングを区別する手がかりがありません。その代わりのトレードオフもあります。ドメインと有効な証明書が必須で、導入のハードルはSSより高くなります。またすべてのトラフィックが完全なTLSを経由するため、シングルコアの暗号化・復号スループットは軽量プロトコルよりわずかに劣りますが、その分「背景に溶け込む」能力が最も安定します。

Hysteria2 と TUIC:QUIC世代の高速化派

前述の4つのプロトコルはいずれもTCP上で動作するため、TCPの輻輳制御とヘッドオブラインブロッキングの制約を受けます。パケットが1つ失われると、接続全体が再送を待つことになります。Hysteria2とTUICは基盤をUDPベースのQUICに切り替えました。Hysteria2の核心は積極的な独自の輻輳制御戦略で、高パケットロス・高遅延の長距離リンクを専門に狙っており、弱いネットワーク環境でのスループット向上は非常に分かりやすい効果があります。TUICはより「標準派」で、QUICの規格に忠実に多重化と0-RTT高速ハンドシェイクを実装し、低遅延を追求しつつプロトコルの振る舞いを穏やかに保っています。両者に共通する弱点は、一部のネットワークがUDPに帯域制限やブロック措置を課している点で、こうした環境ではQUIC系プロトコルはむしろ実直なTCP系より不安定になります。そのため両者は「補助的な高速化オプション」であって、何も考えずに使うデフォルトではありません。

トランスポート層の設計トレードオフ:TCP・TLS・QUICの3つの路線

プロトコル比較はしばしば「どれが速いか」という話に単純化されがちですが、体感を決める第一の変数は実はトランスポート層の路線です。6種類のプロトコルを基盤ごとに3派に分けると、多くの現象が一瞬で腑に落ちます。

TCP直結派:SSと軽量なVMess

SSとTLSを使わないVMessは、独自の暗号文をTCP上に直接乗せて送ります。利点は互換性が最も高く、TCPを許可するネットワークならどこでも動作すること、実装が軽く古い端末やルーターでも扱えることです。欠点は、独自の暗号文自体が一種の特徴になってしまうこと、そしてTCPのヘッドオブラインブロッキングがパケットロスのあるリンクで体感速度を大きく損なうことです。遅延の数値は悪くなくても、ページの読み込みがカクカクする——これはまさに遅延測定の数値の見方で解説した「数値は良いのに体感が悪い」典型例の一つです。

TLSラッピング派:Trojan、VLESS、WebSocketを使うVMess

この派はトラフィックを標準的なTLSセッションに格納します。見た目は通常のHTTPSと一致するため、各種中間デバイスを突破する成功率が最も高くなります。CDN経由(VMess/VLESS + WebSocketの組み合わせでよく見られる)を組み合わせれば、サーバーの実アドレスを隠すことも可能です。代償はハンドシェイクの往復回数が多いこと。TCPの3ウェイハンドシェイクにTLSハンドシェイクが加わるため、初回パケットの遅延は直結派より自然と一段高くなります。また1バイトごとにTLSの暗号化・復号を経る必要があり、スループットの上限がCPUのシングルコア性能に明確に左右されます。

QUIC派:Hysteria2とTUIC

QUICは暗号ハンドシェイクとトランスポートハンドシェイクを統合し、理想的な条件では1往復で接続確立でき、0-RTT対応時にはさらに速くなります。ストリーム単位の多重化によりヘッドオブラインブロッキングを完全に回避し、1本のパケットロスは該当ストリームにしか影響しません。モバイルネットワークの切り替え(Wi-Fiから5Gへなど)時も、QUICのコネクションマイグレーション能力によって再接続がスムーズになります。弱点は前述の通りで、UDPは一部のネットワークでは「二級市民」扱いされ、帯域制限を受けると性能が急落します。

接続速度とリソース消費:数値の裏にある法則

先に結論を述べます。同じサーバー、同じ回線であれば、6種類のプロトコルの「最大帯域幅」の差は、通常回線自体の揺れよりも小さいものです。体感差を本当に生むのは、初回パケット遅延、パケットロス回復、CPUボトルネックの3点です。順に見ていきましょう。

初回パケット遅延:ハンドシェイクの往復回数が下限を決める

新しいウェブサイトを開くとき、クライアントはまずプロキシサーバーと接続を確立する必要があります。SSはTCPの3ウェイハンドシェイクだけでデータ送信可能で、往復回数が最少です。Trojan/VLESSはTCPの上にさらにTLSハンドシェイクを完了させる必要があり、往復が1〜2回増えます。Hysteria2/TUICはQUICによってこの2段階を1つに統合し、長距離リンクでの優位性が明確です。TUICの0-RTTは同じサーバーへの再アクセス時に「送信と同時にデータを乗せる」ことすら可能です。リンク遅延が50msの場合、これらの差はあまり感じられませんが、遅延が200ms以上になると、往復を1回省くごとに目に見える速度向上になります。

スループットとCPU:暗号化経路のコスト

全速ダウンロード時、ボトルネックとなるのは回線ではなく暗号化・復号処理であることが多いです。AEADスイートを使うSSはバイト単位のオーバーヘッドが最も低く、古いルーターでも線速に近づけます。Trojan/VLESSのTLS経路はAES-NI命令セットに対応した現代のCPUではオーバーヘッドを抑えられますが、低スペックなARM機器では帯域幅より先にここが上限になります。QUIC系プロトコルは現時点では多くがユーザースペースで実装されており、同じスループットでもCPU使用率はカーネルスペースで成熟した最適化を持つTCPスタックより概して高くなります。これが「Hysteria2はベンチマークが速いがファンも速く回る」理由です。デスクトップ環境では通常気になりませんが、ソフトルーターやTVボックスでは真剣に検討する必要があります。

パケットロス回復:弱ネットワークでの分水嶺

パケットロス率が1%を超えるリンクでは、TCP系プロトコルのスループットは輻輳アルゴリズムによって大きく抑え込まれ、同じ接続を再利用しているすべてのリクエストが一緒に詰まってしまいます。Hysteria2の積極的な補償戦略はこうした環境で利用可能な帯域幅を数倍に引き戻せることが多く、TUICのストリーム分離も「1つのリクエストが詰まっても他に影響しない」ことを保証します。逆に、パケットロスの少ない良好なリンクでは3派の実速度差は無視できるレベルになるため、この場合はベンチマークではなく偽装能力と互換性でプロトコルを選ぶべきです。

モバイル端末の電力消費:プロトコルがバッテリー持続時間に与える影響

スマートフォンでクライアントを一晩起動しっぱなしにしてバッテリーが大きく減る場合、プロトコルの選択も変数の一つですが、通常は最大の要因ではありません。本章では「プロトコルに関連する」消費電力要因だけを取り出して整理します。システムレベルの調査(省電力ホワイトリスト、バックグラウンド動作方針、プローブ間隔)については、ブログのAndroidバッテリー消耗チェックリストを参照してください。

無線唤醒:小さなパケットの頻度が隠れた大敵

モバイルチップのベースバンドには「スリープ―ウェイク」の状態機構があり、データの送受信ごとにベースバンドを低消費電力状態から引き上げてしまう可能性があります。引き上げられた後は、しばらく高消費電力状態を維持し続けます。そのため消費電力はトラフィックの総量とはあまり関係がなく、「どのくらいの頻度でパケットが来るか」と強く関係します。プロトコルやその上位実装のハートビート、キープアライブ、プローブが頻繁であればあるほど、ベースバンドは眠りにつきにくくなり、一晩の待機時のバッテリー消耗が増えます。

3派プロトコルの消費電力プロファイル

TCP系プロトコル自体には強制的なハートビートがなく、接続が静止している間は余分なウェイクをほぼ発生させないため、待機時に優しい性質があります。注意が必要なのはWebSocketを使うVMess/VLESSで、一部のサーバーが定期的なpingフレームを設定しており、間隔が短すぎると典型的な「バッテリー刺客」になります。QUIC系プロトコルはNATマッピングとコネクションマイグレーション能力を維持するため、通常組み込みのキープアライブプローブを持ち、静止状態でのウェイク回数は自然とTCP系より多くなります。その代わり、ネットワーク切り替え時に接続をゼロから作り直す必要がないという利点があります。Wi-Fiとモバイル回線を頻繁に切り替える通勤シーンでは、1回の完全な再接続(再ハンドシェイク、ノードの再プローブ)の消費電力が、数回分のキープアライブより大きくなることもあります。したがって結論は一方的ではありません。ネットワークの切り替えが激しいユーザーはQUIC系のほうが省電力になる場合があり、単一ネットワークに長時間留まるユーザーはTCP系のほうが安定します。

実践できる省電力の原則

• 待機中心の端末:SSまたはTrojanを優先し、ハートビート間隔が短すぎるWebSocket設定は避けましょう。
• 通勤などでネットワーク切り替えが多い場合:TUICまたはHysteria2を試し、コネクションマイグレーションで再ハンドシェイクを減らしましょう。
• プロトコルを問わず:ポリシーグループの自動速度テスト間隔を10分以上に広げましょう。プローブ自体もウェイクの原因になります。
• TUNモードを常時有効にするとグローバルトラフィックを引き受けるため、一部アプリだけをプロキシする場合より消費電力が高くなるのは通常の現象です。必要に応じて有効にしましょう。

カーネルファミリー:無印、Meta、mihomoはどんな関係か

まず一点をはっきりさせておきます。この3つの名前は3つの競合プロダクトではなく、同一の進化ラインにおける3つの段階です。系譜を理解しておけば、クライアント選びと設定互換性の問題は大幅に減ります。より完全な時系列の整理はブログのカーネルの違い比較を参照してください。

無印カーネル:ルールベース分流方式の礎

最初のClashカーネルは、今日のすべての派生製品が踏襲する骨格を確立しました。YAML設定、proxiesノードリスト、proxy-groupsポリシーグループ、rulesルールセクション、そして「ドメインとIPルールでトラフィックの行き先を決める」分流方式です。当時主流だったSS、VMess、Trojanなどのプロトコルにはネイティブ対応していましたが、後に登場したVLESS、Hysteria2、TUICへの対応はありません。元のリポジトリは更新が停止しており、無印カーネルは現在「歴史的段階」に位置づけられます。新規ユーザーがこれを中心に環境を構築することは推奨されません。

Metaブランチ:コミュニティが引き継いだ機能拡張版

無印が現役だった時期、コミュニティが保守するClash.Metaブランチが並行して開発を進めていました。新プロトコル対応(VLESS、Hysteria系、TUIC)の追加、TUNモードの強化、DNSとスニッフィング能力の拡張、sub-rulesなどより柔軟なルール記法の導入です。無印の設定に対する下位互換性は保たれており、古い設定ファイルは基本的にそのままMetaカーネルに渡して動作しますが、逆は成立しません。Metaの拡張フィールドを使った設定を無印カーネルに渡すと「unsupported」系のエラーが出ます。

mihomo:同一カーネルの現行名

無印のリポジトリがアーカイブされた後、Metaブランチはmihomoに名称変更し、今日まで開発が続いています。**mihomoはClash.Metaの現行名であり、両者は同一のプロジェクトです**。設定形式、コマンドライン動作、APIはすべて引き継がれています。今日の主要クライアント——ダウンロードページで第一に推奨されるClash Plus、およびClash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Androidなど——は、いずれも下位カーネルにmihomoまたはその派生を採用しています。クライアント選定時に「mihomo/Metaカーネルベース」という表記を見かけたら、6種類のプロトコルとTUN、スニッフィングなどの能力がすべて対応範囲内であることを意味します。

設定フィールドとカーネル互換性:新カーネルしか認識しない記法とは

サブスクリプションを取得したり手動で設定を書いたりする際、最も多いトラブルは「フィールドとカーネルの不一致」です。本章ではフィールドの階層ごとに互換性の境界線を確認します。設定ファイル全体の構造を段落ごとに精読したい場合は設定ファイル構造の解説をご覧ください。

全カーネル共通の骨格フィールド

port、socks-port、mixed-port、allow-lan、mode、log-level、external-controllerといったトップレベルのフィールドは無印時代から今日まで引き継がれており、どのカーネルでも認識されます。proxies内のSS、VMess、Trojanの3種類のノードの基本的な記法も同様に共通です。これらのフィールドだけで構成された設定であれば、どのクライアントに渡しても動作します。

Meta/mihomoのみ対応する拡張フィールド

以下のいずれかが記法に含まれる場合、その設定はMeta/mihomo系カーネルでしか動作しません。typeがvless、hysteria2、tuicのノード、tunセクションの完全な設定(stack、auto-route、dns-hijackを含む)、snifferスニッフィングセクション、GEOSITE系ルールや一部の拡張ルールタイプ、proxy-providersとrule-providersの拡張パラメータです。最小構成のHysteria2ノードの例:

proxies:
  - name: "サンプル-Hysteria2"
    type: hysteria2
    server: hy2.example.com
    port: 443
    password: "your-password"
    sni: hy2.example.com

全カーネル共通のShadowsocksノードと比較すると、拡張プロトコルはフィールドが数個増えただけで骨格は完全に一致していることが分かります。

proxies:
  - name: "サンプル-SS"
    type: ss
    server: ss.example.com
    port: 8388
    cipher: chacha20-ietf-poly1305
    password: "your-password"

互換性トラブルシューティングの3ステップ

1. カーネルを確認する:クライアントの設定画面を開いてカーネル表示を確認します。mihomoまたはMetaと表記されていれば新カーネルです。バージョン番号の横にカーネル名が付いていることが多いです。
2. エラーのキーワードを見る:ログにunsupported typeやunknown fieldが出ていれば、古いカーネルが新しいフィールドに遭遇していると判断できます。
3. 上位に合わせる:クライアントをmihomoカーネルベースのバージョンに切り替えましょう(ダウンロードページに掲載されている保守中のクライアントはすべて対応済み)。逆に設定フィールドを削って古いカーネルに合わせるのは避けてください。

サブスクリプション形式の互換性:クライアントを変えると何が起きるか

サブスクリプションは「1本のURLでノード設定一式を受け取る」仕組みですが、生態系が異なればサブスクリプション形式も共通ではありません。よくある3つの形態を理解しておけば、クライアントやプラットフォームを変える際にも困惑しません。

Clash YAMLサブスクリプション:このエコシステムのネイティブ形式

サブスクリプションリンクは完全なYAML設定(少なくともproxiesセクションを含む)を返し、クライアントは取得後そのまま読み込みます。これはClash系クライアントのネイティブ形式で、フィールド情報が最も充実しています。ノードパラメータ、ポリシーグループ構造、ルールセクションを一括で配布できます。注意点は1つだけで、返された設定にMeta拡張フィールドが含まれる場合、古いカーネルのクライアントでは読み込みに失敗します。エラーの現れ方は前章を参照してください。

共有リンクとBase64集約:生態系を跨ぐ最大公約数

ss://、vmess://、trojan://で始まる単一ノードの共有リンク、および複数のリンクをBase64でまとめた集約サブスクリプションは、クライアント生態系を跨いだ汎用の交換形式です。これはノード自体しか記述せず、ポリシーグループやルールは含みません。mihomo系クライアントの多くはこの種のサブスクリプションを直接認識し、自動でデフォルトのポリシーグループを付与します。逆方向の互換性は対象クライアントに依存し、一部のプロトコル(特にHysteria2、TUIC)の共有リンク形式は実装ごとに細部が異なるため、生態系を跨いだ取り込みで一部パラメータが失われることは珍しくありません。

サブスクリプション変換:便利だが何が失われるかを知っておく

サブスクリプション変換サービスは一つの形式を別の形式に翻訳するもので、「プロバイダーが汎用サブスクリプションしか提供せず、クライアント側は完全なYAMLを欲しがる」場面でよく使われます。3点必ず把握しておいてください。第一に、変換はテンプレートに基づいてポリシーグループとルールを生成するため、元のサブスクリプションになかった分流ロジックはテンプレートが追加したものであり、サービス提供者の意図を反映しているわけではありません。第二に、あまり使われないプロトコルのパラメータ(例えばHysteria2の帯域幅ヒントフィールド)は変換時に黙って失われる場合があり、接続できないときはまずここを疑ってください。第三に、サブスクリプションリンクには認証情報が含まれるため、公開の変換サービスに提出することはノード情報を渡すことに等しく、自前で構築するかクライアント内蔵のローカル変換を使うほうが安全です。サブスクリプション関連のよくある質問はヘルプセンターも参照してください。

用途別の選び方:そのまま使える答え

ここまでの内容がこの章に集約されます。自分のシーンを見つけ、推奨順にクライアントで試し、最初に安定してつながったものが今の環境での正解です。

デスクトップの日常利用:ウェブ、業務、開発

やること:Trojan、またはVLESS + TLSを優先し、次点でSS。デスクトップはCPU性能に余裕があり、TLSのオーバーヘッドは気にならず、偽装能力を優先できます。見えてくる結果:遅延が安定し、長時間の起動でも切断しにくくなります。WindowsやmacOS向けのClash Plusと組み合わせ、分流ルールは入門ガイドのデフォルト設定のままで十分です。

モバイル端末:通勤とアウトドア

やること:ネットワーク切り替えが頻繁な場合はTUICまたはHysteria2でQUICのコネクションマイグレーションを活用し、単一ネットワークに留まりバッテリー持続を重視する場合はSSまたはTrojanを選びます。見えてくる結果:切り替え後の復帰が速くなる、または一晩の待機時消費電力が抑えられます。前述の電力の章のプローブ間隔設定と合わせて調整してください。

弱ネットワークと長距離リンク:高パケットロス、高遅延

やること:第一候補はHysteria2、次点はTUICです。見えてくる結果:同じ劣悪な回線でもスループットが明確に回復し、動画のシークで読み込みが止まらなくなります。所属するネットワークがUDPを制限している場合(QUICノードが全滞ロールアウトタイムアウトになる、または速度が急落する)は、Trojanに切り替えてください。

ルーターと常時稼働サーバー

やること:SS(AEAD)を優先し、CPU負荷を最小限に抑えます。機器性能に余裕がある場合はTrojanも検討してください。カーネルはmihomoのコマンドライン版を直接動かし、ダウンロードページのカーネル区で各アーキテクチャ向けのパッケージを提供しています。見えてくる結果:低スペックなARM機器でも線速に近い転送が可能になります。QUIC系プロトコルはソフトルーター上でCPU使用率が高めになるため、常時稼働には慎重を要します。

1つのサブスクリプションで複数プロトコルが共存する場合の推奨姿勢

多くのプロバイダーでは同一ノードに複数のプロトコルの入口が用意されています。推奨する方法は、ポリシーグループ内で異なるプロトコルの同一地域のノードを同じグループにまとめ、数日間手動で切り替えて比較すること。クライアントはmihomoカーネルベースのバージョンを選び、6種類のプロトコルすべてが使える状態を保証することで、プロトコルに合わせてクライアントを選び直す必要がなくなります。

よくある誤解と関連記事

最後に頻出の誤解を整理します。それぞれが実際の相談スレッドのパターンに対応しています。

誤解その1:プロトコルは新しいほど良い

成立しません。Hysteria2、TUICは特定の環境(弱ネットワーク、頻繁なネットワーク切り替え)向けの特化型ソリューションであり、良好な有線回線ではTrojanに対して体感上の優位性はなく、その分CPUと電力を余計に消費します。プロトコル選定は環境との適合度で判断すべきで、リリース年で判断するものではありません。

誤解その2:遅延が低い=プロトコルが速い

そうではありません。クライアントに表示される遅延は1回のプローブ往復にすぎず、スループット、パケットロス回復、ハンドシェイクコストの情報は含まれていません。同一ノードでSSとTrojanのプローブ値がほぼ同じでも、弱ネットワーク下での実際の体感は数倍異なることがあります。詳しい仕組みは遅延数値の読み方を参照してください。

誤解その3:MetaとmihomoはCloud2つのカーネルで、どちらか選ばなければならない

同一プロジェクトの前後の名称です。クライアントの説明にどちらの名前が出てきても、機能セットは一致しており、選択の問題は存在しません。

誤解その4:サブスクリプションがAのクライアントで使えれば、Bのクライアントでも必ず使える

サブスクリプション形式とカーネルバージョンの組み合わせに依存します。YAMLサブスクリプションに拡張フィールドが含まれる場合、古いカーネルは読み込みを拒否します。汎用サブスクリプションを生態系を跨いで取り込むとパラメータが失われる場合があります。クライアントを変えてつながらなくなった場合は、まず設定互換性の章の3ステップでトラブルシューティングし、それでも解決しなければヘルプセンターのトラブル対応カテゴリから該当項目を探してください。

誤解その5:分流が効かないのはプロトコルのせい

その可能性は低いです。分流はルールセクションとDNSの挙動によって決まり、ノードのプロトコルとは無関係です。ルールが効かない最もよくある根本原因はDNSリークやfake-ip設定の誤りで、調査手順はDNSリーク検出と修復を参照してください。

本ページを読み終えれば、プロトコルとカーネルの選定根拠は揃っています。次のステップ:インストールパッケージのページでプラットフォームに応じたクライアントを入手し、入門ガイドに沿ってサブスクリプションの導入、モード選択、接続確認までの一連の流れを完了させてください。