Clash・Clash Meta・mihomoの機能比較と設定互換性ガイド

コアの系譜：オリジナルClash、Premium、Meta系統

Clashクライアントを選ぶ際は、画面に表示される製品名とコアの名称を分けて確認しましょう。クライアントはサブスクリプション管理、システムプロキシの切り替え、設定のマージ、ログ表示を担います。一方、コアはプロキシ接続の確立、ルールの判定、DNS処理を担当します。同じクライアントでも、内蔵コアが更新されたり、別のコアに切り替えられたりする場合があります。ソフトウェア名だけでは、VLESSノードやTUN設定が使えるかどうかは判断できません。

オリジナルClashでは、オープンソースのコアとClash Premiumを区別する必要があります。Premiumは元プロジェクトの別リリース系列で、TUNやルールセットなどの拡張機能を備えていました。Premiumの機能をオープンソース版のものとして扱うことはできません。元プロジェクトは2023年に開発が終了しました。旧クライアントや旧バイナリが動作する場合はありますが、新しい設定の機能を判断する基準には適しません。

Clash MetaはClashから派生したコアで、その後mihomoに名称が変更されました。そのためMetaとmihomoは、互換性のない別製品というより、同じ技術系列の異なる時期の名称です。古いチュートリアルの「Metaコア」やサブスクリプションの「Clash Meta形式」は、通常この拡張系列を指します。実際に使える機能は、実行中のリリース版によって異なります。

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

以下は機能の範囲を比較したもので、すべての過去バージョンの機能を網羅した一覧ではありません。「対応」にはサーバー側のパラメーター、クライアントのパッケージ構成、OSの権限も関係します。特に、現在のmihomoの機能が初期のMetaのどのバージョンでも使えると考えないでください。

機能	オープンソース版Clash	Clash Premium	Meta／mihomo系統
主なプロキシプロトコル	SS、VMess、Trojan、SOCKS、HTTPなどに対応。利用できるパラメーターはバージョンによって異なります	元プロジェクトの対応範囲が基本	VLESS、Hysteria2、TUICなどを追加。バージョンとパラメーターの確認が必要です
基本的なルーティング	ドメイン、IP範囲、GEOIPなどの一般的なルールに対応	基本ルールと拡張機能に対応	一般的なルールに加え、GEOSITEや論理ルールなどをサポート
ルールセット	PremiumのRULE-SET設定に対応しているとは限りません	rule-providersとRULE-SETに対応	ルールセットに対応。形式と動作が設定に合っているか確認が必要です
TUNによる通信の取り込み	Premiumと同等のTUN機能は内蔵していません	TUNに対応。利用できる機能はプラットフォームとバージョンによって異なります	TUNに対応。スタック、ルーティング、権限を個別に確認してください
DNS	内蔵DNSやFake-IPなどの基本機能に対応	元プロジェクトのDNS機能をベースに拡張機能を追加	名前解決ポリシーや接続時の名前解決制御を拡張。設定項目はバージョンとともに変化しています
メンテナンス状況	過去のプロジェクト。開発終了	過去のリリース系列。開発終了	mihomoプロジェクトの最新リリース情報を確認してください

プロトコルへの対応とサブスクリプションを読み込めるかは別問題

YAMLを読み込めるのは、基本的な形式が正しいことを示すだけです。たとえばサブスクリプションにtype: vlessが含まれていても、VLESS非対応の旧コアで読み込むと、ノードの解析に失敗したり、設定全体を読み込めなかったりする場合があります。Realityは関連プロトコルで使う通信のセキュリティ設定であり、VLESSやTrojanと並ぶノード種別ではありません。移行時はtype、network、TLSと、対応する通信オプションをあわせて確認してください。

サブスクリプションサービスに「Clash」と書かれていても、オリジナルClashとの互換性が保証されるわけではありません。サービスによってはYAML形式の出力全般を指しており、実際にはmihomo独自の拡張項目が含まれていることがあります。Metaまたはmihomo形式を明示的に選べる場合は、使用するコアに合わせてください。変換ツールで変換できるのは対応するデータ構造だけで、旧コアに未実装のプロトコルを追加することはできません。

設定の互換性：引き継げる構造と確認が必要な項目

一般的なproxies、proxy-groups、rulesの構造は、多くの場合そのまま使えます。基本的なDOMAIN-SUFFIX、IP-CIDR、MATCHルールも、名称が変わったからといってすべて書き換える必要はありません。移行では、拡張項目がサポートされているか、クライアントが最終的にどのような設定を生成するかを確認しましょう。

項目ごとの確認リスト

ローカルポート：port、socks-port、mixed-portを確認します。たとえばmixed-port: 7890に統一する場合、システムプロキシと手動設定が必要なアプリの接続先は、実際に待ち受けているポートに合わせます。以前の環境で使っていた7897をそのまま使わないでください。
コントローラー：external-controllerは管理APIであり、アプリがプロキシ接続に使う入口ではありません。127.0.0.1:9090を使う場合、ブラウザーのプロキシ先に9090を指定しないでください。ローカル端末だけから管理する場合はループバックアドレスを使い、アクセスキーを設定します。
ルール参照：RULE-SETで参照する名前は、rule-providers内のキーと一致させます。GEOSITEには対応するデータファイルも必要です。データのダウンロード失敗とルール構文のエラーは分けて対処してください。
ルールの振り分け先：各ルールが参照するポリシーグループが存在するか確認します。「自動選択」を「低遅延優先」に変更した場合、ルールや他のグループ内にある参照名もあわせて更新してください。
スクリプト設定：Premiumのscriptによる振り分け機能をそのまま移行しないでください。クライアントのJavaScriptによる書き換えは設定生成時に実行されるもので、コアが接続を処理するときに実行するスクリプトとは別の仕組みです。
クライアント固有の設定：旧クライアントの設定マージ、設定ファイルの拡張、起動オプションは、mihomoネイティブのYAML設定とは異なります。移行するのは設定によって生成される最終的な結果であり、古いファイルをすべてまとめてコピーするわけではありません。

まず独立した設定でポートとルールを確認

以下はローカル診断用の設定例で、使用可能なプロキシノードは含まれていません。コアが起動すること、ポート7890で待ち受けること、基本ルールを読み込めることを確認するためのものです。MATCH,DIRECTは、どのルールにも一致しない通信を直接接続します。設定済みのプロキシ構成として使わないでください。

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

proxies: []
proxy-groups: []

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

まずこの設定例をテストし、その後、実際のノード、ポリシーグループ、ルールセットを少しずつ追加します。こうすれば、数千件のルールを含むサブスクリプションを使いながら複数の要因を同時に調べるのではなく、追加した内容に起因する起動エラーを特定できます。

TUNの移行：権限、ルーティング、DNSの取り込みを個別に確認

システムプロキシは、OSのプロキシ設定に従うアプリで使われます。TUNは仮想ネットワークインターフェースを通じて通信を取り込みます。コアを切り替えた後、TUNがオンになっていても、仮想インターフェースの作成、ルーティング、DNSのリダイレクトが成功したとは限りません。Windowsではサービスモードや管理者権限、Linuxではネットワーク管理権限が関係することが多く、macOSでも適切な許可が必要です。設定画面や操作方法はクライアントによって異なります。

古いチュートリアルのTUNの初期値をそのまま使わないでください。stack、自動ルート、インターフェース検出が適切かどうかは、プラットフォーム、コアのバージョン、他のネットワークソフトウェアによって変わります。以下のmihomo設定例は一般的な項目を示すものです。初回テストではenable: falseのままにし、システムプロキシ経由の通信を確認してから有効にしてください。

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

まず権限を確認：ログに仮想インターフェースの作成やルートの追加に失敗したと表示された場合は、ノードを変更する前にサービスと権限を確認します。
次に通信経路を確認：別のVPN、仮想マシン、コンテナのネットワークが同時に動作していると、自動インターフェース検出で出口が誤って選ばれることがあります。ほかの通信制御ツールを一時的に停止し、結果を比較してください。
最後にDNSを確認：any:53が対象とするのは、通常のポート53を使うDNS通信です。ブラウザーに組み込まれたHTTPS経由のDNSを自動的に復号するものではありません。後者は通常のHTTPS接続として扱われ、ルールによって通信経路が決まることがあります。

TUNを使っても、ノードにないUDP機能が追加されるわけではありません。ゲームや音声通話のアプリで問題が続く場合は、ノードのプロトコル、サーバー側のUDP対応、ポリシーグループの振り分け、ローカルファイアウォールを個別に確認してください。TUNのスタックを何度も切り替えるだけでは解決しません。

DNSとFake-IP：項目が互換でも名前解決の経路は同じとは限らない

オリジナルClashにもFake-IPの仕組みがあり、Fake-IP自体はmihomo独自の機能ではありません。まず仮想IPアドレスを返し、その対応情報をもとにコアがドメイン名を復元して接続を処理します。移行後にDNSクエリーがコアに届かない場合や、アプリに古い結果がキャッシュされている場合は、YAMLのenhanced-modeを変更していなくても実際の動作が異なることがあります。

DNS項目は役割ごとに確認

nameserverは通常の上流DNSサーバーを指定します。暗号化DNSの上流サーバーをドメイン名で指定する場合は、そのサーバーのアドレスを最初に解決する方法も考慮してください。
nameserver-policyはドメイン名に応じてDNSサーバーを選択します。プロキシの振り分けルールではないため、rulesをそのまま置き換えることはできません。
fake-ip-filterはFake-IPを返さないドメインを指定します。互換性に問題があるドメインだけを例外として追加し、広範囲に一致するワイルドカードで全体を実IPアドレスによる名前解決に戻さないようにしてください。
fallbackとfallback-filterは、別のDNSサーバー選択の仕組みです。すべての設定で有効にする必要はありません。旧設定にこれらの項目があるからといって、移行時に地域判定の条件まですべてコピーする必要はありません。

以下はFake-IPとドメイン別の名前解決ポリシーを組み合わせた最小構成です。example.comはドキュメント用の例示ドメインです。置き換える際は、個別の名前解決が実際に必要なドメインを指定してください。1053はローカルDNSの待ち受けポートで、システム標準の53番ポートではありません。DNSリスナーを起動しただけでは、システムのDNS設定は自動的に変更されません。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
  nameserver-policy:
    '+.example.com':
      - 1.1.1.1
  fake-ip-filter:
    - '*.lan'

テストにはnslookup example.com 127.0.0.1 -port=1053と同等のコマンドを使えます。コマンドの引数順や実装はOSによって異なります。digを使える環境では、以下のクエリーをそのまま実行できます。Fake-IPに該当する場合は設定した仮想アドレス範囲の結果が返りますが、実IPアドレスが返る場合もフィルター設定が原因の可能性があります。単一のIPアドレスだけでDNS漏えいと判断しないでください。

dig @127.0.0.1 -p 1053 example.com A

コアのログにクエリーが記録されるかも確認し、システムDNS、ブラウザーのセキュアDNS、接続の出口を照合してください。オンライン検査ページに表示されるDNSサーバーの情報は、あくまで確認材料のひとつです。DNSサーバーの所在地とプロキシの出口が異なるだけでは、通信が想定した経路を迂回した証拠にはなりません。

移行の手順：オフラインテスト、段階的な復元、ロールバック

移行時にクライアント、サブスクリプション形式、DNSの構成、ルールの配布元を一度に変更する必要はありません。同じノードとテスト先を使い、最小限の切り替えを済ませてから拡張機能を戻しましょう。そうすることで、結果を正しく比較できます。

現在の稼働状況を記録：サブスクリプションの元ファイル、クライアントの上書き設定、現在有効な設定、コアのバージョン情報を保存します。ローカルプロキシのポート（例：7890）と、システムプロキシ、TUN、LANアクセスの有効・無効も記録してください。ノードのパスワードやサブスクリプションの認証情報を含むファイルは、信頼できる場所にのみ保管します。
実際に使うバイナリを確認：バージョン確認コマンドを実行し、インストーラーの名称から推測するのではなく、実際の出力を記録します。デスクトップクライアントに同梱されているコアは、単体で配布されているバージョンと異なる場合があります。
設定をテスト：まず構文と参照先を確認します。テスト後に起動し、ポリシーグループが見つからないというエラーが出たら、DNSを同時に変更せず、先にグループ名の参照を修正してください。
システムプロキシ経由の通信を検証：TUNをオフにし、利用可能だと確認できている実際のノードを1つ読み込みます。プロキシを明示したリクエストで待ち受けポート、ハンドシェイク、出口を確認し、その後システムプロキシの切り替えをテストします。
ルールとDNSを戻す：ルールセットを1つずつ追加し、ログに記録された一致ルールと振り分け先を確認します。続いてDNSの経路を確認し、最後にTUNを有効にしてください。
すぐに戻せる状態を維持：新しい設定に問題がある場合は、新しいクライアントのTUNとシステムプロキシを先に無効にしてから、以前の環境に戻します。2つのクライアントに同じポートや仮想インターフェースのルートを同時に使わせないでください。

コマンドラインでの確認例

ここでは、バイナリ名をmihomo、設定ファイルをカレントディレクトリのconfig.yamlとして説明します。Windows PowerShellでは、ローカルの実行ファイルを通常.\mihomo.exeと指定します。デスクトップクライアントを使う場合は、サブスクリプションのダウンロードファイルだけをテストするのではなく、クライアントが実際に読み込む設定を確認してください。

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

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

-tのチェックに通っても、リモートノードへの接続が保証されるわけではありません。以下のリクエストでは、障害時に応答を無期限に待たないよう、接続タイムアウトを10秒、全体のタイムアウトを20秒に設定しています。速度測定の基準ではありません。前述の直接接続用の診断設定を使っている場合、このリクエストで確認できるのはローカルのプロキシ入口だけで、リモートノード経由の通信は検証できません。

コア選定の結論とトラブルの切り分け

VLESS、Hysteria2、TUICや新しいルール機能が必要な場合は、オリジナルコアで新しい項目を繰り返し試すのではなく、mihomoの該当バージョンが対応しているか確認してください。古い環境を維持する場合は、設定を元のコアが実装済みの機能に限定し、サブスクリプション更新後にノードを解析できなくなる事態を避けましょう。

Clash Metaからmihomoへの移行では、主にバージョンの違いと、クライアントが設定を生成する方法を確認します。オリジナルClashやPremiumからmihomoに移行する場合は、スクリプト、ルールセット、DNS、TUNの実装の違いも確認が必要です。すべての項目を一律に置き換える方法はありません。バージョンの確認、有効な設定の検査、段階的な接続テストが確実な手順です。

クライアント選びについてはクライアントの対応プラットフォームとコアの比較をご覧ください。ルールの構文や設定の構造を確認するにはプロトコルガイドをご利用ください。各項目の用途を説明できる設定を1つ保つほうが、出所の不明な上書き設定を重ねるより、継続的に管理しやすくなります。