Clash・mihomoと各クライアントの関係｜オープンソースの系譜を整理

まずは4つの層を整理：コア、クライアント、パネル、設定

ダウンロードページの「Clash」は、プロキシコアを指す場合も、GUIアプリを指す場合も、Clash YAML互換の設定形式を指す場合もあります。プロジェクト同士の関係を判断するには、まず担う層を確認し、次に実際に読み込まれるコアの名称とバージョンを調べましょう。アプリ名にClashが含まれているかだけでは、プロトコル対応、ルール構文、TUN機能は判断できません。

たとえば、GUIクライアントが正常に開いても、確認できるのは画面のプロセスが動作していることだけです。コアの設定検証に失敗していれば、プロキシは起動していない可能性があります。反対に、画面を閉じてもバックグラウンドサービスが稼働していれば、通信が引き続きプロキシ経由になることもあります。トラブルシューティングでは、画面、コアのプロセス、システムプロキシの状態を個別に確認してください。

プロジェクトの系譜：Clash、Premium、Meta、mihomo

Clash本家：ルールベースのプロキシコアの原点

Clash本家とは、一般にDreamacro/clashプロジェクトを指し、Goで書かれたルールベースのプロキシコアです。proxies、proxy-groups、rules、dnsなど、このエコシステムで広く使われる設定構成を確立しました。本家プロジェクトは2023年に公開メンテナンスを終了しています。古いバイナリが動作しても、プロトコル対応やOS互換性の更新が続くわけではありません。

Clash Premiumは、歴史上存在した別のリリース系列です。TUN、ルールプロバイダー、スクリプトなどの機能が追加されていましたが、これらを本家のオープンソースコアの全バージョンが備えている機能として扱うことはできません。Premiumの拡張部分はすべてが公開されているわけではありません。「Clashエコシステムにオープンソースプロジェクトが含まれる」ことと、「Clashを冠するすべての配布物のソースコードが公開されている」ことは別の話です。

Clash.Meta：プロトコルとルール機能を拡張したフォーク

Clash.MetaはClashから派生したフォークで、プロトコル対応、DNS、スニッフィング、TUNなどの機能を拡張しています。古いチュートリアルの「Meta」「Clash Meta」や、ファイル名のclash-metaは、通常このフォークを指します。本家コアの設定で有効にする機能でも、見た目だけを変更したクライアントでもありません。

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

MetaCubeXがメンテナンスしていたClash.Metaは、後にmihomoへ改称されました。現在のプロジェクトを特定する際は、MetaCubeX/mihomoリポジトリ、リリース履歴、バイナリのバージョンを確認してください。古い設定、パス、クライアント画面には、引き続きMetaの表記が残っている場合があります。名称の変更が行き渡っていなくても、別のコアを使っているとは限りません。

Dreamacro/clash
├─ Clash本家のオープンソースコア
├─ Clash Premium（歴史的な拡張版）
└─ Clash.Meta（フォーク）
   └─ mihomo（Metaプロジェクトの後継名称）

GUIクライアント → コアを起動・設定・内包
コントロールパネル   → コアのコントロールAPIに接続

Verge Rev、ClashX、Nyanpasuはそれぞれどの層にあたるか

これらの名称は主にGUIクライアントを指します。クライアントはシステムトレイ、サブスクリプション管理、権限の要求などの操作を担い、プロトコルやルールの処理は主に同梱されたコアが行います。アプリとコアの更新は別々のバージョン系列で進むことがあります。問題を報告する際は両方のバージョンを記録してください。

同名のフォークはメンテナーとリリース履歴を確認

Clash Verge本家とClash Verge Revは、継続してリリースされている同一プロジェクトではありません。Revは後継として独立してメンテナンスされているフォークです。本家の開発停止状況からRevの状態を推測したり、両者のバージョン番号を一つの更新系列として扱ったりしないでください。ClashXの各フォークも個別に確認し、特に対応OSの最低バージョン、CPUアーキテクチャ、コアの出所を調べてください。

macOSのインストーラーを確認する際は、Apple Silicon向けのarm64とIntel向けのx86_64を区別してください。互換レイヤー経由でアプリが起動しても、バックグラウンドの補助プログラムのアーキテクチャ、インストール先、権限は別途確認が必要です。iOSはシステムのネットワーク拡張機能の制約を受けるため、デスクトップで補助サービスをインストールする手順をiPhoneにそのまま適用することはできません。

「Clash設定と互換」でも、すべての項目が動作するとは限らない

Clash YAMLは共通の基盤であり、すべてのコアの全バージョンで機能が同じであることを保証するものではありません。古いコアは新しいプロトコル、スニッフィングのオプション、DNS項目に対応していない場合があります。起動エラーになる項目もあれば、意図どおりに反映されない項目もあります。クライアントにサブスクリプションをインポートできても、すべてのノードで接続テストが完了したことにはなりません。

移行前に確認したい3種類の違い

1. ノードのプロトコル：各ノードのtypeとパラメーターを確認してください。Hysteria2やTUICなどを使う場合は、Clash本家の機能から判断せず、対象のmihomoバージョンでの対応状況を調べましょう。
2. ルールとリソース：rule-providersの形式、behavior、更新パスを確認してください。RULE-SETを使う場合は、指定したリソース名が実際に存在することも確認します。
3. システムの通信制御：tun、DNSハイジャック、ルーティング、権限要件を確認してください。設定構文が受け付けられることと、システムへのルート追加が成功することは、別々の確認項目です。

同じサブスクリプションでも、実際に使われる設定は異なる場合がある

クライアントはサブスクリプションの取得後にルールを追加したり、ポートを書き換えたり、DNS設定をマージしたりできます。そのため、設定画面に保存された元のYAMLが、コアの最終的な読み込みファイルとは限りません。「別のクライアントでは同じサブスクリプションが動く」場合は、何度もインポートを繰り返すのではなく、まず実行時の設定を比較してください。

# 7890 はこの例での設定値で、すべてのクライアント共通のポートではありません
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port: 7890は、同じポートでHTTPとSOCKSのプロキシ接続を受け付ける設定です。コントロールAPIのポートではなく、TUNを自動的に有効にするものでもありません。クライアントがポートの上書きを有効にしている場合、システムプロキシには最終的に適用されたポートを指定してください。サブスクリプション内の数値だけを変更しても、実行結果が変わらないことがあります。上記は設定項目の一部であり、ノードや完全なルーティングルールは含みません。

アプリ名だけでなく、実行中のコアを確認する方法

クライアントのメニュー名はバージョンによって変わります。複数の情報を照合して確認してください。画面に表示されるコア名、起動ログ、実際のバイナリが表示するバージョンです。クライアントの「このアプリについて」に表示される番号はアプリ本体のバージョンであり、コアのバージョンの代わりにはなりません。

1. アプリのバージョンを記録：クライアントの「このアプリについて」またはバージョン情報を開き、アプリの正式名称、バージョン、OSのアーキテクチャを記録します。「最新版」とだけ書かないようにしてください。
2. コアの情報を確認：設定で「コア」「Core」またはコア管理の項目を探し、選択中の名称と更新チャネルを記録します。ダウンロード一覧にある別のコアを、実行中のコアと取り違えないでください。
3. 起動ログを確認：設定を再読み込みしてログを確認し、コアが正常に起動したことと、設定ファイルのパスが正しいことを確かめます。未知のプロキシタイプ、リソースの読み込み失敗、ポートの競合も確認してください。
4. 実行ファイルを確認：さらに調査が必要な場合は、クライアントが実際に使用しているバイナリにバージョン確認コマンドを実行します。別途ダウンロードした同名ファイルから分かるのは、そのファイルのバージョンだけです。

# macOS / Linux：カレントディレクトリに mihomo と config.yaml がある場合
./mihomo -v
./mihomo -t -f ./config.yaml

# Windows PowerShell：カレントディレクトリに mihomo.exe と config.yaml がある場合
.\mihomo.exe -v
.\mihomo.exe -t -f .\config.yaml

-vはバージョン表示、-tは設定のテスト、-fは設定ファイルの指定に使います。構文テストに合格しても、そのバージョンのチェックを通過しただけです。リモートノードへの接続や、TUNに必要な権限が承認されたことを示すものではありません。設定でローカルのルール、証明書、プロバイダーのファイルを参照する場合は、パスと実行ディレクトリが実際の環境と一致していることも確認してください。

用途に合ったクライアントの選び方：まず設定、次にシステムの通信制御を確認

新しいプロトコルやmihomo専用の設定項目が必要な場合

mihomoの採用を明記したクライアントを選び、コアのバージョンと項目の対応状況を確認してください。ノード名が画面に表示されるだけで、プロトコルに対応しているとは限りません。最小限の確認手順は、設定テストに合格すること、対象のポリシーグループを選ぶこと、実際に接続すること、接続画面で適用されたルールとアウトバウンド名を確認することです。

システムプロキシを参照しないアプリをTUNで制御する場合

クライアントが対象プラットフォーム向けのサービスや補助プログラムを提供しているか、必要な権限がOSで承認されているかを確認してください。システムプロキシの影響を受けるのは、プロキシ設定に従うアプリが中心です。TUNは仮想ネットワークインターフェースとルーティングを使って通信を処理し、対象範囲はルート、除外設定、プラットフォームの制約によって変わります。TUNを有効にしても、すべての通信が強制的にプロキシへ送られるわけではありません。最終的なアウトバウンドは、ルール、ポリシーグループ、DIRECT設定によって決まります。

古いクライアントからメンテナンス中のプロジェクトへ移行する

1. サブスクリプションの取得元、手動で追加したルール、DNS設定、ポリシーグループの選択をバックアップします。画面のスクリーンショットだけを保存しないでください。
2. 新しいクライアントに設定を1つインポートし、設定テストに合格することを確認してから、上書き設定を一つずつ戻します。
3. 古いクライアントのシステムプロキシとTUNを無効にし、バックグラウンドサービスが通信を制御していないことを確認してから、新しいクライアントを有効にします。
4. プロキシポートを確認し、ドメイン名の解決、ルールの適用、接続先サイトへの接続をそれぞれテストします。問題があれば、この3つの段階に分けて記録してください。
5. 検証が完了してから古いサービスとスタートアップ項目を削除し、2つのプログラムが同じ待ち受けポートを取り合わないようにします。

クライアント選びで特に役立つ記録は、「アプリ名とバージョン」「コア名とバージョン」「実行設定の取得元」「システムの通信制御方法」の4項目です。アプリの画面構成は操作手順を左右し、コアはプロトコルとルールの対応範囲を決め、OSの権限は通信制御が実際に機能するかを左右します。この3つを分けて確認すれば、クライアントの変更、コアの更新、設定の修正のどれで解決すべきか判断できます。

プラットフォーム別の対応状況を比較するにはクライアント比較をご覧ください。ポリシーグループ、ルール、DNSの違いを確認するには用語集を参照してください。ダウンロードとインストールの後は、使用中のクライアントに実際に表示される設定を確認し、別フォークのメニュー画像を流用しないようにしてください。