Clash・mihomo・Clash Verge Revの違いと関係｜プロジェクトの系譜を解説
Clashの開発終了からmihomoへの継承、GUIクライアントの役割まで、コアと画面の関係を整理して選び方を解説します。
まずはコア・クライアント・サブスクリプションを区別する
Windows向けのClashクライアントを検索すると、Clash、Clash Meta、mihomo、Clash Verge Rev、Clash for Windowsなどの名前が見つかりますが、それぞれ同じ階層のものではありません。通信を処理するプロジェクトと、操作画面を提供するプロジェクトを区別し、設定の互換性を確認しましょう。そうすれば、古い解説のボタン操作を新しいクライアントにそのまま当てはめずに済みます。
| 階層 | 代表例 | 役割 |
|---|---|---|
| プロキシコア | Clash、mihomo | プロキシポートの待ち受け、DNSの解決、ルール照合、外向き接続の確立を行います。 |
| GUIクライアント | Clash Verge Rev | 設定の管理、プロキシグループの切り替え、ログ表示のほか、コアのプロセスやシステム連携を管理します。 |
| 設定データ | サブスクリプションから取得する YAML | プロキシノード、プロキシグループ、ルールに加え、DNSなどの設定が含まれる場合もあります。 |
通信の流れは3段階に分けられます。アプリが接続をローカルプロキシに渡し、コアが設定に基づいて接続先を選び、クライアントが動作状況を表示します。クライアントが利用可能なノードを提供するわけではありません。インストール後も、利用権限のあるサブスクリプションを読み込むか、手動で設定する必要があります。
プロジェクトの系譜：Clashからmihomoへ
オリジナルClashとClash Premium
オリジナルClashは、Dreamacroが開発を始めたGo製のプロキシコアです。多くのGUIクライアントは、コアのプロセスを起動して制御APIを呼び出すことで管理します。Clash Premiumは同時期に存在した別系統のコアで、オリジナルのオープンソース版にはない機能を含んでいましたが、ソースコード全体は公開されていません。過去の解説を読む際は、Premiumの機能一覧をオリジナルのオープンソース版にも当てはまるものとして扱わないようにしましょう。
2023年11月ごろ、オリジナルプロジェクトの公開メンテナンスが終了し、関連リポジトリやリリースへの導線も変化しました。この時期は「オリジナル版のアーカイブ」とまとめて呼ばれることがありますが、実際にはリポジトリの削除、保存用ミラー、第三者によるバックアップなどがあり、すべての公開先が単に読み取り専用になったわけではありません。古いソフトが動作する場合はありますが、メンテナンス終了後は、元の開発者による互換性修正やセキュリティ更新を期待できません。
Clash.Metaとmihomo
Clash.MetaはClashのエコシステムから派生したコアで、後にmihomoへ改称し、MetaCubeXコミュニティがメンテナンスしています。古いドキュメントにあるClash MetaやClash.Meta、一部の実行ファイル名に含まれるMetaは、多くの場合このプロジェクトの系譜を指します。名称が変わっても設定方式がまったく別物になったわけではありませんが、利用できる機能はコアのバージョンによって異なります。
mihomoはClash系のYAML設定、プロキシグループ、ルールの仕組みを引き継ぎながら、対応プロトコルやネットワーク処理機能を拡張しています。たとえば、type: hysteria2のノードを含む設定を使うには、コアが該当プロトコルに対応している必要があります。古いクライアントの画面上の名称を「Meta」に変えただけでは、プロトコルへの対応は追加されません。unsupported proxy typeのようなエラーが出たら、サブスクリプションのURLを何度も変更するのではなく、まずコアの対応状況を確認してください。
- 歴史的な起点：Clashはオリジナルのコアプロジェクトで、Clash.Metaはそこから派生した系統の一つです。
- 名称の変遷：Clash.Metaは後にmihomoというプロジェクト名になりました。旧称は解説記事や設定画面に残っていることがあります。
- メンテナンスの関係：コミュニティによる開発の継続は、元の作者がメンテナンスを再開したことを意味しません。また、Clashの名を含むソフトがすべて同じチームから公開されているわけでもありません。
Clash Verge Revとコアの役割分担
Clash Verge RevはGUIクライアントで、Clash Vergeの画面プロジェクトを引き継ぎ、プロキシ通信の処理にmihomoを使用します。mihomoの別名でも、オリジナルClashの「Windows版インストーラー」でもありません。インストーラーには通常、GUIアプリと対応するコアが含まれているため、設定の読み込み、プロキシの起動、ログの確認を一つのウィンドウから行えます。
Clash Verge Revでは、サイドバーから「設定」→サブスクリプションを読み込み、「プロキシ」→プロキシグループを選択し、「ログ」→接続エラーを確認する順に操作できます。バージョンによってボタン名や設定項目の配置は変わることがありますが、各画面の役割はおおむね共通です。システムプロキシやTUNモードを有効にする場合は、「設定」で該当する項目を確認してください。プロキシ画面でノードを選ぶ操作と、通信を取り込む設定は別です。
| 操作・症状 | 主に関係する層 | 優先して確認する項目 |
|---|---|---|
| サブスクリプションの読み込みボタンが反応しない | クライアント | 画面のメッセージ、サブスクリプションの取得、設定の解析エラー。 |
| ノードのプロトコルが認識されない | コア | コアのバージョンと、該当プロトコルへの対応状況。 |
| ブラウザーは使えるが、一部のアプリは接続できない | 通信の取り込み | アプリがシステムプロキシに従うか、TUNが必要か。 |
| 接続が誤ったプロキシグループに振り分けられる | 設定とルール | 現在の設定、ルールの順序、プロキシグループの選択結果。 |
Clash for Windowsは別のGUIクライアントで、CFWと略されることがあります。Windows向けClashクライアント全般の総称でも、Clash Verge Revの旧称でもありません。CFWの古い解説にはProfiles、Proxies、Generalなどの画面名が登場することがあります。移行時は機能に対応する画面を探し、記載されたファイルパスやサービスのインストール手順をそのまま流用しないでください。
設定の互換性：YAMLが似ていてもそのまま使えるとは限らない
基本構造が似ていることは、クライアント間の移行が比較的容易な理由の一つです。一般的な設定にはproxies、proxy-groups、rulesなどの項目が含まれます。ただし、新しいプロトコル、ルールの拡張、DNSオプション、クライアント独自の上書き機能などにより差が生じることがあります。また、設定全体を含むサブスクリプションと、ノード一覧だけを返すサブスクリプションは別物です。後者は通常、プロキシグループやルールをクライアント側のテンプレートで補う必要があります。
まずは最小限の動作設定を確認する
以下は設定項目の関係を説明するための抜粋です。ノードやプロキシグループは含まれていないため、既存の完全な設定を置き換える用途には使えません。7890はこの例で指定した混合プロキシポートで、すべてのクライアントの初期値ではありません。実際のポートは、使用中のクライアントの「設定」に表示される待ち受けポートを確認してください。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: infomixed-port：同じポートでHTTPとSOCKSのプロキシ接続を受け付けます。allow-lan: false：LAN内の機器からのプロキシ接続を許可しません。このPCだけで使う場合は、まずこの制限を維持してください。mode: rule：ルールに基づいて接続先を選択します。すべての接続がリモートプロキシを経由するという意味ではありません。log-level: info：通常のログを記録し、設定の読み込みや実行時エラーを確認できるようにします。
元のサブスクリプションと実際に適用される設定を区別する
クライアントはコアの起動前に、ポート、DNS、TUN、ルールの追加内容、スクリプトの処理結果などを統合する場合があります。そのため、サブスクリプションに記載された値と、実行時に使われる値が異なることがあります。問題を調べる際は、クライアントの実行設定や設定プレビューを確認し、ログと照らし合わせてください。ダウンロードした元のYAMLだけを見て判断しないようにしましょう。
制御APIのポートはプロキシポートとは別です。external-controllerは、コアの制御APIが待ち受けるアドレスを指定し、クライアントはこのAPIを通じて状態の取得や切り替えを行います。制御APIを自分で有効にする場合は、127.0.0.1にバインドし、secretを設定してください。画面との接続問題を解決するために、すべてのネットワークインターフェースへ公開するのは避けましょう。サブスクリプションURL、制御キー、ノードの認証情報を公開画像に載せないでください。
Windowsでの選び方：通信の取り込み要件を確認する
一般的なWindowsユーザーは、現在もメンテナンスされ、コアの提供元が明確で、ドキュメントを確認できるGUIクライアントを選びましょう。画面の見た目だけを比べたり、「mihomo内蔵」ならネットワークの問題がすべて自動で解決すると考えたりするのは禁物です。システムプロキシ、TUN、サービスモードは、それぞれ解決する問題が異なります。
- まずシステムプロキシで基本の接続を確認します。設定を読み込み、使えるノードを選び、システムプロキシを有効にして対象サイトにアクセスします。この方法で接続するのは、システムプロキシの設定に従うアプリだけです。
- 次にTUNが必要か判断します。ゲーム、コマンドラインツール、独自にプロキシを管理するプログラムなどは、システムプロキシに従わない場合があります。TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込みますが、対象範囲はルートの除外設定、DNS設定、アプリの動作にも左右されます。
- クライアントの要件に従ってサービスモードをインストールします。サービスモードは、仮想ネットワークアダプターやルートの管理など、より高い権限が必要な操作を支援するために使われます。ノードを提供したり、サブスクリプションの代わりになったりするものではありません。
- ログを確認できる状態にしておきます。コアの起動エラー、DNSエラー、ルールの適用結果を確認できるかチェックしてください。問題を特定できることは、設定項目を増やすことより重要です。
Windows PowerShellでは、次のコマンドで例示したポートがプロセスに使用されているか確認できます。出力の最後の列はプロセスID（PID）です。待ち受けの記録があっても、そのプロセスが現在開いているクライアントだとは限りません。
netstat -ano | findstr ":7890"クライアントが7890以外のポートを使っている場合は、コマンドの数字を設定画面に表示されたポートに置き換えてください。次に「タスク マネージャー」→「詳細」タブを開き、PIDでプロセスを探します。該当するプログラムを通常の方法で終了してから新しいクライアントを起動するほうが、ポートを何度も変更するより原因を特定しやすくなります。
移行チェックリスト：古いクライアントからmihomoクライアントへ
移行の目的は、古いソフトのフォルダーを丸ごとコピーすることではなく、使える設定を復元し、新しいクライアントの通信取り込み動作を確認することです。古いキャッシュ、データベース、サービス登録情報は、通常ほかのクライアントにそのまま移すべきではありません。
- 現在の状態を記録する。サブスクリプションURL、手動で追加したルール、プロキシグループの選択、ローカルポートを控えます。バックアップはローカルに保管し、共有する前に認証情報を削除してください。
- 古い通信の取り込みを停止する。古いクライアントの自動起動、システムプロキシ、TUNを無効にしてから終了します。古いサービスを削除する必要がある場合は、そのクライアントに対応したアンインストール手順を使ってください。
- サブスクリプションを新たに読み込む。新しいクライアントの「設定」画面から読み込み、YAMLの解析エラーや未対応のノードタイプがないことを確認してから有効にします。
- 段階的にテストする。まずシステムプロキシ、次にルールモード、最後にTUNを確認します。ログから変更の影響を追いやすくするため、一度に変更する設定は一つにしてください。
- 終了後のネットワークを確認する。新しいクライアントを終了し、Windowsのプロキシ設定が元に戻っていることと、よく使うアプリが正常に接続できることを確認します。問題があれば、まず残ったプロキシ設定やルートを調べてください。
最後に、3つの関係を押さえておきましょう。Clashは歴史的な起点、mihomoはコアの機能を引き継いで発展させたプロジェクト、Clash Verge Revはその機能を管理するGUIです。クライアントを選ぶときはメンテナンス状況、解説を読むときは画面名、互換性を調べるときはコアのバージョンを確認してください。「ソフトの名前」を、使っているWindows PCで必要な設定に結び付けられます。