Clash無印版・Meta・mihomoの関係とは？カーネルの違いと選び方

クライアント・カーネル・設定ファイルをまず区別する

Clashのバージョンを語るとき、混同しやすいのが「クライアント」と「カーネル」です。デスクトップに表示されるウィンドウやトレイメニュー、サブスクリプションボタンはグラフィカルクライアントにあたります。プロキシ接続の確立、ルール照合、DNS処理、トラフィックの取り込みを担う実行プログラムがカーネルです。Clash Verge RevやMihomo Partyなどは通常クライアント名であり、Clash、Clash.Meta、mihomoはクライアント内部から呼び出されるカーネルを指します。

設定ファイルは第三の要素です。一般的なYAMLファイルには、リッスンポート、プロキシノード、プロキシグループ、ルール、DNS設定が含まれます。クライアントが設定をダウンロード・編集してカーネルへ渡し、カーネルが各フィールドを読み込んで動作します。そのため、同じサブスクリプションを似た画面の2つのクライアントに読み込んでも、結果が異なる場合があります。一方が無印版Clash、もう一方がmihomoを使っていれば、認識できるプロトコルやフィールドは完全には一致しません。

グラフィカルクライアント: サブスクリプション管理、システムプロキシの切り替え、ノード選択、ログ確認、カーネル更新などの画面を提供します。

プロキシカーネル: YAML設定を解析し、接続を確立して、ルール照合、DNS解決、TUNトラフィック処理を実行します。

サブスクリプション変換: サーバーから提供されたノード情報を、特定のカーネルが読み込める設定形式に整えます。カーネルの機能を新たに追加するものではありません。

ルールセット: ドメイン、IP、プロセス、ネットワーク条件に基づき、リクエストをプロキシグループ、ダイレクト接続、拒否のいずれに振り分けるかを決めます。

Clash無印版・Clash.Meta・mihomoの関係

Clash無印版：ルールベースプロキシの出発点

一般に「Clash無印版」と呼ばれるのは、Dreamacroが開発していたClashプロジェクトです。現在も使われている設定構造を確立しており、proxies、proxy-groups、rules、proxy-providers、rule-providersなどが含まれます。標準例でよく使われるHTTPプロキシポートは7890、外部コントロール用インターフェースは9090で、これらの慣例は後続の多くのクライアントにも引き継がれています。

無印版プロジェクトは2023年11月に公開メンテナンスを終了し、その後関連コードリポジトリはアーカイブされました。末期によく見られたバージョン表記はv1.18.0です。開発終了後も既存のインストールが直ちに使えなくなるわけではありません。旧来のプロトコル、基本的なドメインルール、通常のシステムプロキシは動作し続ける可能性がありますが、新しいプロトコルやルールフィールド、今後のOSのネットワーク変更には対応しません。

過去にはClash Premiumも存在しました。無印版をベースに、強化されたルールやTUN関連機能などを提供していましたが、現在のmihomoの旧称ではありません。古い記事に「Premiumカーネル」と書かれている場合は、特定の歴史的な派生版として理解し、現在のmihomoと直接同一視しないでください。

Clash.Meta：Clash設定を拡張したコミュニティカーネル

Clash.Metaは、Clashの設定体系を基盤にコミュニティが継続的に拡張してきたカーネルです。無印版のフィールドを数多く維持しているため、既存のルールやプロキシグループを大きく変更せず移行できます。同時に、より多くのプロキシプロトコル、ルールタイプ、DNS制御、TUN機能が追加されています。ユーザーにとって「Meta設定」とは通常、無印版には定義されていない拡張フィールドを設定内で使用していることを意味します。

ここでいう互換性は、「mihomoが無印版の設定の大部分を読み込める」という意味に近く、双方向の完全互換ではありません。DOMAIN-SUFFIX、IP-CIDR、GEOIP、MATCHなどの基本ルールだけを使う場合、差は小さくなります。一方、VLESS、Hysteria2、TUIC、GEOSITE、mihomo固有のインバウンドフィールドを使う設定では、無印版カーネルがエラーを出したり、設定を無視したりする可能性があります。

mihomo：Clash.Meta改名後の継続名称

mihomoはClash.Metaの後に登場した別の未知のカーネルではなく、Clash.Metaプロジェクトが改名後に採用した名称です。旧バージョンのクライアント、サブスクリプション変換ツール、過去の記事ではClash.Metaと表示されることがあります。新しい配布パッケージ、ログ、設定ドキュメントでは通常mihomoが使われます。「Metaカーネル」と「mihomoカーネル」を見かけたら、まずは同じコミュニティプロジェクトの時期による呼び方の違いと理解してください。二者択一の別製品ではありません。

プロトコル・ルール・DNS・TUNの機能差

カーネルは「Webページを開けるか」だけで選べません。プロトコル対応はノード接続の可否を、ルール機能はトラフィックを正確に振り分けられるかを左右します。DNSとTUNは、アプリのカバー範囲やドメイン解決の経路にも影響します。ここでは実際の設定を前提に違いを整理します。

比較項目	Clash無印版	mihomo
メンテナンス状況	元プロジェクトはアーカイブ済みで、末期の代表的なバージョンはv1.18.0	コミュニティによる継続的なメンテナンスがあり、クライアントは通常安定版に追従して更新できます
基本プロトコル	Shadowsocks、VMess、Trojan、HTTP、SOCKS5などの一般的なタイプに対応	複数の基本タイプに対応し、VLESS、TUIC、Hysteria2などの設定を拡張
ルールタイプ	ドメイン、IP、ポート、プロセス名、ルールセット、MATCHなどの基本的な照合に対応	GEOSITE、IP-ASN、ネットワーク種別、インバウンド種別など、より細かな条件を追加
DNS	nameserver、fallback、fake-ipなど一般的な仕組みを搭載	nameserver-policy、ルール連携、より詳細な名前解決制御を拡張
TUN	古い派生版では機能に差があり、過去の記事ではPremiumを前提にしていることが多い	継続的に保守されるTUN実装を提供し、DNSハイジャックやルーティングの自動設定と組み合わせられる
新しい設定への対応	拡張フィールドがあると起動できない場合がある	現在のサブスクリプションや継続的に更新されるルールテンプレートに適している

プロトコル対応：ノード名が同じでも形式が同じとは限らない

Shadowsocks、VMess、Trojanなどは無印版とmihomoの双方で広く使われていますが、暗号方式、トランスポート層のパラメータ、拡張オプションは設定フィールドを確認する必要があります。VLESS、Reality、Hysteria2、TUICなど比較的新しいノード形式は、通常mihomoで処理するのが適切です。サブスクリプションの読み込み後にノード数が大幅に減ったり、ログにunsupported proxy typeと表示されたりする場合は、まずカーネルが古すぎないか確認してください。

サブスクリプション変換で変更できるのはテキスト構造だけです。たとえばノードをYAMLのproxiesリストに整理することはできますが、無印版カーネルが突然Hysteria2を理解できるようにはなりません。ノードタイプがカーネルの能力を超えている場合は、そのプロトコルに対応したカーネルまたはクライアントへ変更するのが正しい対処です。サブスクリプションURLを何度も編集しても解決しません。

ルール機能：基本ルールは共通、拡張ルールはカーネル次第

無印版Clashでも、一般的なドメインやIPの振り分けは十分に行えます。次のような記述は基本的なルールの典型です。ドメインサフィックスをプロキシグループへ送り、ローカルネットワークのアドレスは直接接続、それ以外のリクエストは最終ポリシーへ渡します。

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

mihomoはその上で、より細かな照合条件に対応します。たとえばGEOSITEはドメイン分類データを参照でき、IP-ASNは自律システム番号で照合でき、NETWORKはTCPとUDPを区別し、IN-TYPEはインバウンド種別に応じてトラフィックを処理できます。複雑な振り分けに適した機能ですが、無印版カーネルに戻した場合の動作は保証されません。

rules:
  - GEOSITE,category-ads-all,REJECT
  - NETWORK,udp,UDP-Proxy
  - IP-ASN,13335,Proxy,no-resolve
  - MATCH,Final

ルールは上から順に照合され、ヒットすると判定を終了します。どのカーネルを使う場合でも、具体的なルールを汎用的なルールより前に置き、MATCHは末尾に配置してください。そうしないと、高度なルールに対応しているカーネルでも、前の広範な条件に先に一致して実行されないことがあります。

DNS：サーバーアドレスだけでなく解決経路を確認

無印版Clashはnameserver、fallback、fallback-filter、enhanced-modeなどの主要設定に対応しています。mihomoはこれらのフィールドを引き継ぎ、より細かなドメインポリシーやルール連携も提供します。移行時は、fake-ipとredir-hostのモード、リッスンアドレス、IPv6の切り替え、TUN使用時のDNSハイジャック設定を特に確認してください。

一般的な混合プロキシのリッスンポートは7890で、DNSのリッスン例には0.0.0.0:1053が使われることがあります。ポートは固定規格ではないため、最終的には設定ファイルとクライアント画面を確認してください。端末上ですでに7890、9090、1053を別のプログラムが使用している場合、カーネルログには通常address already in useと表示されます。その場合は競合するポートを変更し、サブスクリプションの問題と決めつけないでください。

TUN：より多くのアプリを取り込めるかを左右する機能

システムプロキシが対象にできるのは、主にプロキシ設定を自動で読み取るアプリです。一部のゲーム、コマンドラインプログラム、UDPトラフィックはこれを回避することがあります。TUNモードは仮想ネットワークインターフェースを通じて、より広い範囲のシステムトラフィックを取り込みます。そのため、カーネルのネットワークスタック、ルーティング設定、DNS連携への依存度が高くなります。現在TUNを使う場合は、mihomoがより一般的な選択肢です。

有効化の手順はクライアントによって異なります。一般的な入口は「設定」→「ネットワーク設定」→「TUNモード」、またはメイン画面の「サービスモード」や「TUN」スイッチです。Windowsでは初回の有効化に管理者権限が必要になることが多く、macOSではネットワーク拡張の許可を求められる場合があります。Linuxでは適切なCAP_NET_ADMIN権限、または適切なサービス方式での実行が必要です。有効化後は、ブラウザーのページを1つ確認するだけでなく、LANアクセス、DNS解決、スリープ復帰も同時に確認してください。

古い設定をmihomoへ移行するときの確認事項

無印版からmihomoへの移行は、通常その逆方向よりスムーズです。ただし「起動できる」ことは第一段階にすぎません。サブスクリプション提供元、クライアント、ローカルオーバーライドが設定を書き換える可能性があるため、決めた順番で確認するのがおすすめです。

まず実際のカーネルを確認します。 クライアントで「設定」→「カーネル」または「設定」→「バージョン情報」を開き、名称、バージョン番号、アーキテクチャを記録します。コマンドライン環境ではmihomo -vを実行できます。古い無印版の実行ファイルでは通常clash -vを使います。
元の設定をバックアップします。 YAML、ルールセットのURL、ローカルオーバーライド、自作のプロキシグループを保存してください。サブスクリプションURLだけでは、ローカルで追加したルールが含まれていない場合があります。
まず構文をテストします。 mihomoではmihomo -t -f config.yamlを使って設定を確認できます。テストに通るのは構造を読み込めることを示すだけで、すべてのリモートルールセットやプロキシノードへの接続を保証するものではありません。
プロキシグループの参照を確認します。 各ルール末尾のポリシー名はproxy-groupsに存在していなければなりません。たとえばルールにProxyと書かれているのに、設定には「ノード選択」しかない場合、カーネルはポリシーが見つからないと報告します。
外部リソースを確認します。 proxy-providers、rule-providers、GEOIP、GEOSITEのデータはダウンロードされ、キャッシュディレクトリへ書き込めなければなりません。更新に失敗したら「設定」→「ログ」を開き、HTTPステータスコード、タイムアウト、ファイル権限を確認してください。
最後にTUNを有効にします。 まずシステムプロキシで7890のリッスン、ノード接続、ルール振り分けを確認してからTUNを有効にします。これにより、ノードの問題とシステムルーティングの問題を切り分けられます。

基本設定で高い互換性を保つ方法

複数のデバイスで設定を共有する場合は、共通部分を基本フィールドに限定し、mihomoの拡張機能は別のオーバーライドに分けると管理しやすくなります。次の骨格は、混合ポート7890、ローカルコントロールインターフェース127.0.0.1:9090、ルールモードを使っており、構造を確認する出発点として利用できます。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

この例には実際のプロキシノードがないため、Proxyグループには一時的にDIRECTだけが含まれています。実際に使う場合は、サブスクリプションまたはローカル設定からノードを追加してください。Web上の設定にあるコントロールインターフェースを0.0.0.0:9090へ直接変更しないでください。LANからの操作が本当に必要な場合は、アクセスキーを設定し、ファイアウォールの範囲も制限してください。

2026年にクライアントをインストールするなら、どのカーネルを選ぶべきか

新規インストールでは、メンテナンスが続いており、mihomoを明確に採用しているクライアントを優先してください。名称が新しいからではなく、現在のノードプロトコル、ルールデータ、DNSの挙動、OSのネットワーク変更に対応し続けられるためです。サブスクリプションにVLESS、Reality、Hysteria2、TUICが含まれる場合や、TUN、GEOSITE、IP-ASNを使う予定がある場合は、mihomoのほうが設定の想定に合っています。

mihomoをそのまま選ぶのが適しているケース

Clash系クライアントを初めてインストールし、今後のカーネル修正や機能更新を通常どおり受けたい。
サブスクリプションにVLESS、Reality、Hysteria2、TUICのノードが含まれている。
ゲーム、コマンドラインツール、UDP、システムプロキシを読み取らないアプリをTUNで取り込みたい。
ルールでGEOSITE、IP-ASN、NETWORK、IN-TYPEなどの拡張条件を使っている。
ドメインごとに異なるDNS上流を設定したい、またはより細かなfake-ip除外ポリシーを使いたい。

それでも無印版を残すことが考えられるケース

隔離された環境で既存設定が安定しており、基本プロトコルと基本ルールだけを使っている。
特定の古いクライアントや自動化スクリプトが無印版のコマンド引数に固定依存しており、移行前に互換性テストが必要である。
短期的に過去の問題を再現する必要があり、当時と同じカーネルと設定の挙動を維持したい。

こうした場合は、新しいデバイスの標準として無印版を選ぶのではなく、「一時的に残し、移行を計画する」のが適切です。古い環境では少なくともクライアントのバージョン、カーネルのバージョン、設定の入手元、使用中のポートを記録し、再インストール後に復元できるようにしてください。

クライアント選びで確認したい6項目

カーネル名とバージョン：mihomoと明記され、「設定」→「カーネル」で現在のバージョンを確認できること。
設定管理：サブスクリプションの原文、ローカルオーバーライド、実行時設定を区別でき、更新で手動変更が上書きされないこと。
ログ画面：少なくともinfo、warning、errorの各レベルを提供し、ノード、DNS、ルールセット、ポートのエラーを確認できること。
TUN管理：単なるスイッチではなく、サービス状態、必要な権限、失敗理由を表示できること。
プラットフォームのアーキテクチャ：Windowsではx64とARM64、macOSではApple SiliconとIntelを区別し、Linuxではamd64、arm64、インストール方式を確認できること。
更新範囲：クライアント、カーネル、GEOデータ、サブスクリプションの更新状況をそれぞれ確認でき、どの層に変化があったか特定しやすいこと。

よくある誤解とトラブルシューティングの結論

「設定を読み込める」ことは「すべてのフィールドが有効になる」ことではない

YAMLの構文が正しいということは、インデントと構造を解析できるという意味にすぎません。クライアントによっては読み込み時に未知のフィールドを削除したり、ローカルオーバーライドでサブスクリプションの内容を置き換えたりします。機能が有効かどうかは、実行時設定とカーネルログで確認してください。たとえばGEOSITEを記述したのにルールのヒット記録がない場合は、ルールデータが読み込まれているか、ルールの順序が正しいか、実際のカーネルがそのタイプに対応しているかを確認します。

「Meta」と「mihomo」は並行してアップグレードされる2本の系統ではない

現在の文脈では、mihomoはClash.Metaが改名後に使用しているプロジェクト名です。ダウンロード時に、いわゆる「Meta版とmihomo版の性能比較」を探す必要はありません。確認すべきなのは、リリース日、バージョン番号、プロセッサアーキテクチャ、そしてクライアントが何年も更新されていないカーネルファイルを呼び出していないかどうかです。

バージョンが新しくても、まず設定をテストする

継続的にメンテナンスされるカーネルは問題を修正する一方、デフォルト動作の変更、フィールドの廃止、設定検証の厳格化が行われることもあります。アップグレード前に設定をエクスポートし、アップグレード後はサブスクリプション更新、プロキシグループ、DNS、システムプロキシ、TUNの順にテストしてください。企業ネットワーク、学校ネットワーク、ローカルDNSを使う環境では、イントラネットのドメインやLANのアドレス範囲が引き続き直接接続されるかを特に確認しましょう。

最終的な選び方は一言でまとめられる

新しいデバイスと新しい設定ではmihomoを優先し、古い無印版環境に業務上の依存がある場合は、バージョンを記録して段階的に移行してください。Clash.Metaとmihomoは主に改名前後の名称の関係です。クライアント名は外側の器にすぎず、プロトコル、ルール、DNS、TUNの能力を決めるのは実際に動作しているカーネルです。