Clash オープンソースエコシステム整理：カーネル・クライアントとルールセットの関係

三層構造：カーネル・クライアントとルールセット

Clash エコシステムのプロジェクトは三層に分けられます。カーネルは設定の解析、接続の確立、振り分けの実行を担う、実際にトラフィックを処理する唯一の部分です。クライアントはウィンドウ、トレイ、サブスクリプション管理、プロセスの常駐化を提供しますが、ルール自体は解析しません。ルールセットとデータファイルは単なるリストで、実行時にカーネルが読み込みます。三層のやり取りは二種類のファイルを介して行われます。ひとつは YAML 設定、もうひとつはルールデータです。

層を分ける意味は、問題の切り分けにあります。サブスクリプションの更新失敗、接続が確立できない、特定のドメインが意図しない経路に流れる——この三種類の不具合は、それぞれクライアント、カーネル、ルールセットに属します。まずどの層の問題かを見極め、該当するリポジトリで答えを探すほうが、クライアントのスイッチを何度も切り替えるよりはるかに効率的です。

カーネルの系譜：オリジナル Clash、Clash Premium、そして mihomo

オリジナルカーネルとその保守の終点

オリジナルカーネルとは Dreamacro/clash を指し、Go で書かれています。現在広く使われている proxies、proxy-groups、rules という YAML 構造を定めたのがこのカーネルで、すべてのクライアントが読み込む設定フォーマットはここに由来します。2023 年 11 月前後にオリジナルカーネルは更新を停止し、リポジトリは読み取り専用になりました。同じ時期に Clash for Windows も GitHub から姿を消しています。

その能力の範囲は正確に押さえておく必要があります。rule-providers、proxy-providers、tun には対応していません。アウトバウンドプロトコルは Shadowsocks、VMess、Trojan、Snell が中心で、ルール種別は DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP、MATCH に限られます。設定に tun: フィールドがひとつでもあると、オリジナルカーネルはエラーを出して即座に終了します。

Clash Premium：クローズドソースのバイナリ、本流とともに配布終了

Clash Premium は原作者が公開したクローズドソースの無償カーネルで、tun、script、rule-providers、proxy-providers の 4 つの機能を補いました。一時期は macOS で TUN モードを使う際の主要な選択肢でした。配布はオリジナル本流とともに終了しており、現在では歴史的な価値しかありません。チュートリアルに「Premium カーネルを使用してください」と書かれていれば、その文書はおそらく 2023 年より前で止まっています。

Clash.Meta と mihomo：現在の事実上の本流

MetaCubeX が保守する Clash.Meta は、オリジナルをベースにプロトコルと設定機能を補完したもので、2024 年初頭に mihomo へ改名されました。リポジトリは MetaCubeX/mihomo、実行ファイル名とデフォルトの設定ディレクトリも mihomo に変更されています。現在も更新が続くクライアントが内蔵するカーネルは、ほぼすべてこれかその下流です。

オリジナルと比べた mihomo の追加点は、主に次の 4 つです。

• アウトバウンドプロトコル：VLESS、Hysteria、Hysteria2、TUIC、WireGuard、SSH、ShadowTLS。
• 設定機能：sub-rule、論理ルール（AND / OR / NOT）、listeners、sniffer、find-process-mode、geox-url。
• ルールセット形式：YAML と text に加えて、より小さく読み込みも速い mrs バイナリ形式に対応。
• データファイル：geoip.dat に加えて geoip.metadb が使え、ASN によるマッチングにも対応。

互換性の方向は一方通行です。オリジナルで動く設定はほぼそのまま mihomo で実行できますが、逆は成り立ちません。移行時はまず mihomo -t -f config.yaml で検証すると、どのフィールドが範囲外かが一目で分かります。

クライアント層：誰が保守し、誰が 2023 年で止まったか

クライアントは設定フォーマットを定義せず、決めるのは次の 3 点だけです。どのカーネルを内蔵するか、設定ファイルをどこに置くか、UI にどのスイッチを出すか。したがってクライアント選びでまず見るべきはカーネルの出所で、UI の使い勝手は二の次です。

Clash Verge は元のリポジトリが更新停止した後、コミュニティが Clash Verge Rev として引き継ぎ、カーネルは mihomo に置き換わりました。サブスクリプション管理と profile の構成はそのまま受け継がれています。デスクトップでまだ Clash for Windows を使っているなら、mihomo ベースのクライアントへ移るのが最も変更の少ない一歩です。YAML 自体はそのままで、設定をインポートし直すだけで済みます。

iOS は別ルート

iOS には Clash カーネルをそのまま流用したクライアントはありません。App Store の Stash のようなアプリは独自にルールエンジンを実装しており、Clash 形式の YAML を読み込むだけです。「iOS でも Clash の設定をインポートできる」というのはフォーマットの互換性を指すのであって、カーネルが同じという意味ではありません。判断は簡単です。tun、script、rule-providers といったフィールドがどこまで対応しているかは各アプリのドキュメントに従うべきで、デスクトップの経験をそのまま当てはめることはできません。

設定ディレクトリ：カーネルのデフォルトとクライアントによる管理

カーネルを単体で起動した場合、オリジナルはデフォルトで ~/.config/clash/ を読み込み、Windows では %USERPROFILE%\.config\clash\ に展開されます。mihomo は ~/.config/mihomo/ に変更されました。GUI 付きのクライアントは通常この部分を引き受けます。たとえば Clash Verge Rev は profile とルールのキャッシュを自身のアプリデータディレクトリ（Windows では %APPDATA%\io.github.clash-verge-rev.clash-verge-rev\）に置くため、上書きインストールしてもサブスクリプションは消えません。問題を調べるときは、カーネルが実際にどのファイルを読んでいるかを先に確認するほうが、YAML を何度も見直すより有効です。

ルールセットとデータファイル：最も更新頻度の高い層

ルールセットは純粋なリストで、ネットワーク実装は含みません。カーネルは rule-providers でリストを取得して RULE-SET で参照するか、GEOSITE、GEOIP を通じてコンパイル済みの dat ファイルを読み込みます。この層は更新が最も頻繁で、カーネルの一部だと誤解されやすい部分でもあります。

よく使われるリポジトリは次のとおりです。

• Loyalsoldier/clash-rules：domain と ipcidr でグループ分けされた rule-provider。release ブランチに reject.txt、direct.txt、proxy.txt、gfw.txt、cncidr.txt などのファイルがあり、そのまま rule-providers に記述できます。
• blackmatrix7/ios_rule_script：サービスごとに分割されたルールセット。パスは rule/Clash/<サービス名>/<サービス名>.yaml の形式で、ストリーミングや AI サービスの細かいリストはほぼここで見つかります。
• MetaCubeX/meta-rules-dat：mihomo 向けにコンパイルされた geosite.dat、geoip.dat、geoip.metadb、country.mmdb を提供。mrs 形式の個別ルールセットも用意されており、上流データは v2fly の domain-list-community です。
• ACL4SSR/ACL4SSR：ACL4SSR_Online.ini に代表されるルールテンプレートで、通常はサブスクリプション変換ツールと組み合わせて使います。
• tindy2013/subconverter：Clash 以外の形式のサブスクリプションリンクを Clash YAML に変換します。形式変換のみを担い、動作には関与しません。

rule-providers:
  reject:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/reject.txt"
    path: ./ruleset/reject.yaml
    interval: 86400
  cn-domain:
    type: http
    behavior: domain
    format: mrs
    url: "https://github.com/MetaCubeX/meta-rules-dat/raw/meta/geo/geosite/cn.mrs"
    path: ./ruleset/cn.mrs
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - RULE-SET,cn-domain,DIRECT
  - GEOSITE,geolocation-!cn,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

この設定では、format: mrs を読めるのは mihomo だけです。interval: 86400 の単位は秒で、24 時間ごとにリストの更新を確認するという意味になります。rules セクションは具体的なものから広いものへと並べ、一致した時点で評価が止まります。最後の MATCH が受け皿になるという構成も、設定が一通り揃っているかを見分ける最低ラインです。

GEOSITE / GEOIP と RULE-SET の使い分け

• GEOSITE、GEOIP はローカルの dat ファイルを読み込み、マッチングはメモリ上で完結するため高速です。代わりにパッケージ全体が大きくなり、更新の粒度はデータベース全体になります。
• RULE-SET は provider 単位で個別のリストを取得するため粒度が細かく差し替えも容易ですが、provider ごとに HTTP リクエストが 1 回発生し、ローカルキャッシュを 1 つ持つことになります。
• mihomo では geodata-mode: true のとき GEOIP ルールは geoip.dat を読み、デフォルトでは country.mmdb を使います。geox-url と組み合わせればデータ取得先をミラーに向けられ、ダウンロード失敗を避けられます。

設定の互換性：実行できるチェックの順序

1. まずカーネル名とバージョンを確認します。クライアントの設定に mihomo または Clash.Meta と表示されていれば Meta 系です。Clash とだけ書かれ、更新日時が 2023 年で止まっていればオリジナルカーネルです。
2. 次に高度なフィールドを確認します。設定に tun、rule-providers、proxy-providers、script、listeners、sub-rule のいずれかがあると、オリジナルカーネルはエラーを出して即座に終了します。
3. カーネル内蔵の検証オプションで一度実行します。mihomo -t -f config.yaml は解析のみで起動は行いません。オリジナルカーネルも -t に対応しています。
4. ログの最初のエラーを読みます。unsupported proxy type はプロトコル、unsupported rule type はルールを示しており、どちらもカーネルのバージョンに起因する問題で、設定の書き方を変えても解決しません。
5. 最後にポートを確認します。mixed-port（一般的には 7890）と external-controller（一般的には 127.0.0.1:9090）が使用されていないことを確かめます。ダッシュボードが開けるならカーネルは正常に起動しており、残る問題はルール層にあります。

どのリポジトリを追うべきか

利用シーンごとに、対応するリポジトリは次のとおりです。

• デスクトップでの日常利用：クライアント自身のリリースサイクルを追い、カーネルの更新もクライアントに合わせます。個別にアップグレードしたい場合は、クライアントの設定にあるカーネルバージョンの項目から手動で更新します。
• TUN、VLESS、Hysteria2、論理ルールが必要な場合：MetaCubeX/mihomo リポジトリとその公式ドキュメントを基準にしてください。設定フィールドは古いチュートリアルではなくドキュメントに従います。
• ルーター：OpenWrt なら OpenClash、あるいは SSH 経由で ShellClash を導入します。どちらも内蔵カーネルは mihomo です。
• 振り分けの精度：Loyalsoldier/clash-rules が必要に応じて取得するリストを、MetaCubeX/meta-rules-dat が dat と mrs のデータを担当します。この 2 つのリポジトリのコミット日時が、新しいドメインを正しく振り分けられるかどうかを左右します。
• サブスクリプション形式の変換：subconverter または Sub-Store。形式変換のみを担い、動作には関与しません。

ある Clash 関連リポジトリを今後も追う価値があるかは、3 点を見れば十分です。直近のコミット日時、README に明記されたカーネル依存、issue に保守者が今も返信しているか。三層構造のどこかが更新を止めても、影響はその層にとどまります。カーネルが止まればプロトコルと設定フィールドに、クライアントが止まれば OS 連携と UI に、ルールセットが止まれば振り分けの精度に影響します。この 3 つを分けて見れば、どこかのクライアントが終了しただけで設定全体が無効になったと考える必要はありません。