Clashコアのバージョン比較：オリジナル版・Meta・mihomoの機能と互換性

1. オリジナル版Clash、Clash.Meta、mihomoの関係

Clashは特定のデスクトップ画面やモバイルアプリそのものを指す名称ではありません。通常の利用環境は、ネットワーク処理を担うコア、操作画面を提供するクライアント、ローカルファイルやサブスクリプションから生成されるYAML設定の3層で構成されます。コアはプロキシノード、ルール、プロキシグループを解析し、DNS、システムプロキシ、TUNによるトラフィックの取り込みを実行します。クライアントはコアの起動、サブスクリプションの更新、ログ表示、プロキシグループの切り替えを担当します。

オリジナル版Clashは、proxies、proxy-groups、rules、proxy-providers、rule-providersといった一般的な設定構造を確立しました。現在も多くのサブスクリプション変換ツールがこの構造を基盤にしています。ただし、オリジナル版プロジェクトは継続的なメンテナンスを終了しているため、新しいプロトコルやOSのネットワーク環境の変化、長期的に蓄積した不具合への対応は行われません。古い設定を動かせることと、新しい環境の標準コアとして適していることは別です。

Clash.Metaは当初、Clashの設定体系を基盤に機能を拡張したメンテナンス系統で、対応プロキシプロトコル、ルール機能、DNSオプション、透過プロキシ関連の機能を追加しました。その後、このプロジェクトは現在の名称としてmihomoを使用しています。つまり、「Metaコア」と「mihomoコア」は、現代において別々に進化している完全に独立した2つのコアではありません。前者は旧バージョンやクライアントの互換性表示、古いドキュメントで使われることが多く、後者が現在のメンテナンス名称です。

一部のクライアントでは今も「Clash Meta」と表示されますが、コアのファイル名、起動ログ、プロジェクトドキュメントにはmihomoと記載されている場合があります。この名称の違いだけでクライアントが古いとは判断できません。確認すべきなのはコアのバージョン日付、配布元、対応する設定項目、更新が正常に行われているかどうかです。画面上の1つのラベルだけで結論を出すのは避けましょう。

比較項目	オリジナル版Clash	Clash.Meta	mihomo
プロジェクトの位置づけ	基本設定体系の原型	拡張系統の旧称	Meta系統における現在のメンテナンス名称
メンテナンス状況	継続的なメンテナンスを終了	旧バージョンや画面表示では現在も広く使用	継続的にリリースと修正を実施
適した用途	旧設定の再現、互換性の検証	過去のドキュメントや古いクライアントの識別	新規インストール、最新プロトコル、複雑なルール振り分け
設定上の関係	基本項目を提供	基本構造を拡張	拡張を引き継ぎながら継続的に調整

2. 対応プロトコルの違い：まずサブスクリプションのノード種類を確認

対応プロトコルは、コア選びで最も直接的な判断材料です。オリジナル版Clashは、メンテナンスされていた時期に実装された一般的なプロキシタイプ、たとえばShadowsocks、SOCKS、HTTP、VMess、Trojanなどを扱えますが、後にMeta系統へ追加されたすべてのプロトコルや拡張パラメータには対応していません。サブスクリプションにVLESS、Reality、Hysteria2、TUIC、または新しいWireGuardの使い方が含まれる場合は、通常、比較的新しいmihomoコアが必要です。あわせて、ノード提供元が指定する具体的な項目を現在のバージョンがサポートしているか確認してください。

プロトコル名が同じでも、互換性が保証されるわけではありません。たとえばShadowsocksでは暗号方式も関係し、VMessやVLESSではWebSocket、gRPC、TLS、Realityなどの転送パラメータを組み合わせることがあります。Hysteria2やTUICでは、証明書、輻輳制御、ポート範囲、UDPネットワークの条件も影響します。コアにはノードの種類だけでなく、そのノードで使われるパラメータの組み合わせを解析する能力が必要です。

サブスクリプションをインポートした後にノードが消える、設定の読み込みに失敗する、ログに項目の解析エラーが出る場合は、まず元の設定にあるtype、network、cipher、reality-optsなどの項目を確認し、コアのバージョンと照合します。システムプロキシを何度も切り替えるのは後にしましょう。設定の読み込み自体に失敗している場合、システムプロキシの状態を変えてもプロトコル解析の問題は解決しません。

プロトコル要件でコアを選ぶ

従来型のノードと基本ルールだけ：古いコアでも動作する可能性はありますが、新しい端末でメンテナンスが終了したオリジナル版をあえて選ぶ必要はありません。
VLESSまたはRealityを含むサブスクリプション：比較的新しいmihomoを選び、リンクをインポートできるだけでなく、クライアントが実際にそのコアを呼び出しているか確認します。
Hysteria2、TUICなどUDP関連プロトコルが必要：コアの対応状況に加えて、ローカルネットワーク、ルーター、サーバー側のポートポリシーも確認します。
サブスクリプション変換で設定を生成：変換先はmihomoまたはClash.Meta形式に合わせ、ツールによってオリジナル版Clash向けに拡張項目が削除されないようにします。

3. ルール、プロキシグループ、DNS機能の違い

基本的なルール記述は、3つの名称が示すコア体系の間で高い連続性を保っています。一般的なDOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP、MATCHは今も設定の骨格であり、select、url-test、fallback、load-balanceなどのプロキシグループもClashの設計思想を引き継いでいます。そのため、多くの基本的なサブスクリプションはオリジナル版の構造からmihomoへ移行できます。

違いが現れやすいのは、拡張ルール、ルールセットの形式、スニッフィング、DNS振り分け、プロキシグループの追加パラメータです。mihomoはより豊富なルール表現に対応し、ルールセット、プロセス情報、ネットワーク種別、論理条件を組み合わせてトラフィックを振り分けられます。具体的な項目はバージョンによって変化するため、複雑なルールを使う際は対象バージョンのドキュメントを確認し、何年も前の例をそのまま現在の設定へコピーしないでください。

DNSについては、オリジナル版Clashにもfake-ipなどの基本機能があります。mihomoでは、ドメイン解決ポリシー、指定DNSサーバー、ルールとの連動、Fake IPの除外などをより細かく制御できます。設定が複雑になるほど、DNSリクエストを誰が処理するのか、ドメインをいつ解決するのか、ルール判定でドメインと宛先IPのどちらを使うのかを明確にする必要があります。これを曖昧にすると、ノード自体には接続できるのに特定サイトの名前解決だけ失敗する、LAN内のドメインが使えない、アプリが想定したポリシーを迂回するといった問題が起こります。

proxy-groups:
  - name: 自動選択
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300

rules:
  - DOMAIN-SUFFIX,example.com,自動選択
  - GEOIP,CN,DIRECT
  - MATCH,自動選択

上の例は一般的な基本構造ですが、proxy-providers内にprovider-mainというプロキシセットがすでに定義されていることが前提です。测速用URL、間隔、ポリシー名も実際のネットワークに合わせて調整してください。古い設定から移行する場合は、まず単純なルールを残して接続性を確認し、その後でルールセット、DNSポリシー、論理条件を段階的に追加するほうが、複雑な設定を一度に読み込むより問題を特定しやすくなります。

ルール移行時に確認する項目

各ルールの転送先が、実際に存在するプロキシグループまたはプロキシノードに対応しているか確認します。
リモートルールセットの形式、種類、ダウンロードURLが現在のコアの要件と一致しているか確認します。
プロキシグループが参照するプロキシセットの更新に成功しているか確認し、グループ内に利用可能なノードがない状態を避けます。
MATCHはルール一覧の末尾に残し、それ以前のルールに一致しなかった接続を受け持たせます。
DNSモードを変更した後は、必要に応じてシステムのDNSキャッシュを消去し、ドメインとIPアドレスへのアクセスを分けてテストします。

4. 設定互換性：基本互換と双方向互換は別

mihomoはオリジナル版Clashの多くの項目を引き継いでいるため、オリジナル版の設定からmihomoへの移行は通常スムーズです。ただし、逆方向も同じとは限りません。新しいプロトコル、拡張ルール、強化されたDNS項目、新しいTUNパラメータを使っている場合、オリジナル版コアは読み込みを拒否したり、認識できない部分を無視したりする可能性があります。「Clash設定に対応」という表現は、一般に基本構造への対応を意味し、任意のバージョンが同じファイルを無条件に読み取れるという意味ではありません。

コアの設定とクライアントの設定も区別する必要があります。YAML内のプロキシポート、ルール、DNSは通常コアが読み取ります。一方、OS起動時の自動起動、トレイ動作、サブスクリプション更新間隔、画面テーマ、システムサービスの権限はクライアント側の設定です。あるクライアントの設定ディレクトリ全体を別のクライアントへコピーすると、パス、データベース、サービス状態に関する問題まで持ち込むことがあります。移行時はサブスクリプションを再インポートするか、確認済みのコア用YAMLだけを移すほうが安全です。

クライアントによっては、サブスクリプションファイルとは別に上書き設定を生成し、TUN、DNS、コントロールポート、ローカルルールを追加します。画面で確認できる設定と、最終的にコアへ渡される設定が異なる場合があります。互換性の問題を調べる際は、クライアントが提供する「実行時設定」「マージ後の設定」やコアのログを確認し、サブスクリプションの原文だけを見て判断しないでください。

旧コアからmihomoへ移行する手順

現在利用できるクライアント、コアのバージョン、待ち受けポート、システムプロキシの状態を記録します。
必要なローカルルールとプロキシグループの設計をエクスポートし、クライアントの実行ディレクトリをそのままコピーしないでください。
新しいクライアントに元のサブスクリプションをインポートし、まずカスタム上書きを無効にしてノード接続を確認します。
ルール、DNS、TUNの設定を1項目ずつ戻し、変更するたびに起動ログを確認します。
ブラウザー、コマンドラインプログラム、ストアアプリ、UDPが必要なアプリを個別にテストし、取り込み範囲が想定どおりか確認します。

5. TUNモードとOSのトラフィック取り込み範囲

システムプロキシは、OSのプロキシ設定に従うアプリに主な影響を与え、ブラウザーや一般的なデスクトップソフトに適しています。一部のゲーム、コマンドラインツール、ストアアプリ、独自のネットワークスタックを使うプログラムは、システムプロキシを読み取らないことがあります。TUNモードは仮想ネットワークインターフェースを通じてより広い範囲の通信を処理するため、TCPとUDPを一括して取り込みたい場合によく使われます。

mihomoはTUN、DNSハイジャック、自動ルーティング設定、トラフィックのスニッフィングに対応した、比較的充実した現代的な実装を備えています。ただし、最終的な動作はクライアントが権限を申請し、サービスをインストールし、システムルートを設定する方法にも左右されます。Windowsではサービスモードや管理者権限が必要になる場合があり、macOSではネットワーク拡張機能に関する許可を求められます。Linuxではデバイス権限、ルーティングテーブル、ファイアウォールが関係します。モバイル版クライアントは通常、システムVPNインターフェースを利用して動作し、バックグラウンド制限が接続の継続性に影響することもあります。

TUNモードは有効にしただけで必ず速くなるわけではありません。広がるのは取り込み範囲であり、DNS、ルーティング、ループバック処理の複雑さも増します。ブラウザーがシステムプロキシで問題なく動くなら、シンプルな設定を保つほうが管理しやすいでしょう。ゲームのUDP、ターミナルプログラム、特定のアプリがシステムプロキシを通らない場合は、TUNを有効にして項目ごとに確認するのが適切です。

オリジナル版コアから移行する際、古いTUNの例をそのまま写さないでください。ネットワークスタックの項目、自動ルーティングの設定、DNSとの組み合わせ方はバージョンによって変わることがあります。クライアントにTUNスイッチが用意されている場合は、まずクライアントが生成する設定を使い、ログを確認しながら除外するネットワーク、LANアクセス、DNSポリシーを追加するのがおすすめです。

要件	推奨モード	重点的に確認する項目
ブラウザーと一般的なオフィスソフト	システムプロキシ	プロキシポート、ルールの一致、ブラウザー独自のプロキシ設定
コマンドラインやシステムプロキシを読まないプログラム	TUNまたは環境変数を個別に設定	ルーティング、DNS、権限、LANアクセス
ゲームとUDPアプリ	アプリに応じてTUNを選択	ノードのUDP性能、プロトコル対応、ネットワークのパケットロス
サブスクリプションが利用可能かだけを確認	まずシステムプロキシを使用	変数を減らし、設定の読み込み成功を先に確認

6. リソース消費と性能：実際の設定で測定

「機能が多い」ことを「必ずリソース消費が大きい」と単純に結び付けることはできません。コアの負荷は通常、同時接続数、ルール数、ルールセットの容量、ログレベル、DNSキャッシュ、プロトコルの暗号方式、TUNで処理する通信量、クライアント画面によって決まります。同じ端末でも、簡潔なmihomo設定のほうが、大量のルールと継続的なデバッグログを読み込む古い設定より安定することがあります。

デスクトップクライアントに表示されるメモリ使用量には、GUI、WebView、サブスクリプションデータベース、更新サービスも含まれるため、すべてをコアの負荷と考えるべきではありません。コアを比較するなら、同じノード、同じルール、同じ取り込みモード、近い通信量の条件で独立したコアプロセスを観察します。起動直後のアイドル状態、継続的なダウンロード、接続数の増加、ルール更新後の変化を同時に記録して、初めて比較材料になります。

モバイル端末では、継続的なウェイクアップ、弱いネットワークでの再接続、バックグラウンド動作時間に特に注意が必要です。プロキシグループの测速間隔が短すぎると、テスト用URLへ周期的にアクセスします。自動更新するプロキシセットやルールセットが多い場合もネットワーク活動が増えます。ヘルスチェックと更新の間隔を適切に延ばし、常時のデバッグログを無効にし、使っていないルールセットを削除するほうが、古いコアへ戻すより効果的です。

よくある性能改善の順番

まずログレベルを通常利用に必要な水準へ戻し、詳細ログはトラブルシューティングの間だけ有効にします。
重複するルールと使っていないリモートルールセットを減らし、更新のたびに同じデータを複数処理しないようにします。
url-test、プロキシセットのヘルスチェック、サブスクリプション更新の間隔を適切に延ばします。
異常なリソース消費がコアプロセスによるものかクライアント画面によるものかを確認してから、アップグレード、リセット、クライアント変更を判断します。
TUNとシステムプロキシを切り替えて比較テストし、問題がトラフィックの取り込み範囲に関係するか確認します。

7. 用途別の選び方

新規ユーザーや新しい端末：比較的新しいmihomoコアを内蔵し、コアのバージョンを表示でき、設定ログを確認できるクライアントを選びます。現代のサブスクリプションでよく使われるプロトコルやルール形式に対応でき、今後の更新も容易です。クライアント名にClashが含まれるかどうかは本質ではなく、実際のコアとメンテナンス状況が重要です。

現在もオリジナル版Clashを使っている既存環境：現在の設定が安定しており、業務上変更する必要がないなら、まず実行環境を記録してから移行を計画すればよく、作業中に急いで置き換える必要はありません。ただし、新しいプロトコル、新しいOSへの対応、安全性や安定性の修正が必要になった時点で、メンテナンスが続いているmihomoへ移行すべきです。移行前は、プロキシグループ名、DNS、ルールセット、TUN項目を重点的に確認します。

Clash.Metaのダウンロード項目が表示された：まず公開日とコアのログを確認します。新しいクライアントでもユーザーが識別しやすいようにMetaという名称を使い続け、実際にはmihomoを動かしていることがあります。一方、長期間更新されていないインストーラーには古いMetaコアが含まれている可能性があります。同じ名称でも、メンテナンス状況は大きく異なる場合があります。

基本的なサブスクリプションとシステムプロキシだけを使う：それでもmihomoが適しています。新しいコアを選んだからといって、すべての高度な機能を有効にする必要はありません。シンプルなノード、プロキシグループ、ルールを使い続けられます。理解していない項目を新機能のために積み重ねるより、設定の範囲を明確に保つほうが信頼性は高くなります。

複雑なルール振り分け、最新プロトコル、TUNが必要：比較的新しいmihomoを優先し、システムサービス、権限、設定の上書きを正しく管理できるクライアントを選びます。問題が起きたら、「設定が読み込まれたか、ノードに接続できるか、ルールが一致したか、システムが通信を取り込んでいるか」の順に確認し、複数の箇所を同時に変更しないようにします。