クライアントレビュー · Clash 技術ブログ

Mihomo、Clash Meta、オリジナルの Clash の違い:設定の互換性と移行ガイド

Mihomo は現在もメンテナンスされているカーネルで、Clash Meta は過去に使われていた名称です。一方、オリジナルの Clash は別のバージョン系列で更新が止まっています。まず名称を整理してから、古い設定を移行できるか判断してください。

  • Mihomo
  • Clash Meta
  • 設定互換性
  • カーネル
目次

Mihomo、Clash Meta、初期の Clash が同じ層にあるものかを、まず整理する

Original Clash は通常、Dreamacro が始めた初期の Clash カーネルを指します。Clash Meta はその設定思想を引き継いで拡張したフォークで、Mihomo は後に Clash Meta が採用したプロジェクト名です。

Clash Meta と Mihomo は、同じプロジェクトの異なる時期を指す名称であり、二者択一が必要な新しいカーネルが二つあるわけではありません。以前のチュートリアルには「Meta」と書かれていることが多く、現在のプロジェクトとログでは「Mihomo」が多く使われます。

さらに紛らわしいのがクライアント名です。Clash Verge Rev、FlClash、Clash Party はグラフィカルクライアントで、サブスクリプション、システムプロキシ、画面を管理します。その内部で実際に動作するカーネルが Mihomo である場合があります。ファイル名に Clash が含まれるだけでは、初期の Clash を使用している証明にはなりません。

名称が示す層

呼称通常指すもの現在確認する意味
Original Clash初期の Clash カーネルと基本設定モデル以前の設定と古いクライアントの動作を理解する
Clash Meta元のモデルを拡張した後継カーネルの名称以前のドキュメント、ログ、サブスクリプションの説明を読む
MihomoClash Meta が現在使用しているプロジェクト名新規導入、現在のフィールド、メンテナンス中のカーネル
Clash のグラフィカルクライアントカーネルを管理するデスクトップまたはモバイルアプリ画面、対応プラットフォーム、実際に内蔵されているカーネルのバージョンを確認する

アイコンで判断せず、「情報」と起動ログでバージョンを確認する

同じサブスクリプションでも二台のコンピューターで動作が異なる場合、通常はサブスクリプションがランダムに変化したのではなく、クライアントに内蔵されたカーネルまたはバージョンが異なります。まずクライアントの「設定 → 情報」「カーネル」または「実行ログ」を開き、完全な名称とバージョンを記録してください。コマンドラインで導入した場合は、バイナリのバージョン出力を直接確認します。

コマンドライン環境での確認方法
mihomo -v

# 如果机器上运行的是旧名称的二进制,也应先看它自己的版本
clash -v

記録を「最新版」だけで済ませない

  • クライアントの名称とバージョン
  • カーネルの表示が Mihomo、Clash Meta、Clash のどれか
  • カーネルの具体的なバージョン番号
  • OS と CPU アーキテクチャ
  • エラー発生時に実際に読み込まれた設定ファイル

設定形式が似ていても、異なるカーネル間でそのまま使い回せるとは限らない

Mihomo は proxies、proxy-groups、rules などの主要構造を引き継いでいるため、基本設定は見慣れたものに見えます。一方で、その後プロトコル、DNS、TUN、ルールセット、スニッフィング、実行時フィールドが追加または拡張されています。

古いカーネルが未知の内容に出会うと、unknown field や unsupported proxy type を返すことがあります。一部のフィールドをそのまま無視し、見つけにくい動作差だけが残る場合もあります。

逆方向の移行も完全に無条件ではありません。以前の設定が、変更された動作、スクリプト機能、クライアントが生成したフィールドを参照している場合、Mihomo で再検証が必要になることがあります。本当の互換性は「YAML を開ける」ことではなく、設定チェックに合格し、ポリシーグループの参照が完全で、ルールの一致と DNS の結果が想定どおりであることです。

同じサブスクリプションで差が出やすい箇所

対象項目初期 Clash の環境Mihomo の環境移行時の対応方法
ノードのプロトコルと転送方式以前のカーネルとそのバージョンに左右され、当時対応していたフィールドだけを認識するより多くのプロトコルと転送方式を継続的に追加、保守しているunsupported proxy type が出たらカーネルを確認し、無理に合わせるためノードのフィールドを削除しない
DNSオープンソース版と Premium 版では、バージョンによって機能とフィールドが完全には一致しない現在のドキュメントには、DNS、Fake-IP、nameserver の全オプションが記載されているまず最小限の DNS をそのまま使い、Fake-IP のフィルターと上流サーバーを一項目ずつ移行する
TUN利用可否は以前のフォーク、バージョン、クライアントへの統合状況によって異なる現在の Mihomo と主要クライアントでは、一般に TUN が提供されているまずシステムプロキシで確認し、その後 TUN とサービス権限を個別に有効にする
ルールと Provider以前のカーネルは、認識できるルールの種類と構造だけを受け付ける現在のドキュメントにあるルール、ルールセット、拡張フィールドに対応するrule-provider behavior、ポリシーグループ名、最終的なマージ結果を確認する
クライアント固有の追加フィールド以前の GUI にある Mixin、Parsers、スクリプトによって生成される場合がある新しいクライアントの Merge、Script、オーバーライドによって生成される目的だけを移行し、クライアント固有の設定をまとめてコピーしない

unknown field

主な原因:現在のカーネルがそのフィールドを認識しないか、フィールドの階層が誤っている

対処方法:実際のカーネルバージョンに対応する公式ドキュメントで確認し、コロンを削除しながら試行錯誤しない。

unsupported proxy type

主な原因:プロトコルまたは転送機能が、現在のカーネルの対応範囲を超えている

対処方法:サービス提供者が求めるメンテナンス中のカーネルへ更新するか、互換性のあるノードを使用する。

proxy/group not found

主な原因:ポリシーグループ、ルール、オーバーライドが参照する名前が存在しない

対処方法:元のサブスクリプションだけでなく、最終的にマージされた設定を確認する。

読み込めるがルールの動作が異なる

主な原因:DNS、ルールの順序、クライアントのオーバーライドによって実行結果が変わっている

対処方法:接続記録を使い、同じドメインに一致したルールと出口を比較する。

新規環境ではメンテナンス中の Mihomo を優先し、古いカーネルは明確な互換要件がある場合にだけ残す

デスクトップクライアント、ルータープラグイン、サーバーサービスを新たにインストールする場合は、Mihomo を使用することが明記され、公式リリースと問題追跡が続いているプロジェクトを優先してください。主な理由は、現在の OS との互換性、セキュリティ修正、ドキュメントの一貫性であり、名称が新しいだけで自動的に速くなるからではありません。

Original Clash を残す合理的な状況は通常ごく限られます。オフライン環境が固定され、設定は既知の機能だけを使い、更新のリスクが利点を上回る場合などです。それでもバイナリの入手元、バージョン、ロールバック方法を記録し、古いカーネルをインターネット公開の制御サービスとして使い続けないでください。

一般的なデスクトップ利用者
Mihomo を内蔵した継続メンテナンス中のクライアントを選び、クリーンなサブスクリプション一つから始める。
OpenWrt の利用者
プラグインのバージョン、Mihomo カーネルのアーキテクチャ、利用可能なストレージをまとめて確認し、LuCI の画面だけを更新しない。
サーバーまたはコンテナへの導入
明確なバージョンに固定し、まずテスト用ディレクトリで設定チェックを実行してから、稼働中のインスタンスを置き換える。
以前の初期版を使う環境
分離とロールバック可能な状態を維持し、新しいプロトコルを含むサブスクリプションを古いカーネルへ直接配信しない。

移行時は以前の動作を先に再現し、新機能を一項目ずつ有効にする

一つの設定を安全に移行する順序

  1. 以前の設定を残す

    以前の設定、カーネルのバージョン、繰り返しアクセスできるテスト用アドレス一式をバックアップする。

  2. クライアント固有の項目を取り除く

    以前の GUI にあるウィンドウ、キャッシュ、サービス設定を Mihomo の設定としてコピーしない。

  3. 最初に設定チェックを実行する

    最初の unknown field、型、参照エラーから対処し、設定ブロック全体を一度に削除しない。

  4. 同じノードに固定する

    普段使う Web サイト、内部ドメイン、システムプロキシを参照しないアプリ一つを比較する。

  5. その後で DNS と TUN の拡張機能を有効にする

    一度に一層だけを変更し、接続記録、ルールの一致、終了後のネットワーク復旧を確認する。

移行完了の基準は、クライアントに「接続済み」と表示されることではありません。以前の環境で重要だった通信が新しいカーネルでも想定したルールに一致し、ローカルネットワークと内部ドメインへ引き続き直接接続でき、システムプロキシまたは TUN を無効にした後でネットワークが復旧することです。これらを確認してから、以前のバイナリとサービスを削除してください。

参考資料