Clash プロトコル完全ガイド

第1章 · ガイドの位置づけと使い方

まず本ガイドとサイト内の他ページの役割分担について説明します。はじめには「インストールから接続まで」の主要手順を担当し、クライアントのダウンロード、サブスクの読み込み、モードの選択、接続確認という4ステップで利用開始できる内容で、プロトコルの知識は一切不要です。本ガイドが担うのはもう半分の役割で、「ノード一覧にある ss・vmess・trojan・hysteria2 という表記は何を意味するのか」「同じサブスクなのに速いノードと遅いノードがあるのはなぜか」「古いクライアントで一部のノードが読み込めないのはなぜか」といった、原理の理解が必要な疑問に答えます。両者の関係を一言でまとめれば、チュートリアルページは「使えること」を保証し、本ガイドは「選べること」を保証するものです。まだインストールを済ませていない方は、先にチュートリアルページの手順を一通り実行し、その後必要に応じて本ページを参照することをお勧めします。各プラットフォームのインストーラーはダウンロードページにまとまっており、いずれのプラットフォームでも Clash Plus を第一候補として推奨しています。

全体の構成は参照しやすい順序で組んでいます。第2章から第4章では技術系統ごとに3グループへ分けて6大プロトコルを紹介します。Shadowsocks と VMess は初期の自作暗号化方式の系統、Trojan と VLESS は標準 TLS を流用する偽装方式の系統、Hysteria2 と TUIC は QUIC トランスポートを基盤とする新世代の系統です。第5章では6つを同一の表で横並びに性能比較し、モバイル端末の省電力性についても個別に取り上げます。第6章では無印版 Clash、Clash.Meta、mihomo という3世代のカーネルの変遷と機能差を整理します。これはクライアントがどのプロトコルに対応できるかを直接左右する要素です。第7章では Clash サブスクリプションと他の共有形式との互換関係を説明します。第8章では利用シーン別に実践できる選定指針としてまとめます。

先に確認しておきたい用語の取り決めが2つあります。1つ目は、本ガイドで言う「プロトコル」とは Clash 設定ファイルの proxies 項目にある type フィールドに対応するもので、クライアントと接続先サーバー間の通信プロトコルを指し、「ルール」や「プロキシグループ」とは別の階層の概念です。2つ目は、ほとんどのユーザーはプロトコルのフィールドを手書きすることはなく、ノードの各パラメータはサブスクリプションによって配信され、クライアントが解析してノード一覧として表示します。したがって「プロトコルを選ぶ」というのは実際には次の2つの行動に落とし込まれます。複数プロトコルが混在するサブスクの中で特定タイプのノードを優先的に選ぶこと、そしてサービス提供者とやり取りする際に特定タイプのノードを明確に要望することです。この点を理解しておくことで、以降の各章の選定指針が実際に役立つようになります。

第2章 · Shadowsocks と VMess:2世代の設計思想

Shadowsocks:最小構成の暗号化転送

Shadowsocks(以下 SS)は6大プロトコルの中で最も構造が単純で、登場も最も早いプロトコルです。設計目標はただ1つ、ローカルと接続先サーバーの間に暗号化された転送経路を確立することのみで、それ以外の機能は一切付加しません。動作の仕組みは、クライアントがローカルでリクエストを待ち受け、アプリからの通信を受け取ると事前共有パスワードで暗号化し、接続先サーバーへ送信して復号・転送するというものです。プロトコル自体にハンドシェイク段階もセッション状態もバージョン交渉もなく、最初のパケットからすでに実データを含みます。現行の実装ではすべて AEAD 暗号スイートを採用し、よく使われる値は aes-128-gcm、aes-256-gcm、chacha20-ietf-poly1305 です。中でも ChaCha20 系は AES ハードウェア命令を持たない古いスマホやルーターで明らかに速度が優れています。

この極めてシンプルな構造には両面性があります。良い面としては、オーバーヘッドが全プロトコル中最も低いことです。ハンドシェイクがないため即座に接続でき、暗号化も一層のみなので CPU・メモリ消費はほぼ無視できるレベルです。そのため SS は今なお古いデバイスや組み込み環境で第一候補とされています。一方で、この構造上の通信特性は長年にわたり詳しく研究されてきたため、現行のデプロイでは伝送層のプラグインで補強することが多くなっています。これはサーバー側の責任範囲であり、クライアント側で対応する必要はなく、サブスクリプションから配信される plugin フィールドをそのまま解析すれば問題ありません。

VMess:構造化されたセッション型プロトコル

VMess は V2Ray プロジェクトのネイティブプロトコルで、SS より後に登場し、発想も全く異なります。極限までシンプルな通路を作るのではなく、構造がしっかりしたセッションプロトコルを作るという方向性です。VMess はユーザー UUID を認証情報として使い、リクエストヘッダーに命令や暗号化方式などのメタデータを含めるほか、時刻検証機構を内蔵しています。クライアントとサーバーのシステム時刻の差が許容範囲(約90秒)を超えるとハンドシェイクが失敗します。これが「ノードが全て接続不能なら、まずスマホの時刻を確認する」という定番のトラブル対処法の由来です。VMess のもう1つの特徴は伝送層の組み合わせが非常に柔軟であることで、TCP をそのまま使うこともできますし、WebSocket や gRPC などのトランスポートに TLS を重ねることもできます。WebSocket に TLS を重ねる構成では外部からは普通の暗号化された Web セッションに見えるため、共有ホスティング環境でよく使われる形態です。

トレードオフも明確です。構造化されたヘッダーと多層トランスポートは柔軟性をもたらす一方、SS を上回るハンドシェイク遅延と CPU 負荷を伴います。かつての alterId による動的ポート難読化機構はすでに AEAD ヘッダーに取って代わられており、現行のサブスクリプションでは同フィールドは 0 であるべきです。0 以外の値を持つ古い形式のノードを見つけた場合は、互換性と安全性の両面で疑問が残ります。両者の典型的な設定フィールドは以下の通りで、サブスク解析結果の確認用途にとどめ、基本的に手動での書き換えは推奨しません。

proxies:
  - name: "サンプル-SS"
    type: ss
    server: node.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
  - name: "サンプル-VMess"
    type: vmess
    server: node.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    network: ws
    ws-opts:
      path: /ws

第3章 · Trojan と VLESS:標準 TLS を流用する偽装系統

Trojan:HTTPS に紛れ込む

Trojan の設計思想は前の2つとは対照的で、新たな暗号化構造を発明するのではなく、インターネット上で最も普及している TLS をそのまま流用します。外部から観測すると、Trojan の通信は標準的な HTTPS アクセスそのもので、実在するドメイン、有効な証明書、標準的なハンドシェイクがすべて揃っています。正しいパスワードを持つクライアントだけが TLS 通信の中でプロキシリクエストとして識別され、それ以外のアクセス(ブラウザで直接そのドメインを開く場合も含む)はサーバー上に設置された実際の Web サイトへフォールバックされます。この仕組みではサーバー側がドメインと証明書を保有している必要があり、デプロイの負担はサービス提供側にかかりますが、クライアント側は逆に極めてシンプルで、主要フィールドは password と sni の2つだけです。

性能面では、Trojan の接続コストは TLS ハンドシェイク1回分にすぎません。データ面も TLS の単層暗号のみで、VMess を WebSocket + TLS で使う多層構成より CPU 負荷が低く、スループットの上限も高くなります。選定時に注意すべきフィールドは skip-cert-verify だけで、true にすると証明書検証をスキップすることになるため、理由が明確なトラブル対応時に一時的に使う程度にとどめ、通常設定でこの値が出てきた場合はサービス提供者に理由を確認すべきです。

VLESS:さらなる簡略化への一歩

VLESS は VMess に対する体系的な簡略化と理解できます。外層にすでに TLS が機密性を担っているなら、プロトコル内層での暗号化は重複作業になります。そのため VLESS は内蔵の暗号化を取り除き、プロトコルヘッダーを最小限まで圧縮しました。認証には引き続き UUID を用い、機密性は完全に外層の TLS に委ねます。この土台の上で、VLESS の生態系は2つの重要な拡張を発展させました。XTLS フロー制御(よく使われる値は xtls-rprx-vision)は内外2層の暗号処理の重複を減らすことで大容量通信のスループットを高めます。REALITY は第三者の実在する Web サイトの TLS フィンガープリントを借用してハンドシェイクを行うことで、サーバー側が独自のドメインや証明書を用意する必要をなくします。

クライアント利用者にとって、VLESS 系統には実務上の重要ポイントが2つあります。1つ目は、プロトコルの対応状況が完全にカーネルの世代に依存する点です。mihomo カーネルは VLESS、XTLS、REALITY を完全にサポートしていますが、無印版 Clash カーネルはいずれも認識しません。この種のノードを使って unsupported proxy type というエラーが出た場合は、まずクライアントのカーネルを確認してください(第6章参照)。2つ目は、VLESS 系のフィールド数が6大プロトコル中最も多いことです。flow、reality-opts、client-fingerprint などのいずれか1つでもサーバー側と一致していなければ接続に失敗するため、この種のノードは必ずサブスクリプションによる自動配信に依存すべきで、手動での書き写しはミスが非常に起きやすくなります。

第4章 · Hysteria2 と TUIC:QUIC を基盤とする新世代プロトコル

共通基盤:QUIC がもたらすもの

前の3章で紹介した4種類のプロトコルはすべて TCP の上に構築されていますが、本章の2つは QUIC の上に構築されています。QUIC はユーザースペースで動作する UDP ベースのトランスポートプロトコルで、HTTP/3 の基盤にもなっています。この層の変更により3つの共通メリットが得られます。1つ目は 0-RTT によるセッション復元で、再接続時に追加のハンドシェイク往復がほとんど発生せず、初回接続の体感速度は「TCP の3ウェイハンドシェイク + TLS ハンドシェイク」を重ねる従来方式より明らかに優れています。2つ目はコネクションマイグレーション機能で、スマホが Wi-Fi とモバイルデータ回線を切り替えてもセッションを維持できるため、接続を再確立する必要がありません。3つ目は輻輳制御がユーザースペースで実装されているため、OS カーネルの TCP スタックの制約を受けず、より積極的なアルゴリズムに切り替えられる点です。

2つの異なる実装アプローチ

Hysteria2 は積極的な帯域利用を重視するアプローチを採用しています。特徴的な設計として、ユーザーが回線帯域(設定内の up/down フィールド)を宣言できるようにしており、内蔵の輻輳制御はこれに基づいて回線を積極的に埋めます。パケットロスや遅延が大きい不安定な回線環境では、標準的な輻輳制御に依存する TCP 系プロトコルよりスループットが明らかに優れることが多く、これは後者がパケットロスを検知すると保守的に速度を落とすのに対し、Hysteria2 はそうならないためです。見た目の偽装は HTTP/3 に基づいており、通常の第3世代 Web トラフィックと同じ層に位置します。一方 TUIC は「より標準的な QUIC」というアプローチを取り、積極的な帯域の埋め込みは行わず、輻輳制御アルゴリズムを bbr、cubic、new_reno から選択できます。また UDP 転送モードを2種類(over stream と native)ネイティブに定義しており、ゲームや音声通話といった UDP 系の通信の転送処理が TCP 系プロトコルよりずっとクリーンです。

明記すべきコスト

QUIC 系のコストとメリットも同様に明確です。1つ目は、通信が UDP に依存するため、一部のアクセス網では UDP トラフィックに帯域制限や優先度の低い扱いが施されており、この場合 QUIC 系プロトコルの実測速度が普通の Trojan 接続より劣ることさえあります。これは実測しない限り判断できません。2つ目は、ユーザースペースのプロトコルスタックと全経路暗号化により CPU 使用率が TCP 系プロトコルより高くなり、モバイル端末では消費電力の増加に直結します(第5章で詳述)。3つ目は、QUIC は定期的な探測によって接続の活性を維持するため、スマホをバックグラウンドで常駐させている際のウェイクアップ回数が、静かな TCP の持続接続より多くなります。総合すると、QUIC 系プロトコルは「特定シーンの強力な選択肢」であり、標準の選択とは位置づけるべきではありません。

第5章 · 通信速度・リソース消費・モバイル端末の省電力性の比較

比較の前提

先に前提を明確にしておきます。プロトコルの性能はサーバー規格、回線品質、トランスポートの組み合わせに大きく左右されるため、環境を無視した「あるプロトコルの遅延は何ミリ秒」という絶対値には意味がありません。以下の表は同等のサーバー・回線条件下での相対的なレベルを示すものであり、「同一サブスク内の各種ノードの優劣を比較する」ための参考にとどまり、特定のノードの性能を保証するものではありません。表中の VMess は最も一般的な WebSocket + TLS 構成、VLESS は REALITY 構成を前提としています。

各列の結果が生じる理由

初回接続の速さはハンドシェイクの階層数によって決まります。SS はハンドシェイクなしで最初のパケットからデータを送れます。Trojan は TLS ハンドシェイクが1回だけです。VMess を WebSocket + TLS で使う場合は TCP、TLS、WebSocket の3層を順に確立する必要があるため最も遅くなります。QUIC 系の2つはセッション復元時に 0-RTT を実現できるため、再接続シーンで特に優位性が際立ちます。不安定回線下のスループットは輻輳制御によって決まります。TCP 系プロトコルは OS の標準的な輻輳制御に縛られ、パケットロス時に保守的に速度を落とします。Hysteria2 は積極的な帯域埋め込み戦略により、パケットロス環境での速度低下が最も小さくなります。CPU の項目は暗号化の階層数とプロトコルスタックの位置によって決まります。単層暗号の SS、Trojan、VLESS は最も省電力で、QUIC 系のユーザースペースプロトコルスタック自体が継続的な計算負荷になります。

モバイル端末の消費電力についての補足

モバイル端末の消費電力については、決定要因がデスクトップ環境とは異なるため、個別に取り上げる価値があります。スマホ上では Clash が VpnService によって仮想ネットワークインターフェースをバックグラウンドで常駐させ、消費電力は3つの要素から成ります。カーネルが通信を処理する CPU 時間、接続の活性を維持するためのハートビートによるウェイクアップ、そして無線基地局モジュールが起動される回数です。TCP 系プロトコルはアイドル時にほぼ静かですが、QUIC は活性確認の頻度が高く、モバイル通信下では毎回の探測が基地局モジュールを起動させる可能性があり、長時間の待機での消費電力差はかなりのものになります。実測による調査手順とバックグラウンド設定の最適化については、サイト内ブログの《Clash でスマホの電池が早く減る場合の対処法》に詳しい手順が掲載されています。Android 版の VpnService の権限設定とバックグラウンド維持の仕組みは《Clash Android クライアント利用ガイド》を参照してください。

第6章 · カーネル系譜:無印版 Clash、Meta、mihomo の関係

3世代の変遷

「Clash」という言葉は、現在の文脈では少なくとも3つのものを指します。1つの YAML 設定形式、1つのカーネル系譜、そして多数の GUI クライアントです。カーネルの変遷を整理することは、互換性の問題を理解する前提になります。最初の無印版 Clash カーネルがこの生態系の基本的な設計パターンをすべて確立しました。YAML 設定、proxies/proxy-groups/rules の3段構成、ルールによる振り分け、プロキシグループです。クローズドソースの Premium ビルドは追加で TUN モードなどの拡張機能を提供していました。その後、コミュニティのフォークである Clash.Meta が設定の互換性を保ちながらプロトコル対応を大幅に拡張しました。無印版のリポジトリがアーカイブされ開発が止まった後、Meta フォークは開発を継続して mihomo に改名され、現在の事実上の主力カーネルとなっています。本サイトのトップページの認証情報欄に記載されている KERNEL mihomo は、このカーネルを指しています。

機能差の対照

設定の互換性とクライアントの対応関係

設定の互換性は一方向の原則に従います。無印版カーネル向けに書かれた設定ファイルは mihomo 上でも基本的にそのまま動作します。mihomo は旧フィールドとの互換性を良好に保っています。しかし逆は成立せず、VLESS ノード、新方式のルールセット、スニッフィング設定を含むファイルを無印版カーネルに渡すと、起動時にそのままエラーになります。この原則をクライアントレベルに反映すると次の選定結論になります。本サイトのダウンロードページに掲載されているメンテナンス中のクライアント(各プラットフォームで第一候補として推奨する Clash Plus、および Clash Verge Rev、FlClash など)はすべて mihomo カーネルを内蔵しており、6大プロトコルすべてが利用可能です。メンテナンスが終了した Clash for Windows と ClashX Meta のアーカイブ項目については、前者が無印版カーネルを搭載しているため QUIC 系および VLESS ノードを認識できません。ノード一覧に unsupported proxy type のようなエラーが出た場合は、本表を参照して mihomo 系のクライアントに切り替えるべきで、サブスクリプションを変更する必要はありません。各クライアントの詳しい横並び比較はクライアント比較ページも参照してください。

第7章 · サブスクリプション形式と設定の互換性

よく見る3種類の形式

日常的に接する「サブスクリプション」には実際には3つの形態があり、互換範囲もそれぞれ異なります。1つ目は Clash 専用サブスクリプションで、proxies、proxy-groups、rules の3セクションをすべて含む完全な YAML ドキュメントであり、Clash 系クライアントが直接読み込めるため最も理想的な形態です。2つ目は単一ノードの共有リンクで、ss://、vmess://、trojan:// のような URI 形式で、1つのリンクが1つのノードを表し、グループやルールの情報は含みません。3つ目は汎用の集約サブスクリプションで、複数行の共有リンク全体を Base64 エンコードして HTTP で配信するもので、クライアントの生態系をまたいだ最大公約数的な形式です。後者2つは Clash のネイティブ形式ではないため、利用には変換が必要です。多くのサブスク提供サービスは Clash 専用アドレスも同時に提供しているので、そちらを優先的に使うべきです。mihomo 系クライアントは一般的な共有リンクの解析機能を標準搭載していますが、変換結果にはノード情報のみが含まれ、グループやルールは別途設定ファイルで補う必要があります。

ノードと設定の分離:proxy-providers

一歩進んだ使い方として押さえておきたい仕組みが proxy-providers です。ノードの取得元を外部リソースとして宣言し、メイン設定ファイルはグループとルールのみを担当し、カーネルが定期的に自動でノード情報を取得・更新します。この仕組みの価値は、独自のルール設定とサブスクリプションの更新が互いに干渉しない点にあります。サブスクリプションから配信される完全な設定を直接書き換えてしまうと、次回の更新で上書きされてしまいますが、providers 構成であれば長期にわたって維持管理できます。典型的な記述例は以下の通りです。

proxy-providers:
  main:
    type: http
    url: "https://example.com/sub?token=xxxx"
    interval: 86400
    path: ./providers/main.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

互換性に関する注意点

実務上記録に値する3つの経験があります。1つ目は、同じサブスクリプションのアドレスでもクライアントによって返される内容が異なる場合がある点です。サーバー側はリクエストの User-Agent に基づいてクライアントの種類を判定し、それに応じた形式を配信することが多いため、「ブラウザでサブスクアドレスを開いたときに見える内容」と「クライアントが実際に取得する内容」は必ずしも一致しません。サブスクリプションの問題を調査する際にブラウザで見た内容を基準にすべきではありません。2つ目は、新しいプロトコルのノードが使えるかどうかはサブスク出力側とカーネルの両方によって決まる点です。クライアントが mihomo を動作させていても、サブスク側が依然として無印版のフィールド形式で出力していれば、Hysteria2 や VLESS といったノードは一覧に表示されません。この場合はサービス提供者に mihomo 形式のサブスクアドレスを求めるべきです。3つ目は、サブスクリプションを読み込んだ後は自動更新の間隔を設定すべきで、長期間更新していないサブスクリプションは「ノードが全て接続不能になる」問題の頻発原因の1つです。読み込みの詳しい手順ははじめにを参照し、各形式の違いについての詳しい解説はブログの《Clash サブスクリプションリンクの読み込み方法》を参照してください。

第8章 · 利用シーン別のプロトコル選定指針

選定にあたっての前提認識

まずよくある誤解を解いておきます。Clash クライアントには「プロトコル選択スイッチ」のようなものは存在しません。いわゆる選定とは、サブスクリプションから配信されるノード一覧の中で、ノードのタイプに応じて優先的に選ぶという行為を指します。多くのサブスクリプションは複数プロトコルが混在しており、同じ地域でも複数タイプのノードが同時に提供されることが一般的です。プロキシグループも異なるプロトコルのノードを同じグループにまとめ、遅延に応じて自動切り替えすることができます。したがって以下の指針の使い方は、利用シーンに応じて優先すべきタイプを決め、ノード一覧でそのタイプを優先的に選び、フォールバック用のタイプも1つ残しておくという流れになります。

シーン対照表

補足事項3点

1つ目は、ゲームやオンライン会議のシーンではプロトコル以外にトラフィックの引き受け方式も関わってくる点です。こうしたアプリケーションはシステムプロキシ設定に従わないことが多く、クライアントで TUN モードを有効にして完全に引き受ける必要があります。両方式の違いについてはブログの《Clash の TUN モードとシステムプロキシの違いとは》を参照してください。2つ目は、モバイル端末で電池消費と速度のバランスを取る際は、第5章の消費電力の列を主な判断材料とし、QUIC 系のノードは実際に回線が不安定な場合や大容量通信が必要な場合にのみ有効にすることをお勧めします。3つ目は、いかなる指針も実測に代わるものではない点です。同じタイプのノードでもサーバーや回線が異なれば挙動の差はプロトコル間の差より大きくなることがあるため、タイプを決めた後も実際の利用時間帯で比較検証を行うべきです。

選定手順のまとめ3ステップ

本ガイドの内容は3つの手順にまとめられます。1つ目は、クライアントのカーネルを確認することです。メンテナンス中の mihomo 系クライアント(各プラットフォームで第一候補として推奨する Clash Plus、インストーラーはダウンロードページ参照)であれば6大プロトコルすべてが利用可能で、旧カーネルのクライアントは先に切り替えてください。2つ目は、サブスクリプションの提供内容を確認することです。ノード一覧に実際にどのタイプが含まれているかを確認し、必要なタイプが不足している場合はサービス提供者に mihomo 形式のサブスクリプションを求めてください。3つ目は、上表のシーンに沿って優先順位をつけて実測検証を行い、TCP 系のノードを1種類フォールバックとして残しておくことです。操作面で疑問がある場合ははじめにの手順に従って進め、エラーが発生した場合はよくある質問ページで対照しながら調査してください。