2026年7月30日エコシステム読了目安 12分

Clashオープンソース・エコシステムの関係：コア、クライアント、メンテナンス系統の違い

Clash、Mihomo、主要GUIクライアントの役割や依存関係、選定時の違いを整理します。

Clashのダウンロード方法や設定ガイドを探していると、Clash、Clash Meta、Mihomo、Clash Verge Rev、FlClashなどの名称を目にすることがあります。これらは同じソフトウェアの別バージョンではなく、単純に「新しい版」「古い版」と考えることもできません。各プロジェクトは、コア、GUIクライアント、設定ファイル、ルーティングデータ、サブスクリプションサービスなど異なる層に分かれています。名称が似ているのは、共通の設定方式とプロキシ振り分けの仕組みを受け継いでいるためです。

現在のデバイスに適したプロジェクトを判断する際、名称にClashが含まれているかだけを見るのは不十分です。使用しているコア、対応する設定項目、継続的なリリースの有無、GUIからシステムプロキシ、TUN、DNS、設定更新を管理できるかを確認する方が確実です。各層を分けて考えると、クライアントの移行、サブスクリプションの読み込み、設定トラブルの切り分けが大幅に分かりやすくなります。

まずコア、クライアント、設定データを区別する

Clashのエコシステムは、ネットワーク接続を処理するコア、操作と表示を担うクライアント、ノードとルーティングロジックを記述する設定データの3層に大別できます。多くのトラブルは、この3層を混同することから起こります。

コアがプロキシ処理とルール判定を担う

コアはプロキシプログラムの実行主体です。ローカルの待ち受けポートを開き、プロキシサーバーへの接続を確立し、DNS設定を解析して、ルールリストに従ってポリシーグループを選択します。システムプロキシ、ブラウザー、その他のアプリが通信をローカルポートへ渡した後、接続先を決めるのはクライアント画面のボタンではなくコアです。

オリジナルのClashコアはGoで開発され、プロキシノード、プロキシプロバイダー、ポリシーグループ、ルールなど、現在広く使われているYAML設定の基本構造を確立しました。オリジナルプロジェクトの積極的なメンテナンスが終了した後、エコシステムの中心は互換性を持つ派生系統へ移っていきました。現在よく使われるMihomoはClash.Meta系統を起源とし、多くのClash設定構文を引き継ぎながら、DNS、TUN、トラフィック解析、ルーティングデータ、プロトコル対応などを拡張しています。

クライアントがGUIとシステム連携を提供する

クライアントは通常、デスクトップまたはモバイル向けのGUIアプリです。設定のダウンロードと切り替え、ノードの遅延表示、システムプロキシの制御、TUNに必要な権限の取得、コアの起動、ログの表示などを担当します。クライアント自体はネイティブUI、Web技術を使ったデスクトップシェル、クロスプラットフォームのツールキットなど、さまざまな技術で開発できます。これは内部でどのプロキシコアを呼び出すかとは別の問題です。

クライアントによってはコアをインストールパッケージに同梱し、クライアントのアップデートと同時にコアも更新します。一方で、コアを個別にダウンロード、切り替え、指定できるクライアントもあります。そのため、同名クライアントでも配布版によって搭載されるコアのバージョンが異なる場合があります。設定項目が反映されないときは、クライアント名だけで判断せず、「概要」「コア設定」、または起動ログで実際のコア名とバージョンを確認してください。

設定、サブスクリプション、ルールデータはクライアント本体ではない

YAML設定には、ポート、ノード、ポリシーグループ、DNS、ルールを記述します。サブスクリプションURLは設定データを取得する入口で、完全なClash設定を返す場合もあれば、ノード一覧だけを返し、クライアントやサブスクリプション変換サービスがポリシーグループを生成する場合もあります。GeoIP、GeoSite、MMDB、ルールセットファイルはルーティングデータに属し、コアから読み込みや更新ができますが、コアプログラムそのものではありません。

つまり、GUIクライアントを変更しても元のサブスクリプションが必ず無効になるわけではなく、コアを変更しても元の設定をそのまま使えるとは限りません。移行できるかどうかは、サブスクリプションの出力形式、設定で使われている拡張項目、移行先コアの対応状況によって決まります。

Clash、Clash Meta、Mihomoのメンテナンス関係

オリジナルのClashは設定モデルとルーティング方式の基礎を築きました。オリジナルプロジェクトの継続的なリリースが止まると、コミュニティの派生系統が新しいプロトコルへの対応、OS互換性、機能拡張を担うようになりました。Clash.Metaはその中でも影響力の大きい系統で、後にMihomoという名称でメンテナンスが続けられています。そのため現在のエコシステムでいう「Clash設定」は互換形式を指すことが多く、実行中のプログラムがオリジナルのClashコアであるとは限りません。

派生系統はプロジェクト名を変えただけではありません。Mihomoは従来の設定を基に複数の機能を拡張しており、リリース時期の異なるバージョン間でも項目、デフォルト値、リソース形式が変更されることがあります。ある設定をMihomoで読み込めても、古いClashコアがすべての内容を認識できるとは限りません。特に複雑なTUNパラメーター、拡張DNS動作、トラフィック解析、GeoSiteルール、特定のプロキシプロトコルでは、バージョン差による問題が起こりやすくなります。

以下は層構造を説明するためだけの簡略化した設定例です。クライアントがファイルを読み込んでコアを起動し、コアがローカルポートを待ち受け、ポリシーグループと最終ルールに従って接続を処理します。

mixed-port: 7890
mode: rule

proxies: []

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,ノード選択

実際のサブスクリプションでは、通常、ノード定義、プロキシプロバイダー、DNS、ルールプロバイダー、より詳細なポリシーグループが追加されます。「設定の解析に失敗しました」と表示された場合は、設定全体を削除するのではなく、ログで具体的な項目を特定してください。YAMLはインデントに敏感で、項目の対応状況はコアの種類とバージョンにも左右されます。この2つの問題は分けて判断する必要があります。

プロジェクトが現在もメンテナンスされているか確認する方法

プロジェクト名にRev、Next、Meta、Communityなどが含まれていても、それだけでメンテナンス状況を証明することはできません。最近の正式版、リリースノート、コードのコミット、Issueへの対応履歴、対応OSのバージョンを確認しましょう。クライアントのインストールパッケージだけが提供されている場合は、同梱されるコアのバージョンも継続的に更新されているか確認してください。

コアのバージョン：実行ログまたはクライアントの概要画面で、Mihomo、オリジナルのClash、その他の互換実装のどれが使われているか確認します。
クライアントのバージョン：クライアントとコアのバージョン番号は通常別体系であり、相互に置き換えることはできません。
リリース日：プロジェクト名にある「新バージョン」という表記より、継続的に正式版が公開されているかどうかの方が参考になります。
プラットフォーム対応：使用中のWindows、macOS、Linux、Androidのバージョンが、現在もサポート対象か確認します。
アップデート方法：クライアントの更新にコアが含まれるのか、設定画面から個別に更新する必要があるのか確認します。

主要GUIクライアントはエコシステムのどの層に属するか

Clash Verge Rev、Clash Nyanpasu、FlClashなどは、まずGUIクライアントであり、通常はMihomoまたは互換コアを利用して設定管理とシステム連携を行います。主な違いはプロキシのルール原理ではなく、対応プラットフォーム、UIの実装、コアの管理方法、TUN権限の取得手順、設定オーバーライド機能、更新頻度にあります。

デスクトップクライアントには通常、システムプロキシの切り替え、ノード選択、接続履歴、設定サブスクリプションの更新、遅延テストなどが備わっています。WindowsとmacOSでは、スタートアップ、システムプロキシの復元、管理者権限、システムトレイの動作にも対応する必要があります。Linuxはデスクトップ環境の種類が多く、システムプロキシの設定方法やトレイ互換性がディストリビューションによって異なるため、同じクライアントでも環境によって使い勝手が完全に一致するとは限りません。

Androidクライアントは通常、システムVPNインターフェースを通じて通信を処理します。これは、デスクトップで「システムプロキシ」にチェックを入れる方式とは異なります。アプリごとの振り分け、バックグラウンドでの継続動作、IPv6、プライベートDNSへの対応は、クライアントの実装とシステムの制限に左右されます。デスクトップ版とモバイル版がどちらもMihomoを使っているからといって、すべての画面機能やネットワーク動作が同じだとは限りません。

以前広く使われていたClash for WindowsはデスクトップGUIクライアントであり、オープンソースのClashコアと同一ではありません。現在はメンテナンスが終了しています。古いガイドにある、特定のメニュー名、設定オーバーライドの入口、サービスモードのインストール方法など、画面を前提にした手順を現在のクライアントへそのまま適用しないでください。設定内のノードやルールは移行できる場合がありますが、画面上の設定は新しいクライアントで改めて確認する必要があります。

クライアント選びで確認すべき境界

クライアント選びでは、画面を比較する前にプラットフォームを決めます。デスクトップでは、OSのバージョンとCPUアーキテクチャ、たとえばWindows x64、Windows ARM64、Appleシリコン搭載Mac、Intelプロセッサ搭載Macなどを確認します。アーキテクチャの合わないインストールパッケージでは、起動できないか、互換レイヤー経由でしか動作しない場合があります。

コアと設定の互換性

既存の設定にMihomoの拡張項目が含まれている場合は、Mihomoを明確に採用し、コアも比較的こまめに更新しているクライアントを優先してください。インポート後はまず起動ログを確認し、設定の解析が成功したことを確認してから、ポリシーグループの切り替えとDNSをテストします。ノード一覧が表示されたからといって、設定全体が正しく反映されたとは限りません。認識できないオーバーライド項目をクライアントが無視していたり、以前のキャッシュ設定を使い続けていたりする場合があります。

サブスクリプションの互換性では、「完全設定サブスクリプション」と「ノードサブスクリプション」も区別する必要があります。完全設定には通常、ポリシーグループとルールが含まれており、インポート後すぐに使えます。ノードサブスクリプションはサーバー情報だけを提供するため、クライアントのテンプレートやローカル設定でグループとルールを補う必要があります。どちらもインポートできたとしても、最終的なルーティング結果は大きく異なる場合があります。

システムプロキシとTUNモード

システムプロキシは、OSのプロキシ設定に従うアプリ、たとえば多くのブラウザーやデスクトップアプリに主に影響します。ターミナルツール、ゲーム、仮想マシン、独自のネットワークスタックを実装したプログラムは、システムプロキシを回避することがあります。TUNモードは仮想ネットワークインターフェースを作成して、より広範な通信を処理しますが、通常は管理者権限またはシステムVPNの認証が必要で、ルーティング、DNS、ファイアウォールとの互換性も関係します。

そのため、TUN対応とは画面にスイッチがあるだけのことではありません。クライアントがサービスを正しくインストールできるか、終了時にネットワーク設定を復元できるか、使用中のOSが必要な権限を許可しているかも確認する必要があります。TUNを有効にして通信できなくなった場合は、まずTUNを無効にして基本接続を復旧し、その後コアのログ、DNSの待ち受け競合、ルーティングループ、他のVPNソフトを確認してください。ノードを何度も切り替えるだけでは解決しません。

設定管理と更新の仕組み

長期利用では、一度インポートに成功するかどうかよりも、設定をどう管理できるかが重要です。サブスクリプションの更新間隔を設定できるか、ローカルのオーバーライドを保持できるか、複数の設定を切り替えられるか、更新に失敗したときに前回有効だった設定を使い続けられるかを確認しましょう。クライアントによってはサブスクリプション更新後に設定を再生成するため、ローカルで直接編集した内容が上書きされることがあります。ルールの調整は、クライアントが対応するオーバーライド、マージ、スクリプト機能で行うのが安全です。

クライアントの自動更新とコアの自動更新も分けて考える必要があります。GUIプログラムの更新に成功しても、コアまで更新されたとは限りません。逆に、コアだけを差し替えると、管理インターフェースの変更によってクライアントとの互換性に問題が出る場合があります。安定運用のため、クライアントが提供する更新経路を使い、アップグレード前に現在のクライアントバージョン、コアバージョン、有効な設定を記録しておきましょう。

旧ClashクライアントからMihomoクライアントへ移行する

移行前に、元のサブスクリプションURL、現在使用中のYAMLファイル、手動ルール、ポリシーグループの選択状態を保存してください。クライアントのインストールフォルダーだけをコピーする方法は確実ではありません。プログラムごとに設定の保存場所、ファイル名、データベース形式が異なるためです。より汎用的な移行対象は、サブスクリプションURLと読み取り可能なYAML設定です。

現在の状態を記録：旧クライアントとコアのバージョンを保存し、ローカルの待ち受けポート、システムプロキシの状態、TUNの状態、現在選択中のポリシーグループを記録します。
設定をエクスポート：完全なYAMLを保存し、手動で追加したルール、DNS設定、設定オーバーライドを別途整理します。
移行先クライアントをインストール：OSとCPUアーキテクチャに合ったインストールパッケージを選び、初回起動時はTUNを有効にしません。
サブスクリプションまたはファイルをインポート：まず設定を読み込めることを確認し、その後ノード、ポリシーグループ、ルールがすべて表示されるか確認します。
基本プロキシをテスト：システムプロキシを有効にし、ブラウザーでのアクセス、DNS解決、ポリシーの切り替えが正常か確認します。
必要に応じてTUNを有効化：基本プロキシが安定してから権限を取得し、ターミナル、ゲーム、その他システムプロキシに従わないプログラムをテストします。
古い設定を整理：新しいクライアントが使えることを確認したら、旧クライアントの自動起動とバックグラウンドサービスを停止し、2つのプログラムが同じポートを使わないようにします。

移行後によくある競合は、ローカルポートの重複です。旧プログラムがバックグラウンドで7890、7891、または別の設定ポートを待ち受けていると、新しいコアは起動に失敗します。別の問題として、システムプロキシが旧ポートを指したままになっていると、新しいクライアントが動作していてもブラウザーは接続できません。その場合は、新しいクライアントのログに表示される待ち受けアドレスを基準に、システムプロキシを設定し直してください。

旧設定が従来のClash項目を使っていて、移行先クライアントがMihomoを採用している場合は、通常まずそのままインポートし、ログを見ながら差異に対処できます。逆方向の移行はより慎重に行う必要があります。Mihomoの拡張項目は古いコアで認識できない可能性があるためです。未知の項目が見つかったら、その項目が制御する機能を確認し、移行先コアが対応する同等の記述に置き換えるか判断してください。機械的に削除するのは避けましょう。

ログで実行中のプロジェクトを確認する

クライアント名にClashが使われていても、起動ログにはより直接的な情報が記録されていることが多いです。トラブルシューティングでは、コア名、バージョン番号、設定ファイルのパス、ローカルの待ち受けポート、外部コントロールポート、TUNの初期化結果、設定解析エラーを確認します。ログにあるクライアントバージョンはGUIプログラムのバージョンを示すだけで、ルールやプロトコルの対応状況を決めるのはコアのバージョンです。

プロセス一覧から実際に起動している実行ファイルを確認することもできます。一般的なクライアントはGUIプロセスとコアプロセスを1つずつ起動します。サービスモードを有効にすると、コアがシステムサービスから管理される場合もあります。クライアントの動作中に同じコアを手動で2つ目として起動すると、待ち受けポートの競合、設定ファイルの取り合い、システムプロキシ状態の不一致が起こりやすくなります。

ノードには接続できるのにルールが期待どおりに動作しない場合は、接続履歴で対象ドメイン、適用されたルール、最終的なポリシーグループを確認します。接続履歴にIPアドレスしか表示されない場合は、DNSの解決方式やトラフィック解析の設定が関係している可能性があります。常にMATCHに到達する場合は、ルールの順序とルールセットの読み込み状態を確認してください。ルールは上から順に評価され、最初に一致した結果が採用されます。クライアント画面に表示されるグループ名は、設定上の関係を示しているだけです。

プロジェクト選びの結論

Clashはエコシステムの出発点であり、設定体系の名称です。MihomoはClash.Metaから受け継がれた、現在も活発に開発されている互換コアです。Clash Verge Rev、Clash Nyanpasu、FlClashなどは、コアを呼び出してシステム連携を行うGUIクライアントに分類されます。サブスクリプション、YAML設定、GeoIP、GeoSite、ルールセットはデータ層に属し、複数のクライアントで利用できますが、互換範囲はコアのバージョンと設定の拡張内容に左右されます。

実際に選ぶときは、プラットフォームとアーキテクチャ、クライアントのメンテナンス状況、コアの種類、設定の互換性、システムプロキシとTUNの要件を順に確認します。旧クライアントから移行する場合は、サブスクリプションと読み取り可能な設定を保持し、ログで実際に動作しているコアを確認してください。GUI、コア、データを分けて判断すれば、似た名称による誤ったダウンロード、設定の非互換、トラブル解決方針のずれを防げます。