mihomo・Clash Metaと各GUIクライアントの関係|オープンソースの系譜を解説
コア、GUIフロントエンド、モバイルの3つの視点から、オリジナルのコア、Meta系統、mihomoの変遷と、主要クライアントが採用するコアを解説します。
まずは3つの層に分けて考える:プロキシコア、管理画面、システム連携
mihomoはプロキシコアで、Clash Metaは以前使われていたプロジェクト名です。Clash Verge Revなどのクライアントは、コア、GUI、システム連携機能を組み合わせ、インストール可能な製品として提供します。そのため、「Clashを使っている」だけでは、どのコアが動作しているかは特定できず、対応プロトコルや設定項目、システム機能も判断できません。
問題を調べるときは、まずどの層で発生しているかを確認しましょう。ノードのプロトコルを認識できない場合は、コアの対応状況や設定形式を確認します。サブスクリプションのボタンでエラーが出る場合は、クライアントの取得・解析処理に問題がある可能性があります。ブラウザーではアクセスできるのに他のアプリではできない場合は、システムプロキシ、仮想NIC、ルーティング設定も確認してください。
| レイヤー | 主な役割 | 主な確認項目 |
|---|---|---|
| プロキシコア | 設定の読み込み、DNS処理、ルール判定、プロキシ接続の確立 | mihomoのバージョン、実行ログ、最終的なYAML |
| GUI | サブスクリプション管理、プロキシグループの選択、接続一覧、設定編集 | クライアントのバージョン、サブスクリプション更新履歴、オーバーライド設定 |
| システム連携 | システムプロキシの設定、サービスの起動、TUNインターフェースの作成 | 権限、サービスの状態、VPNの許可、ルーティングテーブル |
名称の変遷:Clash、Clash.Meta、mihomo
オリジナルのClash:設定体系とルールエンジンの出発点
オリジナルのClashは、この種のツールで広く使われる設定構造を確立しました。proxiesでプロキシノードを定義し、proxy-groupsでポリシーをまとめ、rulesで接続先を決定します。後発の多くのクライアントもこのYAML形式を引き継いでいるため、画面が異なる製品同士でも設定の一部に互換性があります。
オリジナルのオープンソースコアと、過去に提供されていたClash Premiumは区別が必要です。Premiumは一部の高度な機能を備えた別のリリース系列であり、その機能一覧をオリジナルのオープンソースコアの機能として扱うことはできません。元のプロジェクトは2023年11月に公開メンテナンスを終了しました。古いソフトウェアが起動できても、その後登場したノードプロトコルや新しい設定項目に継続して対応できるとは限りません。
Clash.Meta:互換性を保ちながら機能を拡張
Clash.MetaはClashのエコシステムから派生したプロジェクトで、設定との互換性を保ちながら、プロトコル、DNS、ルーティング機能を拡張しました。初期のドキュメントやサブスクリプションのオプション、クライアントのメニューにある「Metaコア」は、通常このプロジェクト系列を指し、独立したGUIクライアントを意味するものではありません。
mihomo:Metaプロジェクトの後継名称
Clash.Metaは後にmihomoへ改称され、MetaCubeXコミュニティによる開発が続いています。そのため「Clash Metaとmihomoのどちらが優れているか」という問いは、通常、並行する別々の新プロジェクトを比較しているのではなく、旧名称と後継名称を混同しています。古いファイル名や互換用の設定項目、ログにMetaの表記が残っていても、コアが改称前のものだとは限りません。
オリジナルのClashオープンソースコア
└─ Clash.Meta系統
└─ mihomo(後継プロジェクト名)
GUIクライアント、モバイルクライアント
└─ 各コアのリリース系列を統合し、それぞれのGUIとシステム連携機能を提供
この図は、コアプロジェクトの変遷とクライアントへの統合関係を示すもので、Clashという名前を含むすべてのソフトウェアが同じ開発チームのものだという意味ではありません。また、各プロジェクトが同じオープンソースライセンスを共有していることを示すものでもありません。プロジェクトの実態を確認するには、リポジトリ、リリースノート、ライセンスファイルを確認してください。
デスクトップクライアント:mihomoベースと旧系統の見分け方
デスクトップクライアントは通常、「設定の管理」と「コアの起動」の両方を担います。以下に代表的なプロジェクトの技術的な位置づけを示します。実際のインストーラーに含まれるコアのバージョンは、クライアント上の表示とリリースノートで確認してください。
| クライアント/プロジェクト | コアとの関係 | 選ぶ際の注意点 |
|---|---|---|
| Clash Verge Rev | mihomoをコアに採用するデスクトップクライアント | Windows、macOS、Linuxに対応。オリジナルのClash Vergeとは別プロジェクト |
| Clash Nyanpasu | 主にmihomoをコアに採用するデスクトップクライアント | コアの配布形態と利用可能なインストーラーは、各リリースで確認 |
| FlClash | mihomoベースのクロスプラットフォームクライアント | デスクトップ版とAndroid版ではシステム連携の方法が異なる |
| ClashX Meta | Meta/mihomo系のmacOSクライアント | 過去のClashX、ClashX Proとは混同しない |
| Clash for Windows | 過去にClashおよびClash Premiumのコアを使用 | 元のプロジェクトは開発終了。名前だけでmihomoの新機能に対応していると判断しない |
Clash Verge Revは独立してメンテナンスされている後継プロジェクトで、オリジナルのClash Vergeのバージョン番号を変えただけのものではありません。移行時は、旧クライアントのシステム連携がそのまま引き継がれると考えず、サービスのインストール、設定ディレクトリ、自動起動項目を改めて確認してください。
似た名前にも注意が必要です。本サイトのダウンロード一覧にあるFlClashsは、上の表に記載した上流のFlClashと、名前が似ているだけで同じ配布元とは限りません。派生クライアントを使う場合は、それぞれのソースコードリポジトリ、統合されているコア、インストーラーの配布元を確認してください。他のクライアントも同じ方法で判断できます。
モバイル:AndroidのVPNサービスとiOSのネットワーク拡張
Android:Clash for AndroidとMeta系統は分けて考える
オリジナルのClash for Androidは開発終了しています。名前にMetaを含むAndroid向け派生版は別の開発系列であり、オリジナル版のバージョン履歴から更新状況を判断することはできません。FlClashなどのクロスプラットフォームクライアントはGUIの実装が異なりますが、Android上でmihomoを利用することもできます。
Androidクライアントは通常、システムのVpnServiceを通じて端末の通信を取り込みます。初回起動時に表示されるVPNの許可は、クライアントによるローカル仮想ネットワークインターフェースの作成を許可するもので、特定のリモートVPNサービスへの自動接続を意味しません。実際の接続先は、ノード、プロキシグループ、ルールによって決まります。
アプリごとの振り分け、バックグラウンドでの常駐、LAN共有に対応するかどうかは、クライアントの実装とシステムの制限にも左右されます。デスクトップ版と同じサブスクリプションを使う場合も、アプリの除外リスト、バッテリー最適化、DNS設定を個別に確認してください。
iOS:画面が似ていても、同じコアとは限らない
iOSクライアントは通常、Network Extensionなどのシステム機能を使って通信を処理します。また、拡張機能の実行環境による制約もあります。Clash形式のサブスクリプションを読み込めることから分かるのは、その形式に対応している、または変換機能を備えているということだけです。同じバージョンのmihomoを完全に実行しているとは判断できません。
iOS向け製品を選ぶ際は、コアの提供元、対応プロトコル、設定項目が公開ドキュメントに明記されているか確認してください。特にスクリプト、ルールセット、DNS、TUNの設定は、デスクトップ向け手順のメニュー構成をそのまま当てはめないようにしましょう。
設定の互換性:サブスクリプション、ルール、GUIのオーバーライド
サブスクリプションURLの内容が、そのまま最終設定になるとは限らない
サブスクリプションから返されるのは、完全なYAML設定の場合もあれば、ノード一覧だけの場合や、クライアント側での変換が必要な別形式の場合もあります。完全な設定には通常、proxies、proxy-groups、rulesが含まれます。一方、ノード用providerは通常ノードのみを提供し、プロキシグループとルールはメイン設定側で定義します。
GUIクライアントでは、ローカルのオーバーライド、スクリプト処理、画面上の設定をサブスクリプションの内容にマージする場合もあります。そのため、「同じサブスクリプションなのに2つのクライアントで結果が異なる」問題を調べる際は、サブスクリプションの元データだけでなく、最終的にコアへ渡される設定を比較してください。移行時は、まず基本のサブスクリプションを読み込み、オーバーライドを一つずつ戻すと差分を特定しやすくなります。
ルールの構文が似ていても、ポリシー名を確認する
以下はルールの順序を説明するための断片であり、そのまま実行できる完全な設定ではありません。プロキシグループにPROXYという名前のポリシーがすでに存在することを前提としています。ここでのPROXYは任意に付けた名前であり、定義せずに使える汎用の組み込み出口ではありません。
rules:
- DOMAIN-SUFFIX,example.org,PROXY
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,PROXY
ルールは上から順に評価され、最後のMATCHが、それ以前のルールに一致しなかった接続を処理します。移行後にプロキシグループを「ノード選択」に変更しても、ルール内でPROXYを参照したままでは、設定の検証に失敗する可能性があります。同様に、RULE-SETが参照するルールセット名は、rule-providers内に定義されている必要があります。
TUNとFake-IPは別の仕組み
TUNは通信をコアに取り込む方法を解決します。Fake-IPはDNSの処理方式で、仮想アドレスへのマッピングによってドメイン名の情報を復元しやすくします。併用されることは多いものの、同じ機能を切り替える設定ではありません。TUNを有効にしても、誤ったプロキシグループが自動で修正されるわけではなく、すべてのDNSリクエストが想定どおりコアに届く保証もありません。
設定内のtun、dns、プロトコル固有の項目、ルールセットの形式には、バージョン要件がある場合があります。新しいコアが受け付ける項目を、古いClashや旧Premiumが認識できるとは限りません。未知の項目や未対応のプロキシタイプが見つかった場合は、エラー項目を削除して移行できたことにするのではなく、まず必要なバージョンを確認してください。
現在のコアを確認する:バージョン、プロセス、ローカルAPI
確実な記録は「クライアント名とバージョン+実際に動作しているコアのバージョン+最終設定」です。クライアントのメニュー位置はバージョンによって変わるため、「バージョン情報」、コア管理画面、起動ログなどから完全なバージョン文字列を確認してください。問題を報告する際は「最新版」とだけ書かず、文字列をそのまま記録しましょう。
- 実行ログを確認:接続を終了してからコアを再起動し、起動情報でコア名と設定の読み込み結果を確認します。
- 実際のバイナリを確認:入手元を確認したmihomoファイルに対して
mihomo -vを実行します。mihomo -t -f config.yamlで指定した設定を検証できます。コマンドラインで確認するファイルは、クライアントが実際に起動しているコアと同じものを使ってください。 - APIを確認:ローカルREST APIを有効にしている場合は、
/versionを照会できます。コントロールポートとプロキシポートは用途が異なります。
以下は値を明示したサンプル設定です。混合プロキシポートは7890、コントロールAPIは127.0.0.1:9090です。これらはすべてのクライアントに共通する固定の初期値ではありません。実際に確認する際は、動作中の設定を参照してください。
mixed-port: 7890
external-controller: 127.0.0.1:9090
secret: "local-demo-token-change-before-use"
ローカルで確認するコマンドは以下のとおりです。サンプルのトークンは、事前に自分で設定した値に置き換えてください。実際のトークンを公開の問い合わせに貼り付けないでください。
curl --header "Authorization: Bearer local-demo-token-change-before-use" \
http://127.0.0.1:9090/version
Windows PowerShellではcurl.exeを使い、コマンドを1行で入力できます。接続が拒否された場合は、ポート番号が違うか、APIが待ち受けていない可能性があります。401が返る場合は認証トークンを確認してください。バージョン確認のためにコントロールAPIをすべてのネットワークインターフェースで待ち受ける設定に変更しないでください。設定や接続を管理できるAPIのため、アクセス範囲を制限する必要があります。
クライアント選びと移行のチェックリスト:まず対応機能を確認し、次に接続方法を調整
クライアントは、以下の順に検討するとよいでしょう。「画面の好み」と「実行機能」を切り分けられ、一度に多くの設定を変更して原因を追えなくなる事態も避けられます。
- OSとアーキテクチャを確認:Windows、macOS、Linux、Android、iOSでは権限の仕組みが異なります。Appleシリコン用とIntel用のインストーラーも、ファイルサイズだけで選ばないでください。
- 必要なコアを確認:サブスクリプションに含まれるプロトコル、provider形式、DNS項目が、利用するコアのバージョンでサポートされているか確認します。
- 設定の保存元をバックアップ:サブスクリプションURL、ローカルルール、オーバーライド、スクリプトを個別に保存します。認証情報を含む設定を公開の場所にアップロードしないでください。
- 通信を処理するクライアントは一つだけ起動:移行時は旧クライアントのシステムプロキシやVPN/TUNを先に無効にし、ポートの競合やルーティングの競合を防ぎます。
- まず基本的な接続をテスト:サブスクリプションを読み込み、プロキシグループを選択したら、ブラウザーからリクエストを送り、接続一覧で適用されたルールと実際の出口を確認します。
- 最後に高度な機能を戻す:TUN、DNSのオーバーライド、アプリごとの振り分け、自動起動を一つずつ有効にし、変更のたびにログを確認します。
まとめると、Clashはこの設定エコシステムの重要な出発点です。Clash.Metaとmihomoは同じプロジェクト系列の旧名称と後継名称であり、各GUIクライアントはコアをさまざまなOSに統合する役割を担います。この3層の関係を理解すれば、問題に応じてコアの更新、設定の変更、クライアントのシステム権限の調整のどれが必要かを判断しやすくなります。
設定項目をさらに確認する場合は使い方ガイドをご覧ください。プロキシグループ、Fake-IP、TUNの仕組みが分からない場合は、まず用語集をご覧ください。