プロトコル&コア技術参考

Aプロトコルの進化の流れ:3世代の設計思想

6種類のプロトコルは同時期に生まれたものではなく、それぞれ当時最も顕著だった課題に向けて設計されています。核心となる発想で分類すると3世代に分けられ、この順序を理解すれば以降の比較はすべて暗記不要になります――各世代の長所と短所は設計目標の直接的な結果だからです。

第1世代:極限のシンプルさ

Shadowsocks が代表例です。設計目標は「軽さ」:対称鍵暗号で TCP ストリームを直接ラップし、プロトコルヘッダーを最小限にとどめ、ハンドシェイクの交渉もセッション管理も余分なメタデータも持ちません。サーバーとクライアントは4つのパラメータ(アドレス、ポート、暗号方式、パスワード)を合わせるだけで通信できます。代償として、プロトコル自体は身元体系を持たず、トランスポート層での偽装能力もありません――以降のニーズはすべて外部手段で補う必要があります。

第2世代:プロトコル内メタデータ

Vmess が代表例です。プロトコル内部にユーザーID(UUID)、タイムスタンプ検証、命令フィールドなどの構造化メタデータを導入し、「搬送方式」を交換可能なトランスポート層として抽象化しました:同一の Vmess ノードは素の TCP、WebSocket、HTTP/2、gRPC のいずれの上でも動作し、必要に応じて TLS を重ねることもできます。柔軟性は大幅に向上しましたが、設定項目もそれに応じて増加します――Vmess ノードの設定可能パラメータは Shadowsocks の数倍にあたり、トラブル対処の難易度も上がります。

第3世代:偽装と土台の入れ替え

第3世代は2つの路線に分かれます。1つは「偽装」路線:Trojan と VLESS は独自の暗号ラップを発明せず、データを標準の TLS セッションにそのまま載せ、プロキシ通信の外見を通常の HTTPS アクセスと同一にしつつ、冗長な暗号化を1層省略します。もう1つは「土台の入れ替え」路線:Hysteria2 と TUIC は TCP を捨て、QUIC(UDP)ベースでトランスポート層を再構築し、高遅延・高パケットロス回線でのスループットとハンドシェイク速度を主軸に据えています。両路線は解決する課題が異なり、代替関係にはありません。

一言でまとめると:万能なプロトコルは存在せず、目標が異なるトレードオフがあるだけです。第1世代はシンプルさと省リソースで勝ち、第2世代は柔軟性で勝ち、第3世代の偽装路線は通信特徴のクリーンさで勝ち、土台入れ替え路線は弱い回線での挙動で勝ちます。選定とは、自分の利用シーンをそのいずれかの目標に合わせることです。

B6種のプロトコル逐次解説

本章ではプロトコルごとに設計上の要点、主要パラメータ、適用範囲を説明します。パラメータ名はすべて Clash 系設定ファイル(YAML)のフィールドに準拠し、サンプル値はすべてダミーであり、そのまま接続には使用できません。

Shadowsocks(SS)

最もシンプルな方式です。現行実装は統一して AEAD 暗号スイート(一般的なものは aes-128-gcm、aes-256-gcm、chacha20-ietf-poly1305)を使用し、機密性と完全性検証の両方を保証します。パラメータはサーバーアドレス、ポート、暗号方式、パスワードの4つだけで、設定ミスの余地がほとんどありません。CPU・メモリの負荷は6種のプロトコル中最も低く、古い端末や組み込み環境にも適します。短所も明確です:通信は暗号化されているものの、プロトコル偽装は一切行わず、マルチプレクシングも持たないため、接続ごとに個別に確立されます。設定例は以下の通りです:

proxies:
  - name: "ss-example"
    type: ss
    server: node.example.com
    port: 8388
    cipher: aes-256-gcm
    password: "your-password"

Vmess

V2Ray エコシステムの中核プロトコルです。認証は UUID に基づき、初期バージョンではクライアントとサーバーの時刻差が約90秒以内であることが求められました――時刻の非同期は Vmess ノードに接続できない典型的な原因の一つです。alterId は旧バージョンの遺物フィールドで、現行の AEAD 認証方式では 0 に設定するべきです。Vmess の本当の価値はトランスポート層の組み合わせにあります:network フィールドで tcp / ws / h2 / grpc を選択でき、さらに tls: true で外層の暗号化を重ねられます。中でも WebSocket + TLS は最も広く使われる組み合わせで、標準的なWebサーバーの背後に配置して443番ポートを共有できるためです。パラメータが多いということはトラブル対処のポイントも多いということです:パス(ws-opts.path)、Host ヘッダー、SNI のいずれかがサーバー側と一致しないとハンドシェイクに失敗します。

Trojan

「偽装」路線を直接体現したものです。Trojan は独自の暗号化を発明せず、セッション全体が実在の TLS 接続そのもので、サーバーは有効な証明書を保持し、認証はパスワードハッシュのみに依存します。認証を通過しない通信はフォールバック(fallback)として実在するWebサイトへ振り分けられるため、外部から観測すると Trojan サーバーは通常の HTTPS サイトと同じ振る舞いを見せます。クライアント側のパラメータは非常に少なく、アドレス、ポート、パスワード、SNI のみです。注意が必要なのが skip-cert-verify フィールドです――これは証明書検証をスキップするもので、自己署名証明書のテスト環境専用です。

VLESS

「内層の暗号化を取り除いた Vmess」と理解できます:外層に既に TLS があるため、プロトコル内部で暗号化を重複させず、UUID 認証と最小限のプロトコルヘッダーのみを保持し、1回分の暗号化・復号にかかる CPU 負荷を省きます。VLESS は必ず TLS 系のトランスポートと組み合わせて使う必要があり、素の状態では動作しません。flow フィールド(例:xtls-rprx-vision)は、TLS の中に TLS を重ねる場面での冗長な暗号化問題をさらに最適化し、現在の低オーバーヘッド方向における主流方式の一つです。重要な制約:VLESS はオリジナル版 Clash コアの対応範囲に含まれず、mihomo(Clash Meta)系のコアのみが解析できます。詳細はE章を参照してください。

Hysteria2

「土台の入れ替え」路線の代表です。QUIC ベースで構築され、認証にはパスワードのみが必要で、設定の複雑さは Shadowsocks に近いレベルです。核心的な違いは輻輳制御にあります:従来の TCP のパケットロス時の後退戦略には依存せず、設定または検出された帯域幅に基づいて継続的に送信を行うため、高パケットロス・高遅延の回線で TCP 系プロトコルより遥かに高い実効スループットを維持できます。代償として回線帯域の使用がやや積極的であり、一部のネットワーク環境では UDP 通信に速度制限や破棄のポリシーが敷かれている場合があり、そうしたネットワークでは挙動が明らかに悪化します。設定例:

proxies:
  - name: "hy2-example"
    type: hysteria2
    server: node.example.com
    port: 443
    password: "your-password"
    sni: node.example.com

TUIC

同じく QUIC ベースですが、設計目標は「高スループット」よりも「低遅延」に偏っています。TUIC は QUIC の 0-RTT 能力を利用し、再接続時には最初のデータパケットにリクエストを含められるため、ハンドシェイク遅延はほぼゼロになります。UDP 通信にはネイティブ転送モード(udp-relay-mode: native)を提供し、ゲームやリアルタイム音声のような遅延ジッタに敏感なアプリケーションに適しています。Hysteria2 と同様に UDP 経路に依存するため、UDP を制限するネットワークでは同様に影響を受けます。対応範囲も mihomo 系コアに限られます。

C接続速度とスループット比較

「どのプロトコルが速いか」は3つの独立した指標に分けて見る必要があります:ハンドシェイク遅延(新規接続に何回の往復が必要か)、安定スループット(帯域をどこまで使い切れるか)、弱い回線での劣化度(パケットロス時にどれだけ落ちるか)。3つの指標のランキングは一致しません。

ハンドシェイク遅延

TCP 系プロトコル(SS、Vmess、Trojan、VLESS)が新規接続を確立するには最低1回の TCP ハンドシェイクが必要で、TLS 1.3 を重ねるとさらに1往復加わり、合計約2 RTT になります。QUIC 系プロトコル(Hysteria2、TUIC)はトランスポートのハンドシェイクと暗号化ハンドシェイクを統合しており、初回接続は約1 RTT、セッション再利用時は TUIC で 0-RTT が実現できます。ウェブ閲覧のような「短い接続を多数行う」負荷では、ハンドシェイクの差がページの初回バイト到達時間に直接反映されます。

安定スループット

回線品質が良好な場合、6種のプロトコル間のスループット差はごく小さく、ボトルネックは通常プロトコル自体ではなくノードの帯域幅にあります。プロトコル側で体感できる差は2点あります:1つは暗号化オーバーヘッド――AES ハードウェア命令をサポートする端末では aes-*-gcm はほぼ無コストであり、VLESS の vision フロー制御は冗長な暗号化をさらに省けます。もう1つはヘッドオブラインブロッキングです――TCP 上でマルチプレクシングを行う場合、1回のパケットロスが同一接続内の全ストリームをブロックしますが、QUIC ではストリーム同士が独立しているため、この問題は発生しません。

弱い回線での劣化

高パケットロス環境は QUIC 系プロトコルの本領発揮の場です。TCP の輻輳制御はパケットロスを混雑と解釈して大幅に速度を落とし、大陸間の高遅延回線では特に顕著です。Hysteria2 の帯域駆動戦略は同じパケットロス率のもとで数倍の実効スループットを維持できます。逆に、UDP に速度制限がかかるネットワークでは、TCP 系プロトコルの方がむしろ安定します。

補足:クライアントのノードリストに表示される「遅延」の数値は、速度測定用アドレスへの1回の HTTP リクエストの合計所要時間を示すもので、現在の回線状態を反映しているだけであり、プロトコルの優劣ではありません。同一ノードで時間帯によって遅延が変動するのは、基本的にプロトコルの種類とは無関係です。遅延の数値が異常な場合の調査方法はブログ記事『Clash ノードがタイムアウトして接続できない場合の調査手順』を参照してください。

Dリソース消費とモバイル端末での電力消費

デスクトップ環境では6種のプロトコルのリソース差はほとんど感じられませんが、スマートフォンでは、プロトコルと動作モードの選択が電力消費の統計に直接反映されます。電力消費への影響を重要度順に並べると:動作モード > 接続維持戦略 > 暗号化オーバーヘッド の順です。

CPU と暗号化オーバーヘッド

現代のスマートフォン SoC は一般的に AES ハードウェア命令を搭載しており、aes-128-gcm / aes-256-gcm の暗号化・復号コストは極めて低くなります。chacha20-ietf-poly1305 は AES 命令を持たない古い端末向けに設計されており、新しい端末ではむしろわずかに遅くなります。VLESS は内層の暗号化を省いているため、単位通信量当たりの CPU 消費は6種の中で最も低くなります。QUIC 系プロトコルのプロトコルスタックはユーザーランドで動作するため、大容量通信のシーン(長時間の高画質動画視聴、大容量ファイル転送)では TCP 系より CPU 使用率が明らかに高くなり、この分がスマートフォンでは発熱と電力消費に転化します。

接続維持とバックグラウンド動作

モバイルネットワークでは、長時間接続を維持するために定期的なハートビートで NAT マッピングを保つ必要があり、ハートビートごとに一時的にベースバンドが起動します。TCP 系プロトコルはシステムのプロトコルスタックの接続維持機能に依存し、動作は比較的控えめです。QUIC 接続の維持はアプリケーション層が担当し、実装によってハートビート間隔の差が大きくなります。日常的にバックグラウンドで動作させ、メッセージング系の通信が主体のシーンでは、SS / Trojan のような「静かな」プロトコルの方が電力消費に優れる傾向があります。Hysteria2 / TUIC はフォアグラウンドでの高負荷利用時間帯に適しています。

動作モードの影響

プロトコル選択より影響が大きいのは動作モードです:システムプロキシモードはプロキシ設定を通るアプリケーションの通信のみを処理します。TUN モードはシステム全体の通信を引き受け、すべてのパケットがクライアントプロセスを経由するため、常駐 CPU 使用率とメモリ使用量がいずれも高くなります。iOS プラットフォームにはさらに制約があります――ネットワーク拡張プロセスにはメモリ上限が厳しく設定されており、ルールセットとサブスクリプションのサイズが大きすぎると拡張プロセスの再起動が発生する可能性があります。モバイル端末で特定アプリを引き受ける必要がない場合は、システムプロキシモードを優先的に使用してください。

Eコアファミリー:オリジナル版、Premium、mihomo

「Clash」という言葉は実際にはコアファミリー全体を指しており、クライアントごとに内蔵しているコアが異なり、それが認識できるプロトコルを直接決定します。クライアントを選ぶ前にまずコアを見分けておくと、「サブスクリプション取り込み後にノードが消えた」という問題の大半を回避できます。

3つの系統の関係

オリジナル版 Clash コアはすべての出発点です:Go 言語で書かれオープンソースで、YAML 設定形式、ポリシーグループ、ルールベースの振り分けという基本モデルを確立し、SS、Vmess、Trojan など当時の主要プロトコルに対応していました。現在はリポジトリがアーカイブ状態となり、更新は行われていません。Premium は原作者がオリジナル版を基に発表したクローズドソースビルドで、主に TUN モードとより強力なルール機能を補完しましたが、これも既に進化を停止しています。Clash Meta はオリジナル版のアーカイブ前後にコミュニティが引き続きメンテナンスした分岐で、後に mihomo に名称変更されました――これが現在唯一活発に活動している分岐であり、新しいプロトコル対応はすべてこの系統で行われています。

機能差の対照

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

クライアントはコアの外側にあるグラフィカルインターフェースの殻であり、コアがプロトコルの対応範囲を決め、殻が操作体験を決めます。現在活発なクライアント――Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android――はいずれも mihomo コアをベースとしており、6種のプロトコルすべてが利用可能です。一方、Clash for Windows、ClashX Meta などメンテナンスが停止したクライアントは古いコアや旧バージョンのままとなっており、新しいプロトコルを含むサブスクリプションでの利用は推奨されません。各クライアントの詳細な取捨選択については比較レビューを、インストールパッケージはクライアントダウンロードページから統一して入手できます。mihomo とオリジナル版コアの全面的な差異分析はブログ記事『mihomo コアとオリジナル版 Clash コアの違い詳解』をお読みください。

F設定とサブスクリプション形式の互換性

プロトコルとコアの選択は最終的にひとつの問題に帰着します:手元のサブスクリプションが、そのクライアントで完全に読み込めるかどうかです。本章ではサブスクリプションの一般的な形態と、コアを跨いだ移行時の互換性のポイントを説明します。

サブスクリプションの3つの形態

1つは Clash YAML サブスクリプション:proxies、proxy-groups、rules の3大セクションを含む完全な設定ファイルで、Clash 系クライアントは直接インポート可能です。これが最も推奨される形態です。2つ目は共有リンク集:ss://、vmess:// などの URI で構成された Base64 テキストで、多様なクライアントで汎用的に使え、Clash 系クライアントに取り込む際はクライアント自身または変換サービスが YAML に翻訳します。3つ目は複数形式対応エンドポイント:同一のサブスクリプションアドレスがリクエスト元の User-Agent に応じて異なる形式を返すもので、サービス提供者側で比較的よく見られます。いずれの形態でも、取り込み手順はチュートリアルページのステップ1を参照してください。

コアを跨いだ移行のポイント

旧コアから mihomo に移行する場合、大部分のフィールドはそのまま互換性があり、YAML を書き直す必要はありません。逆方向は成立しません:設定内に旧コアが認識できない type(vless、hysteria2、tuic など)が1つでも含まれていると、旧コアは解析段階でエラーを出し、設定全体の読み込みが失敗します。これは「サブスクリプション更新後に全ノードが消えた」という現象として表れます。これは Clash for Windows から現行クライアントへ移行する最も一般的な動機のひとつでもあります。サブスクリプションが proxy-providers を通じて外部ノードリストを参照する場合も同じルールに従います:

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

よくある読み込み失敗の原因

サブスクリプションの取得自体は正常だがノードに異常がある場合、順番に3点を確認してください:第一に、クライアントのコアがサブスクリプション内の全プロトコルタイプに対応しているか(テキストエディタでサブスクリプションを開き、type: フィールドを検索して確認)。第二に、YAML のインデントが再編集によって壊れていないか――YAML はインデントに敏感で、スペースが1つ多いだけで解析に失敗します。第三に、proxy-groups が参照するノード名が proxies 内の name と完全に一致しているか、スペースや絵文字も含めて確認してください。サブスクリプション自体の取得失敗(タイムアウト、403 など)についてはよくある質問のトラブル対処カテゴリを参照してください。

G利用シーン別のプロトコル選定指針

前章までの結論をここで実行可能な選定表にまとめます。前提として、サブスクリプション内で同一の着地点に複数のプロトコル入口が用意されていること――多くのサービス提供者はこの形をとっています。サブスクリプションに単一プロトコルしかない場合は、本章をサービス提供者との相談やプラン変更の参考にしてください。

日常のウェブ閲覧とオフィス作業

負荷の特徴は多数の短い接続、単一接続あたりの通信量は小さいことです。Trojan または VLESS がバランスの良い選択です:ハンドシェイクの負荷は許容範囲、通信特徴がクリーン、CPU 使用率も低いです。SS も十分に使えて、パラメータが最少で設定ミスが最も起きにくいです。このシーンではプロトコル間の差は体感上ほぼゼロなので、こだわる必要はありません。

高画質ストリーミングと大容量ファイル

負荷の特徴は長時間接続、高い持続スループットです。回線品質が良好であればどのプロトコルでも帯域を使い切れます。大陸間の高遅延やピーク時のパケットロスが明らかな場合は、Hysteria2 の優位性が最も大きく、同じ回線条件下での実効スループットは通常 TCP 系プロトコルより大幅に高くなります。利用中のネットワークが UDP を速度制限していないことを確認してください。そうでなければ Trojan / VLESS に切り替えましょう。

モバイルネットワークでの通勤

セルラーネットワークは信号の変動が大きく、基地局の切り替えも頻繁で、接続の再確立が常態です。QUIC 系プロトコルの接続マイグレーションと低いハンドシェイクコストがここで最も価値を発揮します:TUIC の 0-RTT により、回線切断からの復帰がほぼ無感覚になります。省電力を優先するなら、D章の結論を参考に、待機時間帯は SS / Trojan を使い、高負荷利用時間帯に切り替えてください。

ゲームとリアルタイム会議

核心となる指標は帯域幅ではなく遅延ジッタで、通信は主に UDP です。TUIC のネイティブ UDP 転送が第一選択で、Hysteria2 がそれに続きます。TCP 系プロトコルで UDP を転送するには追加のラッピングが必要で、ジッタの表現は概して劣ります。クライアント側では TUN モードと併用し、ゲームプロセスの UDP 通信が確実に引き受けられるようにすることを推奨します。

サーバー・ルーター常時運用

画面のない環境で mihomo コアを直接実行する場合、プロトコル選択は安定性を優先します:SS または Trojan の長期的な安定性と低リソース使用率が 7×24 の常時運用に最も適します。コアのインストールパッケージはダウンロードページのコアセクションを参照してください。ルーター等の ARM デバイスでは対応するアーキテクチャのビルドを選んでください。

Hよくある誤解とトラブル対処の入口

誤解1:新しいプロトコルほど速い

プロトコルが決定するのは特定条件下での挙動の差であり、絶対的な速度ではありません。回線品質が良好であれば6種のプロトコルのスループットはほぼ一致し、Hysteria2 は良好な回線上では SS より速くなることはなく、UDP が制限されたネットワークではむしろ遅くなります。まずボトルネックがどこにあるか(ノードの帯域幅、ローカルネットワーク、あるいはプロトコルとネットワークの適合度)を確認してから、プロトコルの変更を検討してください。

誤解2:遅延の数値が低い=体験が良い

ノードリストの遅延は1回の HTTP 往復を測定したものであり、持続的なスループットやパケットロス率とは直接の関係がありません。50ms だがピーク時のパケットロスが激しいノードは、180ms だが回線がクリーンなノードより実際の体験が大幅に劣ることがあります。ノードの品質判断は実際の利用時の読み込み速度と安定性を踏まえるべきで、速度測定の数値だけを見てはいけません。

誤解3:グローバルモードの方が安定する

グローバルモードは単にすべての通信をプロキシに送り込むだけで、接続層の問題を何も解決しません。むしろ本来直接接続すべき通信まで迂回させてしまい、ノード障害の影響範囲を広げます。ルールモードと合理的な振り分けルールの組み合わせが通常の使い方であり、グローバルモードは「ルールが命中していないのでは」という問題を一時的に調査する際に適しています。

誤解4:暗号化の層数が多いほど安全

VLESS が内層の暗号化を省いているのは安全性を弱めることではありません――外層の TLS 1.3 が既に完全な機密性と完全性の保証を提供しており、2層目の対称暗号化を重ねても CPU 負荷が増えるだけで防御力は増えません。安全性の要点は証明書検証が有効になっているか、パスワードの強度が十分かにあり、暗号化の層数にはありません。

トラブル対処の入口一覧

• サブスクリプション更新失敗、起動時自動起動、モード切替などの頻出問題:よくある質問にカテゴリ別の標準対処手順を整理しています。
• ノードが全て、または一部タイムアウトする場合:ブログ記事『ノードがタイムアウトして接続できない場合の調査手順』で示された固定の順序で階層的に確認してください。
• クライアントのログに出るエラーの意味がわからない場合:『Clash の実行ログの見方』を参考にエラーの意味を1件ずつ照合してください。
• 本文中に出てくる用語(AEAD、SNI、RTT、TUN など)の解説:用語集の該当カテゴリを確認してください。