Clash プロトコルとコアの解説

第1章 · まずここから:このページの使い方と、チュートリアルページとの役割分担

サイト内には2つの主要な導線があります。チュートリアルページは導入用の実践ガイドです。クライアントの導入、サブスクリプションの読み込み、モードの選択、振り分けの確認までを順番に進めれば使えるようになり、プロトコルの詳細を理解する必要はありません。一方このページは常設のリファレンスで、「なぜ」「どれを選ぶべきか」に答えます。サブスクのノード一覧に並ぶプロトコルの種類が何なのか、通信速度の差がどこで生まれるのか、スマホではどれが省電力なのか、いくつかのコアがどのような関係にあるのかを解説します。両ページは補完関係にあります。初めて設定する場合はチュートリアルページで一通り進め、動作するようになってからノード一覧の項目を理解したくなったら、このページを章ごとに読み返してください。

本ページは「選定の判断」を軸に構成しており、アルファベット順ではありません。第2章・第3章はプロトコル自体を扱い、まず定番の3種類であるShadowsocks、VMess、Trojanの誕生背景と設計思想を、続いて新世代のVLESS、Hysteria2、TUICがそれぞれどんな課題を解決したのかを解説します。第4章・第5章では横並びで比較し、接続確立の速度、スループットの限界、CPU・メモリ使用量、そしてモバイルで最も気になる電池消費を扱います。第6章・第7章はプロトコルを支えるソフトウェア層に話を移し、コアの系統関係と設定の互換性、サブスクリプション形式が「あるクライアントでは使えるのに、別のクライアントではエラーになる」理由を解説します。第8章では、これまでの結論をシーン別に選べる一覧表にまとめます。

読み方はユーザーのタイプによって3通りに分けられます。Clashを使い始めたばかりの方は、第2章から第4章まで順番に読み、「プロトコルは通信方式、コアは処理エンジン、クライアントは操作画面」という三層構造の理解を築くことをお勧めします。以降のすべての結論はこの枠組みの上に成り立っています。すでに利用中で「特定の種類のノードにつながらない」「あるプロトコルだけ消費電力が高い」といった具体的な問題を抱えている方は、第5章と第7章に直接進み、トラブル対処内の該当する分類項目と合わせて確認してください。家族や友人にクライアントを選んであげる程度で深く追求する必要のない方は、第6章のコア対照表と第8章のシーン別一覧を読めば十分で、10分ほどで読み終えられます。

用語の定義を先に示します。本ページで「プロトコル」とはノードの通信方式、つまり設定ファイルのproxiesセクションにおけるtypeフィールドの値を指します。「コア」とは実際に通信を処理する中核プログラムを、「クライアント」とはグラフィカルインターフェースを持つソフトウェアの外側部分を指します。個々の用語の詳しい解説は用語集に、具体的な不具合の対処手順はトラブル対処にまとめてあり、本ページでは重複して説明しません。わからない用語が出てきたら随時そちらを参照してください。

もう一点、範囲をはっきりさせておきます。本ページで扱うのはあくまで技術的な設計の話であり、ハンドシェイクの往復回数、暗号化のオーバーヘッド、電池消費、互換性などです。特定のサービス提供元を評価するものではなく、ノードの入手元にも触れません。ノードがどのプロトコルを使うかはサブスクリプション提供元が決めることであり、利用者が実際に選べるのは2点だけです。1つは自分のサブスクに対応したコアを備えたクライアントを選ぶこと、もう1つは複数種類のプロトコルのノードが混在するサブスクを使う場合、どのシーンでどのグループに切り替えるべきかを知ることです。本ページのすべての提案はこの2つの判断軸に基づいています。

第2章 · 定番の3プロトコル:Shadowsocks、VMess、Trojanの成り立ちと設計思想

まずは3つの「実績あるプロトコル」を見ていきます。登場が早く、対応範囲も広く、ほぼすべてのコアがサポートしているため、サブスクで最もよく見かける種類です。それぞれの設計思想を理解しておけば、後で新世代プロトコルを見たときに「何が新しいのか」がわかりやすくなります。

Shadowsocks:シンプルさを極めた設計

Shadowsocks(設定上はssと表記)は3つの中で最も古くから確立された方式で、設計思想は「余計なことをしない」ことです。クライアントとサーバーが事前共有鍵を決め、通信は対称暗号アルゴリズムでそのまま封じ込めて転送するだけで、追加のセッション交渉も複雑なメタデータ構造もありません。現行の実装では概ねAEAD系の暗号方式(aes-128-gcm、chacha20-ietf-poly1305など)が採用され、暗号化と整合性検証を両立させています。シンプルさゆえに速く省エネという直接的な利点があり、接続確立にプロトコル上の余分な往復がほとんどなく、暗号化・復号のコストは現代のCPUでは無視できるレベルで、Raspberry Piクラスのルーターでも十分動作します。一方で欠点もはっきりしていて、プロトコル自体にトランスポート層の多重化機能がなく各接続が独立していること、拡張の余地が小さく機能を追加するには外側にプラグインを重ねるしかないことです。一言でまとめると、軽くて速く、古い機器に最も優しい、「動けばいい」という場面での最後の保険的な選択肢です。

VMess:普及の見返りに増えたフィールド、それが招く負担

VMessはV2Rayのエコシステムから生まれたもので、Shadowsocksとは逆の発想、つまり「全部やる」を選んでいます。独自のユーザーID体系、内蔵の暗号化、自由に組み合わせられるトランスポート層(通常のTCP、WebSocket、HTTP/2などいずれも利用可能)を備え、フィールドが豊富なぶんサーバー側で細かなユーザー管理やルーティング管理ができます。しかしフィールドが多いことは負担にもなります。VMessの認証はクライアントとサーバーのタイムスタンプ照合に依存しており、両者のシステム時刻が大きくずれるとハンドシェイクが即座に失敗します。「VMessノードだけ一斉にタイムアウトし、他のプロトコルは正常」という典型的な不具合は、たいていローカルの時刻がずれていることが原因で、対処の流れはノードタイムアウトの切り分け手順に詳しくまとめています。また、VMessでよく使われるWebSocket+TLSの組み合わせは封じ込める層が多く、接続確立の往復回数とCPU負荷はShadowsocksより一段高くなります。一言でまとめると、エコシステムが成熟していて設定の自由度は高いものの「重い」方式であり、新規の構築ではVLESSに置き換わる傾向にあります。

Trojan:HTTPSという成熟した道をそのまま利用

Trojanの設計思想はさらに別の方向を向いています。独自の暗号化を発明せず、通信をそのまま標準的なTLS接続の中に流し込み、サーバー側の挙動を普通のHTTPSウェブサーバーと同じにしてしまうのです。この工夫の実利は大きく、TLSはインターネット上で最も検証されつくした暗号化通信路であり、ハンドシェイクの経路も成熟していて、各種の中間ネットワーク機器との互換性も良く、クライアント側の実装もシンプルです。代償として、導入の敷居がサーバー側に移り、有効なドメイン証明書が必要になり、証明書の期限切れやドメイン解決の異常があるとノード全体が使えなくなります。この種の不具合はクライアント側では解決できず、サブスクリプション提供元の対応を待つしかありません。利用者にとっては、Trojanノードの動作は普段から安定しており、遅延も予測しやすいため、ウェブブラウジングや動画視聴に向いた安定した選択肢です。

第3章 · 新世代プロトコル:VLESS、Hysteria2、TUICはそれぞれ何を解決したのか

3つの新方式はどれも唐突に生まれたわけではなく、それぞれ前章で挙げた具体的な課題に対応しています。見るときのポイントは、それがどの処理をプロトコル層から取り除き、どの処理を重くしたのかです。

VLESS:VMessの軽量化版

VLESSはVMessの引き算バージョンと考えるとわかりやすいです。内蔵の暗号化とタイムスタンプ照合を取り除き、機密性を完全に外側のTLSに委ね、プロトコル自体は最小限のユーザー識別とルーティング情報だけを保持します。暗号化の封じ込め層が1つ減ったことでCPU負荷が大きく下がり、時刻のずれによるハンドシェイク失敗もなくなりました。VMessユーザーが最も頭を悩ませていた2つの問題が一度に解決されたわけです。VLESSは新しいトランスポート層と組み合わされることが多く、例えばTLSのセッション特性を最適化した通信方式などがありますが、これらの組み合わせが使えるかどうかはコアのバージョンに依存します。この点は第7章のサブスク互換性のところで詳しく触れます。選定時の目安として、同じサブスク内にVMessとVLESSの両方があり、クライアントのコアが対応していれば、VLESSを優先してほぼ損はありません。

Hysteria2:劣悪な通信環境向けに設計されたQUICプロトコル

Hysteria2(設定上はhysteria2と表記)は土台そのものを変えています。TCPをベースにせず、QUIC(UDP上に構築された現代的なトランスポートプロトコル)の上に構築されており、独自の積極的な輻輳制御を組み合わせています。この組み合わせが狙うのは具体的なシーン、つまりパケットロスやジッターの多い通信環境、モバイル通信網や複数の通信事業者をまたぐ長距離接続などです。従来のTCPはパケットロスが起きると速度が大きく下がりますが、Hysteria2は事前に設定した帯域を維持し続け、失われたぶんは補うという戦略をとるため、弱いネットワーク環境でのスループットはTCP系プロトコルより明らかに優れることが多いです。代償は2つあります。1つは帯域推定と再送処理を常に行っているため「良好な回線」では優位性がなく、むしろリソースを多く消費すること、もう1つはUDPベースのため、UDP通信を制限したり干渉したりするネットワーク環境ではTCP系プロトコルより性能が落ちることです。一言でまとめると、弱いネットワークでは強いが、良いネットワークでは平凡です。

TUIC:QUICの多重化を最大限に活用

TUICも同じくQUIC上に構築されていますが、力点が異なります。QUIC本来の多重化機能と0-RTTセッション再開を最大限に活用し、複数のプロキシリクエストを1本のQUIC接続にまとめて、互いに待たされることなく処理します。一度接続したことのあるサーバーとはほぼ往復ゼロでセッションを再開できるため、2回目以降の接続確立はほぼ即時です。頻度が高く小さいリクエストが多いシーン(ウェブブラウジング、チャットアプリなど)では体感の向上が明確です。Hysteria2と比べると、TUICの輻輳制御はより一般的な実装に近く、積極的な帯域の奪い合いを行わないため、継続的な負荷は穏やかです。同じくUDPを使うため、Hysteria2と同様の環境依存性があり、UDPに厳しいネットワークでは性能が下がります。

第4章 · 接続速度とリソース消費:最初のデータはハンドシェイクの往復回数で決まる

「どのプロトコルが速いのか」は最もよく聞かれる質問であり、最も答えを誤りやすい質問でもあります。まず「速さ」を2つに分けましょう。接続確立の速さ(リンクを開いてからコンテンツの読み込みが始まるまでの一瞬)と、継続的なスループット(大きなファイルのダウンロードや高ビットレートの動画視聴時の安定した速度)です。この2つを決める要因は全く異なるので、選定時は分けて考える必要があります。

接続確立の速さ:往復回数を数える

接続確立の速さは基本的に「クライアントとサーバーの間で何回やり取りが必要か」で決まり、1回のやり取りごとにRTT(往復時間)を1回消費します。おおまかに数えると、ShadowsocksはTCPで、TCPハンドシェイクが1回完了すればすぐにデータを送信できます。TrojanとVLESSはTCPの上にさらにTLSハンドシェイクが1回必要で、往復が1回増えます。VMessがWebSocket+TLSの構成の場合、さらにアップグレードハンドシェイクが重なり、往復回数は最も多くなります。QUIC系のHysteria2とTUICは、トランスポートのハンドシェイクと暗号化のハンドシェイクを1回のやり取りにまとめ、初回接続を1往復で完了させます。TUICの0-RTT再開はさらに進んでおり、以前接続したことのあるサーバーへの再訪時はほぼ往復を使いません。物理的な遅延自体が大きい場合(例えば大陸間の接続でRTTが200ms以上あるようなケース)、この往復回数の差は体感の差として拡大されます。同じサブスク内でQUIC系ノードは「開けばすぐつながる」のにTCP系ノードは「一瞬もたついてから動く」という現象は、多くの場合これが原因です。

継続的なスループット:ボトルネックは暗号化ではないことが多い

継続的な通信の段階では、現代のCPUはAEAD暗号化・復号を家庭用の帯域幅よりはるかに速く処理できるため、暗号化自体がボトルネックになることはほとんどありません。実際に差が生まれるのは、トランスポート層がパケットロスにどう反応するかです。TCP系プロトコル(SS、VMess、Trojan、VLESS)はOSのTCPスタックの輻輳制御に支配され、パケットロスが起きればすぐに速度が下がります。Hysteria2は独自の戦略で帯域を維持し続けるため弱いネットワークでのスループットが優位です。TUICはその中間に位置します。結論は直感に反します。回線が良好な場合、6つのプロトコルのスループットの差はごく小さく、回線が悪い場合の差は主にトランスポート層に起因し、プロトコル自体の違いではありません。

メモリとCPU:目安として

リソース消費については、定性的な順序を示すだけで十分です。CPU負荷はおおむね低い方から、SS ≈ VLESS < Trojan < TUIC < VMess ≈ Hysteria2の順で、VMessは多層の封じ込め処理が、Hysteria2は継続的な帯域探測が負荷を高くしています。メモリの差は主に接続数に起因し、プロトコル自体の違いではありません。QUIC系プロトコルは1本の接続で複数のリクエストをまとめて処理するため接続の総数が少なく、むしろメモリ効率が良い場合があります。メモリがMB単位しかないルーターのような機器では、Shadowsocksの極めてシンプルな実装が唯一の安心できる選択です。

第5章 · モバイル端末の電池消費:消費電力の原因は3つ、プロトコルはそのうちの1つ

「Clashを起動するとスマホの電池が早く減る」はモバイル端末で最もよく聞く不満です。まず責任の切り分けをしましょう。電池消費は3つの層から来ています。プロトコル自体の保持通信の挙動、クライアントのヘルスチェック戦略、システムレベルの常駐方式です。3つの層は互いに独立しているため、順に切り分けて確認しないとプロトロコルを不当に責めることになります。

プロトコル層:UDPの保持通信は見えない電池消費の元凶

QUIC系プロトコル(Hysteria2、TUIC)はUDPセッションを維持するために定期的に保持パケットを送信する必要があり、Hysteria2の帯域探測処理は接続がアクティブな間ずっと動作し続けます。パケットを送信するたびにモバイル機器の無線モジュールが短時間ウェイクアップされ、この無線モジュールのウェイクアップこそがモバイル端末の電池消費の大きな原因です。TCP系プロトコル(SS、Trojan、VLESS)は通信がない間長時間静かにしていられるため、システムがより深い省電力状態に入ることができます。そのため電池優先のシーンでは、第4章と正反対の結論になります。電源接続時やWi-Fi利用時はQUIC系を安心して使い、バッテリー駆動のモバイル通信環境ではTCP系の軽量プロトコルを優先してください。

クライアント層:ヘルスチェックの間隔は最も見直す価値がある設定

url-test系のポリシーグループはintervalの周期でグループ内の全ノードに対して速度テストを行います。間隔を短く設定しすぎると(例えば60秒)、スマホが1分ごとに数十のノードを1つずつ起こしてテストすることになります。モバイル端末では間隔を600秒以上に広げても体感の遅延はほとんど変わらず、電池消費への効果はすぐに現れます。

proxy-groups:
  - name: 自動選択
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 600        # モバイル端末は600秒以上を推奨
    tolerance: 80        # 新旧ノードの遅延差が80ms未満なら切り替えない
    proxies: [ノードA, ノードB]

toleranceも併せて設定する価値があります。これがないと、遅延の近い2つのノードが何度も切り替わり、切り替えごとに新規接続の確立が発生します。サブスクがプロバイダーによって管理されていて設定を変更できない場合は、クライアントの画面上で自動速度テストグループをselect型の固定ノードに手動で切り替えれば同等の効果が得られます。

システム層:TUNの常駐とメーカー独自のバックグラウンド制御

TUNモードは仮想ネットワークインターフェースを作成して通信を全面的に処理するため、プロセスは常駐しなければなりません。Androidの各メーカーが実装するバックグラウンド制限機能はこのプロセスを繰り返し強制終了・再起動させようとし、この強制終了と再起動の繰り返しの方が静かに常駐しているよりも電池を多く消費します。TUNとシステムプロキシの仕組みの違いについてはTUNモードとシステムプロキシの違いで層ごとに解説しています。Androidでバッテリー統計から消費電力の原因を特定し、1つずつ対処していく完全な手順はAndroid電池消費のチェックリストを参照してください。十分な原則としては、スマホでネットワーク全体を強制的に処理する必要がなければシステムプロキシモードを使い、TUNはデスクトップ端末用に取っておくことです。

第6章 · コアの系統:オリジナル、Meta、mihomoの関係とは

互換性の問題の多くは「Clash」を1つのソフトウェアだと思い込んでいることが原因です。実際にはこれは1つの系統で、コアが設定に従って通信を処理し、クライアントはコアの外側にかぶさる操作画面にすぎません。系譜を理解すれば、第7章の互換性の問題も一目瞭然になります。

系譜:1度の分岐、2つの名前

最初のオープンソースプロジェクトはオリジナルのClashコアで、クローズドソースのPremiumビルド(TUNなどの機能が追加)も併存していました。オリジナルのリポジトリが更新を停止した後、コミュニティが保守するClash.Metaブランチが開発の主軸を引き継ぎ、新しいプロトコルやルールタイプを継続的に追加し、後にmihomoという名前に改称されました。つまり「Clash.Meta」と「mihomo」は同じ血脈の前後の名前であり、日常的に言う「Meta系コア」とはこれを指します。現在も活発に保守され、6種類すべてのプロトコルに対応しているのはmihomoのみです。クライアントを選ぶ際にまず確認すべきなのは、そのクライアントがどちらのコアを内蔵しているかです。

機能差:一覧で全体像を把握

ルールについて補足すると、mihomoはオリジナルコアの一般的なフィールド(port、mode、DOMAIN-SUFFIX、GEOIP、MATCHなど)との下位互換性を保っているため、古い設定をmihomoにそのまま読み込ませても通常は問題なく動作します。しかし逆方向は成立せず、設定にmihomo専用の記法が1つでも含まれていると、オリジナルコアはエラーを出して読み込みを拒否します。

rules:
  - GEOSITE,category-ads-all,REJECT   # mihomoのみ認識、オリジナルコアはエラー
  - GEOIP,CN,DIRECT                   # 両系統のコアで共通
  - MATCH,手動選択                     # 両系統のコアで共通

クライアントとコアの対応関係

クライアントダウンロードページのラインアップに当てはめると、Clash Plus(全プラットフォーム共通の第一候補)、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for AndroidはいずれもMeta系の機能をベースにしており、6種類すべてのプロトコルが利用できます。ClashX MetaもMeta系ですが既に保守が終了しています。Clash for Windowsはオリジナルコアをベースにしており、既に保守が終了しています。これが現在最もよく見られる「サブスクに新しいプロトコルのノードがあるのに読み込みに失敗する」原因です。まだこれを使っている方は、Clash Verge Revへの移行手順をWindowsでのclash Verge Rev導入手順にまとめていますので参照してください。選定のロジックを一言でまとめると、サブスクにVLESS、Hysteria2、TUICのいずれかが1つでも含まれていれば、クライアントは必ずMeta系でなければならず、それ以外の答えはありません。

第7章 · サブスク形式とフィールドの互換性:クライアントを変えるとエラーになる理由

プロトコルとコアの間にはもう1つの層、サブスクリプションが存在します。同じサブスクリプションリンクでも、クライアントAでは全ノードが表示され、クライアントBでは何も表示されない、という問題はほぼこの層に原因があります。この章ではサブスクの形式と失敗のパターンを整理します。

サブスクの2つの形式

サブスクリンクが返す内容は2種類に分かれます。1つ目は完全なClash設定(proxies、proxy-groups、rulesを含むYAML全体)で、これはクライアントがそのまま使えるものであり、振り分けルールはサブスク提供元が作成済みです。2つ目は汎用のノードリスト(多くはBase64エンコードされた共有リンクの集合)で、Clash系クライアントはそのままでは利用できず、サブスクリプション変換サービスを通じてClash形式に変換する必要があります。この変換処理は見えにくい変動要因で、変換テンプレートが出力設定の記法をどちらのコア系統に合わせるか決めており、テンプレートが古いとHysteria2のノードがひそかに除外されたり、オリジナルコアが認識できないフィールドが出力されたりすることがあります。ノード数が合わない場合は、まずサブスクの形式を確認し、その後に変換設定を確認するという順番を守ってください。

フィールドの互換性:1つのフィールドが設定全体を崩壊させる

YAML設定は全体として読み込まれるため、コアが認識できないノードのtypeやフィールドに遭遇したときの処理は実装によって異なります。緩やかな実装はそのノードだけスキップします(ノードが減ったように見えます)。厳格な実装は読み込み自体を拒否します(サブスクの読み込みに失敗し、ノード一覧が空になります)。Hysteria2のノードを例にすると、その専用フィールドはオリジナルコアにはどれも認識されません。

proxies:
  - name: サンプル-HY2
    type: hysteria2          # オリジナルコアはこのtypeを認識できない
    server: example.com
    port: 443
    password: your-password
    sni: example.com

逆に落とし穴になるケースもあります。一部のクライアントはインポート時に設定を「親切に」書き換えたり、デフォルトのフィールドを補完したりしますが、その書き換えロジックが異なるため、同じサブスクでもクライアントによって最終的な動作に微妙な差が出ることがあります。「特定のクライアントだけ異常」という状況に遭遇したら、サブスクのリンクをブラウザで直接開いて元の内容を確認するのが最も速い切り分け方法です。

読み込み失敗時の確認手順

決まった4ステップを順番に実行してください。①サブスクが期限切れになっていないか確認する(多くの失効したサブスクはエラーではなく空の内容やエラーページを返します)。②クライアントがMeta系かどうか確認する(第6章の表を参照)。③サブスク変換を経由しているか、その変換テンプレートがサブスク内のすべてのプロトコルに対応しているか確認する。④クライアントのログに表示されるYAMLエラーの行番号から具体的なフィールドを特定する。最初の2ステップで問題の大半は解決します。「ノード一覧が空」「全ノードがタイムアウトする」というよくある2つの症状については、トラブル対処とノードタイムアウトの切り分けにそれぞれ完全な手順がありますので、その通りに進めてください。

第8章 · シーン別選定:一目でわかる早見表

これまでの7章の結論を、シーン別に確認できる表にまとめました。使い方は、まず左の列で自分の主な利用シーンを見つけ、「優先—次点」の順でポリシーグループに固定またはグルーピングしてください。サブスクに優先候補がない場合は次点に切り替えれば十分で、無理に優先候補を探す必要はありません。

表以外にも、書き留めておく価値のある3つの一般原則があります。1つ目は、プロトコルの選定は常にノードの選定より後に考えるべきということです。同じプロトコルでもノードによって品質の差が大きく出ることが多く、これは同じノードでプロトコルが違う場合の差より大きいことがよくあります。まず遅延テストと実際のダウンロードでノードのプールを絞り込み、その後でプロトコルの好みを検討してください。2つ目は、毎日手作業で選ぶのではなく、ポリシーグループで決定を固定することです。弱いネットワーク向けのQUIC系ノードを1つのグループに、省電力向けのTCP系ノードを別のグループにまとめておき、シーンが変わったらグループを切り替えるだけにすれば、数十のノードを毎回探し回る必要がなくなります。ポリシーグループの作成方法はチュートリアルページの応用編で段階的に解説しています。3つ目は、定期的に見直すことです。サブスク提供元はノードのプロトコル構成を変更することがあり、コアも継続的に進化しています。本ページの定性的な結論自体は安定していますが、あなたの手元のサブスクにとっての最適解は数か月ごとに検証する価値があります。

選定の方針が決まったら、残る作業は2つだけです。クライアントダウンロードページからお使いのプラットフォーム向けにMeta系クライアントを入手してください。全プラットフォーム共通の第一候補はClash Plusで、Windows/macOS/LinuxならClash Verge RevやFlClashも選べます。その後チュートリアルページに戻ってサブスクの読み込みと振り分けの確認を済ませてください。設定の途中で何か詰まったらトラブル対処を分類から検索し、わからない用語があれば用語集を随時確認してください。このリファレンスで押さえるべき要点は、これでひととおり網羅できました。