Clashのオリジナル版・Meta・mihomoの違い｜系譜と設定互換性を比較

コア・クライアント・設定ファイルを区別する

コアはプロキシ接続、DNS処理、ルール判定を実行するプログラムで、クライアントはそれらを管理するための画面です。クライアントはアップデート時にコアが変更されることも、ユーザーがコアを手動で選択できることもあります。そのため、ソフト名にClashと付いていても、対応プロトコルまでは判断できません。

設定ファイルはコアが読み込む入力データです。拡張子が同じ.yamlでも、YAML形式で記述されていることを示すだけで、ノードの種類やルール、拡張項目が各コアで認識されるとは限りません。

• クライアントのバージョン：画面、システムプロキシの切り替え、サブスクリプション管理、インストール時の問題を調べる際に確認します。
• コアの名称とバージョン：VLESS、Hysteria2、TUNや特定の設定項目が使えるかを判断するために確認します。
• 設定ファイルの生成先：サブスクリプション変換ツールの出力がオリジナル版Clash向けか、Meta／mihomo向けかを確認します。

系譜を整理：オリジナル版、Premium、Meta、mihomo

Clashオリジナル版とClash Premiumは対応機能の異なる系統

一般にClashオリジナル版と呼ばれるものは、Dreamacroプロジェクト系のClashを指します。互換性を検討するときは、オープンソース版とPremiumコアも区別する必要があります。PremiumにはTUN、ルールセット、スクリプトなどの拡張機能があり、これらをオープンソース版にも共通する機能として扱うことはできません。

元のプロジェクトは2023年11月に公開メンテナンスを終了しました。インストール済みの旧バージョンがすぐに動かなくなるわけではありませんが、新しいプロトコルや設定項目への対応、今後の互換性修正は期待できません。

Clash Metaは拡張系統、その後継名称がmihomo

Clash MetaはClashをベースに、プロトコル、DNS、ルーティング、接続処理などを拡張し、その後mihomoに名称変更されました。同じプロジェクトの発展過程にあたるため、2つのプログラムを連携して動かす必要はなく、mihomoを使うために先にMetaをインストールする必要もありません。

古い記事にある「Metaコア」や設定ファイルのコメントに記載されたMeta、最近のクライアントに表示されるmihomoは、同じプロジェクトの系譜を指していることが多いものの、バージョン差には注意が必要です。初期のMetaビルドが、新しいmihomoビルドと同等とは限りません。

プロトコル対応：画面から読み込めるかより、ノードを解析できるかが重要

ノードのプロトコルは、設定のtypeフィールドで指定します。クライアント上ではサブスクリプションを保存できても、コアの起動時に非対応のプロキシタイプとしてエラーになる場合があります。この場合、プロキシモードや待ち受けポートを変更しても、プロトコルの解析エラーは解決しません。

REALITYは単独のプロキシタイプではない

一般的なmihomo設定では、REALITYはVLESSノードで使用するセキュリティハンドシェイク関連の設定であり、typeをrealityにするものではありません。type: vless、tls、servername、reality-optsなどの項目がサーバー側と一致しているか確認してください。VLESSに対応していても、任意のトランスポート構成や新しいパラメーターがすべて使えるとは限りません。

サブスクリプション変換で旧コアに新プロトコルを追加することはできない

変換ツールはYAMLの並べ替え、プロキシグループの生成、URIパラメーターから設定項目への変換などはできますが、オリジナル版コアにHysteria2の実装を追加することはできません。変換後にノードが減っている場合は、サブスクリプション自体が無効だと判断する前に、変換先の設定で非対応プロトコルが除外されていないか確認しましょう。

サブスクリプションURLには通常、アクセストークンが含まれます。問題を調べる際は、機密情報を伏せた単一ノードの設定、エラーメッセージ、コアのバージョンだけを共有し、URL全体を公開の場に貼り付けないでください。

ルールと設定項目：基本構文は似ていても、拡張機能は流用できない

mixed-port、mode、proxies、proxy-groups、rulesは、よく使われる設定項目です。DOMAIN、DOMAIN-SUFFIX、IP-CIDR、MATCHなどの基本ルールも広く共通していますが、設定全体をコア間で自由にコピーできるわけではありません。

• ルールセット：Premiumとmihomoではrule-providersやRULE-SETが使われていますが、これを根拠にオリジナル版のオープンソースビルドも対応すると判断することはできません。
• 拡張ルール：mihomoの論理演算、プロセスパス、インバウンド関連ルールなどは、具体的なルール名と必要なバージョンを確認してください。
• ルールファイルの形式：テキスト、YAML、mihomoのMRS形式は、拡張子を変更するだけで相互に変換できるファイルではありません。
• スクリプト：Premiumのscript設定はmihomo共通の互換インターフェースではありません。移行時には、通常、ルールやほかの対応機能に書き換える必要があります。
• DNSの拡張：fake-ip、DNSポリシー、スニッフィングはそれぞれ異なるレイヤーの設定です。古い例にある項目名やデフォルト動作を、新しいバージョンの仕様としてそのまま使わないでください。

以下は基本的な項目だけを残したテスト用設定です。ローカルの7890ポートで待ち受け、ルールモードを使い、最終的にトラフィックをDIRECTへ送ります。コアが設定を読み込めることと、ローカルプロキシ接続を受け付けることを確認するもので、リモートのプロキシノードは含まれていません。

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

proxies: []

proxy-groups:
  - name: 出口選択
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,出口選択
  - MATCH,DIRECT

基本設定で起動できたら、ノード、DNS、ルールセット、TUNを順番に追加します。拡張設定を一度に数百行読み込むと、項目、ファイルパス、外部リソースなど複数の原因が重なり、問題の切り分けに時間がかかります。

TUNとDNS：コアの対応だけでは有効にならない

TUNは仮想ネットワークインターフェースを通じてルーティングされたトラフィックを受け取り、システムプロキシ設定に従わないアプリの通信を処理するのに適しています。第4のプロキシモードではありません。TUNを有効にした後も、トラフィックの処理方法はrule、global、directで決まります。

オリジナル版Clashのオープンソース版とPremiumでは、TUNへの対応に大きな違いがあります。mihomoもTUNに対応していますが、OSの権限、ルーティング設定、クライアント側の連携が必要です。デスクトップOSでは管理者権限やサービスモードが必要になることが多く、Androidクライアントでは通常、システムVPNの許可を通じて接続します。

mihomoのTUN設定例

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

これは設定の一部であり、すべてのプラットフォームで単独利用できる設定ではありません。1053は例で使用しているコアのDNS待ち受けポート、any:53は通常のDNS通信のリダイレクト先です。両方を同じポートにする必要はありません。例にある上流DNSが現在のネットワークから到達できない場合は、利用可能なDNSリゾルバーに変更してください。

• stack: mixedはmihomoで選択できるネットワークスタック設定の一つです。すべての旧バージョンのコアにそのままコピーしないでください。
• auto-routeは関連ルートを自動設定する項目で、ほかのVPN、ルーターのポリシー、ファイアウォールの制限を必ず回避できるわけではありません。
• auto-detect-interfaceは出力インターフェースを自動検出する項目です。複数のネットワークアダプターがある環境では、実際の出力先も確認してください。
• アプリ自身が送信するHTTPS DNSリクエストは、any:53で捕捉できるとは限りません。アプリのセキュアDNS設定と接続履歴も確認してください。

TUNを有効にした後に完全に通信できなくなった場合は、まずTUNを無効にし、ローカルの7890ポートだけで正常にアクセスできるか確認します。基本的なプロキシ接続は使えてTUNだけが動かない場合に、権限、ルーティング、DNSを調べましょう。すぐにサブスクリプションを変更する必要はありません。

クライアントとコアの対応関係・バージョンを確認する

クライアント名はあくまで手がかりです。最終的には、インストール済みの環境で実際に動作しているコアを確認してください。コアの切り替え、テスト版チャンネル、任意のバイナリパスに対応するクライアントもあります。また、アプリの画面に表示されるバージョンとコアのバージョンが連動して更新されるとは限りません。

コマンドラインを使える場合は、バイナリに直接問い合わせる

# Linux または macOS：実際のコアがあるディレクトリで実行
./mihomo -v
./mihomo -t -f ./config.yaml

# Windows PowerShell：実際のコアがあるディレクトリで実行
.\mihomo.exe -v
.\mihomo.exe -t -f .\config.yaml

-vはバージョン情報の表示、-tは設定のテストに使います。クライアントによってファイル名が変更されている場合があるため、実際のファイル名を指定してください。相対パスを使ったルールセットや証明書をテストする際は、作業ディレクトリをクライアントの実行環境に合わせます。必要に応じて-dで設定ディレクトリを指定してください。

テストに合格しても、今回の確認で読み込みを妨げる問題が見つからなかったという意味に限られます。リモートノードに接続できることや、TLSパラメーターが正しいことまでは保証しません。コマンドラインを使えない場合は、クライアントの「アプリ情報」や「コア」の画面、起動ログでコア名とバージョンを確認してください。メニューの場所はクライアントによって異なります。

移行時の確認順：まず読み込み、次に接続、最後にルールを確認

1. 現在の状態を保存する。設定、サブスクリプションの配信元、プロキシグループの選択、DNSとTUNの設定をバックアップし、元に戻せる環境を残します。
2. 適切なサブスクリプションの出力先を選ぶ。VLESS、REALITY、Hysteria2などのノードが含まれる場合は、サービス提供元が明記しているMeta／mihomo向け設定を優先し、「Clash」という表記だけで判断しないでください。
3. 最終的な設定をテストする。クライアントがサブスクリプション、上書きファイル、画面上の設定を統合する場合があります。ダウンロードした元のYAMLだけでなく、コアに実際に渡される設定を確認してください。
4. 基本の接続を確認する。いったんTUNを無効にし、明示したローカルポートでテストします。システムプロキシ、アプリのプロキシ設定、コアの待ち受けポートを一致させてください。
5. ルールの適用を確認する。接続履歴に表示されるドメイン、適用ルール、出力先のプロキシグループを確認し、グループの選択ミスをコアの非互換と取り違えないようにします。
6. 拡張機能を一つずつ戻す。DNSポリシー、ルールセット、スニッフィング、TUNを順番に有効にし、項目を追加するたびに同じアクセス試験を行います。

たとえば、ローカルの混合ポートが7890の場合、以下のコマンドでHTTPプロキシを明示できます。システムプロキシの設定に左右されずにテストでき、実行にはcurlのインストールが必要です。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

例では接続タイムアウトを10秒に設定しています。これは待ち時間を制限するための値で、実測の遅延を示すものではありません。HTTPレスポンスが返れば、リクエストがローカルのプロキシ入口を通ったことがわかります。リモートノード経由で通信したかどうかは、コアの接続履歴で確認してください。前述の基本設定では、リクエストは最終的にDIRECTへ送られます。

インストール前にクライアントの選び方ガイドを確認し、設定項目は設定リファレンスで調べられます。互換性は「実際のコア → 設定項目 → 動作結果」の順に確認し、クライアント名だけで判断しないでください。