Clash 無印版・Meta・mihomo コアの違いを比較：プロトコル対応と選び方
名前は似ていても実力差が大きい3種のコア。本記事ではプロトコル対応、ルール文法、TUN実装、メンテナンス状況の4つの観点から徹底比較し、クライアント・利用シーン別のコア選定結論を提示します。
クライアントをダウンロードすると、設定画面に「コアバージョン」や「コアの種類」という項目があり、選択肢は通常 Clash Premium、Clash Meta、mihomo のいずれかで、更新が止まった無印版 Clash が表示されることもあります。これらの名前は単なるバージョン番号の違いに見えますが、実際には完全に異なるコードブランチであり、機能セット、対応プロトコルの範囲、更新頻度がすべて異なります。コアを間違えると、あるルール文法の解析に失敗したり、特定のプロトコルノードに接続できなかったり、TUNモード起動後にシステムのトラフィックが正しく引き込まれない、といった問題が直接発生します。この記事では4つの軸を整理し、現在のクライアントがどのコアを使っているか、手動で切り替えるべきかを判断できるようにします。
コアの系譜：1つのプロジェクトから分かれた3つのブランチ
差異を理解するには、まず歴史的な経緯を整理する必要があります。最初期の Clash は Dreamacro 氏が Go 言語で開発したもので、長らく事実上の標準とされ、ルールエンジンが簡潔で低リソース消費でしたが、作者は2023年に公開メンテナンスを停止し、リポジトリはアーカイブされて以降新しいプロトコルのサポートがマージされなくなりました。これが通常「無印版 Clash」または Clash Premium（初期には有料コアの Premium ブランチが存在し、ルール速度測定などの拡張機能を提供していましたが、基盤となるプロトコル集合はオープンソース版とほぼ同じでした）と呼ばれるものです。
無印版の更新停止後、コミュニティはそれを基に Clash.Meta ブランチを立ち上げ、無印版に長らく欠けていたプロトコルや機能を追加しました。例えば TUNモードの完全な実装、Hysteria、TUIC、WireGuard アウトバウンドなどです。このブランチは後に正式に mihomo と改名され、現在最も活発にメンテナンスされ更新頻度も最も高いコアとなっています。主流のクライアント（Clash Verge Rev、FlClash、Clash Meta for Android など）の多くはデフォルトで mihomo を内蔵していますが、クライアントのUI上では慣習的に「Meta コア」と表記されることが多く、Meta と mihomo が別物だと誤解されがちです。実際には mihomo は Clash.Meta が改名して続いたバージョンであり、両者は同一ブランチの異なる段階に過ぎません。
ヒント：クライアントの設定画面に「Meta コア」と表記されていて、バージョン番号が v1.18.x 以上であれば、実際に動いているのは mihomo であり、名称だけが旧称を引き継いでいると考えてほぼ間違いありません。
プロトコル対応比較：差は新しいプロトコルに集中
3つとも Shadowsocks、VMess、Trojan といった「定番三種」のプロトコルでは実質的な差はなく、いずれも正常に解析・接続できます。差が出るのは主に近年登場した新しいプロトコルや伝送方式です。
| プロトコル／機能 | 無印版 Clash | Clash Meta | mihomo |
|---|---|---|---|
| Shadowsocks / VMess / Trojan | 対応 | 対応 | 対応 |
| Hysteria / Hysteria2 | 非対応 | 対応 | 対応 |
| TUIC | 非対応 | 対応 | 対応（v5含む） |
| WireGuard アウトバウンド | 非対応 | 一部対応 | 対応 |
| VLESS + XTLS/Vision | 非対応 | 一部バージョンで対応 | 対応 |
| ShadowTLS | 非対応 | 対応 | 対応 |
| TUN 完全引き込み | 制限あり | 対応 | 対応・継続改善中 |
2021年以降に登場したプロトコルは、無印版 Clash がほぼすべて未対応であることが分かります。これが淘汰されていった直接の理由です。過渡期のブランチである Clash Meta は多くの新プロトコルをカバーしていますが、実装が初期バージョンのままの部分もあり、プロトコル規格の更新（例えば TUIC が v4 から v5 に上がった場合）に遅れが出ることがあります。現在活発なブランチである mihomo は新プロトコルへの追従が最も速く、通常はプロトコル標準が発表されてから1〜2回のマイナーバージョン更新以内にサポートがマージされます。
サブスクリプションのノード解析失敗の主な原因
サブスクリプションに Hysteria2 や TUIC のノードが含まれていて、インポート後に「不明なプロトコル」と表示されたり、無条件で除外されたりする場合、多くはクライアントに内蔵されているのがまだ無印版 Clash コアであるためです。この場合クライアントを再ダウンロードする必要はなく、設定に「コア切り替え」の項目があるか確認し、Meta または mihomo コアに切り替えてからサブスクリプションを再インポートすれば通常は解決します。
ルール文法の違い：Meta 系で追加されたマッチタイプ
ルールセット（Rule Provider）とルール文法において、mihomo/Meta は無印版に比べて無印版が認識できないマッチルールをいくつか追加しています。これらを無印版コアの設定ファイルに直接記述すると、起動失敗やルールが静かに無視される事態を招きます。
- RULE-SET：外部ルールセットファイルを参照する記法。無印版の初期バージョンは差分更新に対応したルールセット形式をサポートしていません。
- GEOSITE / GEOIP（mmdb/dat データベースと連携）：ドメイン名やIPの所属地域でまとめて分類する仕組み。無印版は新形式のデータベースとの互換性が低い。
- SCRIPT：簡易的なスクリプトロジックで振り分け判定を行える機能。Meta/mihomo のみ対応。
- SUB-RULE：サブルールセットの入れ子参照。mihomo の後期バージョンで追加され、大規模なルールファイルを簡潔にするために使われる。
- process-name / process-path のプロセス単位マッチ：リクエスト元のアプリプロセスに基づいて振り分けを行う機能で、TUNモードによるプロセス情報の取得に依存する。無印版にはこの機能がない。
rules:
- RULE-SET,private,DIRECT
- RULE-SET,reject,REJECT
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY上記のよく見られるルール断片では、RULE-SET と GEOSITE はいずれもコアに対応する解析能力を要求します。このような設定ファイルを無印版文法しか対応していないクライアントに読み込ませると、ログには通常「unsupported rule type」と表示されるか、ルール全体が反映されずデフォルトのポリシーグループにフォールバックします。結果として、分流ルールを設定したはずなのにすべてのトラフィックが同じ経路を通ってしまう、という現象になります。
TUNモードの実装：引き込みの完全性が使用体験を左右する
TUNモードとは、コアがシステム層に仮想ネットワークカードを作成し、デバイス上のすべてのアプリのトラフィックを強制的にプロキシ処理フローへ引き込む仕組みで、個々のアプリが個別にプロキシアドレスを設定する必要がなくなります。これは3種のコアの差が最も分かりやすく現れる部分です。
- 無印版 Clash：TUN対応はプロジェクトの後期に追加されたもので実装が基本的であり、IPv6やDNSハイジャックの処理が不完全なため、実際の利用では一部アプリがプロキシを回避してしまうことがよくあります。
- Clash Meta：TUN実装を書き直し、ルーティングテーブルの自動設定、DNSハイジャック、プロセス単位のフィルタリングに対応し、UWPアプリやシステムサービスなど無印版では処理できなかったトラフィックの種類までカバーしました。
- mihomo：Meta を基盤としてさらに改良を重ね、Android の VpnService 統合、iOS の NetworkExtension 対応をそれぞれ最適化し、システムバージョンのアップグレードに伴うTUN互換性の問題も多数修正しています。
Android ユーザーにとって、この点は特に重要です。Clash for Android 系クライアントが全体トラフィックを安定して引き込めるか、DNSリクエストの向き先を正しく処理できるかは、内蔵されているのが mihomo コアかどうかに大きく依存します。一部のアプリ（特にネットワーク分離機能を持つシステムレベルのアプリ）が常にプロキシを回避してしまう場合は、まずクライアントのコアバージョンを確認し、その後個別アプリのネットワーク設定を調べてください。
メンテナンス状況と更新頻度：長期的な使いやすさを左右する
プロトコルや文法レベルの静的な比較は現状しか反映しません。実際に選ぶ際にはメンテナンスの活発さこそ重視すべきです。プロキシプロトコル自体が絶えず進化しているため、コアの更新が止まればすぐにサーバー側のプロトコルバージョンに追いつけなくなります。
| 観点 | 無印版 Clash | Clash Meta | mihomo |
|---|---|---|---|
| リポジトリの状態 | アーカイブ済み、更新停止 | mihomo に統合され、独立ブランチとしての進行は停止 | 活発にメンテナンス中 |
| リリースペース | なし | 過去の遺物 | 数週間ごとにマイナーバージョン |
| セキュリティ修正 | 提供なし | 提供なし | 継続的に対応 |
| 新プロトコルのマージ速度 | 該当なし | 該当なし | 比較的速い |
簡単に言えば、「Clash Meta」という名称は現在では歴史的経緯による呼称に過ぎず、実際のコード進化はすべて mihomo リポジトリに移っています。「Clash Meta」というブランチ名を引き続き掲げているクライアントも、本質的には mihomo のビルド成果物を使っているだけで、命名が更新されていないだけです。本当の意味でまだ無印版 Clash コアを使い、一度もアップグレードしていないクライアントは既にかなり少なく、遭遇した場合はルール文法もプロトコル対応も明らかに立ち遅れています。
シーン別のコア選定の考え方
上記4つの観点を踏まえ、代表的なシーンごとの判断基準を示します。
- 日常利用、比較的新しいサブスクリプションノード：mihomo コアを内蔵したクライアントを優先しましょう。新プロトコルへの互換性とTUNの安定性がより保証され、問題が起きてもコミュニティによる修正が早く得られます。
- 複雑な分流ルールや大規模ルールセットに依存：クライアントが RULE-SET と SUB-RULE 文法に対応しているか確認しましょう。この種のシーンでは無印版コアはほぼ選択肢から外れます。
- 完全に静的な設定で長期間ノードを変更しない：サブスクリプションが Shadowsocks/VMess といった基本的なプロトコルのみを使い、TUNによる全体引き込みが不要な場合は、クライアントが「Meta コア」と表記されていても通常は十分であり、頻繁に切り替える必要はありません。
- Android デバイスで全体プロキシとアプリ別ルールが必要：クライアントのTUN実装が mihomo をベースにしているか必ず確認してください。そうでなければプロセス単位の振り分けや一部システムアプリのトラフィック引き込みが不完全になります。
現在使っているクライアントがどのコアを使っているかを判断する最も直接的な方法は、設定画面の「アプリ情報」や「コア情報」欄を確認することです。通常 mihomo v1.18.x のようなバージョン文字列が表示されます。出典が示されていないバージョン番号だけしか表示されない場合は、設定ファイルに新しい文法のルール（例えば RULE-SET）を1行追加してエラーが出るかどうかをテストする、という間接的な検証方法もあります。
注意：コアを切り替えた後は既存の設定ファイルを一度検証し直すことをおすすめします。一部のポリシーグループの記法（アウトバウンドグループの type フィールドの値など）はコア間で細かな差異があり、旧設定をそのまま流用すると解析エラーが起きる可能性がわずかにあります。
コア関連の問題を切り分ける簡易手順
「ルールが効かない」「プロトコルに接続できない」「TUN起動後に一部アプリがネットワークにアクセスできない」といった問題が起きた場合、以下の順序で確認すると、数分でコアの不一致が原因かどうかを特定できることが多いです。
- クライアントのログを確認し、unsupported、unknown rule type、protocol not supported といったキーワードが出ていないか検索する。
- 設定画面で現在のコアのバージョン番号と出典を確認し、無印版 Clash か古すぎる Meta ブランチではないか判断する。
- クライアントにコア切り替えオプションがあれば、mihomo ブランチに切り替えて設定ファイルを再読み込みする。
- それでもルールやプロトコルに問題があれば、設定ファイル内の対応フィールドの記法が現在のコアバージョンのドキュメントと一致しているか確認する。特にルールセットの形式（YAML／テキスト）やフィールド名の変更に注意する。
総合的に見ると、3種のコアは並列の選択肢ではなく、技術進化の1本の系譜です。無印版 Clash は出発点でありながら既に前進を止め、Clash Meta は過渡期であり、mihomo が現在の続きであり終着点です。明確な互換性上の理由（例えば一部の古い設定ファイルが厳密に無印版の挙動に依存している場合）がない限り、日常利用で古いコアにこだわる必要はなく、mihomo を内蔵したクライアントを選ぶことでプロトコルや文法の非互換に起因する切り分け作業の大半を省くことができます。