Clash 無印・Meta・mihomo カーネル比較:機能・プロトコル・設定互換性

一本の進化系譜:Clash から Clash Meta、そして mihomo へ

3つの名前の関係を理解するには、まず時系列を見る必要があります。最初期の Clash(通称「無印」または「Clash Premium」)は個人開発者が長年メンテナンスし、ルールベースの振り分け、ポリシーグループ、Provider サブスクリプションといった基礎アーキテクチャを確立しました。以降のほぼすべてのクライアントの設定文法はこれを原型としています。開発者本人は2023年に更新を停止しコードリポジトリを削除したため、無印カーネルはそこで固定され、新プロトコルや新フィールドへの対応は得られなくなりました。

更新停止後、コミュニティで最も活発だったフォークプロジェクトが Clash Meta(Clash.Meta とも呼ばれる)です。無印のコードをベースにメンテナンスを継続し、無印に長らく欠けていた機能を補いながら、設定文法の高い互換性を保ったため、既存ユーザーはほぼ設定を変えずに移行できました。Clash Meta がしばらく運用された後、プロジェクトは正式に mihomo へ改名されました。名前は変わりましたが、リポジトリ・メンテナンスチーム・技術路線は連続しており、「Clash Meta の続き」であって新規プロジェクトの立ち上げではないと理解できます。

そのため現在も更新が続いている Clash 系クライアント(デスクトップ版、ルーターファームウェアプラグイン、一部の Android クライアント)は、その大半が内部で mihomo カーネルを動かしており、外側に異なるGUIやブランド名をまとっているだけです。この進化系譜を理解しておくと、後述の機能比較も対応づけやすくなります。

プロトコル対応の違い:無印停止時点での機能境界

プロトコル対応は3世代のカーネルで最も分かりやすい違いです。無印カーネルが更新停止時にサポートしていたプロトコルは Shadowsocks、ShadowsocksR、VMess、Trojan、Snell が中心で、当時のほとんどのサブスクリプション用途をカバーしていましたが、更新停止後は増分がありません。Clash Meta が引き継いだ後、VLESS、Hysteria、Hysteria2、TUIC、WireGuard といった比較的新しいプロトコルが順次追加され、mihomo もこの路線を継続しており、新プロトコル特性やハンドシェイクパラメータ対応のスピードは無印の停止前より明らかに速くなっています。

この表を別の角度から見ると:サブスクリプションのノードに VLESS や Hysteria2 プロトコルが含まれている場合、無印カーネルはそのノードを一切解析できず、クライアントはエラーを出すかそのノードをスキップします。これはクライアントを更新したのに「ノードが全部使えなくなった」と気づく人が多い直接的な原因でもあります——サブスクリプションが壊れたのではなく、カーネルがプロトコルに追いついていないのです。

TUN モードとカーネルアーキテクチャ:Meta/mihomo の重要なアップグレード

TUN モード(仮想NICモード)は、ブラウザや指定アプリの通信だけでなく、システム全体の通信をクライアントが引き受けられるかどうかを決めます。無印カーネルにも TUN 対応はありますが実装は比較的基礎的で、プロセス識別能力に限界があり、アプリ単位での振り分け(例えば特定のゲームだけプロキシを通し、他のアプリは直接接続させる)が必要な場面では力不足になることが多々ありました。

Clash Meta は TUN モードを体系的に書き直し、より完全なプロセスマッチング機構を導入しました。プロセス名、パス、さらにはパッケージ名で通信をフィルタリングでき、ルール内の process-name、process-path フィールドと組み合わせて精細な振り分けを実現できます。mihomo はこの基盤の上でパフォーマンスと互換性の最適化を続けており、特に Windows と macOS での TUN の安定性、システムファイアウォールとの連携、IPv6 通信の引き受けなどの点で無印よりかなり成熟しています。

もう一つ見落とされがちなアーキテクチャの違いは、マルチコア並列処理とメモリ使用量の最適化です。mihomo は長時間稼働・ノード数が多いシナリオでのメモリ増加曲線が無印より安定しており、これは24時間365日稼働させるルーターやNAS環境では特に重要です。バックグラウンドで長期常駐し、時々ポリシーグループを切り替えるような使い方であれば、新カーネルを選ぶ方が安定性の面で有利です。

設定ファイルのフィールド互換性:直接移行できるフィールドはどれか

良いニュースとして、3世代のカーネルの設定ファイル文法は高度に同系統で、基礎構造に断絶的な変化はありません。port、socks-port、mode、proxies、proxy-groups、rules といった基礎フィールドは無印・Meta・mihomo で書き方が完全に一致しており、無印用に書かれた設定を mihomo に持っていけば、そのままロードできて正常に動作する可能性が高いです。

違いは主に新規フィールドと新プロトコル専用パラメータに現れます。実例をいくつか挙げます:

• tun セクション内の stack(gVisor か System ネットワークスタックを選択)、auto-route、dns-hijack などのサブフィールドは、無印には対応する実装がないため、無印の設定に書いても無視されるかエラーになります。
• proxies リスト内の type: vless、type: hysteria2 といったノード宣言は、無印カーネルが type フィールドのこれらの値を認識できないため、ロード時にそのノードをスキップするか全体エラーになります。
• dns セクションの enhanced-mode: fake-ip は両世代とも対応していますが、mihomo は fake-ip-filter のマッチングルールを細分化しているため、一部の書き方は無印での効果と差異が出ます。
• ルールセット(rule-provider)の behavior フィールドの取り得る値は新カーネルでより多くの種類に対応していますが、無印は基礎的な domain、ipcidr、classical の3種のみと互換です。

実践的な提案としては:無印から mihomo に移行する際は設定ファイルを基本的にそのまま持っていけて、tun セクションと新プロトコルノードを追記するだけで済みます。逆に mihomo の設定を無印カーネルにダウングレードして使う場合は、新プロトコルノードと tun の上級フィールドを先に削除しないと、設定全体のロードが失敗します。

どう選ぶか:シナリオ別の選定アドバイス

上記のプロトコル対応・TUN機能・設定互換性の違いを踏まえ、実用的な選定基準をいくつか示します:

1. サブスクリプションのノードに VLESS、Hysteria2、TUIC などの新プロトコルが含まれる場合:mihomo カーネルを選ぶ必要があります。無印カーネルはこれらのノードを解析できず、「なんとか使える」余地はありません。
2. アプリ単位でグローバルプロキシを制御したい場合(ゲームはプロキシ経由、他は直接接続など):完全なプロセス単位の TUN に対応した mihomo を選んでください。無印のプロセスマッチング能力は限られており、ルールを書いても効かない場合があります。
3. 長期的にルーターや NAS 上で常駐稼働させる場合:mihomo を優先してください。メモリと並列処理のパフォーマンスがより安定しており、長時間稼働時の信頼性が高くなります。
4. 最も基礎的な Shadowsocks/VMess ノードだけを使い、設定を何年も変えていない場合:両世代とも動作しますが、無印は更新が停止しているため、長期的には継続メンテナンスされている mihomo への移行を推奨します。今後サブスクリプションのプロトコルが更新された際に非互換になるのを避けられます。
5. 他人から受け取った古い設定ファイルの互換性がわからない場合:まずテキストエディタで設定内に vless、hysteria、tuic というキーワードや tun: セクションがあるか検索してください。あれば新カーネル向けに書かれた設定であることを示します。

現在主流の Clash 系クライアントは、画面上の名称にかかわらず、そのほとんどが内部で mihomo カーネルに切り替えられています。これは本サイトのダウンロードページでも既定で推奨しているカーネル路線です。カーネルを選ぶことは本質的にプロトコルのカバー範囲と長期メンテナンスの保証を選ぶことであり、新カーネルはこの両点で優位にあります。無印はもはや歴史的な参照対象としての位置づけです。