Clashプロトコル解説:6種類のプロキシプロトコルとmihomoカーネルの選定リファレンス

R-01クライアント・カーネル・プロトコル:まず3つの階層を区別する

クライアントは単なる外装

Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu——これらの名前はすべてGUIクライアントを指します。クライアントはノードリストの表示、プロキシモードの切り替え、システムプロキシのオン/オフ管理を担当しますが、それ自体はプロキシ接続を確立しません。インターフェースの違いは操作感にのみ影響し、通信の実際の挙動には影響しません。同一のサブスクを2つのクライアントに導入した場合、ノードリスト・遅延測定・振り分け結果は基本的に一致するはずです。一致しない場合、問題は多くの場合クライアント自体の違いではなく設定にあります。

カーネルはエンジン

実際にリモートサーバーと通信するのはカーネルです。クライアント起動時に一緒に立ち上がるバックグラウンドプロセスです。現在ダウンロードページに掲載されているメンテナンス中のクライアントは、ほぼ全てmihomoカーネル(旧称Clash Meta)を内蔵しています。同じノード設定であれば、異なるクライアントでもカーネルのバージョンが近ければ、接続動作・対応プロトコル範囲・ルール適用結果は基本的に一致します。つまり「プロトコルを選ぶ」とは実質的に「カーネルが対応しているプロトコル一覧から選ぶ」ことであり、クライアントのUIで選ぶわけではありません。手元のクライアントのカーネルを確認したい場合は、設定画面や「このアプリについて」を開けば、カーネル名とバージョン番号が表示されます——mihomoまたはClash Metaの表記が見つかれば、対応プロトコルの範囲は本ページのR-08章の内容が適用されます。

プロトコルはカプセル化の約束事

ノード情報に表示されるSS、VMess、Trojan、VLESS、Hysteria2、TUICが、いわゆるプロトコルの種類です。プロトコルが決めるのは次の3点です:データをどうカプセル化するか、どの方式で暗号化するか、TCPかUDPかのどちらを使うか。サブスクを導入すると、クライアントは各ノードをカーネル設定内のproxy項目として解析し、カーネルがプロトコルの仕様に従ってサーバーとハンドシェイクし、トラフィックを転送します。プロトコルの選択が影響するのは「クライアントからノードまで」の区間のみで、ノードから目的サイトまでの最終区間はサーバー側が決めるため、クライアントは干渉できません。

本ページとチュートリアルページの役割分担はここまでで明確です。quickstart.htmlは「手順通りにやれば繋がる」というメインフローで、本ページは「調べて理解する」ためのリファレンスです。見慣れない設定項目に出会ったら、まず用語集を確認し、その後本ページの該当章に戻って詳しく読んでください。

R-02プロキシプロトコルの進化の流れ

汎用プロキシ:SOCKS5とHTTP

最も初期のプロキシプロトコルは汎用的なものでした。SOCKS5は転送機能のみを持ち、暗号化やコンテンツの検証を行わず、主にローカルやLAN環境で使われます。HTTPプロキシも同様で、主にブラウザ向けです。両者は現在もClash系の設定に残っていますが、その役割はインバウンド(ローカルのアプリがクライアントのリスニングポートに接続する側)であり、リモートサーバーへの発信には使われません。設定内のmixed-portはSOCKS5とHTTPの両方のインバウンドを同時に提供する混合ポートで、allow-lanはLAN内の他デバイスからの接続を許可するかどうかを制御します。

# ローカルインバウンド設定(アプリ接続用、ノード設定ではない)
mixed-port: 7890
allow-lan: false
mode: rule

専用プロトコルの3度の方向転換

リモートサーバー向けの専用プロキシプロトコルは、おおよそ3度の設計上の転換を経てきました。1度目はShadowsocksが「軽量な暗号化ストリーム」という発想を確立:ペイロードだけを暗号化し、余分な構造を持たせず、4つのパラメータだけで動作します。2度目はVMessが「機能優先」の路線を取りました:タイムスタンプ検証、複数のトランスポート層、プロトコル内蔵の暗号化をすべて取り込み、機能は強化されましたが構造も重くなりました。3度目には路線が二つに分岐します:TrojanとVLESSは暗号化をTLSに委ね、通常のHTTPSに近い見た目にする方向へ。Hysteria2とTUICはUDP上のQUICを採用し、劣悪なネットワークでのスループットとネットワーク切り替え時の接続維持を優先する方向へ進みました。

6種類が並存する現状

現在サブスクで最もよく見られるのは依然としてSS、VMess、Trojan、VLESS、Hysteria2、TUICの6種類です。どれもすべての面で優位というわけではありません:オーバーヘッドが小さい特徴が目立つもの、擬似HTTPS化の強度がドメインと証明書に依存するもの、速度重視の設計がUDP環境に依存するもの——それぞれに特色があります。プロトコル間はトレードオフの関係であり、置き換えの関係ではありません。まさにこれが選定リファレンスが必要な理由です。

R-03Shadowsocks(SS):軽量な暗号化ストリーム

誕生の背景と設計目標

SSは2012年前後に登場し、設計目標は極めて抑制的でした:SOCKS5の転送フレームワークの上にストリーム暗号化の層を一枚重ね、伝送中のデータを読み取れなくする——それ以外の構造は一切追加しません。SSのノードに必要な情報はサーバーアドレス、ポート、パスワード、暗号化方式の4項目のみです。実用的なSSクライアントの実装はわずか数百行のコードで済み、これが急速に普及し、ほぼすべてのカーネルとクライアントで対応されるようになった直接の理由です。

AEAD暗号化と現行の使い方

初期のSSはストリーム暗号(例:aes-256-cfb)を使っていましたが、能動的に検出可能な弱点があることが判明し、コミュニティはAEAD(関連データ付き認証暗号)を導入しました。現在よく使われるのは3種類:aes-128-gcm、aes-256-gcm、chacha20-ietf-poly1305です。デスクトップCPUの多くはAESハードウェア命令セットを搭載しており、2種類のAES-GCMはほぼコストゼロで動作します。一方、多くのスマホSoCには対応する命令セットがないため、chacha20-ietf-poly1305はモバイル環境でより高速かつ省電力です。SSはUDP転送(設定内のudpフィールド)にも対応していますが、サーバー側で対応した設定が有効になっている必要があります。

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

適用範囲と限界

SSの利点はエンジニアリング面に集中しています:6種類の中でプロトコルオーバーヘッドが最小、実装が成熟、全カーネルが対応、モバイルでのバッテリー消費表現も最良です。限界も同様に明確です:プロトコルに擬似HTTPS化の層が内蔵されていないため、通信の特徴が比較的一定しやすい点、身元や証明書は扱わず暗号化のみを定義するため、サーバーの真正性は運用者に依存する点です。日常用の汎用プロトコルとして、SSは現在も手堅い既定の選択肢であり、古い端末やルーターでの第一候補でもあります。

R-04VMess:機能優先の一体型設計

設計背景

VMessはV2Rayプロジェクトのネイティブプロトコルで、SSとは逆の設計思想を採っています:認証、時刻検証、暗号化、トランスポート層の擬似化をすべてプロトコル自体に取り込んでいます。各リクエストにはタイムスタンプが付与され、サーバー時刻との差が大きすぎるリクエストは即座に拒否されるため、プロトコルレベルでリプレイ攻撃を防止します。UUIDをユーザー識別子として使うことで、1つのサーバーで複数の独立ユーザーを収容し、個別に統計を取ることができます。

トランスポート層と構造上のオーバーヘッド

VMessはTCP、WebSocket、gRPCなど複数のトランスポート層に対応しています。WebSocket形式ではプロキシ通信を通常のWebサービスの構造に包み込むことができ、CDNを介した中継との組み合わせが一般的です。gRPC形式はHTTP/2の多重化機能を活用します。機能が充実している代償として構造が複雑です:ハンドシェイクの流れが長く、ヘッダーオーバーヘッドが6種類の中で最大で、実装難度も高くなります。加えてVMessは暗号化を内蔵しているため、さらにTLSを重ねると二重暗号化となり、CPU使用率が明確に上がる一方でセキュリティ上の利得は限定的です。

現状

既存のサブスクにはVMessが今も多く残っており、mihomoは各トランスポート層形式に完全対応しています。新規に構築されるサーバーはより軽量な構造のVLESSへ移行する傾向にあり、VMessは徐々に旧い設定として位置づけられています。クライアント側で意図的に避ける必要はありません:ノードが接続でき、速度が基準を満たせば問題なく、プロトコルの新旧が乗り換えの理由になるわけではありません。設定を手動で管理する際はalterIdフィールドに注意してください——新しいバージョンのサーバーとカーネルではこの値は0に固定されており、旧チュートリアルにある0以外の値の設定はもう使えません。

proxies:
  - name: "サンプルノード-VMess"
    type: vmess
    server: example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    network: ws
    ws-opts:
      path: /ray

R-05TrojanとVLESS:TLS擬似化路線

共通の発想:暗号化を自前で設計しない

TrojanとVLESSは同じ路線に属します:プロトコル層では暗号化を実装せず、TLS——HTTPSで使われるセキュリティ層をそのまま利用します。サーバーは実在のドメインと有効な証明書を保持し、クライアントとサーバー間の接続は標準的なTLS接続そのものです。ハンドシェイク、暗号化、証明書検証はすべて成熟した実装をそのまま利用するため、外部から見ればHTTPSサイトへのアクセスとほぼ同じに見えます。mihomoはclient-fingerprintフィールド(例:chrome)にも対応しており、uTLSを使って指定したブラウザのTLSフィンガープリントを模倣し、ハンドシェイクの特徴を実際のブラウザに近づけることができます。

Trojan:極めてシンプルな構造

Trojanの設計はほぼ「プロトコルなし」に近いものです:TLSハンドシェイクが完了した後、クライアントはセッション内でパスワードのハッシュ値を送信して認証を済ませ、以降のデータはそのまま転送されます。プロトコル自体の構造が少ないほど、通常のHTTPSに近い挙動となり、オーバーヘッドも小さくなります。設定に必要なのはドメイン、ポート、パスワードの3項目のみで、sniフィールドは通常ドメインと同じ値になります。

VLESS:VMessを軽量化

VLESSはVMessを簡略化して書き直したものです:プロトコル層の暗号化とタイムスタンプを取り除き、UUIDによる身元識別だけを残し、暗号化は完全に外層のTLSに委ねます。構造はVMessよりずっと軽く、ヘッダーオーバーヘッドはTrojanと同等クラスです。XTLSなどのトランスポート最適化と組み合わせると、カーネルとTLSライブラリ間のデータコピーが一回減るため、高帯域のシーンでスループットが向上します。強調しておきたいのは、VLESSは必ずTLSと組み合わせて使う必要があるという点です。平文形式のVLESSは意味がなく、通常のサブスクに出てくるべきものでもありません。

共通の前提:ドメインと証明書

TLS路線はドメインと有効な証明書に依存するため、比較的自前構築や運用がしっかりしたサーバー側で採用されることが多くなります。クライアント側で注意すべき点は一つだけです:ノード内のsni(またはservername)フィールドは証明書のドメインと一致していなければならず、一致しなければハンドシェイクは即座に失敗します。サブスク経由で導入したノードは既にこの項目が設定済みですが、手動でノードを追加・変更する際には注意が必要です。

proxies:
  - name: "サンプルノード-Trojan"
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    udp: true
  - name: "サンプルノード-VLESS"
    type: vless
    server: example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    tls: true
    servername: example.com
    client-fingerprint: chrome

R-06Hysteria2とTUIC:QUIC上のUDP路線

QUICがもたらす変化

QUICはUDPの上に構築された現代的なトランスポートプロトコルで、HTTP/3の基盤にもなっています。暗号化・輻輳制御・多重化をトランスポート層に統合し、ハンドシェイクは通常1往復で完了、0-RTTでのセッション再開にも対応しています。接続は送信元アドレスの4要素ではなくコネクションIDによって維持されるため、Wi-Fiからモバイル通信への切り替え時もセッションを継続でき、再接続の必要がありません。Hysteria2とTUICはいずれもQUICを基盤としていますが、トレードオフの方向性が異なります。

Hysteria2:帯域を積極的に使う輻輳制御

Hysteria2の核心はBrutalという名の独自の輻輳制御方式です:従来のように利用可能な帯域を探査するのではなく、設定した目標帯域に基づいて積極的にパケットを送信します。高パケットロス・高遅延の回線では、この戦略によりどのTCP系プロトコルよりも明らかに高いスループットが得られます——TCP系プロトコルはパケットロスに遭遇すると指数的に速度を落としますが、Brutalは譲歩しません。代償も明確です:送信が積極的なため、サーバー側の帯域に相応の要件が課されます。設定内のupとdownの値は実際の回線に近い値にする必要があり、高すぎても低すぎても実際の速度を下げてしまいます。このプロトコルはポートホッピング(ポート範囲内で切り替える機能)にも対応し、単一ポートの帯域制限を回避するために使われ、mihomoではportsフィールドで設定します。

TUIC:多重化と低遅延

TUICの設計目標は低遅延・低オーバーヘッドです:複数のTCP接続を1つのQUICセッションに多重化することで、アプリケーションが新しい接続を開くたびに再ハンドシェイクする必要がなくなります。UDPリレーにネイティブ対応しており、ゲームや音声通話といった遅延に敏感なトラフィックが直接その恩恵を受けます。輻輳制御はQUIC標準のアルゴリズム群を採用しており、Hysteria2に比べて挙動が穏やかで回線への負荷も小さく、帯域が大きくないサーバーにも適しています。

UDP路線の限界

両プロトコルともUDPの到達性に依存しています。一部のネットワーク環境ではUDPが速度制限されていたり完全に遮断されていたりするため、その場合は直接利用不可になるか速度が急激に落ちてしまい、クライアント側でこの制限を回避することはできず、TCP系プロトコルに切り替えるしかありません。もう一点はリソースです:QUICの暗号化・再送・輻輳制御はすべてユーザー空間で処理されるため、純粋なTCPプロトコルよりCPU使用率が高く、長時間の大容量ダウンロード時にはモバイル端末での発熱や電力消費の差が感じられることがあります。

proxies:
  - name: "サンプルノード-Hysteria2"
    type: hysteria2
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    up: 50
    down: 200
  - name: "サンプルノード-TUIC"
    type: tuic
    server: example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    password: "your-password"
    alpn: [h3]

R-07横断比較:速度・リソース・バッテリー消費

接続確立

TCP系プロトコル(SS、VMess、Trojan、VLESS)はまずTCPハンドシェイクを完了し、TLSを使う場合はさらにTLSハンドシェイクが加わり、初回接続は通常1〜3往復程度かかります。QUIC系はトランスポートと暗号化のハンドシェイクを統合しており、通常1往復で済み、セッション再開時は0-RTTも可能です。日常のブラウジングでは差はさほど感じられませんが、短時間の接続が多いシーン——フィード更新やAPIリクエストが頻繁なアプリなど——ではQUIC系に優位性があります。

スループットとオーバーヘッド

プロトコルのヘッダーオーバーヘッドは小さい順に大まかに:SS < Trojan ≈ VLESS < VMessとなります。QUIC系のヘッダーは小さくはありませんが、多重化によってハンドシェイクのコストが分散されるため、実際のスループットは輻輳制御の戦略に大きく左右されます。同じ回線条件下では、パケットロスが少なく安定している場合、SS・Trojan・VLESSの差はほとんどありません。パケットロスが多い場合はHysteria2のスループットが最も高く、TUICがそれに続き、TCP系プロトコルは全体的に大きく落ち込みます。

CPUとメモリ

デスクトップ環境(Windows、macOS、Linux)では、6種類のプロトコルのCPU使用率はいずれも無視できる範囲にあり、選定の根拠として性能を重視する必要はありません。モバイルでは状況が異なります:スマホSoCの小コアではAESとChaCha20の電力効率の差が顕著に現れます。またQUICのユーザー空間での再送や輻輳制御処理はCPUを持続的に消費します。メモリ面では各プロトコルの差はさほど大きくなく、カーネル全体の使用量は主にルール数とアクティブな接続数に左右され、プロトコルの種類との関係は薄いです。

モバイルのバッテリー消費

同等のトラフィック量における相対的な電力消費は、省電力な順に大まかに:SS(chacha20-ietf-poly1305)< Trojan ≈ VLESS < VMess < TUIC < Hysteria2となります。プッシュ通知やチャットアプリのような常時バックグラウンド稼働の用途では各プロトコルの差はほとんど感じられませんが、動画の連続再生や大容量ファイルのダウンロードでは差が実感できるようになります。iOSのClash PlusとAndroid各クライアントは同じmihomoカーネルを使用しているため、上記の結論はプラットフォーム間で一貫しています。iOS版の入手と設定手順は技術ノートに専門記事があります(iPhoneでのClashの使い方)。

正しい速度測定の方法

選定前には統一した条件で速度を測定することをお勧めします:同じ時間帯、同じ対象、同じデバイスで測定します。クライアントの速度測定で得られるのは遅延で、ハンドシェイクと往復のコストを反映します。スループットは実際のダウンロードで検証する必要があります。単一接続でのダウンロードはプロトコルのオーバーヘッドの影響を強く受け、複数接続でのダウンロードは輻輳制御の影響を強く受けます——両方の数値を確認する方が、遅延だけを見るより確実です。

R-08カーネルの系譜:Clash、Clash Meta、mihomo

原版Clashの歴史的な位置づけ

原版Clashカーネルは2023年にメンテナンスが終了し、リポジトリはアーカイブされました。SS、VMess、Trojanなどの初期プロトコルに対応していますが、VLESS、Hysteria2、TUICは認識できません。原版にはかつてClash Premiumというクローズドソースの強化版もあり、TUNやスクリプト機能を提供していましたが、こちらも同様にメンテナンスが終了しています。Clash for Windows、ClashX Metaなどメンテナンスが終了したクライアントを今も使っているユーザーが実際に動かしているのは、この時代のカーネルまたはその初期の派生版です——既存のノードは接続できますが、新しいプロトコルや新機能は今後追加されず、サブスク内の新しいプロトコルのノードはそのままスキップされます。

Metaからmihomoへ:継承と拡張

Clash Metaはコミュニティによる原版ベースの活発な派生プロジェクトで、2023年末にmihomoへ改名されました。原版のYAML設定形式を完全に継承しつつ、VLESS、Hysteria2、TUICへの対応を追加し、TUNモードの強化、ルールプロバイダー(rule-providers)、外部コントローラーの拡張機能などをもたらしました。TUNモードは仮想ネットワークアダプタを介して全体のトラフィックを引き受ける仕組みで、その原理と有効化方法については技術ノートに専門記事があります(Clash TUNモードとは)。ダウンロードページでメンテナンスされているクライアント——Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu——はいずれも内蔵カーネルがmihomoです。

設定ファイルの互換性

互換性は一方向です:mihomoは原版Clashの旧設定をそのまま実行できますが、逆は成り立ちません——新しいプロトコルのノードや新しいフィールド(rule-providersなど)を含む設定は、原版カーネルでは解析に失敗します。サブスク変換ツールは通常「Clash」と「Clash Meta」の2種類の出力形式を提供します:mihomoクライアントを使う場合はMeta出力を選んでください。選択を誤って旧形式にしてしまうと、新しいプロトコルのノードは変換の段階で削除され、「サブスクには確かにあったノードが、導入後に見当たらない」という現象として現れます。

R-09サブスク形式とシーン別の選び方

サブスク形式の3種類

サブスクリンクから返される内容には主に3種類の形式があります。1つはBase64ノードリスト:1行につき1つのss://やvmess://形式の共有リンクが並んだもので、汎用性が最も高い一方、Clashのポリシーグループやルール構造は含まれておらず、導入後はクライアント側で自動的に整理されます。2つ目はClash YAML:proxies、proxy-groups、rulesの3つのセクションを含む完全な設定ファイルで、導入すればそのまま使え、mihomoクライアントで最も推奨される形式です。3つ目はオンライン変換ツールの出力:Base64リストをClash YAMLに変換するもので、古いサブスクでも完全な構造を得られますが、変換サービス側でノード情報の平文を扱うことになるため、利用時は信頼性に注意が必要です。サブスクの取得と導入の詳細は技術ノートに専門記事があります(Clashサブスクリンクの導入方法)。

利用シーン別の選び方

• 日常のブラウジングと動画視聴:SSまたはTrojan、VLESS。オーバーヘッドが小さく電力効率も良好で、デスクトップ・スマホどちらにも適しています。
• 高パケットロス回線:Hysteria2。大陸間の回線や夜間の混雑時にスループットの優位性が最も顕著に出ますが、前提として利用ネットワークがUDPを制限していないことが必要です。
• ゲームと音声通話:TUICまたはHysteria2。UDPリレーの遅延が低く、クライアントでUDP転送がオンになっていることも確認してください。
• ネットワークの切り替えが頻繁:QUIC系プロトコル。ネットワーク切り替え時も接続が維持され、通勤中の切断回数が明確に減ります。
• 古い端末やルーター:SS。CPU使用率が最も低く、実装も最も成熟しており、長時間の稼働が最も安定します。

3つのよくある誤解

「プロトコルが新しいほど速い」は成り立ちません:速度は回線の品質と輻輳制御に依存し、リリース時期には依存しません。安定した回線ではSSと最新プロトコルの差はごくわずかです。「暗号化の層が多いほど安全」も成り立ちません:VMessにTLSを重ねるような二重暗号化はCPU負荷を増やすだけで、安全性は最も外側の層で決まります。「クライアントを変えればプロトコルの挙動も変わる」も成り立ちません:同じカーネルであればプロトコルの動作は一致し、クライアントが影響するのは操作感のみです——クライアント間の違いの比較は技術ノートの横断比較記事を参照してください(主要クライアント横断比較)。

まとめ:4ステップの選定フロー

1. クライアントのカーネルがmihomoであることを確認する(ダウンロードページのメンテナンス中クライアントはすべて該当)。
2. サブスクを導入し、プロトコルの種類別にノードリストを確認する。
3. 普段使うネットワークで候補のプロトコルをそれぞれ一度速度測定し、遅延とスループットの両方を確認する。
4. 実測で最も良かった種類をポリシーグループの既定にし、残りは予備として保持する。

プロトコルに関する内容は以上です。残りの操作——サブスクの導入、モードの選択、システムプロキシのオン、接続確認——は使い方ガイドに戻って手順に従ってください。クライアントのダウンロードが必要な場合はダウンロードページへ、見慣れない用語がある場合は用語集をご確認ください。