Clash オープンソース生態系全景:コア・GUIクライアント・ルールプロジェクトの関係整理

生態系マップ:4つの階層構造

Clash関連の情報を調べていると、Clash、Clash Meta、mihomo、ClashX、Clash Verge、subconverter、geoipといった名前が同時に登場することが多く、初心者はこれらを互いに競合するソフトウェアだと誤解しがちです。実際にはこれらのプロジェクトは4つの異なる階層に分かれており、それぞれが別の役割を担い、組み合わさることで一つの完全な振り分けプロキシ環境を構成しています。

第一層はコアで、実際にネットワーク接続を処理し、プロキシルールを実行し、接続プールを維持するバックグラウンドプロセスです。GUIは持たず、設定ファイルとAPI呼び出しのみを受け付けます。第二層はGUIクライアントで、コアをユーザーがクリック操作できるアプリとしてラップし、サブスクリプションの取得、ノード切り替え、システムプロキシ設定、TUNアダプタ管理といったインタラクションを担当します。第三層はルールセットと地理データベースで、ドメインやIPレンジの分類リストを提供し、コアが振り分けの際にマッチングに使用します。第四層は変換・パネルツールで、異なる形式のサブスクリプションをコアが読み取れる設定に統一変換したり、Web版の接続モニタリングパネルを提供したりします。

この4層の依存関係を理解すれば、なぜ同じPCにクライアントとコアという2つのプロセスが同時に入っているのか、なぜクライアントを変えてもルールセットファイルを再ダウンロードする必要がないのかが分かります。

コアの進化系譜:オリジナル版Clashからmihomoへ

コアの系譜はこの生態系の中で最も変化が大きい部分であり、時系列を把握しておくことで現在どのバージョンを選ぶべきかが判断しやすくなります。

1. オリジナル版 Clash

   Dreamacroが立ち上げた最初のバージョンで、Go言語で実装され、設定ファイル形式、プロキシグループ、ルールベースの振り分けという基本モデルを確立しました。このリポジトリは現在アーカイブ状態にあり、新機能のマージも新しい互換性問題の修正も行われませんが、定義された設定文法はその後のすべての派生版で引き続き採用されています。

2. Clash Premium

   オリジナル版をベースに一部のクローズドソース機能とより充実したルール文法を追加したもので、一時期は最も機能が充実した派生版でしたが、更新のペースも早々に落ち着き、新しく登場した通信方式へのプロトコル対応が後れを取っています。

3. Clash Meta

   オリジナル版の更新停止後、コミュニティが引き継いでメンテナンスし、Vision、Hysteria、TUNモードなど新プロトコル・新機能への対応を補完しました。一時期は最も活発に更新される派生版となり、多くのGUIクライアントの内部コアがこのバージョンに切り替わりました。

4. mihomo

   Clash Metaを名称変更して継続しているプロジェクトで、リポジトリの移行と名称調整の後も元のチームとコミュニティによってコードの提出が続けられています。新プロトコルの追加、脆弱性の修正、新しいOSバージョンへの対応はここで行われています。現在の主流GUIクライアントの内部コアは、基本的にすでにmihomoへ切り替え済み、あるいは切り替え中です。

つまり、あるクライアントが「どのコアを使っているか」を確認することは、本質的にはそれが更新の止まった旧派生版に接続しているのか、それとも継続的にメンテナンスされているmihomoに接続しているのかを確認する作業です。これは新しく登場したプロキシプロトコルが使えるかどうか、OSをアップデートした後もネットワーク拡張権限が正常にトリガーされるかどうかを直接左右します。

GUIクライアント:メンテナンスが続いているもの、止まっているもの

GUIクライアント層の更新状況は最も見落とされやすい部分です。画面は普段通り開けるように見えても、内部のコアはすでに更新が停止していることがあります。以下は各プラットフォームにおける典型的な状況で、正確なバージョン情報は各プロジェクトのリリースページを参照してください。

iOSは特殊なケースです。OSの制約上、署名されていない実行可能なコアを配布することができないため、iOS向けクライアントの多くは似たコアの考え方を独自に実装したアプリで、App Store経由で配信されます。設定文法はClash系と互換性がありますが、コアのコードそのものを直接再利用しているわけではありません。iOS向けクライアントを選ぶ際は、「公式かどうか」にこだわるより、標準的なサブスクリプションリンク形式とルール文法に対応しているかを重視すべきです。

実用的な確認方法として、クライアントの「このアプリについて」や設定画面を開き、「コアバージョン」や「core version」といった表記を探し、mihomoのリリースページの最新バージョン番号と比較する方法があります。差が大きい場合は、クライアント自体も依存関係の更新が長らく行われていないことを示していることが多いです。

ルールセットと変換ツール:コアだけでは完結しない部分

コアは「ルールに従って実行する」ことだけを担い、ルールがどこから来るかは別のプロジェクト群が解決しています。一般的なルールセットプロジェクトは、世界中でよく使われるドメインやIPレンジを地域別・サービス種別に分類し、geosite、geoip形式のデータファイルにまとめます。コアはこれを読み込むことで、設定内で分類名を直接参照できるようになり、数万件にも及ぶドメインエントリを自前で維持する必要がなくなります。この種のプロジェクトは通常一定周期でデータを更新し、更新記録にはどの分類が追加・調整されたかが記載されています。

変換ツールが解決するのは別の問題です。プロキシサービス提供者が配布するサブスクリプションリンクの形式は統一されておらず、標準プロトコルリンクの集合であるものもあれば、独自のJSON形式であるものもあります。変換サービスはその中間で形式変換を行い、元のサブスクリプションをClash系設定がそのまま読み込めるYAML構造に変換すると同時に、必要に応じてグループ分けやルールテンプレートを挿入できます。変換サービスを使う際は、信頼できる提供元の変換インターフェースのみを利用し、出所不明な第三者サイトにサブスクリプションリンクを送信しないようにすることを推奨します。

パネルツールは、コアのAPIインターフェースにWeb画面をかぶせたもので、現在の接続状況の確認、遅延測定、ノードグループの切り替えなどに使われます。多くのGUIクライアントに内蔵されている「パネル」画面は、実質的にこうしたオープンソースパネルプロジェクトのフロントエンドコードを埋め込んだものです。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - ノードA
      - ノードB
    url: http://www.gstatic.com/generate_204
    interval: 300

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "ルールセットのダウンロードURL"
    path: ./rules/reject.yaml
    interval: 86400

上記の設定例は、ルールセットがコアからどのように参照されるかを示しています。コアはルールデータが具体的にどのように生成されているかは関知せず、rule-providersで指定されたアドレスから定期的に取得・読み込むだけです。これこそが階層設計によるメリットで、ルールセットプロジェクトはコアの新バージョンリリースを待たずに独立して更新できます。

選び方の指針:依存関係から逆算して選定する

上記の階層関係を理解すれば、選定はプロジェクト名の印象で選ぶことではなく、3段階の確認プロセスに変わります。

• まずプラットフォームを確認する。OSによって使えるクライアントの選択肢は異なり、iOSはApp Store独自の生態系、デスクトップとAndroidはより選択肢が豊富です。
• 次にコアを確認する。内部コアが継続的に更新されているクライアントを優先し、設定画面やプロジェクト説明でコアのバージョン番号と更新日時を確認します。
• 最後にルールの出所を確認する。クライアント標準のデフォルトルールセットの更新が遅い場合は、設定内で手動でメンテナンスが続いているルールセットのアドレスに置き換えることができます。この作業にクライアント自体の変更は不要です。

補足として、コアがアーカイブされたことは即座に使用不能になることを意味しません。既にリリースされているバージョンは動作を続けますが、新しいプロトコル対応やセキュリティ修正は今後行われません。日常利用の観点では、内部コアが活発にメンテナンスされ続けているクライアントを選ぶ方が安全です。新しく登場した通信プロトコルやOSアップデートによる互換性問題が発生した際にも、修正版が早く提供されやすく、自分でコア層の問題を調査する必要がなくなります。