プロトコルガイド:プロキシプロトコルとカーネルの技術リファレンス

Aプロトコル概要:6種類のプロトコルが生まれた背景と設計思想

Clash エコシステムで使われる6種類のプロトコルは、登場した順に一本の進化ラインとして並べられます。Shadowsocks が最も古く、VMess と Trojan は中間世代、VLESS・Hysteria2・TUIC はより新しい方向性です。各世代は前の世代で表面化した課題への回答として生まれているため、「すべてに勝る」プロトコルは存在せず、トレードオフの方向性が異なるだけです。

Shadowsocks:極限までシンプルな対称鍵暗号

Shadowsocks(通称 SS)の設計目標は最小化です。クライアントとサーバーが同じパスワードと暗号方式を共有し、データは AEAD 対称暗号で直接送受信されます。ハンドシェイクや追加の認証往復がありません。これにより実装のシンプルさと接続確立の速さという利点が得られますが、代償として偽装レイヤーを持たず、拡張性は SIP003 プラグイン体系(obfs や v2ray-plugin など)に依存します。暗号方式は現在 aes-128-gcm と chacha20-ietf-poly1305 が主流で、前者はハードウェアアクセラレーションのある x86 デバイスで高速、後者は多くのスマートフォンの ARM チップで有利です。

VMess と Trojan:対照的な2つの方向性

VMess は V2Ray プロジェクト由来で、「機能重視」の路線を取ります。ユーザーの UUID による動的認証を基盤に、TCP・WebSocket・gRPC など複数のトランスポート層を自由に組み合わせられ、メタデータには制御情報が多く含まれます。トレードオフはプロトコルヘッダーのオーバーヘッドが大きいこと、そして認証がクライアントとサーバーのシステム時刻の同期にある程度依存する点です——時刻のずれが大きいと即接続失敗になるため、VMess ノードの不調をトラブル対処する際にまず確認すべき項目です。Trojan は逆方向のアプローチで、独自の暗号を用意せず標準 TLS をそのまま利用し、通常の HTTPS アクセスと外見上区別がつかないようにします。その分の負担はサーバー側が負い、ドメインと有効な証明書を要する構成が必要になりますが、利用者側にはほぼ意識されず、設定項目も最少です。

VLESS、Hysteria2、TUIC:新世代の引き算と方向転換

VLESS は VMess の引き算版です。プロトコル自体の暗号化と時刻認証を排除し、安全性を完全に外層の TLS(および REALITY などの拡張)に委ね、ヘッダーを極限まで薄くすることで転送オーバーヘッドを VMess より大幅に下げています。Hysteria2 と TUIC は方向転換型で、TCP を捨てて UDP ベースの QUIC を基盤に採用しています。Hysteria2 の特徴は積極的な輻輳制御戦略を内蔵しており、パケットロスや遅延が大きい弱い回線でもスループットを維持できる点。TUIC はハンドシェイク効率に重点を置き、QUIC の 0-RTT 特性を利用して接続確立を極限まで短縮し、UDP 転送もネイティブサポートします。これら3つは Clash エコシステム内では mihomo 系カーネルのみが対応しており、詳細は E章で解説します。

Bトランスポート層の違い:TCP 系と QUIC 系の分岐点

6種類のプロトコルの本当の分岐点は暗号方式ではなくトランスポート層にあります。SS・VMess・Trojan・VLESS は TCP 系、Hysteria2 と TUIC は QUIC 系です。この線引きを理解することは、各プロトコルの細かなフィールドを覚えるより実用的です。なぜならこれが、ネットワーク環境によるプロトコルの挙動差を直接左右するからです。

TCP 系:成熟・保守的・経路に優しい

TCP 系プロトコルの最大の強みは「経路への優しさ」です。TCP はインターネット上で最も成熟したトランスポートプロトコルであり、経路上のルーター・ファイアウォール・通信キャリアの QoS 機器はいずれも十分に対応しており、丸ごと帯域制限や遮断される事例はほとんどありません。Trojan と VLESS は TLS を重ねることで、通信の特徴が一般的な Web アクセスと同一になり、互換性が最も高くなります。ただし代償は2つあります。1つはハンドシェイクの回数が多いこと——TCP の3ウェイハンドシェイクに TLS ハンドシェイクが重なるため、接続確立には最低でも2〜3回の往復が必要で、物理的な距離が遠いノードほど初回応答の待ち時間が目立ちます。もう1つはヘッドオブラインブロッキングです——TCP はバイト列の順序を厳密に保証するため、1つのパケットロスがそれ以降のすべてのデータをブロックしてしまい、関連のないリクエストのデータであっても影響を受けます。パケットロス率の高い回線では、これが偶発的なロスを全体的なカクつきに増幅させてしまいます。

QUIC 系:ハンドシェイクが少なく耐障害性が高いが、UDP の扱いに依存

QUIC は UDP の上に信頼性のある転送を再実装し、TLS 1.3 のハンドシェイクを接続確立の過程に統合しています。新規接続は通常1往復で完了し、再接続シーンでは 0-RTT により初回パケットにデータを載せることも可能です。QUIC のストリームは互いに独立しており、1つのパケットロスは所属するストリームにしか影響せず、他のリクエストをブロックしません。これが弱い回線下での体感を良くしている構造的な理由です。QUIC は接続マイグレーションもサポートしており、デバイスが Wi-Fi からモバイル通信網に切り替わっても接続を再確立せず継続できるため、モバイル端末にとって明確な価値があります。弱点も同じく UDP に由来します——一部の通信事業者や企業ネットワークは UDP 通信を帯域制限したり優先度を下げたりするため、そうした回線では QUIC 系プロトコルの実際の性能が、むしろ通常の TLS over TCP 接続に劣ることもあります。したがって「Hysteria2 は必ず Trojan より速い」といった結論は成り立ちません——速いかどうかはその経路が UDP をどう扱うかに依存します。

多重化(マルチプレクシング)の位置づけの違い

TCP 系プロトコルは mux 設定によって複数のリクエストを1本の接続にまとめることでハンドシェイク回数を減らせますが、多重化はヘッドオブラインブロッキングの影響範囲も同時に拡大させるため、通常は高遅延回線でのみ必要に応じて有効化することが推奨されます。QUIC 系プロトコルの多重化はネイティブに備わっており、追加設定は不要で、リクエスト間のブロッキングも発生しません。これはトランスポート層の設計そのものによる差であり、パラメータ調整で解消できるものではありません。

C通信速度とリソース消費:定性的な比較

プロトコルの性能について普遍的に使える数値はありません——同じプロトコルでも回線やデバイスによる差は、プロトコル間の差よりも大きいのが実情です。そのためこの章では定性的な比較のみを行い、「他の条件が同一」という前提での相対的な順位、そしてリソース消費の構造的な違いを示します。

接続確立の速さ

「新しいサイトを開くまでの待ち時間」を左右する核心要素は接続確立時の往復回数です。ハンドシェイク回数の少ない順に並べると:TUIC と Hysteria2(QUIC、1往復、再接続時は 0-RTT も可能)が最速。次に SS(プロトコル自体のハンドシェイクなし、TCP の3ウェイハンドシェイクのみ)。Trojan と VLESS は TCP と TLS の2層のハンドシェイクが必要。VMess はプロトコルヘッダーと認証のオーバーヘッドにより、同グループ内で最も接続確立が遅くなる傾向があります。ここでの順位は新規接続の初回応答時間にのみ影響し、接続確立後の継続的な転送速度には関係ありません。頻繁に短い接続を確立する Web ブラウジングはこの速さに最も敏感で、動画視聴や大容量ファイルのダウンロードのような長時間接続のシーンではほとんど影響がありません。

スループットと CPU 負荷

継続的なスループットのボトルネックは通常回線そのものにあり、プロトコル間の差は主に CPU 使用率に現れます。暗号処理が大きな要因です。x86 デバイスは AES ハードウェアアクセラレーション命令を広くサポートしているため、aes-128-gcm はほぼ CPU を消費しません。一方多くの ARM 系モバイルチップでは chacha20-ietf-poly1305 のほうが効率的です。VLESS はプロトコル自体が暗号化を行わない(外層の TLS のみ)ため、同等のスループットにおける CPU 使用率が最も低く、高トラフィックな転送用途で採用される理由にもなっています。QUIC 系プロトコルの暗号処理は現状ユーザースペースで行われることが多く、OS が備える TCP 向けの成熟した最適化を欠くため、帯域を使い切るような極限のシーンでは CPU 使用率が TCP 系より明らかに高くなります——デスクトップでは無視できますが、低電力デバイスでは留意が必要です。

メモリと低スペック機器

メモリ使用量は主にカーネルとルールデータによって決まり、プロトコル自体による差はごくわずかです。実際にメモリを消費するのは GEO データベースや大容量のルールセットで、ルーターや古いスマホのようなメモリが限られたデバイスでは、ルールファイルを絞る方がプロトコルを変えるよりも効果的にメモリ消費を抑えられます。メモリが少ないルーターを使っている場合は、SS や Trojan のような実装がシンプルなプロトコルを優先し、Mihomo カーネルの軽量な設定を利用することをおすすめします。低スペック機器で QUIC 系プロトコルの新機能を追い求めるのは避けたほうが良いでしょう。同時接続数が多いシーン(Web の多数タブ、P2P など)では、TCP 接続1本ごとに独立したシステム負荷が発生するため、mux の有効化やネイティブに多重化に対応した QUIC 系プロトコルへの切り替えは、接続の総数を減らす手段として有効です。これはリソース観点でのプロトコル選定における別の考慮点です。

Dモバイルの電池消耗:プロトコル以外にもクライアントの挙動が関わる

スマホでの電池消耗はプロトコルのせいにされがちですが、実際には3つの層が重なって消費を生んでいます。プロトコルのキープアライブ挙動、クライアントのバックグラウンド戦略、そして OS の VPN サービスに対するスケジューリングです。プロトコルだけ変えてクライアントの挙動を調整しなければ、省電力効果は通常限定的です。

無線モジュールのウェイクアップ:モバイル端末の電池消耗の本当の主因

モバイル通信網では、データ送受信がない間、スマホのベースバンドチップは低電力状態に入り、どんな小さなデータパケットでもこれを起こして一定時間高電力状態を維持させます。したがって電池消耗の本質はデータの転送量ではなく、無線モジュールを何回起こしたかにあります。プロトコル層のキープアライブハートビート、クライアントの定期的な遅延テスト、ポリシーグループの自動速度測定は、いずれも周期的なウェイクアップを引き起こします。QUIC 系プロトコルの接続マイグレーションはここで実際に価値を発揮します——Wi-Fi とモバイル通信の切り替え時に接続をそのまま継続できるため、接続再確立のハンドシェイクとそれに伴う一連のウェイクアップを省けます。TCP 系プロトコルはネットワーク切り替え時にすべての接続が無効になり再確立が必要になるため、頻繁に切り替わる通勤シーンではその差が積み重なります。

クライアント側で調整できる項目

プロトコルの選択よりも影響が大きいのはクライアントの設定です。第一に、ポリシーグループの自動速度測定の間隔です。url-test タイプのグループはデフォルトで周期的にグループ内の全ノードをテストします。間隔を短く設定しすぎると、数分おきにスマホを起こしてまとめて接続を確立させることになるため、モバイル端末では interval を長めに設定するか、あまり使わないグループは手動選択に切り替えることをおすすめします。第二に、TUN モードとシステムプロキシの違いです。TUN モードは全通信を引き受けるため処理経路が長く、ブラウザなど一部の通信だけを代理するシステムプロキシモードよりも待機電力がやや高くなります。全体の通信を引き受ける必要がない場合、モバイル端末ではシステムプロキシモードのほうが省電力です。第三に、ルール数です。新規接続はいずれもルールマッチングを通過する必要があるため、ルールセットが大きいほどマッチングコストが上がります。モバイル向けの設定では、使わない大量のルールセットを積み重ねないようにしましょう。

iOS 特有の制約

iOS 上のプロキシクライアントは Network Extension フレームワーク内で動作し、OS はこの拡張プロセスのメモリに対して非常に厳しい制限を課しています。上限を超えると即座に強制終了され、プロキシが無断で切断されたように見えます。そのため iOS 向けクライアントはルールと GEO データの容量を特に抑える必要があり、プロトコルの選択でも実装が軽いものが望ましいです。Clash Plus は iOS では App Store から配信され、この制約を踏まえたメモリ管理が行われているため iOS 環境での第一候補です。導入はダウンロードページの iOS セクションから。Android では OS のバッテリー最適化のホワイトリストに注意が必要です。クライアントが OS に凍結されると VPN サービスの再起動が発生し、その際にも再接続による電池消耗が生じます。プロトコルを調整するより、ホワイトリスト登録の方が持続時間の改善に効果的です。

Eカーネルファミリー:無印・Premium・Meta・mihomo の関係

「Clash」という言葉は文脈によって指すものが異なります。カーネル(バックグラウンドで通信を処理するコマンドラインプログラム)を指す場合もあれば、クライアント(GUI を備えたアプリ)を指す場合もあります。クライアントはあくまでカーネルの外側の見た目であり、対応プロトコル・ルール機能・TUN 実装はすべてカーネルによって決まります。カーネルファミリーの系譜を理解することは、「このノードがクライアント A では使えて、クライアント B ではエラーになる」理由を理解する前提になります。

3世代のカーネルの進化ライン

無印 Clash カーネルはすべての出発点であり、proxies、proxy-groups、rules の3段構成の設定構造を確立し、SS・VMess・Trojan などの基本プロトコルに対応していました。上流リポジトリはすでにアーカイブされ、更新は止まっています。Premium は無印の作者が維持していたクローズドソースの強化版で、TUN モードやルールプロバイダー(rule providers)などの機能を追加していましたが、無印と共に開発が停止しています。Clash Meta はコミュニティによる無印からの派生分岐で、後に mihomo へと改名されました——2つの名前は同一の系譜を指し、現在の正式名称は mihomo です。設定構造の互換性を保ちながら VLESS・Hysteria2・TUIC などの新プロトコルに対応し、ルールセット(rule-set)、ドメインスニッフィング(sniffer)、より完成度の高い GEO データ管理などの機能を拡張しています。現時点で唯一活発に開発が続いている本流カーネルです。

クライアントとカーネルの対応関係

クライアントを選ぶことは、実質的にカーネルを選ぶことです。ダウンロードページに掲載されているクライアントのうち、Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android、ClashX Meta はいずれも mihomo 系カーネルを採用しており、6種類すべてのプロトコルを完全に利用できます。Clash for Windows は無印/Premium カーネルをベースとしており、開発も停止しているため、VLESS・Hysteria2・TUIC のノードでは非対応エラーになります。過去の設定資産がある利用者にのみ継続利用をおすすめします。サブスクに QUIC 系プロトコルのノードが既に含まれている場合、クライアントは mihomo 系を選ぶしかありません。各クライアントの画面・対応プラットフォーム・更新頻度の詳しい違いはクライアント比較ページを参照してください。結論としては、全プラットフォームでは Clash Plus が第一候補、デスクトップ向けでは Clash Verge Rev が次点です。

F設定とサブスク形式の互換性

サブスクは「サーバーから配信される設定ファイル」であり、形式の互換性問題は2層に分かれます。設定ファイル自体のフィールドがカーネルに認識されるかどうか、そしてサブスクのリンクが返す形式がクライアントに認識されるかどうかです。両者にはそれぞれ別の落とし穴があるため、混同して調査すると余計に時間がかかります。

設定フィールド層:同じ構造でも2種類のフィールド集合

すべての Clash 系カーネルは同一の YAML 構造を共有しています。proxies でノードを定義し、proxy-groups でポリシーグループを定義し、rules で振り分けルールを定義します。差はフィールド集合にあります——無印カーネルは基本プロトコルのフィールドしか認識できませんが、mihomo は同じ構造の中で新しいプロトコル種別や追加パラメータを拡張しています。以下は同一の設定内における新旧2種類のノードの形の違いを示す例です。

proxies:
  - name: "ノード-SS"
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
  - name: "ノード-HY2"
    type: hysteria2
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com

この設定を無印カーネルに渡すと、type: hysteria2 を解析した時点で「unsupported proxy type」的なエラーとなり、設定全体の読み込みが拒否されます——このノードだけスキップされるのではなく、設定全体が失敗するのです。これは「サブスクが新しいクライアントでは正常なのに、古いクライアントでは『ノードが1つもない』」という頻発現象の説明になります。逆に、基本プロトコルのみの設定は mihomo 上でそのまま動作します。互換性は一方向で、新しいカーネルは古い設定を認識できますが、古いカーネルは新しいフィールドを認識できません。

サブスク配信層:形式と User-Agent

サブスクのリンクが返す内容には主に3つの形態があります。Clash YAML(そのまま使える)、Base64 エンコードされた共有リンクの一覧(クライアント側で変換が必要)、そして sing-box など他エコシステムの JSON(Clash 系クライアントは直接対応していません)。多くのサブスクサーバーは、リクエストヘッダーの User-Agent によって配信する形式を切り替えます——同じリンクでも、Clash 系クライアントで取得すると YAML が返り、ブラウザで開くと Base64 が返るといったことが起こります。これには潜んだ問題があります。サーバーが特定クライアントの UA を認識できない場合、誤った形式を配信したり応答自体を拒否したりすることがあり、「他のクライアントでは使えるのに、このクライアントではインポートに失敗する」という現象として現れます。こうした場合は、クライアントのサブスク設定でカスタム UA 文字列を指定するか、サブスク提供元に対応クライアントの一覧を確認しましょう。

サブスクのインポートエラーや更新後にノードがゼロになるといった具体的な障害の項目別チェックは、技術ノート「Clash サブスクが失効・解析失敗する6つの原因とチェック手順」で個別に詳しく解説しているため、本章では割愛します。

G用途別の選定アドバイス

これまでの章の結論を、ここで実行可能なアドバイスとしてまとめます。前提を改めて強調しておくと、回線品質の影響はプロトコル差より大きく、以下のアドバイスはすべて「同じノードサーバーが複数のプロトコル入口を提供している」ことを前提としています。この前提が成立してこそ、用途別にプロトコルを選ぶ意味が生まれます。

ポリシーグループで選定を運用に落とし込む、都度の手動切り替えはしない

選定の実践方法は、都度手動でノードを切り替えることではなく、判断をポリシーグループに落とし込むことです。よくあるやり方は、用途ごとに独立したポリシーグループを作ることです——ブラウジングは url-test グループ(遅延が最も低いノードを自動選択)、ダウンロードは手動の select グループ(スループットの良いノードに固定)を使い、さらにルールで各ドメインを対応するグループに振り分けます。こうすればプロトコル選定は一度行うだけで済み、以降はルールが自動で実行します。グループ内でプロトコルを混在させても構いません——url-test の自動テストが実際のパフォーマンスを比較してくれます。ただし自動テストが反映するのは主に接続確立の遅延であり、スループットの差は自分で使って確認する必要がある点に注意してください。

気にしなくてよい2つのケース

1つ目は、サブスクが1〜2種類のプロトコルしか提供していない場合です。選ぶ余地がないので、そのまま使えばよく、「ガイドによると QUIC のほうが速い」からといってプロトコルの変更を求める必要はありません——得られる効果は不確実なのに、乗り換えの手間は確実にかかります。2つ目は、デスクトップの有線接続で回線品質が良好な場合です。6種類のプロトコルの体感差はほとんど感知できないレベルに収まるため、この場合はルールとポリシーグループの整理(チュートリアルの振り分けの章を参照)に力を入れるほうが、プロトコルを何度も切り替えるよりずっと効果的です。プロトコル選定の価値が発揮されるのは境界的なシーンです——弱い回線、モバイル、低スペック機器、UDP 制限のある環境。この4つの環境では上表に沿って調整すれば、差は明確に感じられます。

Hよくある誤解と{トラブル対処}の手がかり

最終章では、プロトコルとカーネルにまつわる頻出の誤解、そして「症状→原因の見当→参照先」形式の調査インデックスをまとめます。ここでは判断のヒントのみを示し、詳しい調査手順はそれぞれの専門記事を参照してください。

最も広まっている3つの誤解

誤解1:「プロトコルは新しいほど速い」。新しいプロトコルは特定シーンの課題(弱い回線、ハンドシェイク遅延、UDP 転送)を解決するものであり、すべてのシーンで速くなるわけではありません。回線自体の帯域・混雑度・物理的な距離が体感速度の上限を決め、プロトコルはその上限にどれだけ近づけるかという効率にしか影響しません。誤解2:「暗号が強いほど安全なので、最も複雑な暗号のプロトコルを選ぶべき」。6種類のプロトコルはいずれも暗号学的には現代的な AEAD または TLS 1.3 を使用しており、強度はすでに十分です。プロトコル間の複雑さの違いは機能とオーバーヘッドに現れるものであり、「安全性のレベル」には反映されません。想像上の安全性のためにオーバーヘッドの大きいプロトコルを選ぶのは、純粋な損失です。誤解3:「クライアントの遅延テストの数値が使用感を表す」。クライアント内の遅延テストは通常1回の HTTP リクエストにかかった時間であり、接続確立と回線往復を反映するもので、スループット・パケットロス・UDP の扱いは反映しません。2つのノードが同じ遅延数値を示していても、実際の体感には大きな差が出ることがあります。数値は同一プロトコルのノードを横並びで比較するのには有効ですが、プロトコルをまたいで比較する際は慎重に扱うべきです。

症状から原因を特定する

ノードが「unsupported proxy type」と表示される、またはサブスク読み込み後にノードがゼロになる:まずカーネルがそのプロトコル種別に対応していない可能性を疑い、E章を参照してクライアントのカーネルファミリーを確認してください。必要であれば mihomo 系クライアントに乗り換えましょう(ダウンロードページに各プラットフォーム分あります)。VMess ノードだけ単独で不通になり他のプロトコルは正常:端末のシステム時刻が標準時刻と大きくずれていないか確認してください。QUIC 系ノード(Hysteria2/TUIC)が特定のネットワークで明らかに遅い、または不通になり、ネットワークを切り替えると復旧する:UDP が帯域制限されている特徴に合致します。そのネットワークでは TCP 系プロトコルに切り替えてください。全ノードがタイムアウトする:多くの場合、ローカルネットワーク・サブスクサーバー・クライアントの状態に関わる問題であり、プロトコル選定とは無関係です。「Clash のノードが全部タイムアウトして接続できない?」の順序に沿って、近いところから遠いところへと調査してください。プロキシは接続済みなのに Web ページが開けない:通常はシステムプロキシ・DNS・ルールのマッチング段階で詰まっています。「Clash は接続済みなのにWebページが開かない」のチェックリストに沿って1つずつ確認してください。

関連の入口

用語に関する疑問(ポリシーグループ、TUN、GEO データ、REALITY など)は用語集にカテゴリ別で収録しています。インストール・設定・使用中に発生する細かな疑問は FAQで「基礎知識—インストール設定—使い方のコツ—{トラブル対処}」の4分類にまとめています。{プラットフォーム別ガイド}シリーズの技術ノートでは、macOS のネットワーク拡張の権限許可や Windows の TUN モードなど、プラットフォームごとのインストール詳細を画面単位で解説しています。本ページはカーネルとプロトコルのエコシステムの変化に応じて継続的に更新されます。最新のバージョンを基準としてください。