Clash 無印版・Meta・mihomoのカーネルの違い：機能範囲とクライアントの選び方

Clash クライアントが現在の環境に適しているかを判断する際、ソフトウェア名や画面のスクリーンショットだけを見てはいけません。実際に接続の取り込み、ルール判定、DNS 処理、プロキシプロトコルの解析を担うのはカーネルです。デスクトップクライアントは通常、設定、トレイメニュー、システムプロキシの切り替え、ログ確認の画面にすぎません。設定項目を認識できるか、TUN がどう動作するか、新しいプロトコルで接続できるかは、カーネルのバージョンによって決まります。

「Clash 無印版」「Clash.Meta」「mihomo」はよく並べて語られますが、3つが継続的に同期開発され、同等の機能を持つ製品というわけではありません。Clash 無印版は設定モデルとルール体系の重要な源流であり、Clash.Meta は後続の拡張ブランチがかつて使用していた名称です。mihomo は、その拡張ブランチが改名された現在のプロジェクト名です。多くのクライアント、設定ディレクトリ、サブスクリプション変換テンプレートには今も Meta の表記が残っているため、画面上の名称と実際に動作するカーネルが一致しない場合があります。

プロジェクトの関係：Clash 無印版、Meta、mihomo は3本の平行な製品ラインではない

Clash 無印版が汎用設定モデルを築いた

一般に Clash 無印版と呼ばれるものは、Dreamacro が保守していた Go 製のルールベースプロキシカーネルと、その設定体系を指します。プロキシノード、プロキシグループ、ルール、DNS、受信ポート、外部コントローラーといった中核概念を確立しました。多くのクライアントやサブスクリプションサービスがこれらの項目を引き継いでいるため、現在は別の互換カーネルを使っていても、設定ファイルは広く Clash 設定と呼ばれています。

無印版のオープンソースプロジェクトは現在アーカイブされており、継続的な機能開発は行われていません。過去には機能範囲の異なる Premium ビルドも存在し、古い文書ではオープンソース版、Premium 版、GUI クライアントが混同して説明されていることがあります。古い解説を読むときは、どのビルドを指しているのかを確認してください。特に、旧 Premium 版の動作をすべての無印版カーネルが備えている能力として扱わないことが重要です。

Clash.Meta は拡張ブランチの旧名称

Clash.Meta は Clash の主要な設定構造を引き継ぎながら、プロキシプロトコル、ルール機能、DNS、TUN、トラフィック嗅探、実行制御などを継続的に拡張しました。一般的な Clash 設定を低コストで移行できるようにしつつ、より多くの項目を設定ファイルで利用できるようにすることも目的の一つです。互換性の基盤が広かったため、多くのデスクトップ版・モバイル版クライアントが製品名やカーネル切り替え項目、設定ディレクトリに「Meta」と直接記載していました。

mihomo は Meta ブランチ改名後の現在の名称

mihomo は Clash.Meta とは別に新たに登場した並行カーネルではありません。より正確には、Clash.Meta プロジェクトが mihomo に改名され、コードと保守体制が引き継がれています。本稿執筆時点で、新しいバージョンや不具合修正、新しい設定機能について調べる場合は、mihomo の現行ドキュメントを優先してください。古い画面に「Meta カーネル」と表示されていても、クライアント側の表示が更新されていないだけで、実際には mihomo が組み込まれている可能性があります。バージョン情報を確認しましょう。

名称	現在の位置づけ	メンテナンス状況	設定上の特徴
Clash 無印版	ルールと設定モデルの基盤	プロジェクトはアーカイブ済み	基本的な Clash 項目を認識するが、後続の mihomo 拡張には対応しない
Clash.Meta	mihomo の旧プロジェクト名	名称の移行を完了	旧バージョンの時点で実装されていた Meta 拡張に対応
mihomo	Meta ブランチの現在のプロジェクト名・カーネル名	継続的にメンテナンス	一般的な Clash 構造と互換性があり、拡張項目も提供

機能範囲：違いは取り込み方式、プロトコル、ルール処理に集中する

基本的な HTTP、SOCKS、混合ポート、プロキシグループ、ドメインルールだけではカーネルを見分けられません。一般的なサブスクリプションの多くは、これらの内容を生成できます。選択に大きく影響するのは、システムの通信をどのようにカーネルへ取り込むか、DNS リクエストを誰が解決するか、サブスクリプションに新しいプロキシプロトコルが含まれるか、ルールセットが mihomo の拡張構文に依存しているかです。

TUN とシステム通信の取り込み

システムプロキシの影響を受けるのは、プロキシ設定を読み取るアプリだけです。ブラウザーや一部のデスクトップソフトは通常システムプロキシを利用できますが、コマンドラインプログラム、ゲーム、仮想マシン、一部のストアアプリ、独自のネットワークスタックを実装したソフトは設定を迂回することがあります。TUN モードは仮想ネットワークインターフェースでより広範囲の IP 通信を受け取るため、通信を一括して取り込みたい環境に適しています。一方で、管理者権限、ルーティングテーブル、DNS ハイジャック、ネットワークアダプターの競合、ファイアウォールルールも関係します。

Clash 無印版のオープンソースカーネル、過去の Premium ビルド、現在の mihomo の TUN 機能を、同じ一つのバージョンとして扱うことはできません。mihomo は現在、比較的充実した TUN 設定と、複数のプロトコルスタックや自動ルーティングに関する項目を提供しています。ただし、クライアントで正常に有効化できるかは、OS、サービスモード、権限にも左右されます。mihomo 対応クライアントを選んでも、カーネルが機能を備えていることを示すだけで、ドライバー、サービス、ルーティング設定まで自動で完了するとは限りません。

プロキシプロトコルとトランスポート項目

初期の Clash 設定は、当時一般的だった Shadowsocks、VMess、Trojan、SOCKS などを主に対象としていました。mihomo はその後の保守で、複数のプロトコルやトランスポート項目を追加・拡張しています。サブスクリプションに新しいプロトコル、新しい暗号方式、拡張トランスポート項目が含まれている場合、古い無印版カーネルは読み込み時にエラーを出したり、未知の項目を無視したりすることがあります。その結果、ノードが利用できなくなります。

ここで比較すべきなのは、ノード一覧に表示されるかどうかだけではありません。GUI は先にサブスクリプションを解析してノードを描画し、実際に接続するときになって初めて設定をカーネルへ渡すことがあります。ノードは一覧に表示されるのに速度測定に失敗する場合、フロントエンドは項目を受け付けても、カーネルのバージョンが該当プロトコルに対応していないことがよくあります。診断時は、カーネルログの解析エラー、ハンドシェイクエラー、未知の項目に関するメッセージを確認してください。

ルールセット、サブルール、マッチング機能

従来の Clash ルールは通常、ルール種別、照合対象、適用するポリシーで構成されます。たとえばドメインサフィックス、IP ネットワーク、プロセス名、最終マッチなどです。mihomo はこの基盤に、より豊富なルールとルールセット機能を追加し、必要に応じてリモートルールセット、組み合わせロジック、サブルールを構成できます。大規模な設定では、これによりメインファイルを短くし、更新時期ごとにデータを分割できます。

拡張機能には移行上の制約もあります。mihomo だけが対応するルール種別を設定で使うと、無印版へそのまま戻せるとは考えられません。YAML の構文が正しくても、古いカーネルは未知のルールを理由に起動を拒否することがあります。複数のクライアントで互換性を保つ必要がある場合は、対象デバイスの中で最も機能の少ないカーネルを基準にするか、カーネルごとに設定を生成してください。

DNS、嗅探、ドメインの復元

Clash 系カーネルのルール判定はドメインに依存することが多い一方、TUN に入った接続には宛先 IP しか現れない場合があります。DNS マッピング、Fake IP、トラフィック嗅探はドメイン情報を補い、ドメインルールを引き続き適用できるようにします。mihomo はこの処理に関する調整項目をさらに多く提供しており、リスニング、DNS サーバーのグループ化、Fake IP の範囲、フィルター、フォールバック、嗅探の対象範囲などを設定できます。

これらの項目は多ければよいわけではありません。企業内ネットワークのドメイン、LAN 機器、ゲームのアンチチート、ブラウザーの暗号化 DNS、OS 標準の名前解決キャッシュなどが実際の経路を変えることがあります。カーネル選定で利用可能なツールは決まりますが、最終的な設定はネットワーク環境に合わせる必要があります。トラブルシューティングでは、システム DNS、カーネル DNS ログ、ルールの適用結果、実際の出口を分けて確認し、TUN、Fake IP、フォールバックサーバーを一度に変更しないでください。

設定の互換性：基本項目はおおむね引き継げるが、拡張項目は逆方向の互換性を保証しない

Clash 無印版の設定を mihomo へ移行する場合、基本構造は通常そのまま利用できます。ポート、動作モード、ログレベル、プロキシ一覧、プロキシグループ、一般的なルールは、なじみのある階層構造を引き継ぎます。以下は、あえて基本機能に絞った例です。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: example-node
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - example-node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - MATCH,DIRECT

このような設定では、特定ブランチの高度な機能を使っていないため、移行時の負担は小さくなります。ただし、実際のサブスクリプションには、リモートルールプロバイダー、ヘルスチェック、インターフェースのバインド、トラフィック嗅探、新しいプロトコル項目、クライアントによる上書きが含まれることがあります。ファイル冒頭の数行を見るだけでは、設定全体の互換性は判断できません。

Clash 無印版から mihomo への移行

移行は通常、比較的スムーズです。まず元の設定で mihomo を起動し、解析ログと動作ログを確認してから、新機能を一つずつ有効にします。初回起動時に TUN への変更、DNS モードの変更、ルールセットの書き換えを同時に行わないでください。安全な順序は、まずノード接続を確認し、次にプロキシグループの切り替え、続いてルールの適用、最後に TUN と DNS を確認する流れです。

設定がサブスクリプション由来の場合、クライアントがダウンロード後に上書き内容を追加することもあります。たとえばポートの変更、ローカルルールの挿入、プロキシグループの置き換え、LAN アクセスの有効化などです。エクスポートした YAML と実行時の設定が完全に一致するとは限りません。動作に差がある場合は、クライアントの実行設定表示機能を使うか、外部コントロールインターフェースでカーネルが実際に読み込んだ内容を確認してください。

mihomo から Clash 無印版へ戻す

逆方向へ移行する場合は、拡張項目を一つずつ削除し、各ノードのプロトコルが古いカーネルに対応していることを確認する必要があります。トップレベルの項目を一つ削除するだけでは不十分です。互換性のない内容が、プロキシノード、ルール、DNS、TUN、ルールプロバイダー、プロキシグループの項目に隠れている可能性があります。リモートサブスクリプションは次回更新時にそれらを再び書き込むため、一時的な手作業の修正だけではサブスクリプションテンプレートの調整に代わりません。

あるサーバーが古いカーネルに対応しないプロトコルだけを提供している場合、設定変換によって別のプロトコルへ自動変換することはできません。サブスクリプション変換が行えるのは、項目の再構成、ノードの選別、ルールの結合などであり、サーバーが実際に提供するハンドシェイク方式を変えることではありません。その場合は、そのプロトコルに対応する mihomo カーネルを使い続けるか、設定元から互換性のあるノードを取得してください。

クライアントの選び方：システム統合を確認してからカーネルのバージョンを見る

一般ユーザーは通常、カーネルを単体で動かすのではなく、GUI 付きのクライアントをインストールします。選ぶときは、「フロントエンドが操作しやすいか」と「カーネルが設定要件を満たすか」を分けて判断してください。画面は成熟していてもカーネルの更新が止まっているクライアントでは、新しいサブスクリプションを読み込めない可能性があります。反対に、カーネルは新しくてもシステムサービスの管理機能が不足しているクライアントは、TUN を常用する環境に向かないことがあります。

Windows デスクトップ環境

Windows クライアントでは、mihomo カーネルのバージョン、サービスモード、TUN の権限処理、システムプロキシの復元、ログの入口を重点的に確認してください。ブラウザーと一般的なオフィスソフトだけを使うなら、システムプロキシモードのほうが管理しやすいことが多いです。ゲーム、コマンドライン、ストアアプリ、システムプロキシを読み取らないソフトまで取り込みたい場合に、TUN を検討します。有効化前に、既存の DNS、ほかの仮想ネットワークアダプター、セキュリティソフトの状態を記録しておくと、通信できなくなった際に戻しやすくなります。

一部の Windows クライアントでは、複数のカーネルを切り替えられます。切り替え後は画面を再起動するだけでなく、実行ログでカーネル名とバージョンが変わったことを確認してください。古い設定に Premium 専用項目が含まれている場合は、クライアントが自動変換するかどうかも確認します。システムプロキシのポートはカーネルのリスニングポートと一致していなければなりません。不一致だと、画面上は有効でもアプリは空のポートへ接続してしまいます。

macOS デスクトップ環境

macOS では、クライアントが現在のプロセッサアーキテクチャ、システム拡張、ネットワーク権限に対応しているか、終了時にプロキシ設定を復元できるかを確認してください。以前からある名称のクライアントでも、更新によって mihomo を組み込んでいる場合があります。そのため、製品名だけでカーネルを判断できません。Apple Silicon 搭載機では、対応アーキテクチャ向けのビルドを優先し、アーキテクチャ互換レイヤーの問題をプロキシカーネルの障害と取り違えないようにします。

システムプロキシを使う場合は、HTTP、HTTPS、SOCKS の各項目がクライアントによって正しく設定されているか確認してください。TUN を使う場合は、仮想インターフェース、デフォルトルート、LAN アクセスを確認します。企業管理端末では、ネットワーク拡張や管理者の承認が制限されることがあります。これはシステムポリシー上の制約であり、設定ファイルを交換するだけでは解決できません。

Linux デスクトップとサーバー

Linux デスクトップでは、mihomo 対応の GUI クライアントを選ぶことも、カーネルを直接実行することもできます。サーバーでは、コマンドライン設定と systemd サービスの組み合わせが適しています。作業ディレクトリの固定、権限の制限、自動再起動、journal によるログ確認が容易になるためです。シェルで HTTP_PROXY と HTTPS_PROXY を設定しても、影響を受けるのはそれらの環境変数を読み取るプログラムだけであり、全体の通信を取り込むこととは異なります。

TUN の導入には、ネットワーク名前空間、ルーティングルール、フォワーディング設定、コンテナネットワークも関係します。Docker コンテナのリクエストがホスト上の mihomo を経由するかどうかは、ネットワークモードとルーティング設計によって決まります。サーバーでは、デスクトップクライアントが生成した設定をそのままコピーしないでください。GUI 専用の相対パス、コントローラーアドレス、ローカルルールファイルが含まれている可能性があります。

Android と iOS

モバイル OS は通常、システム VPN インターフェースを通じて通信を取り込みます。そのため、デスクトップ版よりもフロントエンドによるカーネルのライフサイクル管理やバックグラウンド動作の制御が重要です。アプリに実際に組み込まれているカーネル、対応プロキシプロトコル、アプリ単位の分岐機能、対応 OS バージョンを確認してください。モバイルクライアントに表示される「VPN」はローカル通信の入口を意味するもので、通信が必ず従来型の企業 VPN へ接続されるわけではありません。その後の直結・転送はルールとプロキシグループによって決まります。

iOS では、デスクトップ版のカーネルファイルをそのままアプリに入れて実行することはできません。利用できるカーネル機能は、アプリのパッケージ版と、システム審査のもとで実装された方式によって決まります。Android でも、メーカーによるバックグラウンド制限、省電力設定、VPN 常駐ポリシーの影響があります。デスクトップでは正常なノードがモバイルで頻繁に切断される場合、サブスクリプションだけでなく、OS のバックグラウンド制限も確認してください。

用途別に選び方を決める

利用シーン	推奨するカーネルの方向性	主な判断理由
固定された古い基本設定を使い続ける	短期的には現状を維持し、移行を計画する	まず本番環境を変更せず、保守停止による互換性と修正不足を評価する
新しくデスクトップクライアントを導入する	mihomo を継続的に組み込むクライアントを選ぶ	現行プロトコル、ルール、DNS、TUN のサポートを得られる
サブスクリプションに Meta または mihomo の拡張項目が含まれる	対応するバージョンの mihomo を使う	無印版では拡張構文を解析できる保証がない
複数デバイスで同じ設定を共有する	カーネル系列と最低バージョンを統一する	プロトコル、ルールセット、DNS の動作差を減らせる
Linux サーバーで長期運用する	mihomo のコマンドライン版とサービス管理を組み合わせる	バージョンの固定、ログ確認、起動順序の制御が容易
ブラウザーのプロキシだけが必要	現行 mihomo クライアントのシステムプロキシモード	設定経路が短く、切り分ける要素が少ないため、すぐに TUN を有効にする必要がない

新規導入では、継続的に保守されている mihomo を選ぶのが通常は合理的です。判断の根拠は名称が新しいことではなく、設定エコシステム、プロトコル、OS のネットワークスタックが今後も変化し続けることにあります。安定して動作している古い環境を、バックアップやテストなしに急いで置き換える必要はありません。ただし、現在のカーネル、クライアントのバージョン、設定元、起動パラメーターを記録し、障害発生時に再現条件を失わないようにしてください。

複数のデバイスを同じサブスクリプションで管理する場合は、カーネルのメジャーバージョンをそろえ、デスクトップとモバイル用に少量のプラットフォーム別上書きを用意するのが望ましいです。共通部分にはノード、プロキシグループ、ルールを残し、プラットフォーム部分で TUN、リスニングアドレス、インターフェースのバインド、LAN アクセスを処理します。これにより、1台のデバイスに合わせるために、そのプラットフォーム専用項目をすべての設定へ入れる必要がなくなります。

移行の進め方：変更要素を最小限にして段階的に検証する

現在の状態を記録する。クライアントのバージョン、カーネル名、カーネルバージョン、設定元、システムプロキシのポート、TUN の有効・無効を保存します。スクリーンショットは補助にはなりますが、比較にはテキストログと設定のほうが適しています。
ローカル上書きをバックアップする。サブスクリプションの URL が提供するのは通常、リモート側の基本設定だけです。ローカルルール、プロキシグループの調整、DNS の例外がクライアントデータベースに保存されていることがあります。アップグレード前に、クライアントのエクスポート機能でこれらを保存してください。
まず基本プロキシをテストする。TUN と複雑な DNS の上書きを無効にし、システムプロキシまたは明示的な SOCKS 接続で1つのノードを検証します。ノードのハンドシェイクに成功したことを確認してから、プロキシグループとルールを確認してください。
ルールの適用結果を確認する。直結すべき対象とプロキシ経由にすべき対象へそれぞれアクセスし、ログで対象ドメイン、ルール種別、最終ポリシーを確認します。ウェブページが開くかどうかだけでは、想定した出口を通ったか判断できません。
DNS 設定を有効にする。カーネルのリスニングポートが競合していないことを確認し、ドメイン解決が想定したサーバーで処理されているか確認します。Fake IP を使う場合は、LAN 機器、内部ドメイン、非対応アプリを個別に検証してください。
最後に TUN を有効にする。管理者権限、仮想インターフェース、自動ルーティング、DNS ハイジャックを確認します。通信できなくなった場合は、まず TUN を無効にしてシステムプロキシを復元し、その後ログを確認してください。複数のネットワークツールを連続して切り替えないでください。
再起動後の動作を確認する。システムまたはサービスを再起動し、クライアントが設定を復元できること、サブスクリプションが重要な設定を上書きしないこと、システムプロキシとルーティングが想定どおり確立されることを確認します。

よくある誤解と切り分け方法

画面に Meta と表示されるので、必ず古いカーネルである：これは誤りです。Meta はクライアントの過去の命名にすぎない可能性があります。起動ログまたはカーネルバージョンのインターフェースを読み取り、実際のバイナリを確認してください。

サブスクリプションのインポートに成功したので、設定は完全に互換性がある：これは誤りです。フロントエンドのインポート、カーネルの解析、ノードのハンドシェイク、ルールの実行は別々の段階です。ログを段階ごとに確認する必要があります。

mihomo に切り替えたら必ず TUN を有効にする：これは誤りです。mihomo は HTTP、SOCKS、混合ポートにも対応しています。システムプロキシで要件を満たせるなら、よりシンプルな取り込み方式を使い続けられます。

設定変換ですべてのプロトコル差を解決できる：これは誤りです。変換ツールで設定の並べ替えはできますが、サーバー側のプロトコルを変更したり、古いカーネルに不足している実装を追加したりはできません。

同名のプロキシグループはすべてのデバイスで同じ動作をする：必ずしもそうとは限りません。ヘルスチェックの間隔、遅延測定先、ネットワーク権限、カーネルのバージョンによって自動選択の結果が変わることがあります。グループ種別、候補ノード、テスト項目を比較してください。

結論：新規導入は mihomo を基準にし、既存環境は互換性を確認しながら移行する

Clash 無印版は広く引き継がれてきた設定・ルールモデルを提供しましたが、プロジェクトはすでにアーカイブされています。Clash.Meta は拡張ブランチがかつて使用していた名称で、mihomo はそのブランチが改名された現在のプロジェクトです。Meta と mihomo を同時に競合する新旧2つのカーネルと捉えると、バージョンを誤って判断します。プロジェクトの沿革、クライアントのパッケージ版、実行ログを照合し、実際のカーネルを確認するのが正しい方法です。

選定時、基本的なシステムプロキシ、単純なルール、従来型のノードプロトコルであれば、カーネルに求められる要件は比較的少なくなります。一方、新しいプロトコル、複雑なルールセット、細かな DNS 制御、トラフィック嗅探、TUN による取り込みでは、現在の mihomo の機能に大きく依存します。新規インストールでは、継続的に保守され、mihomo の統合が明記されたクライアントを優先してください。既存の古い環境では、まず状態を記録し、最小構成で移行をテストしてから、DNS、ルールセット、TUN を段階的に戻します。

最終的な判断基準はクライアント名でも、サブスクリプションファイルをインポートできるかどうかでもありません。カーネルが設定を完全に解析し、ノード接続を安定して確立し、ルールを想定どおり適用し、システム再起動後にネットワーク状態を復元できるかどうかです。この4点を軸に検証すれば、カーネルのアップグレードを一括置換ではなく、観測可能で復旧可能な工程へ分解できます。