Clashのオープンソースプロジェクト相関図｜旧Clash・Meta・mihomoとGUIクライアントの違いと選び方

コア・クライアント・設定ファイルの役割

Clashのデスクトップクライアントを選ぶ前に、接続を処理するコア、設定画面を提供するGUIクライアント、ノードやルールを記述する設定ファイルの3つを区別しましょう。名前にClashが含まれていても、同じコアを使うとは限らず、設定ファイルの互換性が完全にあるわけでもありません。

コアはプロキシポートの待ち受け、設定の解析、ルール判定、外部への接続、DNSなどのネットワーク処理を担います。GUIクライアントはサブスクリプションのインポート、プロキシグループの選択、システムプロキシの切り替え、バックグラウンドサービス、ログ表示を担当します。設定ファイルには、コアが実行するプロキシノード、プロキシグループ、ルール、DNS設定が記述されています。

旧Clash・Meta・mihomoの関係

旧Clash：エコシステムの起点

旧Clashとは、一般にDreamacro/Clashプロジェクトのオープンソースコアを指します。Goで開発され、広く使われるYAML設定形式と制御インターフェースを確立しました。元のプロジェクトは2023年11月に公開メンテナンスを終了しました。過去のバイナリや設定ファイルは今も存在しますが、古いインストーラーを継続的に修正が提供される現行版とみなすことはできません。

歴史上のClash Premiumも区別が必要です。これは「すべてのオープンソースClashコア」の総称ではなく、mihomoの旧称でもありません。以前のチュートリアルにはPremiumを前提とした機能もあるため、設定項目があるだけで旧来のオープンソースコアが対応していると判断しないでください。

Clash Meta：旧Clashを拡張したフォーク

Clash Metaは旧Clashのコードをもとに開発され、プロトコル、DNS、ルーティングなどの機能を拡張しました。古いドキュメントにある「Metaコア」や「Clash.Meta」は、通常このプロジェクトの系譜を指し、独立したサブスクリプション形式を意味するものではありません。サブスクリプションに「Metaが必要」とある場合、旧来のコアにない機能を設定で使っていることが多いです。

mihomo：Metaプロジェクトの後継名称

Clash Metaは後にmihomoへ名称変更されました。現在の主なプロジェクトリポジトリはMetaCubeX/mihomoです。つまりMetaとmihomoは、無関係な2つのコアでも、順番に両方を起動するものでもありません。クライアントのメニュー、サブスクリプションの説明、ファイル名、チュートリアルには旧名称が残っている場合があります。見分ける際は、リポジトリのURLとバージョン表示を確認しましょう。

コアプロジェクトの変遷（簡略図）
Dreamacro/Clash
└─ Clash.Meta（拡張フォーク）
   └─ mihomo（後継名称、MetaCubeX/mihomo）

呼び出し関係（コードの継承関係ではありません）
Clash Verge RevなどのGUIクライアント
├─ サブスクリプションとローカル設定を管理
├─ mihomoを起動・停止・再読み込み
└─ 制御インターフェース経由で状態を取得し、プロキシグループを切り替え

この相関図はプロジェクトの変遷と実行時の役割分担を示すもので、各フォークの機能がすべて一対一で対応することを意味しません。設定が使えるかどうかは、クライアント名に「Clash」が含まれるかではなく、使用中のコアのバージョンが対応する項目やプロトコルを確認してください。

Verge RevなどのGUIクライアントによるコアの利用方法

Clash Verge RevはTauriを採用したデスクトップGUIクライアントで、mihomoとは別のプロジェクトです。インストーラーには通常コアが同梱されます。クライアントは実行用の設定を生成してコアのプロセスを起動し、制御インターフェース経由でプロキシグループ、接続履歴、ログを表示します。クライアントとコアのバージョン番号は別々に管理されるため、片方を更新しても、もう片方が必ず同時に更新されるわけではありません。

1. 設定をインポート：サブスクリプションURLまたはローカルのYAMLを保存し、設定内容を読み込みます。
2. 実行パラメーターを調整：オーバーライド、設定のマージ、スクリプトなどを使って、ポート、DNS、ルールを変更する場合があります。
3. コアを起動：コアが生成後の設定を読み込み、ローカルポートで待ち受けを開始してルールを読み込みます。
4. 画面から操作：クライアントが制御インターフェースを呼び出し、プロキシグループの切り替え、設定の再読み込み、ログ表示を行います。
5. システム連携：必要に応じてシステムプロキシを設定したり、サービスや権限の仕組みを使ってTUNを利用したりします。

GUI・Webパネル・コアはそれぞれ別のもの

Webコントロールパネルは主に制御インターフェース経由で、起動済みのコアを管理します。通常、デスクトップアプリのインストール、OS起動時の自動起動、権限サービスまでは担当しません。パネル画面が表示されているだけでは、PC上でプロキシコアが起動しているとは限りません。逆に、コアはコマンドラインで動作させ、デスクトップ画面を使わないこともできます。

過去のクライアントも個別に判断する必要があります。Clash for Windows、旧Clash Verge、Clash Verge Revは、同一プロジェクトの3つのバージョンではありません。名前が似ていても開発チームが同じとは限りません。また、オープンソースコアを呼び出せるからといって、GUIクライアントのコードすべてが同じライセンスで公開されているとは限りません。

設定の互換性：確認すべき4つのポイント

多くの設定ファイルはproxies、proxy-groups、rulesといったトップレベル構造を引き継いでいます。しかし、「YAMLを解析できる」ことと「設定のすべてを実行できる」ことは別です。古いコアでは、新しいプロトコル、異なるルール構文、新しいDNS項目でエラーが起きたり、想定外の動作をしたりする場合があります。

• ノードの種類：VLESS、Hysteria2、TUICなどへの対応は、mihomoの具体的なバージョンで確認してください。旧来のコアも対応しているとは限りません。
• ルールとルールセット：rule-providersの形式、動作タイプ、ファイル内容が一致している必要があります。ドメインリストをそのまま完全なルール一覧として使うことはできません。
• DNS設定：fake-ip、上流DNS、ルーティング関連の設定は、使用中のコアのドキュメントで確認してください。古いチュートリアルの設定をまとめてコピーするのは避けましょう。
• クライアントによるオーバーライド：サブスクリプションの元データを編集しても反映されない場合、実行用の最終設定で上書きされているか、サブスクリプションの更新で変更が消えている可能性があります。

ポートの例：プロキシポートと制御ポートは別

以下は用途を見分けるための設定例です。単独で接続できる完全な設定ではなく、すべてのクライアントの初期設定を示すものでもありません。例では7890をHTTP・SOCKSプロキシに、9090を制御インターフェースに使用しており、用途は異なります。

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

ブラウザーやコマンドラインアプリはプロキシポートに接続してください。9090をインターネット接続用のプロキシとして設定してはいけません。制御インターフェースはローカルからのみアクセスできるようにするのが基本です。リモート操作が必要な場合は、別途認証とアクセス制限を設定してください。画面から接続できるようにするためだけに、LANやインターネットへ制御インターフェースを公開しないでください。

システムプロキシとTUN：画面側とコア側を分けて確認

システムプロキシは通常、OSのプロキシ設定をローカルの待ち受けポートに向けます。この設定に従うブラウザーやアプリはプロキシ経由でリクエストしますが、すべてのアプリがシステムプロキシを参照するわけではありません。ルールモードは、コアに入った接続をどのように振り分けるかを決める機能であり、すべてのアプリを強制的に接続させるものではありません。

TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込みます。DNS、権限、システムのネットワーク環境も関係します。mihomoがコア機能を提供し、クライアントが切り替え操作、サービスのインストール、権限の連携を担います。画面にTUNボタンがあるだけでは、サービス、ルーティング、DNSが正常に動作しているとは判断できません。

最初の動作確認では、まずシステムプロキシを使い、サブスクリプション、プロキシグループ、プロキシポートが正常か確認してから、必要に応じてTUNを有効にしましょう。ノード接続の問題とシステム側の通信取り込みの問題を切り分けられ、複数の設定を同時に変更せずに済みます。

クライアントの選び方とバージョン確認手順

まずコアとクライアントのバージョンを記録する

Clash Verge Revの場合は、「設定」→「バージョン情報」でクライアントのバージョンを確認し、「設定」のコア関連項目または起動ログでコアの名称とバージョンを確認します。項目の場所は配布版によって異なることがあります。コアのバージョンを個別に確認できない場合は、そのバージョンのログとプロジェクトの説明を参照してください。「最新版」のような曖昧な記録ではなく、完全なバージョン番号を控えましょう。

実際に使われているコアの実行ファイルが分かっている場合は、ターミナルからバージョンを確認できます。以下はWindows PowerShellでのコマンド例です。ファイル名はインストーラーに含まれる実際の名称に合わせてください。GUIクライアントの本体をコアと間違えて実行しないよう注意してください。

# 実際のコアファイルがあるディレクトリで実行
.\mihomo.exe -v

# 使用するYAMLの設定を検証
.\mihomo.exe -t -f .\config.yaml

設定の検証では構文エラーや一部の項目の誤りを見つけられますが、ノードへの接続や、システムプロキシ・TUNによる通信の取り込みを保証するものではありません。設定が相対パス、外部ルールセット、プロバイダーファイルに依存する場合は、対応する作業ディレクトリと関連ファイルを用意して検証してください。

用途に合わせて選ぶ

1. デスクトップで日常的に使う：OSとプロセッサのアーキテクチャを確認し、メンテナンスが継続され、コアの状態を分かりやすく表示するGUIクライアントを選びます。
2. 新しいプロトコルを含む設定を使う：必要なmihomoのバージョンを確認し、クライアントに実際に同梱されているバージョンと照合します。画面上の機能だけで比較しないでください。
3. TUNを使う：使用中のOSでサービスのインストール、管理者権限、既知のネットワーク互換性の問題を確認し、TUNを無効にして元に戻せる手段を確保します。
4. サーバーや自動化で使う：コアを直接実行し、設定、プロセス、制御インターフェースを個別に管理できます。そのためだけにデスクトップGUI一式をインストールする必要はありません。
5. 古い設定を移行する：新しいクライアントで設定の解析、プロキシグループの選択、DNSを確認してから、OS起動時の自動起動やシステムの通信取り込みを移行します。

オープンソース情報を確認するときは、コアとクライアントのリポジトリでライセンスをそれぞれ確認してください。mihomoのライセンスはGPL-3.0ですが、個別のGUIクライアント、インストーラーに含まれるコンポーネント、リリースノートの確認に代わるものではありません。プロジェクト名、リポジトリURL、クライアントのバージョン、コアのバージョンを照合しましょう。

移行後の基本チェックリスト

インストールや入れ替えが済んだら、まず動作確認済みの設定で範囲を絞って検証してください。システムプロキシ、TUN、複雑なオーバーライド、自動切り替えを一度に有効にするのは避けましょう。設定を1つずつ追加すれば、ログから問題を特定しやすくなります。

• コアが起動し、実際の待ち受けポートがアプリに設定したポートと一致していることを確認します。例：127.0.0.1:7890。
• サブスクリプションの解析が完了し、プロキシグループにノードが表示され、削除済みのプロキシグループを参照していないことを確認します。
• ルールモードでアクセスを1回行い、接続履歴で適用されたルールと最終的な接続先を確認します。
• ローカルルールとオーバーライドが実行時の最終設定に反映されていることを確認します。その後、サブスクリプションを更新し、変更が意図どおり維持されるか確認してください。
• 最後に、クライアントの再起動後に設定が復元されることと、必要に応じて有効にしたシステムプロキシまたはTUNの動作を確認します。

インストールと設定のインポートを順に進める場合は使い方ガイドをご覧ください。ポート、サブスクリプション、システムによる通信の取り込みに問題がある場合はヘルプセンターをご確認ください。プロキシグループやルールセットなどの用語が分からない場合は、まず用語集をご覧ください。