Clash・Clash Meta・mihomoの違い｜バージョンの変遷と設定互換性

クライアントのダウンロードとサブスクリプションの追加

これから使い始める場合は、まずClashクライアントのダウンロードページで、OSとCPUアーキテクチャに合ったクライアントを選びましょう。インストール後、クライアントの「設定」または「Profiles」画面から、サービス事業者が発行したサブスクリプションURLを追加します。読み込んだ設定を選択し、プロキシグループから接続先ノードを選んでください。サブスクリプションURLには認証情報が含まれることがあります。URL全体を公開コメントや問い合わせ画面のスクリーンショットに載せないでください。

コアの違いを見分けるには、まず3つの役割を分けて考えます。クライアントはウィンドウやトレイ、サブスクリプション管理、システム設定の画面を提供します。コアは設定の解析、プロキシ接続、ルールの適用を担います。サブスクリプションにはノードのほか、プロキシグループ、ルール、DNS設定が含まれる場合があります。クライアントでサブスクリプションを正常に取得できても、その中のすべてのプロトコルをコアが使えるとは限りません。

インポート後に確認すること

1. サブスクリプションを正常に取得できたか、インストール時のサンプル設定ではなく、追加した設定が有効になっているか確認します。
2. 起動ログを確認し、設定の解析エラー、未対応のノード種別、待受ポートの競合がないか調べます。
3. デスクトップでは、まずシステムプロキシ経由でブラウザーをテストします。Androidでは通常、VPN接続の許可が必要です。
4. システムプロキシに対応していないアプリの通信も取り込みたい場合は、ほかの設定を一度に変更せず、TUNを個別に設定します。

Clash・Meta・mihomoの変遷

オリジナルClashとPremiumブランチ

オリジナルClashは通常、Dreamacroのプロジェクトとそのコアを指します。proxies、proxy-groups、rulesなど、広く使われているYAML設定形式を確立しました。また、オリジナルのエコシステムにはPremiumコアもあります。オープンソース版とPremium版の機能をひとまとめにして比較することはできません。PremiumにはTUN、ルールセット、スクリプトなどの拡張機能がありましたが、対応範囲は使用するビルドによって異なります。

オリジナルのプロジェクトは2023年11月にメンテナンスを終了しました。旧クライアントや旧コアは引き続き動作する場合がありますが、新しいノードプロトコル、OSの変更、新たに追加された設定項目に対応するには、同じ旧プログラムを再ダウンロードするだけでは不十分です。既存の設定は移行時の参考にできますが、新規導入では、現在もメンテナンスされ、サブスクリプションの要件に合うコアを優先しましょう。

Clash Metaからmihomoへ

Clash MetaはClashのエコシステムから派生したプロジェクトで、プロキシプロトコル、DNS、ルールマッチング、透過プロキシなどの機能を拡張しました。その後、プロジェクト名はmihomoに変更されました。そのため、サービス事業者の「Meta形式」、解説記事の「Clash.Meta」、クライアントに表示される「mihomoコア」は、同じプロジェクトの変遷を指していることがよくあります。

名称が引き継がれていても、すべての時期のバージョンが同等とは限りません。古いMetaビルドには、後から追加されたプロトコルや設定項目がない場合があります。新しいmihomoでも、設定項目の挙動が変更されることがあります。移行の可否は、名称にMetaが含まれるかだけでなく、実際のバージョンと起動結果に基づいて判断してください。

ノードプロトコルとサブスクリプション形式の互換性

サブスクリプションでmihomoが必要かを判断するには、ノードのtypeを確認するのが最も簡単です。設定ファイル全体を公開せず、必要な項目だけをローカルで確認してください。Shadowsocks、VMess、TrojanなどはClashエコシステムで長く使われている一般的な方式ですが、同じプロトコルでも暗号化方式、トランスポート、拡張パラメーターが異なる場合があります。

サブスクリプションURLとノード共有リンク

ClashのYAML設定には通常、プロキシグループとルールが含まれます。プロキシプロバイダーのファイルにはノード一覧のみが含まれることが多く、Base64形式のノード一覧や単一のss://、vmess://共有リンクは、さらに別の入力形式です。これらをクライアントが自動判別・変換できるかどうかはクライアントの機能によります。どのコアでも、あらゆるリンクを完全な設定として直接読み込めるとは限りません。

サービス事業者の管理画面でサブスクリプション形式を選ぶ際、「Clash Meta」や「mihomo」の項目があり、サブスクリプションにVLESS、Reality、Hysteria 2などが含まれる場合は、対応する形式を優先してください。旧Clash形式を選ぶと、変換サービスが非対応ノードを削除することがあります。インポート後にノード数が大きく減った場合は、まず出力形式を確認しましょう。すぐにアカウントの通信量を使い切ったと判断しないでください。

ルール、DNS、TUN設定の違い

ルールの順序とポリシー名

DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP、MATCHは一般的なルール種別です。ルールは上から順に評価され、最初に一致したルールで通信先が決まります。末尾にMATCHを置くと、どのルールにも一致しない通信の処理を明示できます。移行時は、ルールが参照するプロキシグループが存在するかも確認してください。グループ名の空白や大文字・小文字も一致させる必要があります。

mihomoはGEOSITEや論理ルールなど、より多くのマッチング機能を備えています。また、プロセスに基づくマッチングは、プラットフォーム、実行権限、機能設定によって利用可否が変わります。これらのルールを含むサブスクリプションを古いコアで読み込むと、解析エラーが発生することがあります。ルール名が認識されても、必要な地理データやリモートルールファイルの読み込みに失敗すれば、最終的な動作に影響します。

ルールプロバイダーと旧スクリプト

rule-providersはルールセットを読み込み、RULE-SETはそれらを参照するために使います。確認時は、このトップレベル項目があるかだけでなく、プロバイダーのbehavior、ファイル形式、パスも確認してください。Premiumの旧script設定は、mihomoの同等機能としてそのまま使えるわけではありません。この種の設定を移行する場合は、対応するルールとプロキシグループで構成し直す必要があります。

DNSはサーバーアドレスだけではない

DNS設定には、待受アドレス、上流サーバー、enhanced-mode、fake-ip-filterなどが含まれます。mihomoにはDNSポリシーや通信のスニッフィングなどの関連機能もあります。旧設定の項目が読み込まれても、旧コアと初期動作が完全に同じとは限りません。移行後は、ドメインの名前解決、ルールの適用、実際の接続をそれぞれ確認してください。

たとえばfake-ipを有効にすると、アプリに198.18.0.0/16の範囲にある仮想アドレスが割り当てられることがあります。これはサーバーの実IPではありません。後続のアドレス対応付けには、アプリの通信を同じコアに取り込む必要があります。DNS設定だけをコピーし、通信を取り込む経路を設定しないと、「名前解決はできるのにWebページが開かない」という状態になることがあります。

TUNとシステムプロキシ

システムプロキシは、OSのプロキシ設定に従うアプリで主に使われます。TUNは仮想ネットワークインターフェースを通じて通信を取り込み、通常は管理者権限、サービスモード、またはOS側の機能が必要です。Windows、macOS、Linuxではルーティングの設定方法が異なります。Androidクライアントは一般にVpnServiceでVPNインターフェースを作成します。クライアント画面にTUNのスイッチがあっても、すべてのプラットフォームで実装が同じとは限りません。

tun.stack、auto-route、dns-hijackなどの設定項目は、対象バージョンとプラットフォームに照らして確認してください。初めて移行する場合は、まずTUNを無効にし、システムプロキシでノードに接続できることを確認してから、ルーティングとDNSの取り込みを一つずつ有効にしましょう。プロトコル非互換、権限不足、ルート競合を切り分けやすくなります。

コアのバージョン確認と設定テスト

GUIクライアントでは、「バージョン情報」画面のコア情報や、起動ログのバージョン行を確認します。具体的な画面名はクライアントによって異なります。クライアント自体のバージョンを、コアに関する問題報告へ記載しないよう注意してください。コマンドラインで利用する場合は、次の2つのコマンドを実行します。1つ目はバージョン表示、2つ目は指定した設定の検証です。どちらも実際に起動する予定のバイナリを指定してください。

mihomo -v
mihomo -t -f ./config.yaml

システムの検索パスにmihomoが登録されていない場合、LinuxやmacOSでは現在のディレクトリから実行する際に./mihomoを使います。WindowsではPowerShellから.\mihomo.exeを実行できます。複数のコピーがある場合は、クライアントの起動パスも確認してください。ターミナルでは新しいコアをテストしていても、GUIクライアントが古いコアを使い続けていることがあります。

最小構成とポートの確認

以下のYAMLは設定構造とローカルの待受を確認するためのもので、サブスクリプションのノードは含まれず、外部向けのプロキシ接続も提供しません。混合ポートを7890に設定し、HTTPとSOCKS5の両方のプロキシ要求を受け付けます。allow-lan: falseにより、アクセスをローカルに限定します。別のテストファイルとして保存し、使用中のサブスクリプション設定を上書きしないでください。

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

proxy-groups:
  - name: テスト用出口
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.com,テスト用出口
  - MATCH,DIRECT

設定の検証に成功したらコアを起動し、次のコマンドでHTTPプロキシの待受を確認できます。この例ではDIRECTを選択しているため、成功しても確認できるのはローカルのプロキシ入口と直接接続だけです。サブスクリプションのノードが使えることを示すものではありません。ログにポート使用中のエラーが出る場合は、別のクライアントを終了するか、テスト用ポートとリクエスト先のポートをそろえて変更してください。

curl --proxy http://127.0.0.1:7890 --head https://example.com

設定検証に成功しても、ネットワーク接続が保証されるわけではありません。ノードのパスワード、リモート証明書、サブスクリプションの残量、通信事業者によるUDP制限までは確認できません。実際のサブスクリプションを使ってノードを一つずつテストし、接続ログも確認してください。コントロールAPIは通常127.0.0.1:9090で待ち受けますが、これはプロキシポートではありません。有効にする場合はアクセスキーを設定し、インターネットに直接公開しないでください。

旧設定の移行とよくあるエラー

移行の手順

1. 元の設定を残す。 ローカルの上書き設定、ルールファイル、プロキシグループの選択内容を別にバックアップし、唯一のコピーを直接編集しないでください。
2. 対応するサブスクリプションを取得する。 サービス事業者が提供するMeta形式またはmihomo形式を優先し、新旧の設定でノード数とプロトコル種別を確認します。
3. 基本の接続をテストする。 まずシステムプロキシを使い、ルールモードのまま、実際のノードで少なくとも1つのWebサイトにアクセスできることを確認します。
4. カスタム設定を統合する。 ルールプロバイダー、DNS、スニッフィングの設定を一つずつ追加し、変更するたびに起動ログを確認します。
5. TUNと自動起動を戻す。 基本の接続が安定してから仮想ネットワークインターフェースとバックグラウンドサービスを有効にし、端末を再起動して設定が維持されるか確認します。

エラーの分類

コアの選び方とよくある質問

新規導入では、既存のサブスクリプションに対応し、継続的にメンテナンスされているクライアントとコアを優先してください。VLESS、Reality、Hysteria 2や新しいトラフィック振り分け機能が必要な場合は、通常、適切なバージョンのmihomoを選びます。旧環境をすぐに移行できない場合は、まず現在の機能要件とシステム制限を確認してから切り替えを計画しましょう。名称が変わったからといって、同じ設定を何度もインポートする必要はありません。

ハードウェアのアーキテクチャも選定時に考慮しましょう。Apple Silicon搭載MacとIntel Macではインストーラーが異なります。Linuxのx86_64用とarm64用のバイナリも互換性はありません。GUIクライアントはデスクトップとの連携や更新管理も担いますが、画面のないサーバーではコマンドラインのコアを利用できます。プラットフォームごとの選択肢は比較・選び方、インストールと設定の追加手順はクイックスタートをご覧ください。