Clash・Clash.Meta・mihomoの違いを比較｜機能と設定の互換性

名称の関係：オリジナル版、Premium、Meta系統

Clashの設定を移行できるか判断するには、まずGUIクライアントとプロキシコアを区別しましょう。クライアントはサブスクリプション管理、トレイメニュー、権限の要求、設定の生成を担い、コアはポートの待ち受け、DNSの解決、ルールの照合、アウトバウンド接続の確立を担います。同じクライアント名でも、搭載されているコアのバージョンは異なる場合があります。画面からYAMLを読み込めても、コアがすべての項目を実行できるとは限りません。

「オリジナルのClash、Clash.Meta、mihomoという3世代のコア」という呼び方は検索には便利ですが、厳密なプロジェクト系譜を表すものではありません。Clash.MetaはClashから派生したフォークで、mihomoはその系統が後に採用したプロジェクト名です。Clash.Metaと無関係な第3の実装ではありません。Premiumは元のClash系統の強化版であり、Metaと同一視できません。

オリジナルのClash：Dreamacro/clashに代表されるオープンソースコア。一般的なYAML設定構造、ルールモード、プロキシグループ、コントロールAPIの基礎を築きました。
Clash Premium：オリジナル作者が提供したクローズドソースの強化版。過去にはTUN、ルールセット、スクリプトなどの機能を備えていました。オープンソース版の機能一覧からPremiumの機能を推測することはできません。
Clash.Meta：MetaCubeXが保守する派生フォーク。プロトコル、DNS、ルール、トラフィックの取り込み機能を拡張しています。
mihomo：Meta系統が引き続き使用している名称です。古いサブスクリプションのテンプレートやクライアントの選択肢、解説記事ではMetaの名称が残っていることもあります。互換性を判断する際は、実際に使うコアのバージョンを確認してください。

オリジナルのClashとPremiumは、2023年末に従来のリリース経路に大きな変化がありました。一方、Meta系統は開発を続け、2024年にmihomoの名称へ移行しました。古いインストーラーが起動しても、後から追加されたプロトコルや設定項目に自動対応するわけではありません。

機能比較：プロトコル、ルール、設定の範囲

以下は各コアの機能の傾向を比較したもので、すべての過去バージョンでの対応を保証するものではありません。特にmihomoでは、新しいプロトコルや設定項目がリリースごとに追加されています。サブスクリプションに type が記載されていても、使用中のコアがその種類と関連パラメーターに対応しているか確認が必要です。

項目	オリジナルのオープンソース版Clash	Clash Premium	Clash.Meta / mihomo
一般的な基本プロトコル	Shadowsocks、VMess、Trojanなどに対応。使用できるパラメーターはバージョンによって異なります	オリジナル版の基本プロトコルを継承	基本プロトコルに対応し、継続的に実装を拡張
VLESS、REALITY、Hysteria2、TUIC	これらの新しいプロトコルや機能への対応を目的としていません	Metaの拡張プロトコルを代替する実装とはみなせません	該当バージョンで対応。トランスポート層と認証パラメーターも要確認
基本的なルーティング	ドメイン、IP、GEOIP、MATCHなどの一般的なルールに対応	基本ルールに対応し、拡張機能も提供	基本ルールを維持し、論理マッチングなどの機能を拡張
ルールセットとスクリプト	Premiumのルールセットやスクリプト機能には対応しません	ルールセットと特定のスクリプト機構に対応	ルールセットに対応。Premiumのスクリプト実行環境との互換性は前提にできません
TUN	Premiumに組み込まれたTUN機能はありません	TUNを搭載。利用可否はOSとリリースバージョンに左右されます	TUNを搭載。プロトコルスタックやルーティングの選択肢は該当バージョンで確認してください

プロトコル名が同じでも、パラメーターがすべて同じとは限りません

たとえばVMessノードでは、WebSocket、TLS、サービス名、リクエストヘッダーなどの設定が必要になる場合があります。VLESSでは、REALITYや特定のフロー制御パラメーターを使用することもあります。REALITYは関連する接続で使われるセキュアなハンドシェイク機能であり、自由に type に指定できる独立したノードプロトコルではありません。移行時にノードの種類だけを変えて、適合しないトランスポート設定を残すと、解析は一部通ってもハンドシェイクで失敗することがあります。

設定の解析に失敗：まずプロトコルの種類、フィールド名のスペル、YAMLのインデント、値のデータ型を確認してください。
ハンドシェイクに失敗：サーバーアドレス、ポート、認証情報、TLSのサービス名、トランスポート方式、サーバー側の設定を確認してください。
接続がタイムアウト：ネットワーク到達性、UDP対応、上流ネットワークでの遮断、ローカルファイアウォールも確認しましょう。コア名だけが原因とは限りません。

設定の互換性：引き継げる項目と書き換えが必要な項目

オリジナル版の設定をmihomoへ移行する場合、proxies、proxy-groups、rulesなどの基本構造は、通常そのまま引き継ぎやすい項目です。ただし「項目が存在する」ことは「デフォルト値や実行結果も同じ」であることを意味しません。プロトコルのパラメーター、ルールデータ、DNS、TUN、クライアントによる上書きを個別に確認してください。

基本ルール：ポリシー名と適用順を確認

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

rules:
  - DOMAIN-SUFFIX,example.com,出口選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,出口選択

この設定例は構造の確認用で、リモートのプロキシノードは含みません。「出口選択」には現在 DIRECT しか設定されていないため、このルールに一致しても直結します。実際の設定を移行する際は、動作確認済みのノード名をプロキシグループに追加してください。ルールで参照する名前は、プロキシグループまたはノードの名前と完全に一致させる必要があります。

ルールは通常、上から順に照合されます。MATCH は末尾に配置してください。例の no-resolve は、このIPルールのためにドメイン名の解決を明示的に行わないという意味です。すべてのDNSを無効にする設定でも、ドメインルールを無効にする設定でもありません。接続先として使えるIPアドレスがまだない場合、このルールに一致しないことがあります。

ルールセット：ファイル拡張子よりデータ形式が重要

rule-providers を移行する際は、type、behavior、format、path、更新先のURLをあわせて確認してください。behavior: domain、ipcidr、classical では、それぞれ必要なデータ内容が異なります。完全なルールを含むclassicalデータをドメインリストとして扱っても、拡張子がYAMLというだけで互換性が生まれるわけではありません。

同様に、mihomo対応のルールセット形式を古いコアにそのまま渡さないでください。たとえばバイナリ形式のルールセットには、対応する実装が必要です。拡張子を変更しても形式は変換されません。リモートのルールセットをダウンロードできても、解析ログと実際のルール適用を確認してください。

DNSとTUN：設定項目が似ていても、トラフィックの取り込み範囲は異なる

システムプロキシが影響するのは、通常、システムのプロキシ設定に従うアプリだけです。TUNは仮想ネットワークインターフェースとルーティングルールを使って、条件に合うIPトラフィックを取り込みます。システムプロキシ設定を参照しないアプリにも適していますが、すべてのトラフィックが必ずリモートプロキシを経由するわけではありません。取り込み後もルール照合が行われ、DIRECT、拒否、プロキシ経由など、異なる結果になります。

まずDNSを確認してから、仮想ネットワークインターフェースを有効化

移行時はまずTUNを無効にし、ローカルプロキシポートでノードとルーティングを確認してから、DNSのハイジャックとルートの取り込みを追加することをおすすめします。これにより、「プロキシ接続の失敗」と「システムのDNSがコアに届いていない」問題を切り分けられます。以下はmihomoの設定例です。既存の設定に統合し、トップレベルの dns や tun を重複して定義しないでください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

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

127.0.0.1:1053 はローカルDNSの待ち受けアドレスです。待ち受けを有効にしただけでは、すべてのアプリが自動的にこのアドレスを使うわけではありません。
198.18.0.1/16 はfake-ip用のサンプルアドレスプールです。アドレスを合成して対応付けるためのもので、リモートプロキシサーバーのアドレスではありません。
enable: false は、まずTUNを使わない経路を検証するための設定です。必要な権限とルーティングを準備した後、true に変更してください。
dns-hijack が処理するのは、取り込み対象となるDNSトラフィックです。アプリが独自に確立したDoHやDoTの接続を、すべて通常の53番ポートへの問い合わせとして扱うことはできません。

OSごとの違い：権限とルーティングをあわせて確認

Windowsでは通常、クライアントのサービスモードか、適切な昇格権限が必要です。macOSでは、特権ヘルパーやアプリごとのネットワーク取り込み機能が使われる場合があります。LinuxではTUNデバイスとネットワーク管理の権限を確認してください。AndroidのクライアントはシステムVPNインターフェースで通信を取り込むことが多く、画面上の設定とデスクトップ版のYAML設定が一対一で対応するとは限りません。

別のVPN、仮想マシンのネットワーク、企業向けセキュリティソフトを同時に使うと、デフォルトルートやDNS設定が互いに上書きされることがあります。TUNを無効にして接続が復旧しても、問題が通信の取り込み経路にあると分かるだけで、特定のプロトコルに互換性がないとは断定できません。デフォルトの出口、DNSアドレス、ルートの変更、ログの時刻を記録し、順番に切り分けてください。

移行時の検証：設定チェック、ポートテスト、ロールバック

確実に移行するには、再現できる手順で進める必要があります。コアの更新、サブスクリプションの差し替え、DNSの変更、TUNの有効化を一度に行うと、問題が起きた際に原因を特定しにくくなります。旧設定のバックアップを残し、新しいクライアントでは独立した設定を使って検証してください。

現状を記録：現在使えているノード、ポリシーの選択、DNSモード、待ち受けポートを保存し、システムプロキシとTUNの有効・無効も記録します。
移行先のコアを確認：mihomoか旧Metaバイナリかを特定し、実際のバージョンを確認してください。サブスクリプションテンプレートのタイトルだけでは判断できません。
設定を検証：まず設定テストを実行し、その後に待ち受けを開始します。テストに通っても、ノードのハンドシェイクやルールの更新が成功したとは限りません。
単一接続を検証：ノードを1つに固定し、同じ接続先アドレスで直結と明示的なプロキシ経由を比較します。最初から自動速度測定グループを使わないでください。
追加機能を順に戻す：ルールセット、DNS、TUN、自動起動を一つずつ有効にし、各段階でログと接続記録を確認します。

mihomo -v
mihomo -t -f config.yaml

クライアントの混合ポートが 7890 の場合、次のコマンドで明示的なプロキシ経由と直結の経路を比較できます。実際のポートは稼働中の設定で確認してください。7890 はよく使われる例であり、すべてのクライアントに共通する固定のデフォルト値ではありません。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://clashgrand.com/
curl --noproxy "*" --connect-timeout 10 --max-time 20 -I https://clashgrand.com/

この2つのコマンドは実際の速度測定ではなく、ステータスコードだけで通信の出口を判断することもできません。クライアントの接続記録とあわせて、対象の接続に適用されたルール、使用したポリシー、最終的なノードを確認してください。プロキシグループで DIRECT が選択されていれば、ローカルプロキシポートを明示して接続しても対象に直結する場合があります。

よくあるトラブルと優先して確認する項目

症状	優先して確認する項目	対処方法
不明なプロキシ種別、またはフィールドのエラー	実際に使われているコア、サブスクリプションの対象形式、パラメーターのデータ型	mihomo用の設定を選ぶか、該当項目に対応するバージョンへ更新
ポートのバインドに失敗	旧クライアントが7890番ポートやローカルDNSポートを使用中でないか	旧プロセスを終了するか、ポートを変更してアプリ側の設定も更新
サブスクリプションのノードは表示されるが、接続できない	クライアントが最終的に生成したノードパラメーターとハンドシェイクログ	モードを何度も切り替えるのではなく、トランスポートの設定、認証情報、サーバー側のプロトコルを確認
設定を手動で変更しても、再起動後に元に戻る	サブスクリプションの更新、設定のマージ、クライアントによる上書き	一時的な実行ファイルだけでなく、永続化される上書き設定やマージ設定を変更
TUNを有効にするとLANに接続できない	LANルート、DNS、他のVPN、トラフィックの取り込み範囲	まずTUNを無効にして確認し、適切なルート除外を設定

ロールバックする場合は、新しいクライアントのシステムプロキシとTUNを先に無効にし、新しいプロセスを終了してから、旧クライアントと元の設定を復元してください。2つのコアが同時に待ち受けポートやシステムルートを取り合わないようにします。コントロールAPIも、まずはループバックアドレスにバインドしてください。リモート管理が必要な場合は、認証とアクセス範囲を個別に設定します。

コア選びの結論：設定の依存関係で選ぶ

基本的なノードと一般的なルーティングだけを使用：移行は比較的簡単です。ポリシー名、DNSの挙動、クライアントによる上書きを重点的に確認してください。
VLESS、REALITY、Hysteria2、TUICを使用：該当するパラメーターに明確に対応したバージョンのmihomoを選び、サーバー側の設定と項目ごとに照合してください。
Premiumのスクリプトに依存：まず動作を置き換えて検証してください。バイナリの入れ替えだけで移行が完了するとは限りません。
TUNが必要：クライアントの権限管理、OSの対応状況、ルーティングの競合もあわせて評価してください。コアの機能名だけを比較して選ぶことはできません。

新規に導入する場合は、現在も保守され、コア情報を明確に表示するクライアントを優先し、実際に使うサブスクリプションのプロトコルに合わせて設定形式を選んでください。既存環境では、再現可能なテスト手順とロールバック手順を先に用意しましょう。コア選びで重要なのは名称の新しさではなく、ノードがハンドシェイクできるか、ルールが適用されるか、DNSが正しく解決されるか、通信の取り込み範囲が想定どおりかどうかです。