mihomo コアと従来版 Clash の違いは?Meta 系列の特徴を総整理

Clash から Clash Meta、そして mihomo へ:コアの進化の歴史

従来版 Clash コアは Dreamacro 氏によって始められ、Go言語で実装され、config.yaml の基本構造、プロキシグループの抽象化、ルールマッチングエンジンを確立しました。これは以降のすべての派生版の出発点となっています。プロトコルの進化(Hysteria2、TUIC、WireGuard などが次々登場)とユーザーによる細かい制御へのニーズの高まりに伴い、コミュニティは従来版をベースに Clash Meta 分岐を立ち上げ、新しいプロトコル、新しいルールタイプ、パフォーマンス最適化を継続的に取り込んでいきました。従来版のリポジトリは2022年以降更新が緩やかになった一方、Clash Meta は活発な保守の下で機能カバー範囲が従来版を逆転し、最終的に mihomo と名称を変え、独立したプロジェクトとして進化を続けています。

現在「mihomo コア」という呼び方は、文脈上ほぼ初期の「Clash Meta コア」と同義です──両者は同じ開発系譜の異なる段階の名称であり、プロトコルのプレフィックスや設定フィールドはおおむね互換性がありますが、パッケージ、バージョン番号、一部のデフォルト動作は世代を経て変化しています。この系譜を理解しておくと、あるクライアントが表示する「コアバージョン」がどの能力セットに対応しているのかを判断しやすくなります。

出站プロトコル対応:mihomo が追加したプロトコルとは

プロトコル対応は両コアの最も直感的な違いです。従来版 Clash コアは Shadowsocks、ShadowsocksR、VMess、Trojan、Snell といった比較的早期に成熟したプロトコルに重点を置き、設定フィールドは比較的固定的で、長期間大きな拡張がありませんでした。mihomo はこれをベースに、近年新たに登場した出站タイプを補完しました。よく見られるものは以下の通りです。

• Hysteria / Hysteria2:QUIC ベースの輻輳制御プロトコルで、通信品質が不安定でパケットロスの多い経路において従来の TCP 系プロトコルより優れた性能を発揮します。
• TUIC:同様に QUIC 上に構築され、低遅延シナリオに特化しており、操作の遅延に敏感な用途に適しています。
• WireGuard:出站プロトコルとして直接接続でき、システムレベルの別途 WireGuard クライアントとの連携が不要になります。
• VLESS / VMess のフロー制御拡張、および ShadowTLS 前置レイヤーで、通信特徴のさらなる秘匿化に利用されます。
• Snell v4 など、プロトコルの新バージョンフィールドへの対応。

つまり、サブスクリプションのノードが上記の比較的新しいプロトコルを使用している場合、mihomo コアだけが正しく解析して接続を確立できます。従来版コアは未知のプロトコルタイプに遭遇すると、通常そのノードをスキップしたりエラーを出したりし、プロキシグループで「ノード数が合わない」という現象が起きます。

ルールセットとGEOデータ:更新メカニズムの違い

ルール分流は GEOIP、GEOSITE データベースとルールセット(rule-provider)を用いて、ドメインやIPの帰属を判定します。従来版コアの GEO データ形式は比較的固定的で、更新頻度はコア自体のリリースサイクルに依存します。mihomo はより柔軟なルールセットのソースと形式に対応しています。

1. rule-set によるリモートルールセットの参照に対応し、behavior(domain / ipcidr / classical)と更新間隔を指定できます。ルール内容がコアバージョンから分離されているため、コアの新バージョンを待たずに最新の分流ルールを取得できます。
2. MRS(mihomo 専用バイナリルール形式)に対応し、従来のテキストルールより読み込みが高速です。特にルール項目が数万件規模になると、起動やマッチングの性能差が顕著に表れます。
3. GEOデータベースのソースをカスタマイズ可能で、コミュニティが管理する GeoIP2/GeoSite データリポジトリを指定でき、コア内蔵の固定バージョンに依存する必要がありません。

一般ユーザーにとって分かりやすい表れは、mihomo コアを搭載したクライアントの「ルールプロバイダー」設定では、通常より豊富な動作オプションと短い更新サイクルが確認できることです。一方、従来版コアをベースとしたクライアントでは、ルール更新はクライアント全体のバージョンリリースに合わせて行われることが多いです。

TUNモードとネットワークスタック:mihomo の基盤改善

TUNモードにより Clash はブラウザなどプロキシ設定に対応したアプリだけでなく、システムレベルの通信全体を引き受けられるようになります。従来版コアの TUN 対応は比較的基本的なもので、システムのルーティングテーブルを手動で設定する必要がありました。mihomo はこの層で多くの改善を行っています。

• 自動ルーティング管理を内蔵し、仮想ネットワークカード作成後に自動でルーティングテーブル項目を書き込み、終了時にクリーンアップすることで、手動設定によるミスの可能性を減らします。
• gVisor ユーザー空間スタックとシステムネイティブスタック(system stack)の切り替えに対応。前者は互換性が高く、後者は一部プラットフォームで性能が優れており、用途に応じて選択できます。
• DNSハイジャックと Fake-IP プールと TUNモードの連携を強化し、DNS解決経路の不整合による接続失敗を減らしています。
• Android、macOS などのプラットフォームにおける仮想ネットワークカードの権限処理を最適化し、システム層で接続が切断される可能性を低減しています。

これが、「グローバル透過プロキシ」「システム全体の通信を引き受ける」といった用途を求める大半のクライアントが、mihomo コアを優先的に選ぶ理由でもあります──TUNモードの安定性は日常的な使用体験に直結します。

RESTful API と設定機能の強化

両コアともHTTPベースの外部制御インターフェース(通常 127.0.0.1:9090 のようなアドレスでリスニング)を提供し、クライアントUIがプロキシ状態の照会、ノード切り替え、ログ確認を行えるようにしています。mihomo はこのAPIをさらに拡張しています。

• グループ単位での遅延照会や、ルールプロバイダー単位での個別更新トリガーなど、設定全体をリロードせずに済む、より細かいインターフェースを追加。
• ScriptルールやLuaによる論理判定など高度なマッチング方式に対応し、ルールファイル内で単純なスクリプトロジックを記述できるようになり、静的ルールの列挙だけに限定されません。
• Providerオーバーライド(override)機能を強化し、サブスクリプション自体を変更せずに、ローカルの上書きルールで一部フィールド(UDPの強制有効化、速度測定URLの変更など)を調整できます。

これらの機能は主に上級ユーザーやクライアント開発者向けで、一般ユーザーがAPIを直接呼び出す必要はありませんが、クライアントUI上の「速度測定方式をカスタマイズ可能」「あるプロキシグループがスクリプトセレクターに対応」といった設定項目は、その裏でコアのAPI拡張によって実現されていることが多いです。

主要クライアントはどのコアを搭載しているか?

クライアントを選ぶ際、コアのバージョンが機能の上限を決めます。以下の表に主要クライアントと対応するコアの状況をまとめましたので、素早く確認する際にご活用ください。

注意点として、同一のクライアントプロジェクトでもバージョンによってコアが移行することがあります。例えば以前は従来版コアに依存していたものが、後に mihomo を内蔵するケースなどです。ダウンロード前にクライアントのリリースノートや設定ページ内の「コアバージョン」フィールドを確認することが、実際の能力を確認する最も確実な方法であり、クライアント名だけを見るより正確です。

どう選ぶべきか?

サブスクリプションのノードが Hysteria2、TUIC、WireGuard といった比較的新しいプロトコルを使用している場合、あるいは安定したグローバルTUNモードやより柔軟なルールセット更新が必要な場合は、mihomo コアを搭載したクライアントを選ぶことがほぼ唯一の合理的な選択です。Shadowsocks、VMess などの定番プロトコルのみを使用し、クライアントのUIや操作感にすでに慣れている場合は、従来版コアのクライアントでも基本的な分流や切り替えのニーズを満たせるため、無理に移行する必要はありません。

両コアともGPL-3.0オープンソースライセンスに従い、設定ファイルの文法は高度に互換性があるため、大半の config.yaml は両者間で直接移行できます。ただし新しいプロトコルや新しいルール文法に関わる部分は、従来版コアが認識できないことがあり、この点はクライアントを切り替える前に確認しておく価値があります。