Clash 代理プロトコルとカーネル選定ガイド

Ⅰプロトコルの系譜概観:SOCKS5からQUIC世代まで

代理プロトコルとは、クライアントとリモートサーバー間の取り決めのことで、データをどう封筒に入れるか、どう暗号化するか、認証情報をどう確認するか、TCPかUDPかを定める。Clash系クライアントの立ち位置は、ルールの実行者であり各プロトコルの実装者だ。プロトコル自体を発明するわけではなく、各コミュニティが公開したプロトコルを実装し、ルールエンジンに統括的に扱わせている。したがって、どのプロトコルを使うかは、実質サーバー側とクライアント側が共に対応する封筒形式を選ぶ話であり、クライアントの機能がいくら強くても、サーバーが提供していないプロトコルは動かせない。

プロトコルには2方向あることも区別しておきたい。イン方向は、ローカルアプリがどうクライアントに接続するかで、ブラウザやシステムプロキシはHTTPまたはSOCKS5ポートを経由する。これら2つは入口を担うだけでサブスクには現れない。アウト方向こそ本巻の主題で、クライアントがトラフィックをSSやVLESSなどの形式に封筒詰めしてリモートサーバーへ送る部分だ。日常的に「プロトコルを選ぶ」と言うときは、常にこのアウト方向を指している。

系譜と誕生の背景

SOCKS5とHTTPプロキシは最も古い汎用プロキシ形式で、転送のみを担い暗号化は定義しない。今もClashのローカルイン用プロトコルとして使われている。2012年頃、Shadowsocksが対称暗号を代理プロトコルに持ち込んだ。トラフィックを暗号化してリモートに送り、サーバー側で復号して転送する仕組みで、プロトコル本体は極めてシンプルなまま、十数種類の言語で実装が存在する。2016年頃にV2Rayプロジェクトが発表され、そのネイティブプロトコルVMessは別路線を取った。全量暗号化・タイムスタンプ認証・トランスポート層の付け替え可能性を重視し、設定の自由度を大きく引き上げた。2018年頃登場のTrojanは偽装優先を掲げ、代理接続の見た目を通常のHTTPSアクセスと一致させ、認証はパスワード1つだけに絞った。2020年頃、VMessの簡略版としてVLESSが登場し、暗号化の責務をTLSに戻してヘッダーを軽量化。同時期、QUICを基盤とするHysteriaとTUICが相次いで現れ、UDPを使って低速回線下のスループットを確保した。Hysteria2は前者の改良版だ。この6本の流れが、今日のClash設定のproxies項目における主な選択肢を構成している。

項目一覧

以下の表で6種類のプロトコルを並べ、まず全体像をつかんでもらう。詳細は後続の各章で扱う。

この表を読むときは3つの軸を押さえておけば十分だ。封筒と外形——プロトコル自体が偽装を持つか、トラフィックがどんな形をしているか。オーバーヘッドと性能——ハンドシェイクの往復回数、暗号化によるプロセッサ負荷、低速回線でのスループット維持力。エコシステムと対応度——サーバー側の普及度、クライアントのカーネルが実装しているか、サブスク形式が対応しているか。以降の各項目はすべてこの3軸に沿って展開する。

ルールエンジンとの関係

2つのレイヤーをはっきり区別する必要がある。プロトコルは1本の接続をどう送るかを決め、ルールはどの接続をどのプロトコルに流すかを決める。Clashのルールエンジンはプロトコルの上位で動作する。1つの設定内にSS・VLESS・Hysteria2の3種のノードを共存させ、ルールがドメイン・IP範囲・プロセス名に応じてトラフィックを異なるポリシーグループに振り分け、ポリシーグループが具体的なノードに結びつく。したがって、プロトコルを選ぶこととトラフィックを振り分けることは別の話であり、前者は本巻を、後者の実践的な解説は「Clashルールベース振り分け設定実践」を参照してほしい。

ⅡShadowsocks:軽量暗号化の原点

Shadowsocks(略称SS)はClashが最も長くサポートしてきた代理プロトコルであり、サブスクに登場する頻度も最も高い部類に入る。設計目標は一言で言える。できるだけ少ないハンドシェイクと、できるだけ単純な形式で、TCPとUDPのトラフィックを暗号化して転送することだ。

設計目標と封筒形式

SSのセッションにはハンドシェイク段階がない。クライアントは宛先アドレス・ポート・ペイロードを一括暗号化して直接送信し、サーバーは同じ事前共有鍵で復号し、宛先アドレスを読み取って転送する。鍵はユーザーのパスワードから鍵導出関数で生成され、マスターキーに加え各接続ごとにサブキーを派生させることでリプレイを防いでいる。ハンドシェイクがないため、SSの初回応答遅延はTCP系プロトコルの中で最も低い。形式が単純なため、完全な実装がわずか数百行のコードで済み、ルーターのファームウェアからブラウザ拡張まで幅広く移植されている。

SSはネイティブでUDPリレーを定義している。クライアントがUDPデータグラムを暗号化してサーバーに送受信を代行させる仕組みで、ゲーム・ボイスチャット・QUICの接続確立はこの機能に依存する。Clash設定のudp: trueがこのスイッチをオンにする。ゲーム用途のノードでは、このスイッチをオンにするだけでなく、サービス提供者側がUDPリレーを制限していないことも確認すべきだ。

SSにはプラグインのエコシステム(simple-obfs、v2ray-pluginなど)もあり、SS本体の外側にもう1層の偽装やWebSocketトランスポートを重ねられる。mihomoはpluginとplugin-optsフィールドでその一部をサポートしている。プラグインはあくまで上乗せ層であり、SS本体の形式を変えるものではない。

暗号スイート:AEADへの移行

初期のSSはaes-256-cfbやchacha20-ietfといったストリーム暗号を使っていた。これらは暗号化のみで完全性検証を行わず、後に能動的な探知に利用され得る欠陥が指摘されたため、コミュニティ全体でAEAD(認証付き暗号)への移行が進んだ。現在使える3つの主要スイートはaes-128-gcm、aes-256-gcm、chacha20-ietf-poly1305で、前2つはAES-NI命令セットを持つデスクトップ・サーバー用プロセッサ上でほぼオーバーヘッドゼロで動く。一方chacha20-ietf-poly1305はハードウェア支援に依存せず、スマートフォンや低性能ルーターのARMチップ上ではむしろ高速だ。その後コミュニティは2022-blake3-aes-128-gcmなどの新スイートも提案し、shadowsocks-rustとmihomoの両方で実装済み。BLAKE3による鍵導出とリプレイ保護の強化を行っており、新規デプロイでは優先的に検討する価値がある。

適用場面と限界

SSの限界もその簡潔さに起因する。プロトコル自体に偽装層がなく、暗号化されたトラフィックは外形上、長さがランダムでエントロピーの高いデータストリームであり、通常のHTTPS通信のTLSレコードとは形が異なる。またサーバー側のマルチユーザー管理も定義されておらず、1ポートに1つの鍵という対応になる。したがってSSは十分に使える汎用の選択肢として向いている——実装が広く、オーバーヘッドが低く、運用の手間も少ない。外形の偽装を重視するなら、第四章のTrojanや第三章のVLESSを検討してほしい。

クライアント設定のポイント

Clash設定において、SSノードに必須の項目はserver、port、cipher、passwordの4つだけで、udpがUDP転送の有効/無効を制御する。cipherはサーバー側と厳密に一致させる必要がある。スイートの記載ミスはSSノードが接続できない最大の原因なので、トラブル時はまずこの行を確認し、次にパスワードとポートを確認するとよい。サービス提供者からss://形式の共有リンクが提供された場合は、クライアントに取り込む際に自動で以下のフィールドに展開されるため、手で書く必要はない。

proxies:
  - name: "ss-aead"
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

ⅢVMess と VLESS:V2Ray系の2回の進化

VMessとVLESSは共にV2Rayプロジェクト由来(その後V2FlyやXrayなどに分派)で、前者はプロジェクトのネイティブな主力プロトコル、後者は前者の複雑さを見直して軽量化した版だ。この2世代間のトレードオフを理解することは、代理プロトコルにおける核心的な論点——暗号化はどの層で行うべきか——を理解することにつながる。

VMess:全量暗号化という設計

VMessの発想は、プロトコル自身が全てのセキュリティを担うというものだ。リクエストヘッダーにユーザーUUID・タイムスタンプ・検証情報を含み、セッション全体をAES-128-GCMまたはChaCha20-Poly1305で暗号化し、外側のTLSに依存しない。タイムスタンプ認証はクライアントとサーバーの時刻誤差が約2分以内であることを要求するため、VMessのトラブルシューティングでまず確認すべき点だ。デバイスのタイムゾーンがずれていたり、ネットワーク時刻同期がオフになっていたりすると認証失敗を招く。初期VMessのalterIdパラメータは複数の鍵を派生させるために使われていたが、後にセキュリティを弱めることが判明し、新しい実装では廃止されている。設定にalterIdが0以外で残っている場合は古い書き方と見なすべきだ。

VMessのUUIDはユーザー識別も兼ねており、サーバー側はこれに基づいてマルチユーザー振り分けやトラフィック統計を行う。これがvmess://共有リンクのフィールドが最も多い理由でもある——Base64エンコードされたJSONの中に、アドレス・ポート・UUID・トランスポート層・TLSスイッチ・偽装ドメインを詰め込む必要がある。

VLESS:暗号化をTLSに戻す

VLESSという命名自体がその立場を表している。VMessの暗号化層を取り除き、プロトコルヘッダーにはUUIDと極少数の制御フィールドのみを残し、暗号化は完全に外側のTLSに委ねる。利点は2つある。ヘッダーが短くなり、プロセッサが二重暗号化をしなくて済むこと。XTLS Vision フロー制御(flow: xtls-rprx-vision)と組み合わせれば、TLSレコードを直接転送でき、暗号化・復号のコピーをもう一段省略できる。代償として、VLESSは必ずTLSと組み合わせて使う必要がある——TLSなしのVLESSには機密性がなく、mihomoなどのカーネルもTLS形態のVLESSノードしか受け付けない。

Xray分派は後にVLESSの上にREALITYという形態を提案した。自前の証明書を発行せず、実在するサイトのTLS外形を借用してハンドシェイクを行うことで、ドメインと証明書の維持を省略できる。mihomoはreality-optsフィールドで対応している。これはTLS層におけるもう1つのトレードオフで、デプロイは簡単になるが設定項目は増える。一般の利用者は基本的にサービス提供者が渡すサブスクに従えばよい。

トランスポート層:WS、gRPC、中継

V2Ray系のもう1つの重要なパーツはトランスポート層(network)だ。wsはトラフィックをWebSocketフレームに、grpcはHTTP/2ストリームに詰め込む。いずれもTLSを重ねて通常のウェブサイトのトラフィックに偽装できる。この組み合わせの実用的な価値は、CDNの背後に置けることにある。ドメインをCDNに解決させ、CDNがサーバーへオリジン取得を行うため、実際のアドレスが露出せず、CDNの接続ポイントを利用して迂回路線を改善することもできる。Clash系カーネルはwsとgrpcトランスポートを完全にサポートし、設定ではnetwork、ws-opts、grpc-optsフィールドで記述する。

どちらを選ぶかの結論

新規デプロイならVLESS + TLSを選び、既存ノードはVMessのまま維持すればよい。VMessの全量暗号化はTLSがない場面では依然として意味を持つが、証明書がある条件下ではVLESSの低オーバーヘッドと直接転送が全面的に優位だ。対応する設定は以下のような形になる。

proxies:
  - name: "vless-vision"
    type: vless
    server: example.com
    port: 443
    uuid: "00000000-0000-0000-0000-000000000000"
    network: tcp
    tls: true
    udp: true
    flow: xtls-rprx-vision
    servername: example.com

ⅣTrojan:偽装優先の設計思想

Trojanの設計文書は冒頭でこう述べている。代理トラフィックを何か別のものに見せかけるより、そもそも本当に別のものであることにしたほうがよい。Trojanの接続は外形上、標準的なTLSセッションそのものであり、プロトコル本体はTLSの内側に隠れ、認証はパスワードのハッシュ値1つに依存する。

TLSこそが本体

Trojanサーバーは443ポートで待ち受け、外部には正常なHTTPSサイトとして振る舞う。証明書は有効で、ハンドシェイクも標準的だ。認証できない接続を受け取った場合、トラフィックを実在のウェブサイトへフォールバックすることもできる。認証が通った後、TLSレコード内には極めて簡潔なTrojanリクエストヘッダー——パスワードのハッシュ・宛先アドレス・ペイロードが載る。プロトコル自体は暗号化を一切行わず、暗号化はすべてTLSが提供する。この点はVLESSの発想と同じだが、Trojanのほうが登場が早く形式もより単純だ。

Trojanの偽装には細部の要件もある。サーバーが本当にウェブサイトらしく見える必要があるのだ。証明書は有効だが443ポートに何もページ内容がないだけのサイトは、能動的な探知の目には逆に目立ってしまう。そのため多くのデプロイではfallback先に実在のページを用意している。この部分はサーバー運用側の話であり、クライアントは関与しないが、選定時には知っておくべきだ。似ているかどうかはサーバー側の完成度に左右される。

VMess + TLSとの異同

同じくTLS内で代理を走らせる点は共通だが、TrojanとVMess + WS + TLSの違いは層の数にある。後者はTLS→WebSocket→VMessの3層封筒、前者はTLS→Trojanの2層のみだ。層が少ないほどオーバーヘッドが小さく実装も短くなるが、その分設定の自由度も少ない——Trojanにはトランスポート層のバリエーションがなく、TCP + TLSの1形態のみだ。CDN中継が必要な場合、Trojanも(多くのカーネルで対応する)WebSocketを使えるが、それは結局多層封筒の道に戻ることになる。

TrojanのUDP対応はプロトコル内のコマンドコードで実現される。UDPデータグラムはTLSストリームの中に封じ込めて送られ、クライアント設定は同じくudp: trueで有効化する。UDPがTCPに包まれている以上、パケットロスに敏感な場面ではTCPの特性をそのまま引き継ぐ——これは第五章のネイティブQUICによるUDP転送との対比になる。

デプロイの前提条件とクライアント設定

Trojanの簡潔さには前提条件がある。デプロイする側はドメインと有効な証明書を持つ必要があり、証明書は通常ACMEで自動発行し、ドメインをサーバーに解決させる。一般の利用者にとってはこれらはサービス提供者側で完了しているため、クライアント側で必要なのはserver、port、password、sniの4項目だけだ。sniは証明書のドメインと一致させる必要がある。skip-cert-verify: trueは証明書検証を無効化するもので、TLSの偽装防止機能を放棄することを意味する。自己署名証明書のテスト環境で一時的に使うにとどめ、本番設定ではfalseを保つべきだ。

proxies:
  - name: "trojan-tls"
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    skip-cert-verify: false
    udp: true

性能面では、Trojanのオーバーヘッドは純粋なTLSセッション1回とほぼ同等だ。ハンドシェイクは2〜3往復(TLS 1.3でセッション再利用すれば短縮される)、通信中は対称暗号1回のみ。デスクトップやサーバーではHTTPS通信と大差ない。モバイル端末では、TLSセッションの保持とTCPキープアライブが電力消費の主因になる。詳細は第六章を参照。

ⅤHysteria2 と TUIC:QUIC世代のスループット重視プロトコル

これまでの4章のプロトコルはすべてTCP上で動く。TCPの信頼性のある転送には代償があり、パケットロスが起きると1本のストリーム全体が再送待ちで詰まる(ヘッドオブラインブロッキング)。パケットロスの多い回線ではスループットが急落する。QUICは信頼性のある転送をユーザー空間に持ち込みUDPの上で動かすことで、ストリーム単位の独立した再送を可能にし、さらに0-RTTハンドシェイクとコネクションマイグレーションという2つの基盤機能も備える。Hysteria2とTUICはQUIC系代理プロトコルの中で最も実装が広い2つだ。

Hysteria2:スループット優先

Hysteria2はHysteriaの改訂版で、プロトコルは大幅にスリム化された。認証を簡略化し制御面を絞り込み、核となる強みは輻輳制御に置いている。独自のBrutal輻輳制御はパケットロスに応じて速度を落とさず、ユーザーが宣言した帯域目標に基づき送信を続ける。パケットロス率が高いが物理帯域は十分にある回線(大陸間の無線、混雑するピーク時間帯の出口回線が典型例)では、TCP系プロトコルの数倍のスループットが得られることもある。代償も明確だ。Brutalはネットワークの状況を気にせず動くため、帯域目標を高く設定しすぎると同一回線上の他の通信を圧迫し、通信事業者側のUDP制限ポリシーを誘発する可能性もある。設定内のupとdownフィールドがこの速度宣言に相当し、単位はMbpsで、サーバーの実際の帯域に合わせて設定すべきであり、高く盛るべきではない。

Hysteria2のエコシステムにはmihomoが既に実装している実用的な機能もある。ポートホッピングだ。サーバーが一定のポート範囲を待ち受け、クライアントは約束に従い範囲内でポートを切り替えながらパケットを送る。設定ではportsフィールドを範囲形式で記述する。この機能は単一ポートの速度制限を回避するためのものであり、通信経路上のテクニックであってプロトコル本体の形式には影響しない。

TUIC:低オーバーヘッドのQUIC封筒

TUICの目標はHysteria2とは異なり、QUICの上でできるだけ余分なオーバーヘッドを持たないことを追求している。プロトコルはネイティブでUDP転送に対応し、2種類のUDPモードを提供する。nativeはUDPデータグラムをそのままQUICデータグラムにマッピングし、quicはUDPパケットも信頼性のあるストリーム転送に含める。前者はゲームやボイスチャットのような遅延に敏感な実際のUDP用途に適している。TUICはQUIC標準の輻輳制御をそのまま使い、積極的な高速化は行わず、より規律的に振る舞うため、UDPが速度制限されるネットワークでもより緩やかに劣化する。

QUICは輻輳制御を差し替え可能な仕組みにしている。TUICのcongestion_controlフィールドではbbrやcubicなどのアルゴリズムを選べる。おおまかに言えば、cubicは保守的な汎用デフォルトで、bbrは帯域と遅延をモデル化し、バッファが大きい回線でより安定する。一般の利用者は既定値のままで問題ない。このつまみの存在を知っておけば、速度が思わしくないときにもう1つの調査方向が得られる。TUICのheartbeat_intervalはハートビート間隔を制御し、待機時の消費電力に直接影響するため、モバイル端末では数秒以上に広げてもよい。

コネクションマイグレーションと0-RTT

QUICが持つ2つの恩恵は個別に取り上げる価値がある。0-RTT:同一サーバーへの再接続時、最初のパケットにペイロードを乗せられ、ハンドシェイクの往復を省略できる。代理の起動時の体感は直結に近くなる。コネクションマイグレーション:接続は4タプルではなくConnection IDで識別されるため、スマートフォンがWi-Fiからモバイル通信に切り替わったり、基地局間のハンドオーバーでIPが変わったりしても、接続は切断・再構築されない。進行中のダウンロードや通話も影響を受けない。この2点はモバイル端末での意義がデスクトップよりずっと大きく、第六章で再度触れる。

proxies:
  - name: "hy2"
    type: hysteria2
    server: example.com
    port: 443
    password: "your-password"
    up: 30
    down: 200
    sni: example.com

Ⅵ速度・リソース消費・モバイル端末の電力:横断比較

プロトコル比較は「どれが最速か」という問いに誤読されがちだ。誠実な答えはこうだ。回線状況が良好な場合、6種類のプロトコル間のスループット差は通常ほとんど感知できないほど小さく、ボトルネックはサーバーの帯域と通信事業者の回線にある。プロトコル間の差が現れるのは3つの縁の場面——ハンドシェイク遅延、低速回線でのスループット、デバイスのオーバーヘッド——に限られる。本章はこの3軸に沿って比較する。

もう1つ過大評価されがちな指標がスピードテストのスコアだ。計測サイトが最大帯域を出せるかどうかは、サーバーの出口とピーク時間帯の混雑状況に大きく依存する。プロトコル単体のスコアより、同一回線でプロトコルだけ切り替えて3回ずつ計測して比較するほうが、素朴だが参考になる。自分で実験するなら、サーバーと時間帯を固定し、プロトコルの種類だけを変えて各3回計測し中央値を取る。さらに時間帯を変えて再計測する。変数がプロトコルだけになったとき、はじめて結論に意味が出る。

ハンドシェイクと初回応答遅延

TCP系プロトコルはまずTCPハンドシェイク(1往復)を完了し、TLSを伴う場合はさらにTLSハンドシェイク(TLS 1.3なら1往復、セッション再利用ならゼロにできる)が加わる。SSはプロトコルレベルのハンドシェイクがないため総オーバーヘッドは最も低く、TrojanとVLESSがそれに続く。QUIC系は初回接続で1往復、再接続では0-RTTになる。200ミリ秒級の大陸間回線では、再接続シナリオでHysteria2とTUICの初回応答がTCP + TLS系より0.5秒近く速くなることがある。ウェブページの閲覧や短命な接続でAPIを呼ぶような場面では体感差が明確だ。

プロセッサ・メモリ・デバイスのオーバーヘッド

通信中のプロセッサ消費は主に対称暗号による。AES-NIを持つx86デバイスでは、AES-GCMは1コアで数Gbpsをこなせるため、プロトコルによるオーバーヘッドは無視できるレベルだ。AES命令を持たないARMデバイスでは、ChaCha20-Poly1305がAES-GCMより約2〜3倍速く、これがモバイル端末でchacha20系スイートが推奨される理由になっている。メモリについては、各プロトコルとも1接続あたりMB未満で、実際にメモリを大きく消費するのはカーネルのルールセットと接続追跡テーブルであり、プロトコルとは無関係だ。処理能力が数百MHz級のルーターなどでは、二重暗号化(VMessの内部暗号化に加え外側TLSを重ねる構成)を避けることで実質的な余裕が生まれる。これはVLESSとTrojanがVMessに対して持つ実用的な優位性だ。

モバイル端末の電力

モバイル端末で電力を最も消費するのは暗号化・復号処理ではなく、無線モジュールの起動回数だ。TCPの長時間接続はアドレスマッピングを維持するためキープアライブパケットに依存し、起動ごとに電力を消費する。Wi-Fiからモバイル通信への切り替え時にTCP接続が切れると、再接続のハンドシェイクもまた無線活動の1回分になる。QUICのコネクションマイグレーションは切り替え時に接続を切らずに済ませ、0-RTTは必要な再接続を短縮する。この2つが相まって、頻繁に移動する使い方をする日には、Hysteria2とTUICはTCP系より電力・通信量ともに低く抑えられる。逆の要因もある。ハートビート間隔を短く設定しすぎると待機時の起動が頻発するため、関連パラメータは長めに設定するのが基本だ。

6軸比較表

この表に全能の優勝者はいない。SSは実装の広さと低遅延で強く、QUIC系は低速回線とモバイル用途で強く、TrojanとVLESSは外形と低オーバーヘッドで強い。実際に選ぶ際は、まずサービス提供者が何を提供しているかを見て(第八章)、その中で本章の3軸に沿って取捨選択するのがよい。

Ⅶカーネルファミリー:無印Clash、Meta、mihomo

Clashという言葉はエコシステム内で3つのものを同時に指す。カーネル、設定形式の一種、そしてクライアントの一族だ。この3層を区別することが、互換性に関する議論全般を理解する前提になる。カーネルは実際に動く部分——ローカルポートを待ち受け、ルールを解析し、プロトコルに従ってパケットを送る。クライアントはカーネルのGUI外殻。設定形式は両者を結ぶ契約に相当する。

無印Clashのアーカイブ化

無印Clashのカーネルは Dreamacro によりGoで開発・維持され、YAML設定形式・ルールエンジン・ポリシーグループ体系を確立した——今日のClash系クライアントの文法はすべてこの定義に由来する。2023年末、開発者はリポジトリをアーカイブ化して開発を停止し、クローズドソースのPremiumブランチも同時に更新終了となった。アーカイブ化は無効化ではない。無印カーネルは今も動作し、SS・VMess・Trojanなど旧来のプロトコルは問題なく機能する。しかしHysteria2・TUIC・VLESSといった新プロトコルやrule-setなどの新機能は、今後も無印には決して追加されない。

Clash Metaとmihomoによる継承

Clash Metaは無印が更新停止する前からコミュニティが進めていた強化ブランチで、無印に欠けているプロトコルと機能を補うことを目標としていた。無印がアーカイブ化された後、事実上の後継となり、その後 mihomo に名称変更された。無印と比べたmihomoの主な追加点は、VLESS・Hysteria2・TUIC・WireGuardなどのプロトコル対応、rule-set規則集(大量のルールをバイナリ形式にコンパイルし必要に応じて読み込む、逐行テキストマッチングに代わる仕組み)、DNSモジュールのnameserver-policyやfallback-filterといった細粒度制御、TUICイン方向やプロセス名マッチングなどのシステムレベルの機能だ。現在活発なクライアント——Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android——はすべてmihomoをカーネルとして採用している。各プロジェクトの成り立ちについては「Clashオープンソースエコシステム総覧」に完全な系譜があるので、本巻では選定に関係する部分のみ取り上げる。

設定の互換性

互換の方向は一方向だ。無印用に書かれた設定は、ほとんどそのままmihomoで動く。mihomo用に書かれた設定は、新しいフィールドを使っている部分は無印が認識しない。実務上は2点だけ覚えておけばよい。1つ目、古いクライアント(Clash for Windows、旧版ClashX)は無印のフィールドしか認識せず、サブスクにhysteria2タイプのノードがあるとスキップまたはエラーになる。2つ目、mihomoは一部フィールドの意味を調整している。例えばdnsブロックのdefault-nameserverが必須化されている。無印から設定を移行して起動エラーになった場合は、エラー行に沿って公式ドキュメントを1つずつ確認すればよく、多くはフィールドの追加であって書き換えではない。

クライアントとカーネルの対応関係

ダウンロードページのパッケージ一覧はこの区分に沿って構成されている。全プラットフォームで最も推奨されるClash Plus、デスクトップ主流のClash Verge RevとFlClash、AndroidのClash Meta for Androidは、いずれもmihomo系だ。更新終了と表示されるClash for WindowsとClashX Metaは旧カーネル時代のまま留まっており、アーカイブとして残されているにすぎない。GUIクライアントでは、カーネル切り替えは通常1つのスイッチにすぎない。Clash PlusとClash Verge Revは設定ページでカーネルバージョンと更新チャンネルを提供し、FlClashはカーネルを内蔵してクライアント本体と一括更新する。一般の利用者はカーネルのバイナリを手動で入れ替える必要はない。手動での入れ替えは高度な操作にあたり、入れ替え後は-tパラメータで設定を検証してから起動するのが望ましい。実用的な結論としては、新規導入なら常にmihomo系クライアントを選び、古いクライアントは動くうちは使い続け、動かなくなったら移行する、という方針でよい。

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

サブスクリプションは、サービス提供者とクライアントの間の輸送形式だ。1本のURLをクライアントが定期的に取得し、一群のノードとルールを得る。エコシステムには2つの形態が並存している。Clashネイティブのサブスク(完全なYAML1本)と、汎用共有リンク(ss://、vmess://などのリンクの集合)だ。mihomo系クライアントはどちらも取り込めるが、両者の情報量は異なる。

Clashネイティブサブスク

Clashサブスクが返すのは、完全またはほぼ完全なconfig.yamlで、proxies項目にノードを列挙し、proxy-groups項目にポリシーグループを事前設定し、rules項目に振り分けルールを含める。サービス提供者はサブスク内にオートセレクト・マニュアルセレクト・保険用フォールバックなどのポリシーグループをあらかじめ組んでおり、利用者は取り込むだけで使える。利点は、ルールとノードが同一の元から一括管理されるため、提供者がルールを更新しても利用者は特に何もしなくてよいこと。代償は、各社のルールの方向性が異なるため、サービス提供者を変えると振り分けの傾向も丸ごと変わってしまうことだ。mihomo系クライアントでClashサブスクを取り込む際は、通常「ノードのみ取り込む」か「一式そのまま採用する」かを選べる。前者はローカルのルールを保持し、後者はルールも提供者版に丸ごと入れ替わる。このスイッチを理解しておけば、ルールが不意に上書きされて困惑することを避けられる。

汎用共有リンクとサブスク変換

汎用サブスクは共有リンクを行単位で並べて返す。ss://とtrojan://はURI形式、vmess://はBase64エンコードされたJSON、vless://、hysteria2://、tuic://はそれぞれ独自のURI規約を持つ。この種のサブスクにはノード情報のみが含まれルールは含まれず、クライアントは取り込み後に自前のルールテンプレートを適用する。汎用サブスクをClash形式に変換するサービスをサブスク変換と呼ぶ。オンラインサービスまたは自前ホストのプログラムがテンプレートに沿ってYAMLを生成する。変換のプライバシー上の意味も理解しておく必要がある。サブスクリンクにはサーバーアドレスと認証情報が含まれるため、第三者による変換を経ることは、ノード情報をその相手に渡すことに等しい。機密性の高いノードは自前ホストの変換ツール、またはクライアント内蔵の解析機能(mihomo系クライアントの多くは汎用サブスクの直接取り込みに対応)を使うべきだ。

フィールド単位でのカーネルの差異

同一ノードでも異なるカーネルにおけるフィールドの書き方は概ね一致しているが、差異は主に3か所に集中する。1つ目、新プロトコルのフィールド。hysteria2のupとdown、tuicのudp_relay_modeなどはmihomoしか認識しない。2つ目、トランスポート層のネスト。ws-opts下のheaders、grpc-optsのservice-nameなど、各パーサーの既定値への許容度が異なる。3つ目、ルール部分。rule-providersとrule-setはmihomoの拡張機能で、無印カーネルが遭遇するとエラーになる。サブスクのYAMLを手動編集した際は、クライアントの設定検証機能やカーネルのテストパラメータで一度流すほうが、直接再起動して不具合を追うより速い。

mihomo -d /etc/mihomo -t

サブスクはmihomoの設定内では、より工程的な形態も取り得る。proxy-providersは外部由来のノード一覧を宣言的に定義し、intervalで定期更新し、health-checkで定期的に速度測定を行い、url-testポリシーグループと組み合わせて自動的に最良のノードを選ぶ。サービス提供者のサブスクは本質的に1つの遠隔proxy-providerだと考えれば、この抽象を理解した上で、複数サブスクの並存やローカルノードとサブスクの混合編成も、同じ仕組みの組み合わせにすぎないことが分かる。

サブスクはノードをどこから得るかを解決し、ルールはトラフィックをどこへ送るかを解決する。サブスクに付属するルールが合わない場合は、クライアント側で上書きするか自前のルールセットを構築すればよい。ルールの文法・マッチング順序・MATCHによる兜底の完全な書き方は「Clashカスタムルール記法詳解」と「Clashルールベース振り分け設定実践」の2記事を参照してほしい。本巻ではこれ以上展開しない。

Ⅸ用途別の選び方:決定表と全体方針

前8章の事実を決定表にまとめる前に、まず全体方針を1つ立てておく。プロトコルの選択の自由度は、その大半がサービス提供者側にある。純粋な利用者にとっての現実的な決定手順はこうだ。まずサブスクがどのプロトコルを提供しているかを見て、その中から用途に合わせて選ぶ。自前でサーバーを構築する側だけが完全な選択権を持ち、その考慮点は本章にまとめている。

デスクトップの日常利用:安定を第一に

デスクトップ用途では回線が安定していてデバイス性能も十分なため、プロトコル間の差は最小になる。サブスクの既定ノードをそのまま使えば十分だ。同一サブスクで複数プロトコルが提供されている場合は、VLESSまたはTrojan(低オーバーヘッド)、あるいはSS(低遅延)を優先するとよい。クライアント面では、全プラットフォームでClash Plusを第一候補として推薦する。mihomoカーネル、日本語対応の見やすいUI、設定の上書きやビジュアル編集機能が揃っている。ダウンロードとインストールの詳細はダウンロードページを参照。

モバイル端末:電力とネットワーク切り替え

スマートフォン用途の2つの弱点は、ネットワーク切り替えと待機時の電力消費だ。サブスクにHysteria2やTUICのノードがある場合は、モバイル通信下では優先的に使用したい。コネクションマイグレーションによりWi-Fiとモバイル通信の相互切り替えでも接続が切れず、0-RTTが必要な再接続を短縮してくれる。TCP系ノードしかない場合は、キープアライブ系のパラメータを緩め、使わないUDP転送をオフにすることでも電力を節約できる。iOSとAndroidそれぞれの具体的なクライアントと導入手順は入門ガイドにプラットフォーム別の手順がある。

ゲームとリアルタイム音声・映像通話

ゲーム、ボイスチャット、ビデオ会議はUDPと遅延に最も敏感な用途だ。udp: trueが使えるノードを優先し、QUIC系(特にTUICのnativeモード)はモバイル通信下で最も安定した結果を出す。ゲームを代理経由にしたい場合は、ゲームのプロセスやドメインを最も低遅延のポリシーグループに向けることを忘れずに。プロトコルは1接続の品質を決め、ルールはそれが実際に使われるかどうかを決める。

低速回線・パケットロスの多い回線

大陸間通信、ピーク時間帯、無線中継といった年間を通じてパケットロス率が高い回線は、QUIC系の得意領域だ。Hysteria2は宣言した帯域に基づき継続的に送信し、TCP系よりスループット維持力が明らかに優れる。TUICは振る舞いが穏やかで、UDPが速度制限され得る環境に向いている。Hysteria2を使う際は、upとdownを実際の帯域に合わせて設定することが重要で、実際より高く盛ると輻輳が悪化する。UDPが全く使えない場合はSSやTrojanに戻り、スループットの低下を受け入れる。これは物理的な制約であり、設定の問題ではない。

ルーターとサーバー

ルーター、NAS、サーバーにはGUIがなく、mihomoカーネルを直接動かすのが最もシンプルな方法だ。1つのconfig.yamlと1つの自動起動サービスがあれば動く。低性能ルーターでのプロトコルの取捨選択は第六章の方針に従う。SS(chacha20系)またはVLESSを優先し、二重暗号化を避ける。メモリが厳しい場合は大きなテキストルールの代わりにrule-setを使う。OpenWrtでのバイパスルーター構築の完全な手順は「OpenWrtルーターへのmihomoカーネル導入」を参照。

自前サーバー構築

自前サーバー側の決定手順はこうだ。ドメインと証明書があるならTrojanまたはVLESS + TLSを選び、外形とオーバーヘッドの両方で優れる。ドメインと証明書の維持を避けたいならSS(2022系スイート)が最も手間がかからない。回線のパケットロスがひどくUDPが通るなら、Hysteria2を追加でTCP系と並存させ、場面に応じて切り替える。プロトコル以外にも、自前構築ではシステム更新・鍵の強度・管理画面の露出のほうがより重要な要素であり、本巻の範囲を超えるが、プロトコル選択に劣らない重みを持つ。

決定表

プロトコルは通信経路の一部にすぎず、全部ではない。ルールが振り分けの巧拙を決め、DNSが名前解決のきれいさを決め、カーネルとクライアントが機能の境界を決める。この3つはプロトコルと同等に重要だ。DNSのnameserverとfallbackの役割分担は「Clash DNS設定詳解」を、よくある接続トラブルの対処手順はよくある質問ページにまとめている。本巻を読んでもなお判断に迷う場合は、入門ガイドに戻ってまず既定の設定を動かし、その後1項目ずつ差し替えて試すのが、最も迷わない進め方だ。