Clashのオリジナル版・Meta・mihomoのコアの違いを比較
Clashオリジナル版、Clash.Meta、mihomoの系譜を整理し、対応プロトコルやルール、TUN、設定項目の違いを比較。既存設定をそのまま移行できるか判断できます。
まず結論:Metaとmihomoは同じ系譜のコア
移行時は、まずクライアントで実際に動作しているコアを確認し、次にサブスクリプションの形式をチェックしましょう。Clash.Metaは後にmihomoへ名称変更されたもので、互いに無関係な設定体系ではありません。基本的なClash YAML設定の多くは移行の出発点として使えますが、mihomo独自の拡張項目を含む設定が旧版Clashで使えるとは限りません。
コアは設定の解析、ルールの照合、プロキシ接続の確立を担います。クライアントは画面表示、サブスクリプション管理、システム権限の操作などを担当します。同じクライアント名でも、配布バージョンによって搭載コアが異なる場合があります。そのため、「Clashをインストールした」というだけでは、特定のプロトコルに対応しているか判断できません。
名称・メンテナンス状況・設定の互換性
| 名称 | 位置づけ・状況 | 移行時の確認点 |
|---|---|---|
| Clashオリジナルのオープンソースコア | オリジナルのオープンソース実装。元プロジェクトのメンテナンスは終了 | 基本的なプロトコルとルール。後から追加されたプロトコルへの対応は期待しない |
| Clash Premium | 歴史上のクローズドソース強化版。メンテナンス終了 | TUN、ルールプロバイダー、スクリプトなど旧機能の移行方法 |
| Clash.Meta | Clashから派生したブランチで、mihomoの旧名称 | 旧バージョンが設定内の新しい項目に対応しているか |
| mihomo | Metaの系譜を引き継ぎ、プロトコル、ルール、ネットワーク機能を継続的に拡張 | 具体的なバージョン、OS、クライアントによる設定の上書き動作 |
現在動作中のコアを確認する方法
- クライアントの「バージョン情報」「コア」または起動ログを開いてください。メニュー名はクライアントによって異なり、すべてのスマートフォンに共通する決まった手順はありません。
- コア名、完全なバージョン番号、端末のOS、クライアントのバージョンを記録しましょう。アプリストアに表示されるバージョンだけでは不十分です。
- デスクトップ環境でコアを直接実行できる場合は、
mihomo -vでバージョンを確認できます。このコマンドが調べるのは指定した実行ファイルであり、スマートフォンアプリに内蔵されたバージョンではありません。
古い設定のメモにある「Meta専用」は、通常、拡張機能に依存していることを示します。Metaという名前の旧インストーラーを探す必要があるという意味ではありません。名称が一致するかではなく、移行先のmihomoのバージョンが使用中の項目に対応しているかで判断してください。
プロトコルの違い:ノードを読み込めても接続できるとは限らない
プロトコルとは、クライアントとプロキシサーバー間の通信方式です。オリジナル版Clashで一般的な設定には、Shadowsocks、VMess、Trojan、SOCKS5、HTTPプロキシがあります。mihomoはこの基盤を拡張し、VLESS、Hysteria2、TUIC、WireGuardなどにも対応しています。ただし、実際の対応状況はコアのバージョンやプラットフォームによって異なります。
新しいプロトコルは通信パラメーターも確認
- VLESSとReality:VLESSはプロトコル、Realityは関連するTLSセキュリティ機構です。
type: vlessと書かれているだけでは不十分です。サーバーが要求する通信方式、servername、Realityの公開鍵なども確認してください。 - Hysteria2とTUIC:どちらもUDPベースの通信を使用します。ネットワークでUDPが遮断されている場合、対応コアに切り替えても通信上の問題は解消しません。
- Shadowsocks:プロトコル名だけでなく、
cipherで指定する暗号方式も確認しましょう。「どちらもSSノードだから」という理由だけで、古いコアでも使えると判断することはできません。
「未対応のプロキシタイプ」と表示された場合は、まず設定のtypeとコアのバージョンを確認してください。ハンドシェイク失敗やタイムアウトの場合は、サーバーアドレス、ポート、端末の時刻、認証パラメーター、ネットワーク環境も調べましょう。すべての接続失敗をコアの非互換と決めつけたり、問題の切り分けのために証明書検証を無効化したりしないでください。
ルールの違い:基本構文は似ていても拡張ルールは個別に確認
ルールは上から順に照合され、最初に一致したルールに対応するポリシーが適用されます。DOMAINは指定ドメイン、DOMAIN-SUFFIXはドメインとそのサブドメイン、IP-CIDRはIPアドレス範囲に一致します。MATCHは最後のフォールバックに使います。こうした基本的な考え方は、各ブランチでおおむね共通です。
ルールプロバイダーは単なるルールのリンクではない
rule-providersで外部ルールセットを定義し、RULE-SETから参照します。歴代のPremiumとmihomoには関連機能がありますが、すべてのオリジナル版オープンソースビルドで読み込めるとは限りません。移行時はプロバイダーの種類、ファイル形式、コンテンツの種類をあわせて確認してください。
behavior: domainはドメイン系のルールセット、ipcidrはIPアドレス範囲のルールセットを示します。classicalにはルールタイプを含むエントリーを記述します。- 従来のYAML形式のルールセットでは、
payloadリストがよく使われます。プレーンテキスト形式やmihomoのバイナリ形式MRSを使うには、移行先のコアがそれぞれに対応している必要があります。ファイルの拡張子を変えるだけでは使えません。 - プロセスルールには、システムが提供するプロセス情報が必要です。Androidでは、アプリごとの振り分けをクライアントがVpnServiceのアプリ一覧で実装している場合もあり、デスクトップ版のプロセスルールとは仕組みが異なります。
Premiumから移行する場合は、特にscriptを個別に確認してください。旧版のスクリプト設定をmihomo共通の互換インターフェースとして使うことはできません。スクリプトが行っている条件判定を洗い出し、移行先バージョンが対応するルール、論理ルール、サブルールに置き換えて、項目ごとにテストするのが確実です。
TUNとスマートフォンのVPN:コア機能とOSによる通信制御を分けて考える
TUNは、ネットワークデータを仮想ネットワークインターフェースに渡して処理する方式です。システムプロキシ設定を参照しないアプリの通信を、プロキシコアに取り込めます。TUNは歴史的にClash PremiumやMetaなどの強化系統を特徴づける機能でしたが、オリジナルのオープンソースClashのすべてのビルドに同じ実装があるとは限りません。
Androidクライアントは通常、システムが提供するVPNインターフェースであるVpnServiceを使い、通信を制御する権限を取得します。VPNの許可画面が表示されるか、どのアプリの通信をトンネルに通すか、バックグラウンドで動作し続けるかは、クライアントの実装だけでなくOSの制限にも左右されます。コアを変更しても、これらの権限が自動的に付与されるわけではありません。
mihomoのTUN設定例を読み解く
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
これは一般的なデスクトップ環境向けの項目例であり、スマートフォンでそのまま使う完全な設定ではありません。auto-routeは関連ルートを自動設定し、auto-detect-interfaceは送信インターフェースを自動検出します。stackはネットワークスタックの実装を選択します。必要な権限、ルーティングの処理、利用可能な項目は、移行先のOSとコアのバージョンで確認してください。
設定の移行:まず基本設定を動かし、DNSと上書き設定は後から戻す
YAMLはインデントで構造を表す設定形式です。ファイルを解析できるのは、基本的な構造を読み取れたというだけです。一部の未知の項目が無視されていても、期待する機能が有効になったとは限りません。移行後の確認では、起動ログ、接続履歴、実際に適用されたルールをあわせて確認してください。
手順1:元に戻せる設定を用意する
- 元のサブスクリプションURL、現在の設定ファイルのコピー、クライアントの上書き設定を保存しておきます。サブスクリプションURLは機密情報です。スクリーンショットやログを共有する前に、認証情報を隠してください。
- 新しいクライアントに設定を追加し、旧クライアントが使用中のファイルを直接上書きしないでください。
- サブスクリプションサービスが返す内容が、Clashまたはmihomoで読み込めるYAMLであることを確認してください。他のクライアント用形式や、共有リンクだけを含むテキストでは使えません。
手順2:基本設定で問題箇所を切り分ける
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups:
- name: MANUAL
type: select
proxies:
- DIRECT
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,MANUAL
この例は設定の読み込み、ポート、ルールの流れを確認するためのものです。すべての通信は最終的に直接接続され、プロキシ経由の出口は提供しません。mixed-port: 7890は、同じ待ち受けポートでHTTPとSOCKSプロキシ接続を受け付ける設定です。スマートフォンの他のアプリがこのポートを使うかどうかは、VPNによる通信制御または各アプリのプロキシ設定によります。
設定が正常に読み込まれたら、クライアントの設定マージ・上書き機能を使うか、ローカルのテスト用コピーに実際のノードとポリシーグループを追加します。ポリシーグループ名は、ルールから参照する名前と完全に一致させてください。たとえば、ルールにPROXYとあるのに設定にはMANUALしかない場合、名前を統一する必要があります。コアが自動で推測することはありません。
手順3:変更を一度に増やさずDNSを戻す
- まずサブスクリプション元の
dns設定をそのまま使い、基本的な接続が正常であることを確認してから、上書きするか判断してください。 enhanced-mode: fake-ipを使う場合、コア内のマッピングに使用する仮想アドレスが返される仕組みを理解しておきましょう。よく使われる198.18.0.1/16のアドレス範囲は、リモートサーバーの実際のグローバルIPアドレスではありません。nameserverとproxy-server-nameserverなどは役割が異なります。プロキシサーバーのドメイン名の解決に、まだ確立されていないプロキシ接続が必要だと、循環依存になることがあります。- Fake-IPモードを変更した後は、必要に応じてクライアントのDNSキャッシュを消去し、テストするアプリを再起動してください。古いキャッシュが実際の結果を隠してしまうのを防げます。
移行後の確認:エラーの段階に応じて調査する
| 症状 | まず確認する項目 | 次に行うこと |
|---|---|---|
| 設定を読み込めない | YAMLのインデント、ノードタイプ、ポリシー名、コアのバージョン | ログの行番号を確認して、最小限の設定で再テストする |
| ポートの待ち受けに失敗する | 7890番ポートが別のプロセスで使用されていないか | 重複して起動しているプロセスを停止するか、待ち受けポートとアプリのプロキシ設定をあわせて変更する |
| 遅延テストは成功するが、アプリを開けない | テスト用URLと実際の接続先の違い、ルールの出口、DNS、UDP | 対象アプリの接続履歴を開き、適用されたルールとノードを確認する |
| ブラウザーは使えるが、他のアプリは失敗する | ブラウザーのプロキシしか設定していないか、VPNの対象外アプリ一覧 | システムのVPN状態と、クライアントのアプリ振り分け設定を確認する |
コアを直接実行できるデスクトップ環境では、mihomo -t -f config.yamlで指定したファイルを検査できます。検査に合格しても、サーバーに接続できることや、クライアントが最終的にそのファイルを使っていることを保証するものではありません。スマートフォンでは「現在有効な設定」と、サブスクリプション更新後も上書き設定が適用されているかを確認してください。
最後に、少なくとも3つのテストを行ってください。直接接続するサイト、プロキシ経由にする接続先、画面ロック後の再接続をそれぞれ試します。ルールの適用、出口の選択、バックグラウンド接続を個別に確認しましょう。新しいプロトコルや拡張ルールが必要なら、搭載コアのバージョンが明確で更新履歴も確認できるクライアントを選んでください。基本設定だけを使う場合も元の設定を保存し、ネットワーク設定を一度に置き換えず、段階的に移行しましょう。