Clash・mihomo・Vergeの関係とは：OSSエコシステムのプロジェクト系譜を整理

まず3層に分ける：コア、GUIクライアント、設定

Clashエコシステムを理解する最も効果的な方法は、似た名前を暗記することではなく、ソフトウェアを3層に分けて考えることです。最下層はプロキシコアで、YAML設定の読み込み、プロキシ接続の確立、ルール照合、DNSクエリの実行、システム通信の取り込みを担当します。中間層はGUIクライアントで、サブスクリプション管理、トレイメニュー、システムプロキシの切り替え、ログ表示、更新操作を担います。最上層は設定とサブスクリプションで、ノード、プロキシグループ、ルール、DNSパラメータが含まれます。

オリジナルのClashとmihomoはコア層に属します。Clash Verge、Clash Verge Rev、ClashX、FlClashなどは、通常GUIクライアントを指します。サブスクリプションURLは設定の取得元であり、コアでも特定クライアントの構成要素でもありません。同じ基本設定を複数のクライアントで読み込めますが、正常に動作するかは、使用されているフィールドを基盤コアがサポートしているかどうかで決まります。

プロキシコア: 設定を解析して通信を転送します。代表的な名称にはオリジナルのClash、Clash.Meta、その後継のmihomoがあります。
GUIクライアント: コアにウィンドウ、トレイ、サブスクリプション管理、システムプロキシ、TUN切り替え機能を提供しますが、プロキシプロトコルの実装そのものではありません。
サブスクリプションと設定: YAMLまたはサブスクリプションのレスポンスとして、ノード、プロキシグループ、ルール、DNS、通信取り込みのパラメータを提供します。

オリジナルのClashからmihomoまでのプロジェクト系譜

オリジナルのClash：設定構文とルールモデルの出発点

Dreamacroが開発したオリジナルのClashは、現在も広く使われる設定構造の基礎を築きました。proxiesでノードを定義し、proxy-groupsで選択や自動テストを構成し、rulesを順番に適用して通信先を決めます。DOMAIN-SUFFIX、IP-CIDR、GEOIP、末尾のフォールバックルールなどは、すべてこのモデルに由来します。

オリジナルのオープンソース版Clashで一般的な最終バージョンはv1.18.0です。かつて個別に公開されていたClash Premiumの公開版には2023.08.17もあります。元プロジェクトは2023年に継続的なメンテナンスを停止しましたが、設定互換性を理解するうえでは重要です。ただし、新しいプロトコルやルール機能、最新プラットフォーム向けの修正を確認する唯一の基準には適しません。

Clash.Meta：互換性を土台にした機能拡張

Clash.Metaは、Clashの設定体系と互換性を持つ拡張コアとして登場しました。一般的なプロキシグループやルール構文を維持しながら、TUN、DNS、ルールセット、プロトコルのサポートを継続的に拡充しています。設定で使われるrule-providers、fake-ip-filter、プロセスマッチング、より詳細なネットワークスタックのオプションなどは、Meta系コアでより積極的に保守されています。

ここでいう「互換性」は、あらゆる方向に完全互換という意味ではありません。基本的なClash設定は通常mihomoで読み込めますが、mihomoの拡張フィールドを使う設定を旧版のオリジナルClashに戻すと、「フィールドを認識できない」「プロキシタイプに対応していない」といったエラーや、設定の読み込み失敗が起きる場合があります。移行時は、旧構文から新しいコアへの互換性は比較的高い一方、完全な双方向互換ではないと理解してください。

mihomo：Clash.Metaの後継名称

Clash.Metaは後にmihomoへ改称され、MetaCubeXコミュニティが開発を引き継ぎました。名称が変わっても、まったく別の設定体系になったわけではありません。多くのクライアント、設定変換ツール、ログ画面では、Meta、Clash Meta、Meta Coreといった旧称が残っています。これらの語を見たら、3つの無関係なコアと考えるのではなく、具体的なバージョン番号と合わせて判断しましょう。

現在よく見られる流れは、オリジナルのClashが基本設定モデルを提供し、Clash.Metaが互換性を保ちながら機能を拡張し、mihomoがClash.Metaの開発を引き継ぐというものです。クライアントに「mihomoコア」と記載されていれば、通常は現在も更新が続くこの系統を対象にしています。

Verge、ClashX、Clash for Windowsとは何か

プロジェクト	所属レイヤー	主なプラットフォーム	コアとの関係	選ぶ際の確認点
Clash	コア	コマンドライン・マルチプラットフォームビルド	オリジナルプロジェクト	継続的なメンテナンスは終了。主に基本互換性の理解に利用
Clash.Meta / mihomo	コア	Windows、macOS、Linux、モバイル	Metaの後継名称がmihomo	バージョン更新、設定拡張、TUNとDNS機能
Clash Verge	デスクトップGUIクライアント	Windows、macOS、Linux	コアを通じてプロキシ機能を実行	元プロジェクトのメンテナンス状況と後継ブランチは分けて判断する必要がある
Clash Verge Rev	デスクトップGUIクライアント	Windows、macOS、Linux	通常はmihomoと組み合わせて使用	コアのバージョン、サービスモード、TUN権限、システム互換性
ClashX	macOS向けGUIクライアント	macOS	Clash系コアをパッケージ化	OSバージョン、コアの世代、設定フィールドの互換性
Clash for Windows	デスクトップGUIクライアント	Windows、macOS、Linux	歴史的にClash系コアを統合	一般的な最終バージョンは0.20.39。プロジェクトは更新終了

Clash VergeとClash Verge Rev

Clash Vergeはデスクトップ向けWeb技術で構築されたクロスプラットフォームGUIクライアントで、サブスクリプション、プロキシ選択、システムプロキシ、設定編集を管理します。元のClash Vergeプロジェクトが活発な開発を終えた後、Clash Verge Revが後継メンテナンスブランチとして近い操作性を引き継ぎました。名前は似ていますが、公開リポジトリ、バージョン系列、メンテナンス状況は異なるため、ダウンロード時にアプリアイコンだけで判断してはいけません。

Clash Verge Revでは通常、「設定」→「Clash設定」でポート、外部コントローラー、コア関連のパラメータを確認でき、「設定」→「システム設定」で自動起動やサービスモードを管理できます。バージョンによって表示訳は多少異なりますが、実際の機能を判断するには、インストーラー名より「設定画面に表示されるコアバージョン」のほうが有用です。TUNを有効にする場合、Windowsではサービスモードのインストールと起動が必要になることが多く、macOSではシステム権限の許可を完了する必要があります。

ClashX：macOS向けメニューバークライアント

ClashXの特徴はmacOSのメニューバー体験です。設定の切り替え、プロキシグループの選択、システムプロキシ、ログへの入口をステータスメニューにまとめ、システムプロキシを主な通信取り込み方法とする用途に適しています。ClashX、ClashX Pro、コミュニティによる後継版は、名前だけでは機能を判断できません。コアの種類、最終更新日、現在のmacOSへの対応状況をそれぞれ確認する必要があります。

旧版のClashXは多くの古典的なClash設定を読み込めますが、mihomoのみが対応するプロトコル、ルールセットの挙動、DNSフィールドに遭遇すると、完全には読み込めない場合があります。サブスクリプションの説明でMetaまたはmihomoコアが明示的に必要とされているなら、対応フィールドを削って旧クライアントを無理に起動するのではなく、該当コアを明確に統合したクライアントを選びましょう。

Clash for Windows：影響は大きいが更新終了

Clash for WindowsはCFWと略されることが多く、多くのユーザーが最初に触れたデスクトップクライアントです。Profiles、Proxies、Connections、Logs、Settingsなどの画面を備え、サブスクリプションを取り込んですぐにプロキシグループを切り替える操作方法を広めました。一般的な最終リリースは0.20.39で、プロジェクトは2023年に更新を終了しています。

もう一点、明確にしておく必要があります。Clash for Windowsは完全なオープンソースGUIクライアントではありません。名前にClashが含まれているからといって、オリジナルのオープンソースコアと同一プロジェクトとみなすことはできません。現在も古いインストーラーを使い続けると、新しいシステムへの対応、コア機能、問題修正が止まっているという制約があります。新規環境では、更新履歴があり、使用コアを明記しているクライアントのほうが適しています。

同じサブスクリプションがクライアントによって異なる理由

サブスクリプションを取り込めるかどうかは最初の関門にすぎません。クライアントが内容を取得した後、コアに解析を渡す必要があります。どちらの画面にも「Clash設定」と表示されていても、基盤コアのバージョン、上書き処理、DNS実装、通信の取り込み方法が異なれば、最終結果も変わります。主な違いは次の4点に集約されます。

設定フィールドとプロキシプロトコルの対応

mixed-port、proxies、proxy-groups、rulesなどの基本フィールドは、幅広い範囲で互換性があります。
新しいプロトコルのパラメータ、ルールセットの挙動、高度なDNSオプションには、通常より新しいmihomoコアが必要です。
クライアントはサブスクリプション原文に加えて、ポート変更、LANアクセスの有効化、TUN設定の追加など、ローカルの上書きを適用する場合があります。
同名のプロキシグループはサブスクリプションから生成されることもあれば、クライアントのスクリプトで変更されることもあります。調査時は、リモートの原文と最終的な実行設定を区別してください。

システムプロキシとTUNでは取り込み範囲が異なる

システムプロキシは通常、HTTPとSOCKSのプロキシアドレスをOS設定に書き込みます。一般的なローカル混合ポートは127.0.0.1:7890です。アプリがシステムプロキシを読み込むか、このポートを手動で指定して初めて通信がコアに入ります。ゲーム、一部のコマンドラインプログラム、独自のネットワークスタックを実装するアプリは、システムプロキシを迂回する場合があります。

TUNモードは仮想ネットワークデバイスを通じて、より多くのIP通信を取り込みます。そのため、システム権限、ルーティングテーブル、DNSの横取り、ネットワークスタック設定への依存が大きくなります。同じmihomoバージョンを使っていても、一方がサービスコンポーネントのインストールに成功し、もう一方が権限を取得できなければ、TUNの動作は異なります。問題を判断する際は、まずログでTUNデバイスの作成成功を確認し、次にルールのヒット状況を調べてください。権限エラーをノード障害と取り違えないことが重要です。

mixed-port: 7890
external-controller: 127.0.0.1:9090
secret: "change-this-controller-secret"

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

上記の7890はプロキシの入口で、9090は外部コントロール用インターフェースです。用途は異なります。外部コントロールインターフェースはクライアント画面で接続を確認したりプロキシグループを切り替えたりするためのもので、ブラウザーからHTTPプロキシポートとして使うものではありません。クライアントがコントロール用のキーを自動生成している場合は、画面とコアの接続が失われないよう、生成された値をそのまま保持してください。

DNSポリシーがルール照合結果を変える

Clash系コアは、ドメイン、IPアドレス、ルールの順序に基づいて通信先を決定します。fake-ipモードでは、コアがまずアプリに予約アドレスを返し、その後のルール照合のためにドメインとの対応を管理します。クライアントがenhanced-mode、nameserver、fake-ip-filterを変更すると、同じルールでも結果が異なる場合があります。

調査時は、クライアントの「ログ」画面でレベルをinfoに設定し、日本国内のドメイン、プロキシが必要なドメイン、純粋なIPアドレスへそれぞれアクセスします。少なくとも30秒間継続して観察し、3種類のリクエストが想定したプロキシグループやルールに一致することを確認してください。ドメインのルールは正常なのに純粋なIP通信だけが迂回する場合は、まずTUNまたはシステムプロキシの取り込み範囲を確認します。すべてがフォールバックルールに入る場合は、ルールの順序とDNSマッピングを確認します。

プロジェクトが現在も使う価値があるか判断する方法

プロジェクト名は出自を示すだけで、現在の状態を直接表すものではありません。クライアントを選ぶ際は、リリース履歴、コアの出所、OS対応、設定互換性を同時に確認してください。画面が開くからといって、現在のサブスクリプションに含まれるすべてのフィールドを適切に処理できるとは限りません。

最近のリリース履歴を確認する。リポジトリにアクセスできるかだけでなく、正式版のリリース日、変更内容、対応OSを確認します。
コアの名称とバージョンを確認する。「設定」→「概要」または「設定」→「Clash設定」でmihomoのバージョンを明確に表示できるクライアントを優先します。
OSのアーキテクチャを確認する。Windowsではx64とARM64、macOSではApple SiliconとIntelを区別し、LinuxではAppImage、deb、rpm、コマンドライン導入のどれに対応するかも確認します。
権限の仕組みを確認する。TUNを使う場合は、サービスモード、管理者権限に関する説明、macOSのネットワーク拡張を許可する手順が用意されているか確認してください。
サブスクリプションの要件を確認する。設定の提供元がmihomo、Meta、または特定プロトコルへの対応を指定している場合、旧版のオリジナルClashだけを統合したクライアントは選ばないでください。
戻せる設定を保存する。クライアントやコアを更新する前に、現在動作している設定をエクスポートし、システムプロキシのポート、上書き項目、DNS設定を記録します。

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

Clash for Windows、旧版ClashX、初期のVergeから移行する場合は、サブスクリプションとローカル設定を分けて扱うのが最も安全です。まず新しいクライアントに元のサブスクリプションを取り込み、基本的なプロキシ通信を確認します。その後、上書き設定、TUN、LANアクセス、カスタムルールを1項目ずつ戻してください。古い設定ディレクトリ全体を直接コピーすると、キャッシュ、旧コアのパス、無効になったコントローラー設定まで持ち込むおそれがあります。

移行前に5つの項目を記録する

現在のサブスクリプションURLと更新時刻。サブスクリプションを正常に更新できることも確認します。
プロキシの入口ポート。一般的には混合ポート7890ですが、HTTP7890とSOCKS7891を分けて使う場合もあります。
現在のモードがRule、Global、Directのどれか、そしてデフォルトのプロキシグループの選択。
TUN、LAN接続、IPv6、カスタムDNSを有効にしているかどうか。
ローカルで追加したルール、スクリプト、設定の上書き。これらは通常、リモートのサブスクリプションには含まれません。

3段階のテストで移行結果を確認する

第1段階はシステムプロキシだけを有効にする。TUNを無効にし、Ruleモードを選択します。日本国内のサイトとプロキシが必要なサイトをそれぞれ開き、ログに対応するルールとプロキシグループが表示されることを確認してください。
第2段階はサブスクリプションの更新をテストする。設定を手動で1回更新し、画面に更新時刻が表示されるまで待ちます。その後、プロキシグループの選択が意図せずリセットされていないことを確認します。
第3段階でTUNを有効にする。サービスモードを起動するかシステムの許可を完了し、システムプロキシを読み込まないコマンドラインプログラムをテストします。curl --connect-timeout 10 https://example.comを使えば接続タイムアウトを10秒に制限でき、クライアントの接続一覧と照合できます。

第1段階は成功して第3段階だけ失敗する場合、問題は通常TUNの権限、ルーティング、DNSにあります。サブスクリプションを再変更する必要はありません。設定の読み込み段階ですでにエラーが出る場合は、最初の解析エラーを確認し、そのフィールドにmihomoが必要かどうかを確認します。特定のノードだけが失敗する場合は、プロトコルパラメータとサーバー側の状態を比較してください。

1枚の関係図でエコシステム全体を覚える

Clashエコシステムは「1つのソフトウェアが何度も名前を変えたもの」ではなく、設定の考え方を共有しながら、異なるチームが開発する一連のプロジェクトです。オリジナルのClashは基盤コアであり、Clash.Metaはその設定モデルを拡張し、後にmihomoという名称で開発が続いています。Clash Verge RevやClashXなどはGUIクライアント層に位置し、コアを統合して実際のプロキシ処理を行います。サブスクリプションは設定層にあり、互換性のあるクライアント間で移行できます。

サブスクリプションとYAML設定
        │
        ▼
GUIクライアント
Clash Verge Rev / ClashX / その他のクライアント
        │
        ▼
プロキシコア
mihomo（旧Clash.Meta）
        │
        ▼
ルール照合 / DNS / システムプロキシ / TUN / 接続転送

選ぶ際の確認点は3つに絞れます。クライアントが現在も保守されているか、どのコアを統合しているか、現在のサブスクリプションがそのコアの拡張機能に依存しているかです。この3点に答えれば、似た名前による混乱は大きく減ります。新規インストールでは、リリース履歴があり、mihomoを明確に統合し、現在のOSの権限方式に対応するクライアントを優先してください。既存の安定した環境では、まず設定とポートを記録し、段階的に移行します。