mihomoとオリジナルClashの違いを比較｜対応プロトコル・ルールタイプ・設定互換性 | Clash測評

まずコア、クライアント、過去の派生版を区別する

結論：新しいプロトコルや細かなルール設定、継続的にメンテナンスされるコアが必要なら、mihomoを優先して検討しましょう。安定している旧設定を使っている場合は、互換性を確認してから実際の通信を切り替えてください。主な違いは機能範囲と開発・保守の方針です。名称を変えるだけで、すべてのノードが高速になるわけではありません。接続品質は、サーバー側の設定や利用中のネットワークにも左右されます。

Clashは、通信の中継やルール判定、DNS処理などを担うプロキシコアです。デスクトップ版やモバイル版のクライアントは、サブスクリプション管理、トレイ表示、システムプロキシ、権限管理などの機能を提供します。Clash MetaはClashから派生したプロジェクトで、後にmihomoへ改称されました。古いドキュメントや設定テンプレート、クライアントの設定画面にはMetaという名称が残っている場合がありますが、通常は旧称を示すもので、別のコアを追加でインストールする必要があるという意味ではありません。

「オリジナルClash」も、さらに区別が必要です。過去にはオープンソースのコアと、クローズドソースのClash Premiumがあり、機能は完全には同じではありません。オリジナルプロジェクトは2023年に開発・保守を終了しました。かつてのPremiumの機能をすべてオープンソース版のものとみなしたり、サードパーティ製クライアントの更新をオリジナルコアの保守再開と同一視したりしないようにしましょう。

対応プロトコル：新しい種類に対応しても自動的に使えるとは限らない

mihomoは、従来のプロキシ機能に加えて、複数のプロトコルやトランスポート方式に対応しています。ユーザーにとって特に重要なのは、サブスクリプションにVLESS、Hysteria2、TUICのノードが含まれている場合、旧コアでは解析できないことがある一方、該当する実装に対応したmihomoなら処理できる点です。ただし、実際に使えるかどうかは、バージョン、設定項目、サーバー側の構成によって異なります。ノードの表示名だけで判断しないでください。

主な機能の比較：オリジナルのオープンソースコアとmihomo
機能	オリジナルのオープンソース版Clash	mihomoを選ぶメリット
Shadowsocks、VMess、Trojan	基本的な方式に対応。利用できるアルゴリズムやトランスポートの選択肢はバージョンによって異なります。	従来の方式に対応しつつ、一部のアルゴリズム、トランスポート、接続オプションを拡張しています。
VLESSとREALITY	mihomoにある同等の機能には対応していません。	VLESSを利用でき、対応する設定ではREALITYも使用できます。両者は同じ階層の概念ではありません。
Hysteria2、TUIC	これらの新しいノードタイプには対応していません。	それぞれに対応する実装を提供します。UDPを使う通信では、利用するネットワークとサーバーの双方がUDPに対応している必要があります。
ルールセットとTUN	Premiumの機能一覧をそのまま適用することはできません。	ルールプロバイダーやTUNなどに対応し、複雑なルーティングや通信の取り込みにも適しています。

ノードの移行時に確認したい3種類の設定

認証情報：サーバーアドレス、ポート、パスワードまたはUUIDがサーバー側の設定と一致している必要があります。TLSでよく使われるポート443は単なるポート番号であり、そのノードが必ず「HTTPSを使用する」ことを示すものではありません。
トランスポート設定：WebSocketのパスやHost、gRPCのサービス名などを一つずつ照合してください。YAMLを読み込めても、ハンドシェイクの設定が正しいとは限りません。
TLSとREALITY：servername、フィンガープリント、必要に応じてreality-optsを確認します。ドメイン名や証明書の設定ミスを隠すために、skip-cert-verify: trueを使わないでください。

サブスクリプションの変換時に新しいプロトコルのノードが削除されていた場合、コアをアップグレードしてもノードは復元されません。サービス提供元のサブスクリプション形式、変換ツールの出力、クライアントで最終的に有効になった設定をあわせて確認しましょう。まずノードの種類が保持されていることを確かめてから、ハンドシェイクの失敗を調べると、切り分けがスムーズです。

ルールとルールセット：順序を保ち、ファイル形式を区別する

基本的なマッチングの仕組みは変わりません。ルールモードでは、rulesが上から順に評価され、最初に一致したルールによって接続先のポリシーが決まります。DOMAIN、DOMAIN-SUFFIX、IP-CIDRなどの基本ルールは引き続き重要で、通常は最後にMATCHを置き、どのルールにも一致しない通信を処理します。機能が増えても、誤ったルール順が自動で修正されるわけではありません。

mihomoでは、プロセス名、宛先ポート、論理条件による組み合わせなど、より多くの条件で通信を判定できます。ただし、プロセスの識別はOSや権限、通信を取り込む方式の影響を受けます。設定にPROCESS-NAMEがあっても、すべてのプラットフォームで期待どおりのプロセス情報を取得できるとは限りません。

RULE-SETはノードのサブスクリプションではない

proxy-providersはノードを提供する設定で、内容は最終的にプロキシ設定として解析できる必要があります。
rule-providersはマッチング対象のルールを提供します。そのルールをRULE-SETで参照し、適用するポリシーを指定します。
behavior: domain、ipcidr、classicalではルール項目の形式が異なります。ファイルの拡張子を変えるだけで相互に置き換えることはできません。
mihomoのmrsはルールセット形式です。オリジナルClashにそのまま読み込ませることはできず、通常のYAMLテキストとして編集することもできません。

Premiumから設定を移行する場合、すでにrule-providersやRULE-SETが含まれていることがあります。一方、オリジナルのオープンソースコアから移行する場合は、これらの設定項目が以前から使えたと決めつけないでください。以下は設定の基本構造を確認するためのサンプルです。リモートサブスクリプションは含めず、プロキシグループの選択肢もDIRECTのみです。

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

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

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

この設定は、読み込み、ポート、ルール構造を確認するためのもので、プロキシ回線は含まれていません。実際のノードを接続したら、有効なノードまたはノードプロバイダーをプロキシグループに追加してください。MATCHを個別のルールより前に置かないでください。また、ルールが参照するポリシーグループの名前を変更したり、削除したりしないようにしましょう。

DNSの違い：名前解決の経路と起動時の依存関係を確認

オリジナルClashにもDNSとFake-IPの機能があるため、「mihomoに変えないとFake-IPを使えない」という説明は正確ではありません。mihomoの違いは、より多くの名前解決オプションがあり、ルーティング機能と組み合わせられる点です。たとえば、nameserver-policyで特定のドメインに使用するDNSサーバーを指定したり、proxy-server-nameserverでプロキシサーバーのドメインを個別に名前解決したりできます。

fake-ipモードでは、ドメイン名に対して対応するIPアドレスを返し、コアがその対応関係に基づいて接続を処理します。redir-hostは、実際の名前解決結果を返す方式に近いものです。どちらが適しているかは、アプリとの互換性や通信を取り込む方式によって異なります。LAN内のデバイス検出、特定のゲーム、社内ネットワークで問題が起きた場合は、すべてのドメインをフィルターリストに追加するのではなく、該当するドメインとアクセス経路を特定しましょう。

混同しやすいDNS設定項目3つ

設定項目	主な役割	移行時の確認ポイント
`default-nameserver`	DNSサーバー自身のドメイン名を解決するなど、起動時の名前解決に使用します。	利用可能なIPアドレス形式の初期接続先を設定し、DNSサーバーの起動に必要な名前解決が未確立の状態で依存するのを避けます。
`proxy-server-nameserver`	プロキシノードのサーバードメインを解決するDNSサーバーを指定します。	ノードへの接続には、事前に名前解決が必要です。「ノードを解決するには、そのノード経由の接続が必要」という循環が起きないようにしてください。
`respect-rules`	DNS上流への接続を、設定されたルールに従ってルーティングします。	有効にする場合は、ノードのドメイン解決設定とルールの出口もあわせて確認してください。真偽値だけをコピーしないようにしましょう。

TUNとクライアント：機能の切り替えだけでなく権限も確認

システムプロキシの影響を受けるのは、通常、システムプロキシ設定に従うアプリです。一方、TUNは仮想ネットワークインターフェースを使い、ルーティング条件に合うIP通信を取り込みます。mihomoはTUNに対応していますが、正常に動作するかどうかは、システム権限、仮想NIC、ルーティングルール、他のVPNソフトに左右されます。TUNを有効にしてもサーバー側のプロトコルは変わらず、UDP転送に対応していない回線が自動的に対応することもありません。

まず通常のプロキシを確認：システムプロキシまたは明示的なHTTPプロキシを使ってテストし、ノード単体で接続できることを確認してからTUNを有効にします。問題を同時に二種類調べる状況を避けられます。
次に権限を確認：デスクトップクライアントは、サービスコンポーネントを通じて必要な権限を取得する場合があります。コアを直接実行するときは、OSの要件に従ってネットワーク管理権限を付与してください。
最後にルーティングとDNSを確認：auto-route、auto-detect-interface、DNSの取り込みは、実際のネットワーク環境に合わせて設定してください。複数のネットワークアダプター、企業VPN、仮想マシンのネットワークでは特に注意が必要です。

混合プロキシの待ち受けポート7890をTUNインターフェースのポートと混同しないでください。また、コントロールポート9090をブラウザーのプロキシ設定に入力しないでください。コントロールインターフェースはクライアントからコアを管理するためのもので、通常のWebプロキシの入口ではありません。設定する場合は、ループバックアドレスに制限し、アクセス認証情報を設定してください。

旧設定の移行：上書きせず、6段階で確認

基本的なYAML構造の多くは引き継がれていますが、「旧設定で起動できること」と「新しい設定がすべて反映されること」は別々に確認する必要があります。未知の設定項目が無視されたり、特定のルールやノードが読み込み後にエラーになったりする場合があります。元の設定とクライアント環境を残したまま、別のコピーで段階的に検証するのがおすすめです。

設定の入手元をバックアップ：サブスクリプションの原文、クライアントのオーバーライドルール、現在有効な設定をそれぞれ保存します。クライアントに表示されるサブスクリプションファイルが、コアに渡される最終設定と同じとは限りません。
実行環境を記録：OS、クライアントのバージョン、mihomo -vの出力、システムプロキシとTUNの有効状態を記録します。ポートの競合を避けるため、切り替え前に別のインスタンスを終了してください。
設定をテスト：設定ファイルのあるディレクトリで、次のコマンドを実行します。ルールプロバイダーに相対パスを使う場合は、作業ディレクトリと実際の実行環境を一致させてください。

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

エラーの種類を確認：YAMLのインデントや型のエラーは構文を修正し、プロキシグループが存在しない場合は名前を確認します。ノードタイプが認識されない場合は、コアのバージョンとサブスクリプションの出力を照合してください。エラーが出たからといって、状況を確認せずにサブスクリプションを何度も更新しないでください。
実際の接続をテスト：コアを起動したら、明示的なプロキシ経由のリクエストでプロキシ入口、ノード、TLSを確認し、ログでどのルールが適用されたかを調べます。設定テストに成功しても、実際に通信できることの確認にはなりません。
拡張設定を一つずつ戻す：最後に、リモートルールセット、DNSポリシー、プロセスルール、TUNを追加します。項目を追加するたびにテストを繰り返すと、どの変更が問題の原因か特定しやすくなります。

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

このコマンドは、混合ポートが7890で、プロキシ認証が設定されていないことを前提としています。ポートが異なる場合は適宜変更してください。HTTPレスポンスを受信できたことが示すのは、そのリクエストが完了したことだけです。すべてのルール、UDPアプリ、TUNが正常とは限りません。直結する想定の宛先と、プロキシ経由の想定の宛先をそれぞれテストし、ログに記録されたポリシー名も照合してください。

サブスクリプション更新後に設定が元に戻る場合

サブスクリプション管理下のファイルを手動で編集すると、次回の更新時にサーバーの内容で置き換えられる可能性があります。現在のクライアントが対応しているオーバーライド、マージ、スクリプトの仕組みを使ってローカルの変更を保存し、マージの順序も確認してください。マージ構文はクライアントによって異なります。あるクライアント用のオーバーライド設定を、そのままmihomo標準の設定項目として使うことはできません。

選び方の結論：実際の要件に合わせて移行範囲を決める

新しいプロトコルが必要：適切なバージョンのmihomoを組み込んだクライアントを選び、サブスクリプションの出力にノードの設定項目がすべて残ることも確認します。
複雑なルーティングが必要：ルールプロバイダー、プロセス識別、DNSポリシー、対象プラットフォームへの対応を確認します。「ルールモード」ボタンの有無だけで比較しないでください。
安定した旧環境を使っている：コピーで検証を済ませてから、普段使う環境を切り替えます。移行の目的は、必要な機能と保守性を得ることであり、名称を変えること自体ではありません。

クライアントを選ぶ際は、クライアント比較で対応プラットフォームとコアの方針を確認できます。プロトコルの設定項目を詳しく調べる場合は、プロトコルガイドをご覧ください。最終的な判断は、実際に動作しているバージョン、読み込みログ、接続結果に基づいて行いましょう。ノードを解析でき、ルールの適用状況を追跡でき、DNSの経路を把握できてはじめて、再現可能な移行が完了したといえます。