Clashのオープンソースエコシステム：mihomoコアとGUIクライアントの役割

コア・クライアント・設定の3層構造

Clashエコシステムで使われる名称は、それぞれ異なる層を指します。mihomoはネットワーク通信を処理するコア、Clash Verge RevやFlClashは操作画面を提供するクライアント、YAMLはプロキシノードやグループ、ルールを記述する設定形式です。ソフトを選ぶ前にこの3層を区別しておけば、機能の対応状況を調べる際に、コアのドキュメントとクライアントの設定のどちらを確認すればよいか判断できます。

コアはデスクトップのウィンドウなしでも動作します。たとえばサーバー上でYAMLファイルを読み込み、ローカルのプロキシポートを開くことができます。一方、クライアントは設定のインポートやプロセスの起動、システム設定の変更などをボタン操作にまとめます。両者は一緒にインストールされることが多く、画面に表示されたバージョンをコアのバージョンと取り違えがちです。

旧Clash、Clash Meta、mihomoの変遷

2023年11月、旧Clashと関連プロジェクトの公開リポジトリで削除やアーカイブなどの変更があり、従来の上流メンテナンス体制は途絶えました。過去の資料に登場するオープンソース版Clash、Clash Premium、GUIクライアントは、それぞれ別のものです。Clash Premiumは追加機能を提供していたクローズドソースのコア派生版で、Clash for Windowsはクライアントです。

Clash MetaはClashを基に開発されたオープンソースの派生プロジェクトで、後にmihomoへ名称変更されました。そのため、古いチュートリアルの「Metaコア」と新しいドキュメントの「mihomoコア」にはプロジェクトの系譜があり、互いに無関係な設定体系というわけではありません。一部のアプリ名、リポジトリ名、サブスクの入口には今もMetaの表記が残っています。名称が変わっていないからといって、内部で使われているコアのバージョンが分かるわけではありません。

設定の互換性は項目ごとに確認

• 基本構造：proxies、proxy-groups、rulesなどのフィールドはClash系の構成を引き継いでいますが、すべてのバージョンがすべてのサブフィールドに対応するわけではありません。
• 新しいプロトコル：たとえばtype: vlessやtype: hysteria2を使うには、実際に動作するコアが該当プロトコルを実装している必要があります。クライアント名にClashが含まれているだけでは判断できません。
• 拡張機能：通信のスニッフィング、DNSポリシー、TUN関連のフィールドはバージョンによって変わることがあります。実際に動作しているコアのドキュメントで確認してください。
• 別のエコシステム：sing-boxのJSONはClashのYAMLとは別の形式です。画面が似ていても、設定ファイルをそのまま相互に使えるとは限りません。

mihomoを「後継」と呼ぶのは、コミュニティでの利用や機能開発が受け継がれていることを指します。旧プロジェクトが公式に公開したアップグレード版という意味ではありません。古いクライアントも、サブスクURLを変えただけで新しいコアのプロトコルに対応するわけではありません。

Verge Rev・FlClash・Androidクライアントの役割

以下では、継続的に変化するリリース状況を単一のバージョン番号で表すのではなく、各プロジェクトの位置づけを比較します。各プラットフォーム向けのインストーラーの有無や、パッケージに含まれるコアは、各プロジェクトのリリースノートで確認してください。同じプロジェクトでも、配布経路によって更新ペースが異なることがあります。

デスクトップクライアント：システム連携の違い

Verge RevとFlClashは、近いバージョンのmihomoを使っていても、使い勝手が異なることがあります。スタートアップ、トレイメニュー、システムプロキシの復元、サービスのインストール、設定の上書き、エラー表示などは、主にクライアント側の機能です。比較するときはプロキシ一覧のレイアウトだけでなく、「アプリ終了後にプロキシ設定が戻るか」「サブスク更新後もローカルルールが残るか」といった具体的な動作を確認しましょう。

Androidクライアント：VPNによる通信制御とバックグラウンド制限

Clash Meta for Androidなどのアプリは、通常AndroidのVPNインターフェースを使って通信を制御し、ユーザーの許可を必要とします。このVPNインターフェースはシステム側の通信制御方式を示すもので、サブスクの接続先が従来型VPNプロトコルを使うという意味ではありません。Androidでは通常、一般的なVPNサービスを同時に1つしか有効にできないため、VPN型ファイアウォールや通信フィルタリングアプリと競合することがあります。

Androidの省電力設定、バックグラウンドプロセス管理、アプリごとの通信振り分けも、クライアント選びで考慮すべき点です。デスクトップで問題なく動くYAMLでも、スマートフォンでは待ち受けアドレスやポート、ルーティング関連の設定変更が必要な場合があります。複数のOSに対応していても、システム上の動作まで同じとは限りません。

通信経路：システムプロキシ、制御インターフェース、TUN

アプリのアイコンを覚えるより、通信経路を理解するほうが問題の切り分けに役立ちます。よくあるシステムプロキシの経路は「アプリがシステムのプロキシ設定に従う → ローカルのプロキシ待ち受けポート → コアがルールを照合 → ノードまたは直接接続」です。システムのプロキシ設定に従わないプログラムは、そもそもこの経路を通らないことがあります。

混同しやすい3つのインターフェース

• プロキシ待ち受けポート：ブラウザーやコマンドラインツールなどがプロキシ要求を送るポートです。例：127.0.0.1:7890。
• 制御インターフェース：クライアントやパネルが状態を確認したり、ポリシーを切り替えたりするためのものです。例：127.0.0.1:9090。ブラウザーがインターネットに接続するためのプロキシポートではありません。
• TUN仮想ネットワークインターフェース：ルーティングされた通信をシステムのネットワーク層で受け取ります。実際に制御される範囲は、ルーティング、除外設定、DNS、権限などによって異なります。

以下の設定例は、ポートと制御インターフェースの役割を説明するためのものです。ノード情報を含む完全な設定ではありません。ポート番号は例であり、すべてのクライアントの初期値を示すものではありません。GUIクライアントが起動時にこれらのフィールドを書き換える場合もあります。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

mixed-portを使うと、1つの待ち受けポートでHTTPとSOCKSのプロキシ要求を受け付けられます。mode: ruleはルールに基づいて通信を処理する設定で、システム上のすべてのプログラムが自動的にプロキシを使うという意味ではありません。制御インターフェースには管理機能があるため、信頼できる範囲内に限定してください。リモートから接続する必要がある場合は、認証とネットワークアクセス制限も設定しましょう。

サブスクから実行用設定へ：クライアント側の処理

サブスクのダウンロードに成功したのは、クライアントがリモートのデータを取得できたということにすぎません。その後、形式を解析し、ローカル設定のマージや上書きを適用し、実行用の設定を生成してからコアに読み込ませる必要があります。サブスクの元ファイル、クライアントのエディターに表示されるファイル、コアが実際に使うファイルは、必ずしも一致しません。

2種類のリモート更新を区別する

1. 完全な設定ファイルのサブスク：リモートのYAMLにノード、グループ、ルールをまとめて含められます。更新時にローカルの変更がどう保持されるかは、クライアントの設定管理方式によって異なります。
2. プロキシプロバイダー：proxy-providersで参照するリモートリソースが提供するのは、主にプロキシノードです。外側の設定には、グループとノードの使い方も定義する必要があります。
3. ルールプロバイダー：rule-providersが提供するのはルールセットで、ノードのサブスクの代わりにはなりません。ルールセットはルール項目から参照する必要があります。

たとえば、プロキシグループが 仕事用出口 という名前のノードを参照していても、サブスクリプション更新後にその名前がなくなると、設定の読み込みに失敗したり、選択時に問題が起きたりすることがあります。これは設定内の参照関係の問題であり、クライアント画面の表示不具合ではありません。原因を調べる際は、生成された設定ファイルとカーネルのエラーログを確認しましょう。アプリを何度も再インストールする必要はありません。

クライアントを移行するときは、アプリ内部のデータベースだけでなく、サブスクURL、ローカルルール、上書きの設定を優先して保存してください。特にスクリプトによる上書きは、クライアントによって利用できるオブジェクトや実行手順が異なる場合があります。あるクライアントで実行できるスクリプトが、mihomoコアの共通機能とは限りません。フィールドの詳細はYAML設定ハンドブックを確認してください。

クライアント選びと移行時の確認手順

クライアントは、OS、必要なプロトコル、通信の制御方法の3点から選び始められます。ブラウザーだけをプロキシ経由にしたいデスクトップユーザーは、まずシステムプロキシの経路を確認しましょう。より多くのアプリの通信を制御する場合は、TUNとサービスの権限を確認してください。Androidでは、VPNの許可、バックグラウンド動作、アプリごとの通信振り分けが用途に合うかを優先して確認します。

1. OSとアーキテクチャを確認する。Windows、macOS、Linux、Androidの別を確認し、x64やARM64などインストーラーの対応アーキテクチャも照合します。Apple Silicon搭載MacとIntel Macは、ファイル名にmacOSとあるだけで選ばないようにしてください。
2. 2つのバージョンを記録する。クライアントのバージョンとmihomoのバージョンを、クライアントのバージョン情報、コア設定、起動ログなどからそれぞれ確認します。画面の項目はクライアントのバージョンによって異なるため、実際の画面を基準にしてください。
3. 先にインポートし、次にログを確認する。まずYAMLの解析が成功し、ノードとグループが存在することを確認してから、システムプロキシやTUNを有効にします。設定の誤りをネットワーク障害と取り違えないためです。
4. 通信を制御する仕組みは1つだけ動かす。移行時は、旧クライアントのシステムプロキシ、TUN、バックグラウンドサービスを停止してから新しいクライアントを起動し、ポートの競合やルーティングの衝突を防ぎます。
5. 実際の通信を確認する。接続画面で、プロセス、宛先アドレス、適用ルール、出口ポリシーを確認します。ノードの遅延テストに成功しても、確認対象のテスト通信が成功しただけで、すべてのアプリの通信経路が正常とは限りません。
6. 更新後の動作を確認する。サブスクを手動で更新し、ローカルルールが残っていること、グループの参照先が有効であること、実行用設定で想定した待ち受けポートが使われていることを確認します。

2つのクライアントが同じ7890ポートを使う設定の場合、後から起動した側でアドレスの競合が起きることがあります。旧クライアントの終了後もシステムが127.0.0.1:7890を参照していると、ブラウザーが接続できなくなる場合があります。どちらも、接続先ノードがオンラインかどうかとは直接関係ありません。

よくある誤解：名前が似ていても機能は同じとは限らない

mihomoをインストールしたら、GUIクライアントも必要？

必須ではありません。コマンドライン、サービス管理、設定ファイルに慣れていれば、コアだけで動かせます。トレイからの操作、サブスク管理、システム設定との連携が必要なら、GUIクライアントのほうが日常的に使いやすいでしょう。同じコアを使う場合、プロトコルへの対応は主にコアのバージョンで決まり、システム連携の機能はクライアントの実装によって異なります。

古いClashのYAMLは新しいクライアントにそのまま読み込める？

基本的な設定は引き継げるものが多いですが、まず読み込みテストをしてください。ファイル内のプロトコルタイプ、外部リソースのパス、ルールの参照先に加え、クライアントが追加するDNSやTUNの設定も確認が必要です。古いファイルを解析できても、現在の端末に適した通信ポリシーとは限りません。

選ぶのはGUI？それともコア？

まずコアの機能を基準に、必要なプロトコルとルールを決めます。次にクライアントの機能を見て、操作方法を選びましょう。対応プラットフォーム、設定の上書き、バックグラウンドサービス、更新方式を比較するにはクライアント比較レビューをご覧ください。初めて使う場合はクイックスタートガイドに沿って、設定のインポートと動作確認を進めてください。コア、画面、設定の3層を分けて記録しておくと、アップデートやトラブルの切り分けがしやすくなります。