Clash オープンソース生态系プロジェクト相関図：カーネル派生版・デスクトップクライアント・モバイル実装

Clashを検索すると、Clash、Clash Meta、mihomo、Clash Verge Rev、Clash Nyanpasu、FlClash、OpenClashなどの名前が同時に表示されることがあります。これらは同じプログラムの別インストーラーではなく、すべてが同じチームによって保守されているわけでもありません。プロキシカーネルを提供するもの、グラフィカルインターフェースだけを担当するもの、ルーター、Android、特定のデスクトップOS向けのものがあります。

これらのプロジェクトを理解するうえで重要なのは、まず名前を覚えることではなく、どの層に位置するかを見極めることです。接続処理を担うカーネル、設定操作を担うクライアント、システム全体の通信を取り込むプラットフォームコンポーネント、ノードやルールを配布するサブスクリプションサービスに分けられます。層を整理できれば、バージョン選び、設定の互換性確認、障害の切り分けが格段に容易になります。

Clash生态系をまず4つの層に分ける

実際に動作するClash環境は、通常複数の要素で構成されます。名前にClashが含まれていても、必ずしも公式Clashカーネルを含むとは限りません。反対に、名前にClashがなくても、一般的なClash設定を読み込める場合があります。プロジェクト同士の関係は、単一製品のバージョン系列というより、部品を組み合わせる構造に近いものです。

サブスクリプションとローカル設定
        ↓
グラフィカルクライアント / Webコントロールパネル
        ↓
Clash系カーネル：Clash、Clash Meta、mihomo
        ↓
システムプロキシ / TUN / ルーター転送
        ↓
接続先ネットワーク

第1層：サブスクリプションと設定

サブスクリプションURLは通常YAML設定を返し、プロキシノード、プロキシグループ、ルール、DNS設定、ルールセットへの参照などが含まれます。サブスクリプションサービスはクライアントでもカーネルでもありません。クライアントは設定を定期的にダウンロードして管理するだけで、設定の解析と接続処理を実際に行うのはカーネルです。サブスクリプションに特定の派生版専用フィールドが含まれている場合、古いカーネルへ切り替えると解析エラーが発生することがあります。

第2層：クライアントとコントロールパネル

デスクトップクライアントは通常、サブスクリプション更新、プロキシグループの切り替え、接続状況の確認、ログ表示、システムプロキシの切り替え、TUN管理を提供します。カーネルを内蔵するものもあれば、カーネルファイルを切り替えられるものもあります。Webコントロールパネルは外部コントロールインターフェースを介してカーネルに接続し、状態を表示しますが、データ転送そのものは担いません。

第3層：プロキシカーネル

カーネルはポートの待ち受け、DNS解析、ルール照合、プロキシグループの選択、プロキシ接続の確立、ログ出力を担当します。同じグラフィカルクライアントでも、異なるカーネルに置き換えると利用できるフィールドや動作が変わります。問題を調査するときは、クライアントのバージョンとカーネルのバージョンを併記し、「Clash最新版」とだけ記録しないようにしてください。

第4層：システム全体の通信取り込み

システムプロキシの設定を参照するアプリだけが、システムプロキシの影響を受けます。TUNモードは仮想ネットワークインターフェースを作成し、システムプロキシを参照しないプログラムもより広く取り込めます。ルーターへの導入では、ファイアウォール、ポリシールーティング、DNS転送によってLAN内の端末を取り込みます。3つの入口はいずれも最終的に接続をカーネルへ渡せますが、必要な権限、DNS経路、トラブルシューティング方法は異なります。

公式Clash、Clash Meta、mihomoの派生関係

公式Clashは、初期生态系を支えた中核的な基盤です。YAML設定、ルール照合、プロキシグループ、外部コントロールインターフェースなど、現在もよく使われる構造を確立しました。多くのデスクトップクライアント、ルータープラグイン、サブスクリプションテンプレートがこれらのインターフェースを中心に構築されています。公式リポジトリの継続的な保守が終了した後も、生态系全体が止まったわけではなく、保守が続く派生版や互換実装へ移行しました。

Clash Metaは当初、公式Clashの派生版として発展し、プロキシプロトコル、ルール機能、DNS動作、TUN対応、設定フィールドを拡張しました。その後、プロジェクト名は段階的にmihomoへ移行しました。現在「Metaカーネル」と「mihomoカーネル」と呼ばれているものは、通常、同じ進化の流れにおける異なる段階を指しており、同時にインストールする別個のカーネルではありません。

mihomoは一般的なClash設定との高い互換性を保っていますが、互換性があるからといって、すべてのフィールドを無条件に相互移行できるわけではありません。ルールセットプロバイダー、特定のDNSオプション、新しいプロトコルパラメーター、トラフィックのスニッフィング、拡張ルール形式を使う場合は、対象カーネルの現行ドキュメントを基準にしてください。mihomoの設定を古い公式カーネルへそのまま渡すと、未知のフィールド、プロキシグループ参照の失敗、ルールプロバイダーの読み込み失敗が起きるのが一般的です。

デスクトップクライアントは外殻であり、カーネル名と同義ではない

Windows、macOS、Linuxのユーザーは、まずグラフィカルクライアントに触れることが多いでしょう。クライアントは設定ファイル、カーネルプロセス、システムプロキシ、トレイメニューを1つの画面にまとめますが、カーネルとは別の層です。クライアントの更新は画面やプラットフォーム連携だけを変更する場合がある一方、カーネルの更新はプロトコル、DNS、ルールの動作を変えることがあります。リリースノートにアプリのバージョンとカーネルのバージョンが別々に記載されているなら、これが層分けの直接的な表れです。

Clash Verge Rev

Clash Verge Revは、Windows、macOS、Linuxで使われるクロスプラットフォームのデスクトップクライアントです。mihomoを中心に、サブスクリプション管理、プロキシ切り替え、システムプロキシ、TUN、接続履歴、ログ画面を提供します。名称のRevはコミュニティによる継続プロジェクトを示すもので、名前が似ていても保守状況の異なる過去のプロジェクトと混同しないでください。

このタイプのクライアントは、複数の設定を視覚的に管理したいデスクトップ環境に適しています。インストール時はOSだけでなく、Windowsのx64とARM64、macOSのIntelとAppleシリコンなど、プロセッサーのアーキテクチャも確認してください。アーキテクチャの不一致はインストーラー選択の問題であり、サブスクリプションの有効性とは関係ありません。

Clash Nyanpasu

Clash Nyanpasuもデスクトップのグラフィカル層に位置し、設定管理、カーネル制御、システム連携を提供します。Clash Verge Revと近い内容のサブスクリプションを利用できますが、画面の実装、設定の保存場所、アップグレード手順、プラットフォームごとの細部は異なります。通常は代替関係にあるため、「機能を補う」目的で両方を同時に実行する必要はありません。

ClashX系の名称

macOS生态系では、ClashX、ClashX Pro、ClashX Metaなど、似た名前が長く使われてきました。保守元、組み合わせられるカーネル、ライセンス方式は完全には同じではありません。名前を見たら、リポジトリの出所、最終リリース、カーネルの種類、対応するmacOSアーキテクチャまで確認してください。「X」や「Meta」という文字だけでは、現在のシステムに適しているか判断できません。

デスクトップクライアント間で移行する際は、アプリのデータディレクトリ全体をそのままコピーすることはおすすめしません。ディレクトリにはYAML以外に、データベース、ウィンドウ状態、サービス権限、システムプロキシのバックアップ、古いカーネルファイルが含まれていることがあります。より安定した方法は、サブスクリプションURLと確認済みのローカル上書きルールを保管し、新しいクライアントへ再インポートしたうえで、TUN、DNS、自動起動を項目ごとに戻すことです。

モバイル、ルーター、Webパネルの実装の違い

モバイル向けプロジェクトはカーネルを組み込むだけでなく、OSが提供するVPNインターフェースやバックグラウンド実行の制限にも従う必要があります。Androidクライアントは通常、ローカルVPNサービスを介してアプリの通信をカーネルへ送り込むため、ステータスバーにVPN接続が表示されます。ここでいうVPNはシステム上の通信入口を指し、サブスクリプションのノードが従来型のVPNプロトコルを使うことを意味しません。

Androidクライアント

Clash Meta for Androidは、かつてよく使われたMeta系Android実装で、多くの古い解説にその画面が掲載されています。使い続けるか判断する際は、プロジェクトの保守状況とカーネルの更新時期を確認してください。FlClashなどのクロスプラットフォームプロジェクトもAndroidで動作し、現行のClash系カーネルで設定を処理できます。アプリごとのデータディレクトリやローカルバックアップ形式は通常共通ではありませんが、標準的なサブスクリプションURLは再インポートできます。

Androidでブラウザーだけ使えて一部のアプリが接続できない場合は、アプリ別ルーティング、バイパスリスト、VPN権限、省電力制限、IPv6経路を確認してください。すべてのドメインで失敗するなら、まずDNSログと設定の解析結果を確認します。モバイルの障害は、ノードを頻繁に交換するだけで解決しようとしないでください。システムの制限とカーネル設定は別の層にあります。

iOSとiPadOS

iOSでは、Network Extensionなどのシステム機構を介してネットワークを取り込む必要があり、アプリの配布やバックグラウンドリソースもプラットフォームの規則に制約されます。市場にはClash風の設定やサブスクリプションを一部読み込めるネットワークツールがありますが、名称、カーネル、設定の互換範囲はそれぞれ異なります。プロキシグループに対応しているからといって、公式Clashプロジェクトだと判断することはできません。

インポート前に、アプリが対応しているのが完全なClash YAMLなのか、サブスクリプション変換後のノード一覧なのか、それとも独自の設定形式なのかを確認してください。サブスクリプションにmihomo専用のルールやDNSフィールドが含まれている場合、モバイルアプリはそれらを無視、変換、拒否することがあります。その場合は同じデスクトップ設定を何度も読み込むのではなく、対象アプリに合った形式を用意してください。

OpenClashとルーターへの導入

OpenClashはOpenWrt環境向けの管理・統合プロジェクトです。カーネルのダウンロードと起動、実行用設定の生成、ファイアウォール連携、DNS転送、管理画面の提供を担当します。実際の通信処理は選択したカーネルが行います。OpenClash、mihomo、OpenWrtはそれぞれ管理プラグイン、プロキシカーネル、ルーターOSに対応し、互いに置き換えることはできません。

ルーターへの導入では、デスクトップクライアントよりもLAN転送、ポリシールーティング、透過プロキシ、DNSハイジャックなどの工程が増えます。クライアントでノードが利用可能でも、ルーター側の経路が正しいとは限りません。LAN内の端末に接続できない、中国本土のドメインだけ名前解決がおかしい、一部端末が再接続を繰り返すといった場合は、カーネルログ、DNS上流、IPv4とIPv6のルール、ファイアウォールチェーン、旁路ルーターのゲートウェイ設定を順に確認してください。

Webコントロールパネル

YacdやMetaCubeXDなどのWebパネルは、コントロールインターフェースを通じてプロキシグループ、接続、ログを読み取ります。これらは操作画面であり、プロキシカーネルではありません。ブラウザーの画面を閉じても通常プロキシサービスは停止しません。反対に、パネルが開けてもカーネルが正しく通信を取り込んでいるとは限りません。パネル接続に失敗した場合は、コントロールアドレス、待ち受け範囲、認証キー、ファイアウォールを確認し、ノードのプロトコルを変更しないでください。

同じサブスクリプションがプロジェクトごとに異なる動作をする理由

サブスクリプションをインポートできることは、クライアントがデータを取得できたことを示すだけです。実際に動作するには、設定の解析、リソースのダウンロード、DNSの初期化、待ち受けポートの確立、システムによる通信の取り込みを経る必要があります。各プロジェクトの既定値はこれらの段階で異なるため、同じサブスクリプションでも2台の端末で結果が変わることがあります。

1. カーネルのバージョンが異なる：新しいルール形式、プロトコルパラメーター、DNSフィールドは古いカーネルで認識されない場合があります。
2. クライアントの上書き設定が異なる：クライアントがポート、コントロールインターフェース、TUN、DNS、設定ディレクトリを自動的に変更することがあります。
3. ルールリソースが異なる：リモートルールセットのダウンロードに失敗すると、ポリシーに重要なマッチ項目が不足し、ログにproviderエラーが表示されることがあります。
4. システムの入口が異なる：デスクトップはシステムプロキシ、モバイルはローカルVPN、ルーターは透過プロキシを使うため、通信の取り込み範囲も異なります。
5. DNS経路が異なる：システムDNS、カーネルDNS、ブラウザーのセキュアDNS、ルーター転送が同時に存在する場合があり、最終的な問い合わせが同じリゾルバーに届くとは限りません。
6. ポリシー選択が同期されていない：設定のプロキシグループの既定項目と、古い端末に保存された選択が異なることがあります。インポート後は現在のポリシーを再確認してください。

トラブルシューティングでは、まず最小構成の経路を試します。設定を解析できることを確認し、接続実績のあるノードを1つ選び、追加の上書きを一時的に無効にして、必要最小限のDNSとルールだけを残し、カーネルの待ち受けポートをテストします。カーネルへの直接接続が成功してから、システムプロキシやTUNを有効にしてください。これにより、問題が設定層、カーネル層、システム取り込み層のどこにあるかを切り分けられます。

確認する順番：
1. サブスクリプションがYAMLを正常に返しているか
2. カーネルが設定の解析を完了しているか
3. プロキシとルールリソースが読み込まれているか
4. ローカルの待ち受けポートが確立しているか
5. システムプロキシまたはTUNが通信を取り込んでいるか
6. DNS問い合わせが想定した経路に入っているか
7. ルールが想定したプロキシグループに一致しているか

ログレベルはまずinfoに設定し、設定の読み込み、DNS、ルールセット、接続エラーを確認します。具体的なリクエストを追跡する必要があるときだけ一時的に詳細度を上げ、重複ログで重要なエラーが埋もれないようにしてください。ルール、DNS、TUNを調整するときは、一度に1つの変数だけを変更し、元に戻せる設定を保管します。

保守状況、プラットフォーム、設定要件でプロジェクトを選ぶ

Clash系プロジェクトを選ぶときは、まず保守状況、次にプラットフォームとアーキテクチャ、最後に必要な機能が対応するカーネルで提供されているかを確認します。名前が似ていること、検索結果の上位に出ること、古い解説が多いことは、これらの確認の代わりにはなりません。

目的がデスクトップのブラウザーや一般的なアプリのプロキシだけなら、保守が活発なデスクトップクライアントを使うほうが手順を減らせます。ゲーム、コマンドラインプログラム、システムプロキシに従わないソフトウェアまで取り込みたい場合は、TUNを検討してください。LAN全体で統一的にルーティングしたいならルーター方式が候補になりますが、ファイアウォールとDNSの切り分けに対応できるよう準備が必要です。サーバー環境では通常デスクトップの外殻は不要で、mihomoを直接実行し、systemdに管理させるほうが構成を明確にできます。

設定移行は、特定クライアントの内部データベースに依存せず、標準YAML、サブスクリプションURL、自作ルールを中心に進めてください。カーネル専用フィールドは個別に記録し、次のプロジェクトが確実に対応していることを確認します。古い解説を参照するときは、解説に登場するプロジェクト名、公開時期、カーネルの段階を先に確認してから、現在も使える手順を判断してください。

相関図から最終的に判断する方法

新しいプロジェクト名を見つけたら、4つの質問で位置づけられます。プロキシカーネルを含むか、含む場合は公式Clash、旧称のMeta、mihomoのどれか、システムプロキシ、TUN、ローカルVPN、ルーターのファイアウォールのどれで通信を取り込むか、設定が標準Clash YAML、拡張フィールド、独自形式のどれかです。4つの答えが明確になれば、生态系における位置はほぼ確定します。

Clash生态系の継続は、複数の独立したプロジェクトの協力に支えられています。mihomoは現代的なカーネル機能、デスクトップとモバイルのクライアントはプラットフォーム連携、OpenClashはルーター統合、Webパネルはリモート操作、サブスクリプションとルールのプロジェクトは設定データを担当します。組み合わせて使えますが、リリース時期、保守チーム、互換性の境界はそれぞれ独立しています。選ぶときは層ごとに確認し、障害時はデータ経路を順番に調べるほうが、すべてを「Clashクライアント」と一括りにするより正確です。