Clashのカーネルの選び方|Clash、Premium、Metaからmihomoへの変遷

Clashの各カーネルの歴史と現在のメンテナンス状況、クライアントごとの採用カーネルを解説。用途やOSに合った選び方がわかります。

クライアント・カーネル・サブスクリプション設定の違い

Clashを選ぶときに混同しやすいのが、画面に表示されるクライアントのバージョンと、実際に通信を処理するカーネルのバージョンです。クライアントはサブスクリプション管理、トレイメニュー、システムプロキシの切り替え、設定編集を担当します。カーネルはYAMLの読み込み、DNSの解決、ルール判定、プロキシ接続を担当します。両者は別々に更新でき、名称も一致するとは限りません。

サブスクリプションは設定の提供元です。ノード情報だけの場合もあれば、グループ、ルール、DNS、TUNの設定が含まれる場合もあります。同じサブスクリプションでもクライアントによって動作が異なるのは、カーネルの機能差だけでなく、インポート時にクライアント側で設定が上書きされることも原因です。拡張子が.yamlというだけでは、どのカーネルに対応しているか判断できません。

  • クライアントのバージョン:画面機能、OSとの互換性、リリースノートの確認に使います。
  • カーネルのバージョン:プロトコル、設定項目、TUNの実装、ルール機能の確認に使います。
  • 設定形式:サブスクリプションで実際に使われる機能を左右します。「Clash対応」という表記だけで互換性を判断することはできません。

変遷の流れ:4つの連続したアップグレードではない

Clash:オープンソースのルールベースプロキシカーネル

一般にClashと呼ばれるのは、Dreamacro/Clashプロジェクトのオープンソースカーネルです。多くの人になじみのあるproxies、proxy-groups、rulesなどの設定構造を確立しました。ルールを上から順に判定し、該当したルールに応じて出力先を選ぶ仕組みは、後続の派生プロジェクトにも引き継がれています。

2023年11月ごろのプロジェクトの変更以降、Clashは従来の公式チャンネルで継続的にメンテナンスされていません。現在入手できるClashのインストーラー、ミラーリポジトリ、第三者による再コンパイル版を、元の開発者が配布を再開したものと見なすべきではありません。旧設定の理解には役立ちますが、現在のプロトコル対応を評価する際の標準的な基準ではありません。

Clash Premium:過去に提供されていたクローズドソースの拡張カーネル

Premiumは元のプロジェクトが提供していたクローズドソースの拡張版であり、特定のGUIクライアントの有料プランではありません。従来版に加え、TUN、ルールプロバイダー、スクリプトなどの機能を備えていました。「Premium」はカーネルの系統を表す名称であり、サブスクリプションサービスが有料かどうかを示すものではありません。

Premiumも従来の配布元での更新を終了しています。古いチュートリアルにあるscriptやPremium専用の設定項目を、mihomoでも使える汎用的な記述と見なすことはできません。移行時は実行ファイル名を変えるだけでなく、移行先カーネルのドキュメントを確認し、項目ごとに置き換えてください。

Clash Meta:Clashから派生したコミュニティ版

Clash MetaはClashをベースに開発されたコミュニティ版です。ClashやPremiumと並行して早くから存在しており、Clashのメンテナンス終了後に登場したものではありません。プロトコルや設定機能を拡張し、独自のメンテナンス路線を築きました。旧クライアントの「Metaカーネル」や、旧サブスクリプションのMeta形式は、通常この系統を指します。

mihomo:Meta系統で現在使われているプロジェクト名

Clash Metaは後にmihomoへ改称され、現在は主にMetaCubeX/mihomoとしてメンテナンスされています。Clashの公式な後継でも、Premiumの次世代クローズドソース版でもありません。この点を理解しておけば、「Meta形式の設定をmihomoで使えるか」を正しく判断できます。基本構造は引き継げる場合が多いものの、個々の設定項目は実行するバージョンによって異なります。

名称が変わっても、古いバイナリに新機能が自動的に追加されるわけではありません。クライアントのメニューに「Meta」と表示されていても、内部ではmihomoを同梱している場合があります。一方、古いインストーラーには初期のMetaビルドしか含まれていないこともあります。実際に動作しているカーネルは、ログやバージョン情報で確認してください。

機能の違い:設定要件から比較

カーネルの選び分け
確認項目 Clash Premium Meta / mihomo
メンテナンス状況 過去のオープンソースプロジェクト。従来の配布元での更新は終了 過去のクローズドソース拡張版。従来の配布元での更新は終了 コミュニティによるメンテナンス。現在のプロジェクト名はmihomo
基本的なルールベースの振り分け ドメイン、IP、プロキシグループなどの基本構造に対応 基本構造を維持しつつ、拡張機能を提供 一般的な構造を維持し、ルールと出力機能を拡張
TUNによる通信の取り込み Clashのオープンソースカーネルには標準搭載されていません 過去のバージョンで提供。設定は旧実装の制約を受けます TUNに対応。設定項目やOSの対応状況はバージョンごとに確認が必要
新しいプロトコルへの対応 後から追加されたプロトコルには対応できません 古いビルドで後から追加されたプロトコルが使えるとは限りません より幅広いプロトコルに対応。例:VLESS、Hysteria2、TUIC。対応状況は実際のバージョンで確認してください
スクリプトの互換性 Premiumのスクリプト設定は利用できません 過去のバージョンには専用スクリプト機能がありました Premiumの旧スクリプト設定がそのまま実行できるとは限りません

プロトコル対応は名称だけで比較できません。たとえばノード設定がtype: hysteria2の場合、古いカーネルでは読み込み時に「未対応のプロキシタイプ」としてエラーになることがあります。プロトコルを認識できても、認証パラメーター、トランスポート設定、TLS設定がサーバー側と一致しない可能性があります。まず設定を読み込めることを確認し、その後に接続の問題を調べてください。

TUNを有効にしても、すべての通信がプロキシ経由になるわけではありません。TUNが変えるのは通信をカーネルに取り込む方法です。取り込まれた後の通信は、ルールに従ってDIRECT、プロキシグループ、拒否などに振り分けられます。システムプロキシとTUNは通信を取り込む入口の違いであり、「通常速度」と「高速化」の切り替えではありません。

クライアントで一般的に使われるカーネル

次の表はよくある組み合わせを把握するためのもので、インストーラーのリリースノートに代わるものではありません。同じ名称のクライアントでも、時期の異なるバージョンではカーネルが変更されている場合があります。配布元がパッケージ方法を変更することもあります。

クライアントまたは利用方法 一般的なカーネルとの関係 確認方法
Clash for Windows(CFW) 過去のリリースでは主にPremiumを採用。クライアントのメンテナンスは終了 インストーラーに含まれるカーネルのバージョン情報を確認し、CFWの画面に表示されるバージョンをカーネルのバージョンと混同しない
ClashX / ClashX Pro 過去にはClash系とPremium系の両方が使われていました 配布プロジェクト、ビルド日、カーネル情報を確認
Clash Verge Rev mihomo系を採用 カーネルのバージョンとテストビルドの使用有無を確認
Clash Meta for Android Meta/mihomo系を採用 アプリ内のカーネル情報と該当バージョンのリリースノートを確認
Linuxサーバーまたはルーター用プラグイン 実際に起動するバイナリによって異なり、切り替えに対応している場合もあります サービスの起動コマンドで実行ファイルのパスを確認

Windows、macOS、Linux

デスクトップで新規導入する場合は、mihomoを使用すると明記され、OSのアーキテクチャに合ったインストーラーを提供するクライアントを選びましょう。macOSではApple SiliconとIntelを区別してください。Linuxではx86_64、ARM64などのアーキテクチャを確認します。アーキテクチャが合わないと、サブスクリプションの設定に関係なく、プログラムが起動しないことがあります。

AndroidとiOS

AndroidではVPNの許可によってアプリが端末の通信を取り込めるようになりますが、VPN権限があっても、サブスクリプション内のすべての設定項目にカーネルが対応しているとは限りません。iOSでは、デスクトップ版Clashのように同名カーネルへ置き換える方法を探さないでください。ネットワークツールごとに設定形式や実装が異なるため、対象のサブスクリプション形式をアプリがインポートできるか確認が必要です。対応プロトコルが同じというだけで、YAML全体が使えるとは判断できません。

実際のカーネルを確認:バージョンを調べてから設定をテスト

手順1:実行中のファイルを特定する

まずクライアントのカーネル情報と起動ログを確認してください。コマンドラインで構築している場合は、サービスが実際に呼び出すファイルにバージョン確認コマンドを実行します。ダウンロードフォルダーにある新しいファイルをテストしても、バックグラウンドのサービスが旧パスのファイルを実行していることがあります。

# Linux / macOS:カーネルファイルのあるディレクトリで実行
./mihomo -v

# Windows PowerShell:カーネルファイルのあるディレクトリで実行
.\mihomo.exe -v

出力されたカーネル名、バージョン番号、ビルド情報、ファイルパスを記録します。問題を報告する際は、これらの情報が「最新版に更新済み」という説明より役立ちます。クライアントとカーネルは別々のバージョン体系を使うため、番号の大小を直接比較して新旧を判断することはできません。

手順2:使用するカーネルでYAMLを検証する

# Linux / macOS
./mihomo -t -f ./config.yaml

# Windows PowerShell
.\mihomo.exe -t -f .\config.yaml

-tは設定テスト、-fは設定ファイルの指定に使います。ルールファイルなどを相対パスで参照している場合は、作業ディレクトリにも注意してください。サービスとして実行する場合は、-dで設定ディレクトリを指定できます。テストに合格すれば、設定の読み込みチェックを通過したことはわかりますが、リモートノード、ルールのダウンロード先、DNS上流への接続まで保証されるわけではありません。

手順3:最小構成で外部要因を切り分ける

次の例は、設定構造とローカルの待ち受けを確認するためだけのものです。ローカルに混合プロキシポート7890を開きますが、リモートノードは含まず、TUNも有効にしていません。クライアントがすでにこのポートを使用している場合は、既存のプロセスを停止するか、テスト用ファイルで空いているポートを指定してください。

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

proxies: []

proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手動選択

この設定で起動できる一方、サブスクリプション全体では起動できない場合は、サブスクリプションの項目、外部リソース、プロキシグループの参照、クライアント側の上書きを重点的に調べます。最初からDNSの変更、TUNの有効化、すべてのルールの置き換えを同時に行わないでください。一度に一種類だけ変更すれば、ログを比較しやすくなります。

Premiumや旧Metaからmihomoへ移行する

  1. 現在の環境を保存:元のサブスクリプション、ローカル設定、上書き内容、カーネルのバージョン記録をバックアップします。バックアップにはノードのパスワードやサブスクリプショントークンが含まれる場合があるため、そのまま公開しないでください。
  2. ノードの種類を確認:各ノードのtypeと関連パラメーターを確認します。サブスクリプションサービスがmihomo形式と明記している場合は、そちらを優先してください。旧「Clash形式」しかない場合は、まず設定をテストします。
  3. ルールとスクリプトを確認:基本的なルールは比較的移行しやすいものです。Premiumのスクリプト処理は個別に確認し、mihomoでも同じ動作になると決めつけないでください。
  4. 通常のプロキシを先に検証:まずTUNは有効にせず、ローカルポートの待ち受け、プロキシグループの選択、代表的なWebサイトへのアクセスを確認します。その後にDNSと仮想ネットワークインターフェースによる通信の取り込みを検証してください。
  5. 上書き設定を一つずつ戻す:ルールプロバイダー、DNS、カスタムルート、TUNの順に戻し、変更のたびに再テストして起動ログを確認します。

通常のプロキシは使えてTUNを有効にすると失敗する場合は、管理者権限、ルーティング、DNSの取り込み、他のVPNとの競合を確認してください。「mihomoがサブスクリプションに非対応」とすぐに判断するべきではありません。起動時に未知の設定項目、未対応プロトコル、存在しないプロキシグループのエラーが出る場合は、まず設定を修正します。システムプロキシの切り替えでは読み込みエラーは解消しません。

選び方のチェックリスト:必要な機能から判断

  • 新規導入で新しいプロトコルが必要:mihomoを明確に採用し、継続的にリリースされているクライアントを選び、必要な最低カーネルバージョンを確認します。
  • TUNを使いたい:ダウンロードページに「TUN」と記載されているかだけでなく、クライアントの権限処理、OSの対応状況、カーネルの設定も確認します。
  • 旧設定を再現したい:対応する旧カーネルと設定のコピーを保管し、過去の動作を現在の標準と混同しないようにします。
  • 端末の性能に余裕がない:実際のルール数、DNSキャッシュ、接続数を確認します。カーネルの系統名だけからメモリ使用量を判断しないでください。
  • メンテナンスの手間を減らしたい:リリースノートが明確で、カーネルのバージョンを確認でき、バックアップやロールバックがしやすいクライアントを選びましょう。テストビルドを毎回追いかける必要はありません。

判断は、まずOSとアーキテクチャを確認し、次にクライアント内蔵のカーネルを確認します。その後、サブスクリプション形式を検証し、最後にTUNなどの追加機能を有効にしてください。クライアントを比較する場合は選び方ガイド、DNSや仮想ネットワークインターフェースの設定を確認する場合はDNS設定とTUN設定をご覧ください。画面に表示されるバージョン、カーネルのバージョン、設定の入手元を分けて記録しておくと、アップグレードやトラブル対処がスムーズになります。

クライアントをダウンロード