Clashの違いを比較｜オリジナル・Clash Meta・mihomoの機能と進化

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

まず結論から説明します。Clash Metaとmihomoは同じ系統の前後の名称で、無関係な別々のコアではありません。オリジナル版Clashは、この技術系統の元となったプロジェクトです。クライアントを選ぶ際は、アプリ名にClashが含まれるかではなく、実際に動作しているコアの名称とバージョンを確認しましょう。

Clash Premiumは別に区別する必要があります。古い解説では、オリジナルのオープンソースコアとPremiumコアをまとめて「Clash」と呼ぶことが多く、「オリジナル版は必ずTUNに対応する」「古い設定はそのまま移行できる」といった誤解につながっています。機能を見極めるには、少なくとも次の4つの名称を区別しましょう。

オリジナル版Clashのオープンソースコア：一般にDreamacro/clashプロジェクトのオープンソース版を指します。ローカルプロキシの受け口、プロキシグループ、ルール判定、DNSなどの基本機能を備えています。
Clash Premium：オリジナルプロジェクトが別途公開していたクローズドソースの拡張コアです。TUN、ルールセット、スクリプトなどの機能を提供していましたが、そのすべてをオリジナルのオープンソースコアの機能として扱うことはできません。
Clash Meta：Clashをベースにコミュニティが開発した派生版で、対応プロトコルやルール、ネットワークの制御機能が拡張されています。
mihomo：Clash Metaが後に使用するようになったプロジェクト名です。現在のドキュメントや実行ファイル、ログではこの名称がよく使われますが、一部のクライアントや購読サービスでは今もMetaの表記が使われています。

クライアントとコア：画面のバージョンと機能のバージョンは別

クライアントは購読の管理、設定の切り替え、システムプロキシの有効化、ログ表示などを担います。コアは設定の読み込み、接続の確立、ルールの適用、DNS処理を担当します。同じクライアントに特定のコアが組み込まれている場合も、コアを切り替えられる場合もあります。そのため、「クライアントを更新した」だけでは、基盤となるネットワーク機能まで更新されたとは限りません。

実際に動作中のコアを確認する3つの方法

クライアントの「バージョン情報」や「コア」画面を開き、クライアントとコアそれぞれのバージョンを記録します。メニュー名はクライアントによって異なるため、アプリのバージョン番号をコアのバージョンと取り違えないようにしてください。
起動ログでコアの名称、バージョン、設定の読み込み結果を確認します。コアを切り替えた後は、ファイルを置き換えただけでプロセスを再起動していない、といったことがないようログを見直してください。
ローカルのコントローラーAPIを有効にしている場合は、/versionにリクエストを送れます。返される内容はコアのバージョンによって異なるため、バージョン欄と系統を示す情報を確認しましょう。

たとえば、コントローラーAPIがexternal-controller: 127.0.0.1:9090に設定されている場合、ローカル環境で次のコマンドを実行できます。APIキーを設定している場合は、正しい認証情報を付けてリクエストしてください。401が返っても、認証に失敗したという意味であり、バージョン照会にコアが対応していないことを示すわけではありません。

curl http://127.0.0.1:9090/version

ここでの9090はコントローラーAPIのポートであり、ブラウザー用のプロキシポートではありません。コントローラーAPIからは実行状態を変更できるため、ローカルからの接続に限定してください。管理画面を接続するために、インターネットからアクセスできるアドレスへ変更するのは避けましょう。

機能を比較：プロトコル、ルールセット、TUN、DNS

以下は各コアの機能傾向を比較したもので、過去のすべてのバージョンを網羅する一覧ではありません。オリジナルプロジェクトとPremiumの公開系統は、元のプロジェクトによる開発が終了しています。mihomoの設定項目は利用するバージョンのドキュメントを参照してください。特に新しいプロトコルのパラメーター、DNSオプション、プラットフォーム固有の機能は確認が必要です。

比較項目	オリジナル版Clash（オープンソース）	Clash Premium	Meta / mihomo
主な対応プロキシプロトコル	Shadowsocks、VMess、Trojanなどに対応。利用できるパラメーターはバージョンによって異なります。	オリジナル版のプロトコル体系を引き継いでおり、mihomoの拡張プロトコルには対応していません。	VLESS、Hysteria2、TUICなどに対応。バージョンとパラメーターの確認が必要です。
基本的なルール	ドメイン、IPアドレス範囲、GEOIP、MATCHなどの一般的なルールに対応しています。	基本的なルールに加え、ルールセットなどの拡張機能を利用できます。	基本的なルール、ルールセットに加え、より多くの条件やロジックに対応しています。
TUNによる通信の取り込み	Premiumのような組み込みTUN機能はありません。	TUNに対応していますが、利用できる機能はOSとリリース版によって異なります。	TUNに対応しています。プロトコルスタックやルーティングの選択肢は、バージョンとプラットフォームによって異なります。
DNSとFake-IP	DNSとFake-IPの基本機能を備えています。	DNSとFake-IPに対応しています。	DNSポリシー、上流DNSの選択、名前解決の制御機能がさらに拡張されています。
移行時の注意点	派生版で追加されたプロトコルや設定項目は認識できません。	Premiumのスクリプトがmihomoでそのまま動作するとは限りません。	基本設定の多くは再利用できますが、拡張項目は一つずつ確認が必要です。

同じプロトコル名でも、転送方式とTLSパラメーターを確認

あるプロトコルに対応していても、あらゆる組み合わせが使えるとは限りません。たとえばVLESSはプロキシプロトコル、REALITYは関連するTLSセキュリティ設定、WebSocketやgRPCは転送方式です。サーバー側で必要な組み合わせに応じて、クライアントのコアも該当する設定項目に対応している必要があります。「VLESS対応」と表示されているだけでは、接続に必要な条件を満たすか判断できません。

同様に、HysteriaとHysteria2は表示名を変えるだけで相互接続できる設定ではありません。購読設定にtype: hysteria2が含まれている場合、古いコアで種類をhysteriaに書き換えても互換性は得られません。エラーが出る項目を一つずつ削除するのではなく、対応するコアと購読出力を選びましょう。

ルールの互換性：基本構文は再利用できるが、拡張機能は要確認

基本的な振り分けの多くは、「上から順に照合し、最初に一致したルールのポリシーを適用する」という考え方に従います。DOMAIN-SUFFIX、IP-CIDR、MATCHなどのルールは幅広く共通していますが、参照先のプロキシグループが存在し、グループ内のプロキシ名が実際のリソースと一致している必要があります。

以下はルールの順序を説明するための抜粋で、購読設定全体ではありません。DIRECTは組み込みの直接接続ポリシーです。実際に使うときは、プロキシが必要なルールを既存のプロキシグループに割り当ててください。すべてを直接接続にする例として、そのままコピーするものではありません。

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,DIRECT

最後のフォールバック：MATCHは通常、末尾に配置します。途中に置くと、後続のルールが照合されなくなります。
ルールセットの定義：RULE-SETを使う場合は、対応するrule-providersの名称、形式、動作タイプを確認してください。ルール参照の行だけをコピーしても動作しません。
名前解決への影響：no-resolveは、そのIPルールのためにドメイン名の名前解決を行わないようにする設定です。接続全体でDNSが不要になるという意味ではありません。
Premiumのスクリプト：scriptを含む古い設定を移行するときは、移行先のコアが該当する仕組みに対応しているか確認してください。必要に応じてルールとプロキシグループに置き換えます。

設定の読み込みに成功しても、振り分けが想定どおりでない場合は、まず現在のモードがruleか確認してください。グローバルモードでは通常のルール一覧に基づく振り分けは行われません。また、直接接続モードではプロキシルールの動作を検証できません。

TUNとDNS：機能があるだけでは通信を取り込めない

システムプロキシとTUNは、異なる経路の通信を扱う

システムプロキシでは、システム設定に従うアプリが、たとえば127.0.0.1:7890のローカルHTTPまたはSOCKSプロキシに接続します。すべてのプログラムを取り込めるわけではなく、あらゆるUDP通信がコアに流れることも保証されません。一方、TUNは仮想ネットワークインターフェースとルーティングを使って、より多くのIP通信を取り込みます。対象範囲も実装方法も異なります。

mihomoがTUNに対応していても、設定にenable: trueと書けば必ず有効になるわけではありません。クライアントに必要な権限があるか、OSがインターフェースの作成を許可しているか、ルートが正しいか、別のVPNや透過プロキシと競合していないかも確認が必要です。切り分けの際はネットワークを取り込む仕組みを一つだけ有効にし、ルーティングループやDNSの二重リダイレクトを防ぎましょう。

Fake-IPはDNSの動作方式であり、プロキシプロトコルではない

Fake-IPはドメイン名に対応するアドレスを割り当て、接続時にコアが元のドメイン名を特定して振り分けられるようにします。よくある設定例では、198.18.0.1/16のアドレス範囲を使用します。対象サイトが実際にそのアドレスにあるわけではなく、ノードの接続地域を判断する材料にもなりません。

以下は関連項目を示す設定例です。1053は任意に設定したローカルDNSの待ち受けポートで、通常システムが使う53を自動的に置き換えるものではありません。システムのDNSリクエストをコアへ送るには、クライアントによる取り込み、TUNのDNSリダイレクト、または別途明示した設定が必要です。

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

DNS設定の項目と通信の取り込み順序は設定ガイドのDNS解説を、Fake-IPの詳しい仕組みは用語ガイドを参照してください。

移行手順：古いClash設定からmihomoへ

移行で大切なのは、設定ファイル内の「Clash」を「mihomo」に置き換えることではありません。プロトコル、ルール、システム通信の取り込みがすべて正しく動くか確認することです。次の順に進め、各段階を確認してから機能を追加しましょう。

元の設定を保存：購読URL、現在のYAML、ローカル上書き設定、プロキシグループの選択内容をバックアップします。購読URLにアクセス情報が含まれる場合があるため、公開ログやスクリーンショットに載せないでください。
購読先の出力形式を確認：サービス提供元がClash用とMeta用の出力を分けている場合は、選択した出力に対象コアが認識できるプロトコルと設定項目が含まれているか確認します。Base64形式のノード一覧は、拡張子を変えるだけでは完全なYAML設定になりません。
構文をチェック：移行先のコアで設定をテストします。一般的なコマンドはmihomo -t -f config.yamlです。Windowsではmihomo.exe -t -f config.yamlを使えます。実際の実行ファイルのパスはインストール先に合わせてください。
まずローカルプロキシを確認：TUNを一時的に無効にし、ローカルの待ち受けポート、プロキシグループ、プロキシ接続が正常に動作することを確認してから、ルールモードを検証します。
次に通信の取り込みを有効化：必要な権限を確認したうえでTUNを有効にし、ログでインターフェース、ルート、DNSの状態を確認します。ブラウザーとシステムプロキシに従わないアプリをそれぞれテストしてください。
最後に自動更新を再開：購読を一度更新し、ローカル上書き設定が引き続き有効か確認します。リモート設定ファイルを直接編集すると、次回の更新で変更が上書きされることがあります。

たとえば設定がmixed-port: 7890の場合、次のコマンドでHTTPSリクエストがローカルHTTPプロキシを経由するか確認できます。コマンドが成功しても、この入口とリクエスト先が使えることを示すだけで、すべてのアプリ、UDP、TUNが正常とは限りません。

curl -I -x http://127.0.0.1:7890 https://example.com

ポート使用中と表示されたら、古いコアや別のクライアントが動作していないか確認します。未対応のプロキシタイプと表示された場合は、コアと購読形式を優先して確認します。構文チェックは通るのに接続がタイムアウトする場合は、サーバー側のパラメーター、ネットワーク到達性、DNSを調べてください。この3種類の問題を分けて考えると、設定を何度も入れ替えるより原因を特定しやすくなります。

選び方の結論：購読プロトコルと実行環境で決める

新しいプロトコルや拡張ルールが必要：mihomoを明確に採用し、継続的にメンテナンスしているクライアントを選びます。組み込みコアのバージョンが設定要件を満たしているかも確認してください。
基本的なプロトコルとドメイン振り分けだけを使う：基本機能なら複雑な設定は必要ありません。ただし新たに導入する場合は、古い解説に慣れているという理由だけで旧コアを選ぶのではなく、現在のメンテナンス状況とOSとの互換性を優先しましょう。
TUNが必要：コアの対応状況に加え、クライアントの権限管理、システムのアーキテクチャ、ルーティング機能を確認します。特にスマートフォンでは、アプリが実際に使うコアとOSのVPNインターフェースの実装を基準にしてください。
Premium設定を移行：スクリプト、ルールセット、TUNの設定項目を優先して確認し、「インポートできる」ことを「すべて同じ動作をする」ことと混同しないでください。

最後に、3種類の更新を分けて管理しましょう。購読の更新はプロキシリソースとルールを変更し、コアの更新はプロトコルやネットワーク機能を変更し、クライアントの更新は画面や統合方法を変更します。未対応の設定項目は購読を更新するだけでは解決しない場合があり、無効になったサーバーアドレスもコアを替えるだけでは直りません。まず問題のある層を特定し、それに合った操作を選びましょう。