Clash プロトコルとコアの技術参考

Clash 系のクライアント自体はプロトコルを独自に発明しているわけではなく、「マルチプロトコル・アウトバウンドフレームワーク」である。設定ファイル内の各ノードは自身の type を宣言し、コアがその種別に応じて対応するプロトコル実装を呼び出す。したがってプロトコル選定の第一歩は「どれが一番速いか」にこだわることではなく、各プロトコルが設計上何を犠牲にし、その代わりに何を得ているのかを理解することだ。6つの主要プロトコルは大きく2つの軸で分類できる。トランスポート層が TCP か UDP(QUIC)か、そしてプロトコル自体が暗号化を TLS に依存しているかどうかである。

Shadowsocks:極限までシンプルな暗号化転送

Shadowsocks は6つの中で最も古い世代であり、設計目標はただ一つ、できるだけ少ないコードでクライアントとサーバーの間に暗号化された SOCKS 転送トンネルを構築することだった。プロトコルヘッダは極めて短く、ハンドシェイクの交渉段階がなく、接続確立後は直ちに暗号文の転送が始まる。初期のストリーム暗号方式は既に廃止され、現行の実装はすべて AEAD 暗号スイート(例:aes-128-gcm、chacha20-ietf-poly1305)を採用し、機密性と完全性検証を同時に提供する。取捨選択は明確で、プロトコル層の拡張性(マルチプレキシングなし、UDP over TCP の内蔵なし)を犠牲にし、代わりに最も低い実装の複雑さと最小のパケットごとのオーバーヘッドを得ている。今なお低スペック機器や古いルーターでの第一選択であり、多くのサブスクリプションにおける「保険的なノード」種別でもある。SS2022 系のスイートは鍵管理とリプレイ攻撃対策を強化しており、コア内部では同じ ss 種別の異なる cipher として扱われる。

VMess:V2Ray 時代の多機能プロトコル

VMess は V2Ray プロジェクトとともに生まれ、SS とは逆の方向性を持つ。複雑さを受け入れても機能を充実させることを重視した。プロトコルヘッダにユーザーID、暗号方式、タイムスタンプなどのメタデータを含み、動的ポートなどの機能をサポートし、V2Ray のトランスポート層プラグイン体系(WebSocket、gRPC、HTTP/2)と自然に組み合わせて使える。代償はプロトコルヘッダのオーバーヘッドが SS より大きいことと、初期は端末とサーバーの時刻同期に依存していたことだ。ローカルの時刻ずれが大きいとハンドシェイクが失敗する、というのは VMess ノードが接続できない際の典型的な確認項目である。VMess の価値はエコシステムにある。多数の管理パネルやサブスクリプション変換ツールがこれを中心に構築されており、互換性の範囲は広い。純粋なプロトコルとして見ると、その暗号化とカプセル化の設計はすでに重くなっており、これが後の VLESS を生み出す直接の要因となった。

Trojan:自らを HTTPS の形に紛れ込ませる

Trojan の発想は引き算だ。TLS が既に十分な暗号化を提供しているのだから、プロトコル層で重複して暗号化する必要はなく、TLS トンネル内に簡単な認証ヘッダと生のトラフィックを流すだけにする。外部から観測すると、Trojan の接続は通常の HTTPS アクセスと通信形態がきわめて似ている。認証に失敗した接続はサーバー側から実在するウェブサイトへフォールバックされる。取捨選択としては、有効なドメインと証明書のセットに強く依存し、導入の敷居は SS より高くなるが、クライアント実装は極めて薄く、動作時のオーバーヘッドも低い。利用者にとって Trojan ノードの接続挙動は安定して予測可能で、TCP + TLS の組み合わせはどのようなネットワーク環境でも互換性が最も高く、「この種のトラフィックだけ回線業者に個別に速度制限される」という問題がほとんど起きない。

VLESS:冗長性を排した次世代フレームワーク

VLESS は Xray エコシステムが VMess を再構築したものだ。プロトコル自体の暗号化を排除して TLS に委ね、タイムスタンプへの依存を排除し、プロトコルヘッダを最小限まで圧縮して UUID 認証と必要最小限のルーティング情報だけを残した。これにより VLESS は「薄い外殻」となり、実際の差別化能力は組み合わせるトランスポート方式から生まれる。XTLS Vision はフロー制御によって TLS in TLS の二重暗号化オーバーヘッドを減らし、REALITY は独自証明書を持つ必要をなくす。選定時の注意点として、VLESS 自体にはほとんどオーバーヘッドがなく、性能はサーバー側がどの組み合わせを設定しているかに依存する。サブスクリプション内で同じ vless と表記された2つのノードでも、実際の挙動は大きく異なる場合がある。クライアント側は対応するトランスポート特性をサポートするコアが必要であり、これが後述のコアの章で mihomo を強調する理由の一つでもある。

Hysteria2:パケットロス環境のために生まれた QUIC プロトコル

Hysteria2 は QUIC の上に構築されており、核となる特徴は独自の輻輳制御だ。従来の TCP の輻輳アルゴリズムは高パケットロスのリンクで大きく速度を落とし、海外を跨ぐ回線では実際のスループットが帯域幅のごく一部にしかならないことが多い。Hysteria2 はより積極的な送信戦略を採用し、利用者が上り下りの帯域幅を直接指定できるようにすることで、パケットロス5%を超えるリンクでも表示帯域に近い速度を維持できる。取捨選択も同様に明確で、積極的なパケット送出は輻輳したネットワークで他者の帯域を圧迫し、一部の回線業者は継続的な大流量 UDP セッションに対して QoS による速度制限をかける。そうしたネットワークでは QUIC 系プロトコルはむしろ TCP 系より不安定になる。「リンク品質は悪いが UDP に制限がない」場面に適しており、何も考えずに常用するデフォルト設定にすべきものではない。

TUIC:低遅延を志向するもう一つの QUIC 路線

TUIC は Hysteria2 と同じ QUIC 系だが、重点が異なる。積極的に帯域を奪い合うのではなく、QUIC のネイティブな能力を存分に活用する。0-RTT ハンドシェイクにより再接続がほぼ意識されないレベルになり、接続内でのマルチプレキシングによりヘッドオブラインブロッキングを回避し、UDP トラフィックのネイティブ中継(native モード)はゲームやリアルタイム音声のような小さなパケットが高頻度で発生するアプリケーションに特に向いている。輻輳制御は cubic、new_reno、bbr から選択でき、挙動は Hysteria2 より穏やかだ。短所はエコシステムがまだ小さいことで、TUIC ノードを提供する業者は他のプロトコルより少なく、クライアント側の対応も Meta 系のコアであることが前提となる。遅延に敏感でパケットロスが深刻でない場面では、TUIC の使用感は6つの中で最も良いことが多い。

6種類のプロトコルをトランスポート層で切り分けると、性能に関する議論の大半がこの層に起因していることが分かる。SS、VMess、Trojan、VLESS の主流形態は TCP 上で動作し、Hysteria2 と TUIC は UDP 上の QUIC で動作する。この2つの路線の違いは4つの側面に現れる。

ハンドシェイクコスト

TCP + TLS 1.3 で新しい接続を確立するには TCP の3ウェイハンドシェイクと TLS ハンドシェイクがそれぞれ必要で、初回バイトまでの遅延はおおよそ2 RTT になる。QUIC はトランスポートのハンドシェイクと暗号化のハンドシェイクを統合しており、初回接続は1 RTT、セッション再利用時は 0-RTT で即座にデータを送信できる。物理遅延200msの海外リンクでは、頻繁に接続を張るシーン(ページを開いた瞬間に発生する数十件の並行リクエストなど)でこの差が明確に体感できる。TCP 系プロトコルは接続の多重化(mux)でこれを緩和するが、mux は次の問題を引き起こす。

ヘッドオブラインブロッキング

TCP は単一の順序付きバイトストリームであり、一つのパケットロスがこの接続上の後続データすべてを止めてしまう。それが無関係なリクエストのデータであっても影響を受ける。TCP 接続上でマルチプレキシングを行うことは、複数のリクエストを一つの、単点障害で簡単に詰まってしまう流れに束ねることに等しく、パケットロス環境ではむしろ体感が悪化する。これが「mux は安易に有効化すべきではない」という原理だ。QUIC はプロトコル内で独立したストリーム(stream)として転送するため、あるストリームのパケットロスは他のストリームに影響せず、マルチプレキシングは負荷ゼロのネイティブな能力となっている。

中間機器との相性

TCP 443ポートの TLS トラフィックはインターネット上で最も一般的な形態であり、どのネットワーク環境でも通過を許可せざるを得ない。一方、UDP の長時間セッションは一部の回線業者や企業ネットワークで QoS による速度制限、NAT タイムアウトの短縮、あるいは破棄の対象になることがある。これが QUIC 系プロトコルが「速いときはとても速いが、使えないときは全く使えない」という現象の根源だ。選定の結論としては、ネットワーク環境が未知の場合は TCP 系が安全な選択であり、QUIC 系は実測で検証する必要がある。

偽装トランスポートの位置づけ

WebSocket や gRPC のようなトランスポートプラグインは TCP 系プロトコルの任意の外殻であり、CDN を経由する中継構成でよく使われる。代償として各層のカプセル化は遅延とオーバーヘッドを増やし、CDN のオリジン取得自体も追加の1ホップを伴う。QUIC 系プロトコルはこの体系を採用しない。サブスクリプション内で同名のプロトコルでもトランスポートの外殻が異なるノードは、遅延の表れ方が倍近く変わることがあるため、速度測定時は分けて扱うべきだ。

プロトコル自体の暗号化・復号のオーバーヘッドは現代のハードウェアでは非常に小さく、実際に差を生むのはハンドシェイクのモデル、輻輳制御、カプセル化の層数だ。以下の表は同等のリンク条件下での定性的な比較であり、方向性は信頼できるが倍率は環境によって異なる。

2点補足する。1点目、QUIC 系プロトコルの CPU 使用率が高めなのは暗号化の負荷ではなく、QUIC のプロトコルスタックがユーザー空間で動作しており、パケットの送受信経路がカーネル空間の TCP より長いためだ。デスクトップでは気づかないレベルだが、低消費電力デバイスでは差が測定できる。2点目、「高パケットロス時のスループット」の行の差は表現できる以上に大きい。同じ10%のパケットロスが発生しているリンクで、TCP 系プロトコルは帯域幅の10分の1程度しか出せないことがあるのに対し、Hysteria2 は半分以上を維持できる。リンク品質がこの表のどの行を重視すべきかを決める。

速度測定の方法についての提案:クライアント内で同じ業者の異なるプロトコルノードに対して遅延テストを行うのはハンドシェイクの RTT を反映するだけで、スループットは反映されない。スループットは実際のダウンロードやストリーミングの読み込みで検証し、朝夕のピーク時間帯それぞれで測るのがよい。ダウンロードページで提供している各クライアントはいずれも遅延テストを内蔵しており、Clash Plus のグループ測速機能を使えば同グループのノードを一括で比較できる。

スマートフォン上のプロキシクライアントの消費電力は3つの要素で構成される。VPN サービス常駐の基礎コスト、プロトコルスタックがトラフィックを処理する際の CPU コスト、そして最も影響が大きい、ネットワーク動作が引き起こすセルラー/Wi-Fi の無線モジュールの起動だ。3つ目が消費電力の大半を占める。プロトコルが消費電力に与える影響は主にハートビートと再接続の挙動を介して伝わる。

ハートビートと保活

TCP 系プロトコルは NAT マッピングの維持に依存し、クライアントまたはサーバーは数十秒単位の keepalive で接続を保つのが一般的だ。ハートビートが発生するたびに、休眠状態のセルラーモジュールが高消費電力状態に呼び起こされ、数秒間その状態が維持される。QUIC 系プロトコルも保活は必要だが、QUIC のコネクションマイグレーション(connection migration)によってネットワークの切り替え(Wi-Fi とセルラー間)後も同じ接続を引き続き使えるため、一連の完全な再接続処理を省ける。TCP 系プロトコルはネットワーク切り替えのたびに接続をすべて再構築する必要があり、まとまったハンドシェイクトラフィックと無線モジュールの活動が発生する。Wi-Fi とセルラーを頻繁に切り替える使い方では、QUIC 系プロトコルの消費電力は通常より良好になる。

暗号化とプロトコルスタックのオーバーヘッド

AEAD の暗号化・復号にはハードウェア命令によるアクセラレーションがあり、各プロトコル間の差は無視できる程度だ。QUIC のユーザー空間プロトコルスタックがモバイル向けチップ上で消費する追加の CPU は測定可能だが目立つほどではなく、大容量のトラフィックを継続して転送する場合(長時間の動画視聴など)にのみ現れる。軽い閲覧用途では気にする必要はない。

プロトコルより影響が大きい要因

実測では、クライアントの設定内容が消費電力に与える影響はプロトコル選択よりずっと大きい。ルールセットの自動更新間隔が短すぎる、ログレベルが debug になっている、DNS の並行解決戦略が積極的すぎる、ノードの自動速度測定の間隔が密すぎる——これらのどれか一つでもプロトコルの差を軽く超える消費電力を生む。項目ごとの確認方法はブログ記事スマホで Clash がバッテリーを大量消費する場合の確認方法にまとめてあり、Android の電池最適化のホワイトリスト設定や iOS のオンデマンド接続の具体的な設定もそこで解説している。

「Clash」という名前は現在、少なくとも3つのものを指している。開発が停止した無印(オリジナル)コアプロジェクト、そのコミュニティ強化版フォークである Clash.Meta、そして Meta が改名して現在まで続く mihomo だ。GUI クライアント(Clash Plus、Clash Verge Rev、FlClash など)はいずれもコアの外側を包むグラフィカルインターフェースであり、コアがプロトコル対応範囲と設定文法の上限を決める。3者の系譜と違いは以下の通りだ。

3世代のコア系譜

無印の Clash は YAML 設定形式、ルールによる振り分けモデル、RESTful 制御インターフェースを確立し、当時主流だった SS、VMess、Trojan などのプロトコルに対応していた。プロジェクトの開発が停止しリポジトリが削除された後、無印コアは一切更新されなくなり、新しいプロトコルには対応していない。Clash.Meta は無印を基盤としたコミュニティの強化版フォークで、VLESS、Hysteria 系、TUIC などの新プロトコルと多くの振り分け機能を追加した。その後、名称に関する争いを避けるため mihomo に改名したが、プロジェクト本体、設定形式、開発チームは断絶していない。mihomo は Meta そのものであり、名前が変わっただけだ。現在のエコシステムで活発に保守されている Clash 系コアは mihomo のみであり、主流の GUI クライアントもすべて mihomo への移行を完了している。3世代のコアの経緯についてはブログ記事Clash 無印・Meta・mihomo コアの違い比較で詳しく解説している。

機能差の対照

設定の互換性

mihomo は無印の設定形式を基本的に後方互換でサポートしている。無印コアで動作する YAML は通常、そのまま mihomo に読み込ませることができる。逆は成り立たない。設定に mihomo の拡張フィールド(hysteria2 というノード種別、TUN セクション、強化された DNS フィールドなど)が含まれていると、無印コアはそのままエラーを出して終了する。設定が mihomo に依存しているかどうかは、次のようなフィールドを探せば判別できる。

proxies:
  - name: hy2-node
    type: hysteria2      # 無印コアはこの種別を認識しない
    server: example.com
    port: 443
    password: your-password

tun:                     # 無印のオープンソースコアにはこのセクションがない
  enable: true
  stack: system
  auto-route: true

選定の結論は明快だ。今日、新しく無印コアを導入する理由はない。プロトコル対応範囲、TUN モード、保守状況のいずれも mihomo を指している。本サイトのダウンロードページで提供している GUI クライアントはすべて mihomo またはその派生をベースにしており、コアのコーナーでは mihomo の各プラットフォーム向けの単体バイナリも提供している。サーバーやルーターの利用者はそちらを使うとよい。

サブスクリプションは業者がクライアントにノード情報を配信するための媒体であり、形式の不一致は読み込み失敗の最大の原因だ。現在流通しているサブスクリプションは主に3種類ある。

3種類のサブスクリプション形式

1つ目は Clash YAML サブスクリプション。完全または一部の Clash 設定ファイルであり、proxies、proxy-groups、rules などのセクションを含む。Clash 系クライアントがネイティブに対応しており、情報量が最も豊富で、グループ分けや振り分けルールを業者側が予め設定しておける。2つ目は Base64 汎用サブスクリプション。ss:// や vmess:// などのノード共有リンクを1行ずつ連結してまとめてエンコードしたもので、ノード情報のみでルールは含まない。歴史が最も長く、互換性の範囲が最も広い。現代の Clash クライアントの多くは自動的に識別・変換できるが、変換後はグループとルールをクライアント側で補う必要がある。3つ目はその他のエコシステム独自の形式(sing-box の JSON など)で、Clash 系クライアントは直接対応しておらず、サブスクリプション変換サービスによる変換が必要になる。

プロトコル対応がサブスクリプションに与える影響

形式が正しくてもすべてのノードが使えるとは限らない。YAML サブスクリプションに hysteria2、tuic、vless 種別のノードが含まれている場合、クライアントのコアが旧版または無印だと、軽い場合はそれらのノードが静かに無視され、重い場合は設定全体の読み込みが失敗する。症状としては「サブスクリプションの読み込みは成功したがノード数が他の人より少ない」「サブスクリプションを更新したらクライアントがエラーを出す」といった形で現れる。対処の順序:まずクライアントのコアが mihomo 系であることを確認し、次にサブスクリプションのリンクに業者が用意した Clash 専用パラメータが付いているか確認する(多くの業者は同じサブスクリプションのアドレスでも URL パラメータによって異なる形式を出力する)。

proxy-providers でサブスクリプションを管理する

設定を手動で管理している利用者には、proxy-providers を使って「ノードの取得元」と「グループ分けルール」を分離することを推奨する。ノードはサブスクリプションのアドレスから定期的に取得し、グループとルールはローカルの設定に記述する。これによりサブスクリプションの更新で個人設定が上書きされることがなくなる。最小限の例:

proxy-providers:
  main:
    type: http
    url: "サブスクリプションのアドレス"
    interval: 86400        # 取得間隔(秒)、モバイル端末では短くしすぎない
    path: ./providers/main.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

前章までの内容を踏まえ、そのまま実行できる判断のフローを示す。前提として、ノードのプロトコルは業者側が決めるものであり、以下の提案は「同じ業者が複数のプロトコルノードを提供している場合にどれを選ぶか」、および「業者を切り替える際に何を優先的に確認するか」のために使ってほしい。

デスクトップでの日常利用(仕事 / ブラウジング / 動画)

Trojan または VLESS を優先する。TCP + TLS の組み合わせはどのネットワークでも互換性が最も高く、オーバーヘッドが低く挙動が安定しており、長時間立ち上げたままでも問題が起きにくい。パケットロスが目立つ(夕方以降の海外リンクなど)かつネットワークが UDP を制限していない場合は、Hysteria2 ノードを予備として設定し、ピーク時間帯だけ手動で切り替える。クライアントはClash Plusを選べば、グループ速度測定とルール管理をそのまま使える。オープンソースのデスクトップ向けを好む場合は Clash Verge Rev もよい。

モバイル端末(スマートフォン / タブレット)

電波が安定している環境では Trojan / VLESS を、通勤などネットワークの切り替えが頻発するシーンでは TUIC を優先する(コネクションマイグレーションにより再接続が減り、0-RTT によって切り替え後の復帰遅延が下がる)。Hysteria2 を長期間バックグラウンドで使うのは避けたい。積極的なパケット送出モデルは電池に優しくない。クライアントの設定内容はプロトコルより重要で、更新間隔やログレベルは消費電力の章の提案に沿って絞ること。iOS 利用者は App Store から Clash Plus を入手できる。手順はチュートリアルページを参照。

不安定な回線・高パケットロス環境

Hysteria2 はまさにこのシーンのために設計されており、最も効果が大きい。帯域幅パラメータは実際のリンクに合わせて入力し、上りを過大に設定するとパケットロスを悪化させるだけだ。UDP が速度制限されている場合(QUIC ノードの速度が周期的に落ち込む現象として表れる)は TCP 系プロトコルに戻し、サーバー側で BBR 輻輳制御を使っているノードを優先する。

ゲームとリアルタイム通信

UDP 転送と遅延のジッターに注目する。TUIC(native UDP モード)と Hysteria2 はネイティブに UDP を転送し、第一グループに位置する。SS はサーバー側で UDP サポートを有効にする必要がある。VMess / Trojan の UDP 対応能力はサーバー側の実装次第で、概して QUIC 系より劣る。選定前に、まずゲームが UDP か TCP を使っているかを確認するとよい。ターン制やブラウザゲームは TCP を使うことが多く、プロトコルの差はほとんど出ない。

サーバーとルーター

mihomo コアを単体で動かし、プロトコルは SS(リソース消費が最も低い)か Trojan を選ぶ。MIPS / ARMv7 などの低スペック機器では QUIC 系プロトコルのユーザー空間プロトコルスタックのオーバーヘッドを避けたい。各アーキテクチャ向けのコアはダウンロードページのコアコーナーにあり、コマンドラインで次のように起動する。

mihomo -d /etc/mihomo    # 設定ディレクトリを指定して起動

判断の早見表

誤解1:あるプロトコルが「最速」で、どんな場面でも通用する。そのようなものは存在しない。速度はリンク品質、サーバー側の負荷、輻輳制御によって決まり、プロトコルはその中の一変数に過ぎない。同じプロトコルでもリンクが異なれば順位は完全に逆転することがあり、結論は自分のリンクで何度も実測して得るしかない。

誤解2:新しいプロトコルは必ず古いプロトコルより優れている。SS は誕生が最も早いが、低スペック機器や安定したリンクでは今も最もオーバーヘッドの低い選択肢だ。VLESS + REALITY の組み合わせは新しいが、コアとサーバーのバージョンが一致していることが前提で、問題が起きた際の切り分けも難しい。プロトコルは道具であり、場面に合わせることが新しさを追うことより重要だ。

誤解3:クライアントがプロトコルの性能を決める。GUI クライアントはコアの外殻に過ぎず、同じ mihomo コアであれば、異なるクライアント間でプロトコルのスループットに本質的な差はない。クライアント間の違いは操作性、プラットフォーム対応、設定管理能力にあり、プロトコルの面ではコアのバージョンだけを見ればよい。

誤解4:遅延テストの数値が低ければ体感も良い。クライアント内の遅延の数値は通常、1回の HTTP ハンドシェイクの RTT であり、スループット、パケットロス、安定性を反映しない。遅延80msだが夕方以降パケットロスが激しいノードは、遅延150msだが一日中安定しているノードより体感が悪いことがある。

誤解5:設定エラーが出たらまずプロトコルを疑う。読み込み失敗の大半の原因は YAML のインデントミス、サブスクリプション形式の不一致、コアのバージョンが古すぎることであり、プロトコル自体に問題がある確率は最後に来る。「形式 → コア → ノード → プロトコル」の順で確認するのが最も効率的だ。

個別のエラーへの具体的な対処方法はヘルプセンターのトラブル対応カテゴリーに掲載している。このページに出てきた用語はすべて用語集ページで一つずつ確認できる。選定が終わったらチュートリアルページに戻って手順に沿って読み込みと確認を進めるか、直接ダウンロードページからクライアントを入手してほしい。