目次
ガイドに異なるプロジェクト名が出てくると、画面を提供するアプリ、プロキシのコア、昔の名称を、互いに置き換えられるツールだと考えてしまいがちです。設定が今の端末に合うかは、実際に動いているコアとそのバージョンで判断します。名称の関係を知ると古い資料を読みやすくなりますが、互換性は設定の検査と実際の接続で確かめる必要があります。
Clash Meta と Mihomo は同じプロジェクトの異なる時期の名称
Mihomo は Clash Meta が後に採用したプロジェクト名です。Original Clash は通常 Dreamacro が始めた初期の Clash コアを指します。古い解説の Meta と現在のログの Mihomo は、二者択一の別コアではありません。
さらに紛らわしいのがクライアント名です。Clash Verge Rev、FlClash、Clash Party はグラフィカルクライアントで、サブスクリプション、システムプロキシ、画面を管理します。その内部で実際に動作するコアが Mihomo である場合があります。ファイル名に Clash が含まれるだけでは、初期の Clash を使用している証明にはなりません。
名称が示す層
| 呼称 | 通常指すもの | 現在確認する意味 |
|---|---|---|
| Original Clash | 初期の Clash コアと基本設定モデル | 以前の設定と古いクライアントの動作を理解する |
| Clash Meta | 元のモデルを拡張した後継コアの名称 | 以前のドキュメント、ログ、サブスクリプションの説明を読む |
| Mihomo | Clash 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 を残す合理的な状況は通常ごく限られます。オフライン環境が固定され、設定は既知の機能だけを使い、更新のリスクが利点を上回る場合などです。それでもバイナリの入手元、バージョン、ロールバック方法を記録し、古いコアをインターネット公開の制御サービスとして使い続けないでください。
- OpenWrt の利用者
- プラグインのバージョン、Mihomo コアのアーキテクチャ、利用可能なストレージをまとめて確認し、LuCI の画面だけを更新しない。
- サーバーまたはコンテナへの導入
- 明確なバージョンに固定し、まずテスト用ディレクトリで設定チェックを実行してから、稼働中のインスタンスを置き換える。
- 以前の初期版を使う環境
- 分離とロールバック可能な状態を維持し、新しいプロトコルを含むサブスクリプションを古いコアへ直接配信しない。
以前の設定をMihomoへ移す：バックアップ、設定チェック、実際の通信テスト
一つの設定を安全に移行する順序
以前の設定を残す
以前の設定、コアのバージョン、繰り返しアクセスできるテスト用アドレス一式をバックアップする。
クライアント固有の項目を取り除く
以前の GUI にあるウィンドウ、キャッシュ、サービス設定を Mihomo の設定としてコピーしない。
最初に設定チェックを実行する
実際に選んだMihomoバイナリを使い、独立したテスト用ディレクトリで候補の設定をチェックします。コマンド例は下にあります。実際に報告された最初の構文解析、型、参照のエラーから対処し、まとまった部分を一度に削除しないでください。
同じノードに固定する
まず普段のサイトと内部ドメインを比較します。システムプロキシを使わないアプリは、次の手順で TUN を有効にしてから試してください。
その後で DNS と TUN の拡張機能を有効にする
一度に一層だけを変更し、接続記録、ルールの一致、終了後のネットワーク復旧を確認する。
以下はMihomo v1.19.32の引数を使ったコマンド例です。バイナリと二つの絶対パスを実際の場所に変更してください。テスト用ディレクトリには、候補の設定が必要とする信頼できるProviderとデータファイルのコピーを用意し、稼働中のディレクトリは指定しないでください。
-tは設定をチェックして終了し、-dは作業ディレクトリ、-fは設定を指定します。初期化時にテスト用ディレクトリへの書き込みや必要なリソースの取得が行われる可能性があり、完全な読み取り専用ではありません。成功表示は設定チェックが通ったことだけを示し、接続、ルール、終了後のネットワーク復旧は別に確認する必要があります。チェックに通っても、未知のフィールドや旧クライアント固有のフィールドへの対応は保証されないため、そのバージョンのドキュメントと照合してください。
mihomo -t -d '/absolute/path/to/test-data' -f '/absolute/path/to/candidate.yaml'移行完了の基準は、クライアントに「接続済み」と表示されることではありません。以前の環境で重要だった通信が新しいコアでも想定したルールに一致し、ローカルネットワークと内部ドメインへ引き続き直接接続でき、システムプロキシまたは TUN を無効にした後でネットワークが復旧することです。これらを確認してから、以前のバイナリとサービスを削除してください。