Clashコアのバージョン違い：オリジナル版・Meta・mihomoの設定互換性

クライアントの設定画面や設定リポジトリ、サブスクリプションの説明では、Clash、Clash.Meta、Meta、mihomoという名称が頻繁に登場します。これらは完全に独立した4種類の設定体系ではありませんが、同じプログラムの表記違いと単純に考えることもできません。YAMLを読み込めるか判断するには、ファイルの拡張子だけでなく、実際に動作しているコア、コアのバージョン、クライアントによる設定の前処理、さらにサブスクリプションが出力する拡張項目まで確認する必要があります。

基本的な設定の多くは、これらのコア間で流用できます。たとえば、待ち受けポート、プロキシノード、プロキシグループ、一般的なドメインルールなどです。一方、TUN、トラフィック解析、新しいプロトコル、ルールセット、DNS拡張、プロセス指定といった機能には明確な差があります。コアを誤ると、設定ファイル全体が読めなくなるとは限りません。一部の項目だけ拒否されたり、特定のノードを作成できなかったり、ルールが想定どおり適用されなかったり、GUIクライアントに対応するスイッチが表示されなかったりします。

Clash、Clash.Meta、mihomoの名称関係

オリジナル版Clash

一般に「オリジナル版Clash」と呼ばれるものは、初期のオープンソースClashコアと、その設定構文を指します。現在も広く使われている基本構造を確立しており、proxies、proxy-groups、rules、dns、mixed-port、external-controllerなどの項目が含まれます。多くのサブスクリプション変換ツールやクライアント用設定テンプレートも、この構造を共通の土台としています。

オリジナル版のプロジェクトは、継続的なメンテナンスを終了しています。そのため、古い端末や既存のクライアントでは引き続き動作する可能性がありますが、新しいプロトコル、プラットフォームのネットワークAPIの変更、今後追加される設定項目には対応しません。HTTP、SOCKS5、Shadowsocks、Trojanなど従来の機能だけを使う古い設定なら、短期的には違いを感じにくいでしょう。しかし、サブスクリプションに新しいノード種別や新しいルール機能への依存が加わると、互換性の限界が表面化します。

Clash.Meta

Clash.Metaは、Clashの設定体系を基盤に発展した派生コアです。多くの基本項目を維持しながら、プロキシプロトコル、TUN、DNS、スニッフィング、ルール種別、プラットフォーム対応を拡張しています。一部のクライアントではコアを単に「Meta」と表示しており、設定ドキュメントでも「Meta専用項目」という表現がよく使われます。そのため、この名称は現在もサブスクリプションのテンプレートやエラーログに登場します。

mihomo

mihomoは、Clash.Metaが後に採用したプロジェクト名です。系譜としては、現在の一般的な用法における新しいMetaとmihomoは、相互変換が必要な2種類の設定形式ではなく、同じ継続開発ラインを指すことが多いです。ただし、実際の判断ではバージョン番号を確認してください。初期のClash.Metaから現在のmihomoに至るまで、項目の追加、デフォルト動作の調整、プロトコル実装の更新が行われています。

したがって、「Meta対応」と「現在のmihomo設定をすべてサポートしていること」は同義ではありません。古いクライアントにMetaコアが内蔵されていても、後から追加されたノードパラメータを認識できない場合があります。反対に、新しいmihomoは基本的なClash設定の大部分を読み込めますが、古い項目の動作、デフォルト値、推奨記法が変わっている可能性があります。

メンテナンス状況・プロトコル・ルール機能の比較

プロトコル対応は、最も分かりやすい違いです。サブスクリプション内の各ノードには、typeとそのパラメータが定義されています。コアがノード種別を認識できない場合、通常は設定チェックや起動ログに解析エラーが表示されます。プロトコル自体には対応していても、特定のパラメータに未対応なら項目エラーになることがあります。この問題はプロキシグループ名を変更しても解決しません。まず、クライアントに内蔵されたコアのバージョンと、ノードが要求するプロトコルを確認してください。

ルール機能の違いは、より見つけにくいものです。DOMAIN-SUFFIX、DOMAIN、IP-CIDR、GEOIP、MATCHなどの従来型ルールは高い汎用性を持ちます。一方、ルールセットの動作、プロセス名、ネットワーク種別、インバウンドのタグ、論理演算を含む設定は、mihomoの具体的なバージョンに大きく依存します。設定が起動できても、拡張ルールが作成者の意図どおりに実行されるとは限りません。移行後は接続ログで実際に適用された項目を確認しましょう。

通常互換性のあるYAML項目

以下の構造は、複数のバージョンで使い回す設定の基本層に適しています。項目の関係だけを示しており、実際のサーバー認証情報は含みません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: Example-Node
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Example-Node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

mixed-portはHTTPとSOCKSプロキシの入口を同時に提供します。mode: ruleは、ルールに基づいて接続先を決める設定です。プロキシグループ名は、ルール末尾で参照する対象と一致していなければなりません。この種のミスはコアの派生元とは無関係です。たとえばルールがProxyを指しているのに、実際のグループ名がPROXYなら、どのコアでも両者を同じグループだと自動判定できません。

ノード項目は、互換性確認の第一段階です。proxiesリスト自体が一般的な構造であっても、内部のプロトコル種別、トランスポート層パラメータ、TLSフィンガープリント、UDPの動作、認証オプションは、特定のバージョンでしか利用できない場合があります。サブスクリプションサービスがノードテンプレートを更新した後、古いクライアントが突然起動できなくなった場合、コアのバージョンが出力形式に追いついていない可能性があります。

DNSは第二段階です。従来のenhanced-mode: fake-ip、デフォルトDNS、フォールバックDNSは広く知られていますが、nameserver-policy、プロキシサーバーのドメイン解決、Fake-IP除外リスト、上流DNSごとの通信形式は、コアのバージョンによって異なります。新しいmihomoの例を古いClashにコピーする前に、エラーが出た最初の行だけを削除するのではなく、各項目をコアのドキュメントで確認してください。

TUN・スニッフィング・ルールセットで問題が起きやすい理由

TUNは単なるオン・オフ設定ではない

TUNモードでは、コアが仮想ネットワークインターフェースを通じてトラフィックを受け取ります。システムプロキシ設定に従わないアプリにも適しています。mihomoの設定では、tunブロックとenable、stack、auto-route、auto-detect-interfaceなどの項目がよく使われます。正常に動作するかどうかは、OSの権限、ルーティングテーブル、既存VPN、仮想マシンのネットワーク、クライアントがサービスコンポーネントを正しく起動しているかどうかにも左右されます。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

この設定をオリジナル版や古いMetaコアに入れると、未知の項目として拒否されたり、プラットフォーム実装の違いでインターフェースを作成できなかったりします。コアが対応していても、GUIクライアントが起動時にTUN設定を書き換えることがあります。したがって、確認はコアのバージョン、設定チェックの結果、起動ログ、システム権限、最後にルーティングの競合という順番で進めるのが適切です。

スニッフィングでドメイン情報を復元

トラフィックスニッフィングは、HTTP、TLSなどの識別可能な通信から宛先ドメインを抽出します。IPアドレスへの接続にしか見えないリクエストも、ドメインルールの判定対象にできます。mihomoでは、スニッフィングするプロトコル、ポート範囲、強制的に指定するドメイン、除外するドメインを細かく制御できます。古いコアはこれらの項目をそのまま扱えず、設定を誤るとLANサービス、ゲーム接続、特殊なハンドシェイクを使うアプリに影響することもあります。

ルールセットは形式と動作を同時に確認する

リモートルールセットでは、ダウンロードURL、キャッシュ更新、ルールの動作種別、コンテンツ形式を確認する必要があります。コアやバージョンによって、Rule ProviderやRule Setの項目名、ペイロード形式、更新方法が異なる場合があります。ルールファイルのダウンロードに成功しただけでは不十分です。対象ルールから参照されていること、セットの動作と内容が一致していることも確認してください。たとえば、ドメインのセットをIPネットワークのセットと同じ方法で解釈することはできません。

ルールリストは上から順に判定されます。どのコアを使っていても、早い位置に広範囲なルールがあると、後続の判定が止まります。MATCHは通常末尾に置きます。LANやプライベートアドレスを直接接続するルールは適切な位置に配置してください。Fake-IPを有効にした場合は、DNSマッピングとルール判定を接続ログと合わせて確認します。コアをアップグレードしても、ルール順序の誤りは自動修正されません。

クライアント名と実際のコアを確認する方法

GUIクライアントは通常、アプリケーションのディレクトリ内にコアファイルを格納し、制御インターフェースを通じてプロキシグループ、接続、ログ、設定状態を読み取ります。設定画面からコアを切り替えられるもの、特定の派生コアを固定で使うもの、アプリの更新時にコアも更新するものがあります。実際の環境は、次の順番で確認できます。

1. 概要画面またはログの先頭行を確認する。起動ログには通常、コア名、バージョン、ビルド情報が表示されます。クライアントの紹介ページより、現在実行中の状態を正確に把握できます。
2. クライアント内蔵の設定チェックを使う。まずYAML構文を検証し、エラーが未知の項目、ノード種別、無効な値のどれを指しているか確認します。
3. オーバーライドとサブスクリプション変換を確認する。クライアントは読み込み前にローカル設定を統合する場合があります。ディスク上のサブスクリプション原文が、コアに最終的に渡される設定と同じとは限りません。
4. 制御インターフェースの互換性を確認する。mihomoは多くのClash API構造を引き継いでいますが、拡張機能が古い画面にすべて表示されるとは限りません。
5. コアの切り替えが実際に反映されたか確認する。ファイルを変更した後は、古いプロセスを完全に停止してから再起動してください。バックグラウンドに残った古いインスタンスへ画面が接続し続けるのを防げます。

クライアント画面に特定の項目がないからといって、コアにその機能がないとは限りません。単に画面側に入力フォームが用意されていない可能性があります。逆に、画面に古いスイッチが残っていても、現在のコアが同じデフォルト値を使うとは限りません。高度な項目は、YAMLやオーバーライドファイルを編集し、起動後に最終設定とログを確認するのが確実です。

モバイルとデスクトップでは、システム機能にも違いがあります。デスクトップクライアントは、システムプロキシやTUNで通信を取り込みます。モバイルOSでは、通常システムが提供するVPNインターフェースに依存します。同じmihomo設定を複数のプラットフォームで使う場合、ノードとルールは流用できますが、インバウンドポート、TUNルート、LANアクセス、DNSの取り込み設定はプラットフォームごとに調整してください。

オリジナル版Clashからmihomoへ移行する手順

古いコアから移行する際は、最初から新機能をすべて追加しないことをおすすめします。まず既存設定を新しいコアで安定動作させ、その後DNS、TUN、スニッフィング、ルールセットを段階的に有効化すると、問題の切り分けが容易になります。

1. 元の設定とクライアント設定を保存する。サブスクリプション原文、ローカルオーバーライド、プロキシグループの選択、DNS設定をそれぞれバックアップし、複数の出所を戻しにくい1つのファイルへ混在させないようにします。
2. 最小構成を作る。利用可能なノードを1つ、選択用プロキシグループを1つ、少数のルールだけ残し、コアが起動して接続を確立できることを確認します。
3. すべてのノードとプロキシグループを戻す。グループ内の参照名、自動速度テストのURL、フィルター式、プロトコルパラメータを重点的に確認します。
4. ルールを戻す。まず従来のドメインルールとIPルールを追加し、その後リモートセットを導入します。変更するたびに、ルールの適用状況とログを確認してください。
5. DNSを設定する。基本の名前解決、プロキシノードのドメイン解決、Fake-IPの除外項目を確認し、続けてLANドメインや特殊なアプリを確認します。
6. 最後にTUNとスニッフィングを有効にする。この2つはシステムの通信入口と宛先の識別方法を変えるため、ブラウザー、ターミナル、ゲーム、LANアクセスを個別にテストしてください。

移行後に「ブラウザーは使えるのにターミナルは使えない」場合は、ターミナルがシステムプロキシを参照しているか、環境変数が設定されているか、TUNが必要かを確認します。「ノードには接続できるのにドメインを開けない」場合は、DNSの上流、Fake-IPモード、ノードサーバーのドメイン解決を確認します。「一部サイトでルールが誤る」場合は、すべてのノードを入れ替えるのではなく、実際に適用されたルールを調べてください。

新しいコアが非推奨項目を表示した場合は、互換処理に長く依存せず、現行バージョンのドキュメントに従って置き換えてください。設定ファイルは継続運用する基盤です。意味を失った項目を残すと、将来のアップグレードコストが増えます。サブスクリプションが生成する項目については、更新のたびに手作業で直すのではなく、サブスクリプションのテンプレートや変換ルールを調整するのが優先です。

利用シーン別のコア選定

既存の古い環境を使い続ける

端末が長期間オフラインで、設定が固定され、ノードプロトコルも安定しており、クライアントとOSのバージョンも変わらないなら、オリジナル版Clashで従来の用途を維持できる可能性があります。ただし、これは現状維持に向いた選択であり、新しい導入環境の基準には適しません。サブスクリプションに新しいプロトコルやパラメータが追加されると、古いコアの互換性問題がすぐに表面化することがあります。

新規インストールと更新頻度の高いサブスクリプション

新規インストール、サブスクリプションを頻繁に更新する環境、TUNが必要な環境、現代的なルール機能を使いたい場合は、新しいmihomoを内蔵したクライアントを優先してください。クライアントを選ぶ際は、画面のデザインだけでなく、コアの更新方法、設定ディレクトリ、ログの確認場所、システムプロキシの制御、TUNサービスのインストール方法も確認しましょう。

複数端末で設定を共有する

複数端末で使う設定は、互換性の高い基本層を中心にし、プラットフォームごとのオーバーライドを追加する構成が適しています。ノードとプロキシグループは同じサブスクリプションから取得し、デスクトップにはTUNやプロセスルールを追加します。モバイルではシステムVPNインターフェースに合う設定を残し、サーバーではコマンドラインサービスと環境変数の要件に合わせます。こうすれば、特定プラットフォーム専用の項目が他の端末の読み込みを妨げることを防げます。

サーバーまたはコマンドラインで導入する

Linuxサーバー、ソフトルーター、コンテナでコアを直接動かす場合は、継続的にメンテナンスされるmihomoを導入基盤にするのが適しています。設定構文だけでなく、管理可能なバージョン更新手順を定め、設定ディレクトリ、作業ディレクトリ、Geoデータの保存先、制御ポート、サービス権限を明確にしてください。アップグレード前に設定テストを実行し、サービスを再起動した後にログを確認することで、構文エラーをネットワーク障害と取り違えずに済みます。

よくある互換性の問題