mihomo コアと旧 Clash コアの違いを徹底解説:追加プロトコルとルール機能の詳細

コアとは何か、クライアント UI との関係

Clash エコシステムでは「クライアント」と「コア」は別々の部分です。コア(core)はグラフィカル UI を持たない実行プログラムで、設定ファイルの解析、プロキシ接続の確立、分流ルールの実行、DNS クエリの処理を担い、ローカル HTTP API(通常は 127.0.0.1:9090 で待機)経由で状態と制御インターフェースを外部に公開します。クライアント(Clash Plus、Clash Verge Rev、FlClash など)はコアを包むグラフィカル UI で、サブスクリプション管理・ノード表示・トグル切り替えを担当し、実際のプロキシ処理はすべてコアに転送して実行されます。

この階層構造から重要な事実が導かれます。クライアントの見た目を変えるのは容易ですが、コアの世代交代は容易ではありません。ユーザーが普段感じる「UI の使いやすさ」はクライアント層の差異であり、「どのプロトコルに対応しているか」「どのルールが書けるか」はコアのバージョンに完全に依存します。だからこそ Clash エコシステムを議論する際は、コアを単独で取り上げて分析する意味があります。

旧 Clash コアの現状:更新停止とアーカイブ化

コミュニティが最初に維持していた旧 Clash コア(リポジトリ名は通常 Clash または Clash Premium)は更新が停止し、リポジトリはアーカイブ(archived)状態となり、新しい issue や PR は受け付けず、新バージョンも公開されません。理由は Clash for Windows のグラフィカルクライアントが公開停止になった経緯と似ており、いずれも原作者のアカウントや関連リポジトリが停止処理を受けたことに関係しています。

更新停止時点での旧コアの機能水準はおおむね以下の通りです。

• プロトコル対応:Shadowsocks、ShadowsocksR、VMess、Trojan、Snell などの主要プロトコルに対応するが、Hysteria、TUIC など後発のプロトコルは非対応。
• ルールタイプ:DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、MATCH などの基本ルールのみで、rule-providers によるリモートルールセット機構やプロセス単位のルールはなし。
• DNS 機能:基本的な DNS 転送と汚染対策を提供するが、Fake-IP の細かい制御やスニッフィング(sniffer)機能はなし。
• TUN モード:初期バージョンでは非対応、または対応が非常に限定的で、プラットフォーム間の一貫性が低い。

一般ユーザーにとって、旧コアは現存する古い設定ファイルを引き続き動かせ、一般的なノードにも接続できるため、突然使えなくなるわけではありません。しかし新機能は追加されず、発生した不具合も公式修正はないため、長期利用では機能面での遅れが避けられないリスクがあります。

mihomo(Clash Meta)とは何か、旧コアとの関係

mihomo の前身はコミュニティのフォークプロジェクトである Clash Meta で、旧コアの開発が停滞した後、別の貢献者グループが旧コアのソースをベースに開発を継続し、新プロトコル・新ルールタイプ・パフォーマンス改善を取り込み続け、後に正式に mihomo という名称で独立しました。現在、活発に更新が続いているデスクトップ・モバイルクライアントのほぼすべて――Clash Plus、Clash Verge Rev、FlClash、Clash Meta for Android の後継系ブランチを含む――は、旧コアではなく mihomo コアを内部で動かしています。

誤解しやすい点を補足すると、mihomo はゼロから作られた別プロジェクトではなく、設定ファイルの文法は旧コアと高い互換性を保っています。旧コアの設定フィールド(port、mode、proxies、proxy-groups、rules など)の大部分はそのまま維持でき、mihomo が行っているのは「拡張」であって「置き換え」ではありません。これが、旧設定ファイルを mihomo コア採用のクライアントに移行する際、多くの場面で設定を書き直す必要がなく、新規フィールドを追加するだけで新機能を利用できる理由です。

プロトコル対応の違い:旧コアで動かないプロトコル

プロトコル対応は両者の最も直感的な違いです。mihomo は旧コアのプロトコルに加えて、後発の伝送プロトコルを複数サポートしており、それぞれ遅延や検知回避性能に特徴があります。

サブスクリプションのノード一覧に Hysteria2 や TUIC タイプのノードが含まれている場合、旧コアではそのまま解析失敗、あるいはスキップされ、「ノード一覧から何個か消えている」またはクライアントが設定エラーを報告する形で表れます。この種の問題の根本原因は設定ファイルの記述ミスではなく、コアのバージョンが古すぎることが多く、mihomo ベースのクライアントに切り替えれば解決します。

ルール機能の違い:rule-providers とより細かいマッチング

ルールシステムは mihomo が旧コアに対して最も大きく強化した部分の一つです。旧コアの rules フィールドは固定ルールを一行ずつ列挙するだけで、ルール数が増えると設定ファイルが極端に肥大化し、保守が困難になります。mihomo は rule-providers 機構を導入し、ルールセットを独立したリモートファイルとして切り出し、メイン設定では参照するだけで済むようにしました。

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    path: ./rules/reject.txt
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

ルールセットファイルは interval で指定した周期で自動更新され、ルール管理者が分類ルールを更新すると、ユーザー側はバックグラウンドで静かに同期され、設定ファイル全体を手動で入れ替える必要がありません。これが現在主流の「ワンクリックサブスクリプション」設定方式が長期的にルールの精度を保てる技術的な基盤です。

それ以外にも、mihomo は旧コアにはなかったルールタイプを追加しています。

• PROCESS-NAME / PROCESS-PATH:接続を発行するプロセス名やパスで分流し、「特定のアプリだけをプロキシ経由にし、他は直接接続」という制御ができます。
• IP-CIDR6:IPv6 アドレス帯のマッチングで、旧コアの IPv6 対応の穴を補います。
• SCRIPT(一部実装):簡易なスクリプトロジックで分流条件を判定でき、複雑なシナリオに適します。
• SUB-RULE:サブルールセットの入れ子参照で、巨大なルール表を再利用可能なモジュールに分割できます。

多くの一般ユーザーにとって、プロセス単位のルールの意義は「どのソフトウェアをプロキシ経由にするか」を精密に制御でき、ドメイン/IP レベルのみのルール粒度による誤判定を避けられる点にあります。

DNS と Fake-IP 機能の違い

DNS 処理は体感差が大きいもう一つのモジュールです。旧コアの DNS モジュールは機能が比較的基本的で、主に「DNS 汚染により誤った IP に解決される」問題への対処が中心でした。mihomo はこれを土台に Fake-IP 機構とスニッフィング機能を整備しています。

• Fake-IP モード:ドメインに仮想 IP 帯内のアドレスを割り当て、アプリが接続を開始する際にはまず仮の IP を取得し、実際の接続確立時にコアが元のドメインを復元して分流判定を行います。従来の DNS モードでの「まず解決してから分流を判断する」往復遅延を減らし、ドメインベースの分流ルールと特に相性が良いです。
• スニッフィング(sniffer):IP-CIDR や GEOIP ルールを設定しているものの対応するドメイン情報がない接続について、mihomo は TLS SNI や HTTP Host フィールドから対象ドメインをスニッフィングし、ドメイン系ルールを適用できます。これにより一部シナリオで Fake-IP とルールが噛み合わない問題を補います。
• DNS 分流:ネットワーク環境(日本国内/海外)ごとに異なる上位 DNS サーバーを設定し、fallback-filter と組み合わせて結果の信頼性を判定できます。この点で旧コアの設定項目は明らかに少なめです。

API 機能とクライアント連携の違い

コアが外部に公開する HTTP API は、クライアントがどのようなリアルタイム連携機能を実現できるかを決定します。旧コアの API はノード一覧・接続状態・ログ配信などの基本機能をカバーしていました。mihomo はこれを土台に、より多くの照会・制御可能なインターフェースを拡張しています。

• プロキシグループ単位での遅延測定結果の照会、複数の戦略グループの並行測定に対応。
• 接続単位での詳細なトラフィック統計、アップロード/ダウンロードのバイト数とリアルタイムレートを区別。
• ルールヒットの追跡、あるある接続が具体的にどのルールにヒットし、どのプロキシを経由したかを確認可能。
• 設定のホットリロードインターフェース、クライアントがサブスクリプションを切り替えたりルールを変更した後、コアを再起動せずに即時反映。

これは現在のクライアントが「接続詳細ページでルールヒットの状況をリアルタイム表示できる」理由でもあります。この種の UI 機能は、基盤の API が対応データを提供しているかどうかに完全に依存し、旧コアの API のカバー範囲ではこうした UI 機能を支えられません。

旧設定ファイルを mihomo に移行する際、書き直しは必要か

mihomo はフィールドレベルで旧コアとの後方互換性を良好に保っているため、大半の旧設定ファイルはそのまま読み込んで動かせます。よくある移行作業は「書き直し」ではなく「追加」です。

1. まずそのまま読み込んでテスト

   サブスクリプションリンクやローカル設定ファイルをそのまま mihomo ベースのクライアントに追加し、まず正常に接続・分流できるか確認します。大半の基本フィールドは変更不要です。

2. プロトコル解析エラーを確認

   ログに特定ノードの解析失敗が出た場合、通常はプロトコルタイプが新しすぎる・古すぎることによるフィールドの不一致が原因です。まずそのノードをスキップして他が正常か確認しましょう。

3. 新規フィールドを追加

   必要に応じて rule-providers、sniffer、tun など mihomo 特有のフィールドを追加し、「動けばよい」という最低ラインで止まらず新コアの機能を十分に活用しましょう。

4. 戦略グループの測定ロジックを確認

   mihomo の url-test と fallback 戦略グループはタイムアウト判定とヘルスチェックが最適化されているため、interval と tolerance パラメータが想定どおりかを確認することをおすすめします。

書き直しが必要な唯一のケースは、設定ファイルに旧コアが元々サポートしておらず、サードパーティの改造版が独自定義した private フィールドが使われている場合です。これは比較的まれで、遭遇した場合は mihomo 公式ドキュメントのフィールド説明を基に一つずつ確認すれば十分です。

どう選ぶべきか:コアレベルでの実践的な提案

これまでの差異を一言でまとめると、旧コアはすでにアーカイブ化され、機能は更新停止前の水準に留まり、新プロトコルや新ルール機能が追加されることはありません。mihomo は現在活発にメンテナンスされ、プロトコルとルール機能が継続的に拡張されているコアであり、旧設定への互換性も保っています。したがってコア選択の観点では、「旧コアに戻す」ために新機能を諦める必要はなく、内部が mihomo ベースのクライアントを直接選ぶのがより手間のかからない選択です。

具体的な判断としては、以下のポイントで現在使用しているクライアントのコアを手早く確認できます。

• クライアントの「概要」や「バージョン情報」ページを確認すると、通常コア名とバージョン番号が表示されており、mihomo または Meta という表記があれば新コアです。
• Hysteria2 や TUIC ノードを追加してみて、正常に認識され遅延が表示されればコアが新プロトコルに対応していることが分かります。
• rule-providers やルールセットの自動更新設定項目があるかを確認します。これはルールシステムが mihomo 系かどうかを判断する直接的な手がかりです。

多くのユーザーにとって、コアの差異を手動で気にする必要はなく、クライアントを選ぶ際にその内部が継続的に更新される mihomo に依存しているかを確認するだけで十分です。以降のプロトコルやルールの進化はクライアントの更新に伴って自動的に反映されるため、コア自体の更新タイミングを個別に追いかける必要はありません。