Clash・Clash Meta・mihomoの違い｜バージョンの変遷と選び方
Clash、Clash Meta、mihomoの成り立ちを整理し、対応プロトコルやルール構文、開発状況を比較。各クライアントに搭載されたコアの確認方法も解説します。
クライアントとコアの違いを理解する
Clashクライアントは、設定のインポートやノードの切り替え、システムプロキシの設定に使うGUIアプリです。一方、コアはYAML設定の解析やルール判定を行い、実際の通信を処理します。両者は別々のプロジェクトが開発している場合があります。そのため、ウィンドウにClashと表示されていても、搭載されているのがオリジナルClash、Clash Meta、mihomoのどれかは判断できません。アプリ名だけでなく、クライアントの「コア」や「バージョン情報」画面で確認しましょう。
この3つは、単純に新旧で並ぶ3つのバージョンではありません。オリジナルClashは初期のプロジェクトで、Clash Metaはそのエコシステムから機能を拡張して登場しました。その後、Clash Metaはmihomoというプロジェクト名で開発が続いています。資料やサブスクリプションの説明、クライアント画面には今も「Meta」と記載されている一方、実際にダウンロードしたコアのファイル名やバージョン情報には「mihomo」と表示されることがあります。この場合はプロジェクト名とバージョンを確認し、すぐに「Metaからmihomoへの変換用設定」を探す必要はありません。
| 名称 | ほかの名称との関係 | 選ぶ際の確認ポイント |
|---|---|---|
| オリジナルClash | 初期の独立したClashコアプロジェクト | 現在の設定が基本的なプロトコルとルールだけを使っているか、利用中のクライアントが今もこのコアを搭載しているか |
| Clash Meta | Clashの機能を拡張したプロジェクト。現在も一般的に使われる旧称 | 設定でMeta系が対応するプロトコル、ルール、DNSオプションを使っているか |
| mihomo | Clash Metaが後に採用したプロジェクト名 | 現在のクライアントに実際に同梱されているコアのバージョンと機能 |
バージョンの変遷と開発状況を確認する
オリジナルClashの公開開発は終了しています。proxies、proxy-groups、rulesなど、現在もよく使われるYAML設定の構造を確立したため、多くの解説ではこうしたファイルをまとめて「Clash設定」と呼んでいます。ただし、設定の構造が似ていても、新しい項目が旧コアで使えるとは限りません。何年も更新されていないクライアントは、リリース当時のコアを使い続けていることもあります。サブスクリプションを更新しても、コアが自動的に入れ替わるわけではありません。
Clash Metaは従来の使い方を引き継ぎながら機能を追加し、その後mihomoという名称で開発が続いています。現在の開発状況を確認するには、クライアントに表示されるコアのバージョンと更新履歴を確認しましょう。アプリのインストーラーと一緒にコアを更新するクライアントもあれば、設定画面からコアを個別に切り替えたり更新したりできるものもあります。クライアントのバージョンとコアのバージョンは別物です。たとえば「クライアント 2.0」と表示されていても、それだけで特定のmihomoルールに対応しているとは判断できません。
使用中の端末で確認する3つの場所
- クライアントの「設定」または「バージョン情報」を開き、「コア」「Core」「Kernel」とバージョン番号を確認します。メニュー名はクライアントによって異なるため、画面に表示されている名称を確認してください。
- 起動時のログを確認します。コア名や設定の読み込みエラー、待ち受けポートは通常、起動時に表示されます。実行中のプログラムを確認するには、インストーラーファイル名よりログが参考になります。
- クライアントに「コアの切り替え」機能がある場合は、まず現在の選択状態を記録し、切り替え先のコアと設定ファイルに互換性があるか確認します。切り替え後に設定を再読み込みし、ログに未対応の項目やルールの解析エラーが出ていないかチェックしましょう。
プロトコル対応状況はノードの項目とコアのバージョンで確認
コアを選ぶ際の最もわかりやすい判断材料は、サブスクリプションに含まれるノードの種類です。オリジナルClashでは、Shadowsocks、VMess、Trojan、SOCKS5、HTTPなどがよく使われてきました。mihomoはこれらに加えて、より多くのプロトコルや拡張形式に対応しており、VLESS、Hysteria2、TUICなども利用できます。ただし、mihomoがあるプロトコルに対応していても、すべてのバージョンでそのプロトコルの全パラメーターを使えるとは限りません。インストール済みコアのバージョンと設定ドキュメントを確認してください。
サブスクリプションを受け取ったら、YAMLのproxies以下で各ノードのtypeを確認できます。ノードにtype: vlessと書かれているのに、クライアントが古いオリジナルClashコアを使っている場合、インポートに失敗したりノードが表示されなかったりすることがあります。多くの場合、原因はシステムプロキシの設定ではなく、プロトコルの非対応です。サブスクリプションがBase64形式の長い文字列や単一ノードの共有リンクの場合は、その形式をクライアントが取り込めるかも確認しましょう。コアがプロトコルに対応していても、GUIがあらゆる共有リンクを直接解析できるとは限りません。
インポートエラーは表示された順に確認する
- 設定を読み込めない：YAMLのインデントや項目名のスペル、クライアントに表示されたエラー行を確認します。YAMLのインデントには半角スペースを使い、同じ階層のリスト項目は位置をそろえてください。
- ノードの種類を認識できない：
typeと実行中のコアを確認します。ノードの表示名だけを変更しても解決しません。プロトコルのパラメーターは、ノードのサーバー側で提供されている情報と一致させる必要があります。 - 設定の読み込みには成功するが接続できない：まずノードのアドレス、ポート、ネットワーク接続を確認し、その後で認証情報を調べます。この場合、コアを入れ替えるだけでは解決しないことがあります。
サブスクリプションサービスに「Clash」「Clash Meta」「mihomo」など複数の設定形式がある場合は、使用中のコアに合った形式を選びましょう。形式を切り替える前に元の設定を保存してください。変換ツールによっては、プロキシグループやルールセットの参照先が書き換わることがあります。インポート後は実際のルーティング結果も確認しましょう。
ルール・DNS・TUNは設定が似ていても動作が異なる
基本的なルールの読み方は共通です。DOMAIN-SUFFIX,example.com,DIRECTは指定したドメインを直接接続し、MATCH,DIRECTはそれ以前のルールに一致しなかった通信を処理します。通常、ルールは上から順に評価され、最初に一致したルールで接続先が決まります。設定ファイルにルールセットの参照やGEOSITEなどが含まれている場合は、使用するコアが該当するルール形式とデータソースに対応しているか確認してください。拡張子がどちらも.yamlだからといって、そのまま使い回せるとは限りません。
以下は、基本的なルールと待ち受けポートの関係を確認するための簡易例です。mixed-port: 7890は、ローカルのHTTP/SOCKS混合プロキシポートを表します。external-controllerにはローカルアドレスとポート9090を指定します。すべてのルールはDIRECTを指定しており、プロキシノードも設定されていません。設定済みのプロキシサブスクリプションとして使用しないでください。
mixed-port: 7890
mode: rule
external-controller: 127.0.0.1:9090
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,DIRECTDNSとTUNは分けて確認する必要があります。DNS設定はドメイン名の解決方法を決め、TUNモードは仮想ネットワークインターフェースを通じて、対象となる端末の通信を取り込みます。TUNを有効にすると、クライアントがネットワークインターフェースの利用許可をシステムに求めることがあります。ただし、TUNを有効にしても、接続できないノードが直るわけではなく、不足しているルールセットが自動で補われるわけでもありません。「Webページは開けるのに特定のアプリだけプロキシを経由しない」場合は、そのアプリの通信がコアのログに記録されているかを確認してから、システムプロキシとTUNの有効状態、ルーティング設定、ルールの適用状況を調べましょう。
使用中のクライアントと設定から選ぶ
現在の設定が正常に動作している
まずクライアント名、コア名とバージョン、設定の入手元を記録します。サブスクリプションのノード形式が現在のコアに対応し、ルールモードでの振り分けも想定どおりなら、今の組み合わせを使い続けて問題ありません。クライアントを変更する場合は、先にYAMLをエクスポートまたはバックアップし、新しいクライアントにインポートしてプロキシグループの選択状態を確認してください。グループ名が同じでも、前回選択したノードが新しいクライアントに引き継がれるとは限りません。
新しいサブスクリプションで拡張プロトコルやルールを使う
mihomoコアを使用し、必要な項目に対応するバージョンが明記されたクライアントを選びましょう。インポート後は、ノードが一覧にすべて表示されているか、プロキシグループから各ノードを参照できているか、接続ログに想定したルールが適用されているかの3点を確認します。ノード名が一覧に表示されただけでは、プロトコルのハンドシェイクや通信の振り分けが成功したとは限りません。クライアントを比較するときは、「端末に合った画面か」と「コアが設定を読み込めるか」を別々の条件として確認してください。
クライアントにClashとだけ表示され、コアの説明がない
まず「バージョン情報」画面と起動ログを確認します。それでも特定できない場合は、クライアントのリリースノートやプロジェクトのドキュメントを調べましょう。画面にTUNの切り替え項目があるからといってmihomo搭載と決めつけたり、ファイル名にMetaとあるからといって実行中のコアが切り替わっていると判断したりしないでください。コアを確認したら、対応するドキュメントに沿って、サブスクリプションのプロトコル、rule-providers、DNS項目、TUN設定を確認します。
選ぶ際は、現在の設定と使い方を基準にします。基本的なルールと古いサブスクリプションでは移行の手間を考慮し、VLESS、Hysteria2、TUICなどのノードでは対応するコアのバージョンを確認しましょう。端末全体の通信を取り込む場合は、使用OSでのTUN設定と権限付与の手順も確認が必要です。選択後は、普段使うサイトと特定のルールが適用されるサイトをそれぞれ開き、接続ログで実際の通信経路を確認してください。