mihomoとオリジナルClashコアの違い｜プロトコル・ルールセット・設定の互換性

結論：基本設定は共通点が多いが、拡張機能は旧コアに流用できない

設定が一般的なノード、selectプロキシグループ、ドメイン振り分けルールだけなら、mihomoへの移行で必要な変更は少ないでしょう。ただし、YAMLを読み込めることと、すべての項目が従来どおり動作することは別です。新しいプロトコル、ルールデータファイル、DNSハイジャック、TUNによる通信制御を使う場合は、普段使いの設定を上書きせず、項目ごとに動作を確認してください。

「オリジナルClash」が指すものは、オリジナルのオープンソースコアと、かつて別途配布されていたClash Premiumコアの2つに分けて考える必要があります。機能の範囲はそれぞれ異なります。特にルールプロバイダーやTUNは、旧クライアントが対応していたからといって、オリジナルのオープンソースコアでも使えるとは限りません。mihomoはClash Metaから引き継がれたプロジェクトであり、旧コアの表示名を変えただけのものではありません。

旧設定からmihomoへ：基本構文には共通点が多くありますが、削除・改名された項目やクライアント側で上書きされる設定を確認してください。
mihomo設定から旧コアへ：VLESS、Hysteria2、GEOSITEなどの拡張機能が使えるとは限りません。
GUIクライアントの変更：サービス権限、設定フォルダー、上書きルール、システムプロキシの設定方法も変わるため、コアだけを比べても判断できません。

プロトコル対応：ノードの種類と通信パラメーターを確認

オリジナルのオープンソースClashで一般的に使える出力タイプは、Shadowsocks、VMess、Trojan、SOCKS5、HTTPなどです。mihomoはこれらに加え、VLESS、Hysteria2、TUICなどのプロトコルや通信方式に対応し、REALITY関連の設定も利用できます。使えるパラメーターはインストール済みmihomoのビルドによって異なります。最新ドキュメントの項目を古いClash Metaバイナリにそのまま適用しないでください。

確認項目	オリジナルClashオープンソースコア	mihomo
VMess、Trojanなど一般的なノード	対応。パラメーターは旧コアの仕様を確認	対応。ただし通信方式とTLSのパラメーターを確認
VLESS、Hysteria2、TUIC	これらのノードタイプはそのまま利用できない	それぞれに対応する実装あり。設定項目は異なる
rule-providers	標準機能として一律に使えるわけではない。旧Premiumは別途確認	外部ルールプロバイダーに対応
GEOSITEルール	mihomoで使うこの記述方式には非対応	対応。ドメイン分類データが必要
TUNによる通信制御	旧PremiumのTUN機能と同一視できない	対応。動作はOS、権限、ルーティングに依存

プロトコル名が同じでも、ノード設定をそのままコピーできるとは限らない

たとえばWebSocketを使うノードでは、typeだけでなく、network、パス、リクエストヘッダー、TLSサーバー名も確認が必要です。REALITYノードには、公開鍵やShort IDなど固有のパラメーターがあります。サーバーアドレスとポートだけをコピーしても、通常は接続できません。サブスクリプション変換ツールがこれらの項目に対応していないと、情報が削除され、「ノードは表示されるのに接続できない」状態になることがあります。

サブスクリプションが、他のクライアント用JSON設定ではなく、mihomoで読み込める形式かを確認してください。
ノード項目のtypeを確認し、続けてそのタイプに必要なパラメーターをすべて確認します。
UDPを使う通信では、ノード、プロキシグループ、ネットワークがUDPを許可しているかも確認してください。Webページが開けても、UDPが使えるとは限りません。

対応プロトコルが増えても、必ず遅延が下がるわけではありません。サーバー回線の混雑やパケットロス、クライアントからサーバーまでのネットワーク環境も結果に影響します。コアは必要な機能で選び、ノードは同じネットワーク、同じ接続先、同じ方法で比較しましょう。

ルールセットの違い：rule-providersとGEOSITEは別の仕組み

rule-providersは外部ルールの取得元を定義し、RULE-SETでルール一覧から参照します。一方、GEOSITEはドメイン分類データベースのカテゴリを使って照合します。どちらもメイン設定のルール数を減らせますが、データの提供元、ファイル形式、更新方法は異なります。

まずローカルのルールファイルで参照関係を確認

以下はmihomoの設定例の一部です。既存の設定に統合して使用してください。ノード設定全体としてそのまま使うことはできません。設定フォルダー内のrules/local-direct.yamlからクラシック形式のルールを読み込み、一致した接続をDIRECTに送ります。

rule-providers:
  local-direct:
    type: file
    behavior: classical
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,DIRECT

対応するrules/local-direct.yamlの内容は次のとおりです。ここではドメインサフィックスの照合例としてexample.comを使っています。実際に利用する際は、直結させる必要のあるドメインに置き換えてください。

payload:
  - DOMAIN-SUFFIX,example.com

behavior: classicalでは、DOMAIN-SUFFIXなどのルールタイプを記述します。behavior: domainに変更する場合は、対応するドメインルール形式を使う必要があります。宣言だけを変えて、ファイルの内容をそのままにしてはいけません。バイナリ形式のルールも対応範囲はそれぞれ異なるため、拡張子を変えるだけで別のパーサーに読み込ませることはできません。

GEOSITEはデータベースとカテゴリの両方を確認

たとえばGEOSITE,cn,DIRECTを使うには、ドメイン分類データにcnカテゴリが含まれている必要があります。これはGEOIP,CN,DIRECTと同じではありません。前者はドメイン分類、後者はIPの地域情報を使って照合します。海外CDNを利用するサイトでは、両方のルールで結果が異なることがあります。これは照合基準の違いであり、必ずしもコアの不具合ではありません。

リモートルールや地理データの初回読み込みには、インターネット接続が必要になることがあります。必要なリソースを、まだ確立していないプロキシ経由で取得しようとすると、起動時に依存関係が発生します。移行初期は最小限のルールを残し、必要なデータをローカルに用意してから、リモート更新を段階的に戻すとよいでしょう。

TUNの違い：コアの対応は通信制御の第一歩

システムプロキシは通常、アプリがプロキシ設定を利用することで通信します。一方、TUNは仮想ネットワークインターフェースとルートを使って通信を受け取ります。mihomoがTUNに対応していても、スイッチをオンにするだけですべてのアプリの通信がプロキシに入るとは限りません。OSの権限、仮想インターフェースの作成、ルートの設定、他のVPNとの競合などが通信制御を妨げることがあります。

旧Clash PremiumにもTUN機能はありますが、その設定一式をmihomoの標準的な記述として流用できるわけではありません。移行時はstack、auto-route、auto-detect-interface、dns-hijackなどの項目を確認し、現在のOSでの対応状況も踏まえて設定してください。

3つの層でTUNの動作を確認

インターフェース層：起動ログで仮想インターフェースが正常に作成されたことを確認します。権限不足やデバイス使用中のエラーがないかも見てください。
ルート層：対象の通信が仮想インターフェースに入っているか確認します。複数のネットワークインターフェース、他のVPN、手動設定した静的ルートによって、通信経路が変わる場合があります。
接続層：対象アプリから新しい接続を行い、接続パネルで宛先アドレス、適用されたルール、最終的なプロキシ設定を確認します。

たとえばdns-hijackでよく使われるany:53は、DNSを横取りする設定であり、「暗号化DNSをすべて捕捉する」スイッチではありません。アプリが送信するHTTPS DNSリクエストはHTTPS接続を使うため、通常の53番ポートへの問い合わせとして単純に処理することはできません。IPv6の通信も個別に確認し、IPv4の結果だけで通信制御が完全だと判断しないでください。

Linuxではroot権限や適切なネットワーク管理権限が必要になる場合があります。WindowsやmacOSのGUIクライアントでは、バックグラウンドサービスを通じて権限処理を行うことがあります。サービスのインストール方法はクライアントによって異なるため、各クライアントの説明に従ってください。トラブルシューティングのために仮想インターフェースやルート管理ツールを何重にも追加しないようにしましょう。

DNSと設定の互換性：まず名前解決の経路を維持し、拡張モードは後から切り替える

mihomoは、Clash設定で一般的なdns、nameserver、fallbackなどの概念を引き継ぎ、より細かな名前解決ポリシーにも対応しています。ただし、各項目の組み合わせによって問い合わせ先が決まります。DNSアドレスをすべて同じサービスに変えても、互換性が高まるとは限りません。ノードのドメイン解決と、アプリが使うドメインの解決経路の違いが見えにくくなることもあります。

fake-ipとredir-hostはコアと同時に切り替えない

fake-ipは、ドメインに対応する仮想アドレスを割り当てます。よく使われるアドレス範囲は198.18.0.0/16です。これはドメインと後続の接続を関連付けるためのもので、リモートサーバーの実アドレスではありません。redir-hostは通常、実際の名前解決結果を返します。どちらのモードも、LAN内の機器、実IPを必要とするアプリ、既存のDNSキャッシュに影響する場合があります。

旧環境でredir-hostを使っていた場合、移行の最初の段階では同じモードを維持してください。ノードとルールが動作することを確認してから、fake-ipを個別にテストします。特定のアプリで問題が起きた場合は、症状に応じた除外設定を行いましょう。アプリの不具合を見つけるたびにTUNを無効にし、DNSを変更し、ノードも切り替えるのは避けてください。

ノードのドメインを解決できない：ノード接続の確立前に使われる名前解決経路を確認し、必要に応じてproxy-server-nameserverなどの関連設定を確認します。
ドメインルールが機能しないように見える：接続にドメイン情報が保持されているか、DNSが想定した経路を通っているか確認します。
変更後も古い設定のままに見える：クライアントが設定の統合、上書き、サブスクリプション更新によってDNS設定を再適用していないか確認します。

fallbackは、メインDNSが完全に失敗した後にだけ予備DNSを使う設定ではありません。フィルター条件と組み合わせて、どの結果を採用するかが決まります。移行時のトラブルシューティングでは、まず現在の設定とログを確認し、この項目を変更する必要があるか判断してください。

移行手順：構文チェックから実際の接続テストまで

旧コア、旧設定、クライアントの上書き内容は残し、別途テスト用のフォルダーを作成してください。以下では単体バイナリを使います。mihomo-testは今回のテスト用フォルダー名です。コマンド内のファイルと作業フォルダーは、現在のターミナルの場所を基準にしています。

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

-tは設定のテスト、-dは作業フォルダー、-fは設定ファイルを指定します。構文チェックを通過したことは、設定テストで致命的なエラーが見つからなかったことを示すだけです。サーバーへの接続、システムプロキシの設定、TUNルートの適用を保証するものではありません。

最初の段階ではローカルプロキシポートだけを確認

テスト用の設定には、以下の基本項目を使えます。7890はここで明示的に指定した混合プロキシポートであり、すべてのクライアントで固定されているわけではありません。有効なノードとプロキシグループを含む設定にこれらの項目を統合してから、テストを開始してください。

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

旧クライアントも7890を使っている場合は、旧コアを停止するか、テスト設定に未使用のポートを指定してください。旧クライアントのウィンドウを閉じるだけでは不十分です。バックグラウンドサービスが引き続き動作している場合があります。この段階ではTUNを有効にせず、LAN共有も設定しません。

設定の解析：未対応のノードタイプ、無効なルール、存在しないプロキシグループ、ルールファイルのパス誤りを修正します。
コアの起動：ポートが正常にリッスンしていることを確認し、「アドレスが使用中」などの起動エラーがないか確認します。
プロキシを指定してテスト：ターミナルで以下のコマンドを実行し、リクエストが成功するか、接続パネルに記録が表示されるか確認します。
ルール振り分けを戻す：ルールプロバイダーと地理ルールを段階的に追加し、実際に適用されたルールを確認します。
最後にシステム全体の通信を制御：まずシステムプロキシをテストし、その後TUNを個別に有効にします。複数の要因を同時に加えないようにしてください。

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

このコマンドで確認できるのは、ローカルプロキシ経由のリクエストです。宛先ドメインにDIRECTが適用されていれば、直結でもリクエストは成功することがあります。そのため、接続パネルで適用されたプロキシ設定も確認してください。テストに成功しても、すべてのアプリがリモートノードを経由することや、回線の上限速度に達することを意味しません。

よくある移行トラブルとコアの選び方

症状	まず確認する項目	次の操作
unknown proxy type	実際に動作中のコア、ノードタイプのスペル	クライアントが旧バイナリを呼び出していないか確認
ルールプロバイダーが見つからない	RULE-SETの参照名、ファイルパス、ダウンロードログ	まず小さなローカルルールファイルで解析を確認
設定テストは成功するがインターネットに接続できない	リッスンポート、ノードへの接続可否、プロキシの選択	まずプロキシを明示したリクエストでシステム設定の影響を切り分ける
TUNを有効にすると一部アプリに問題が起きる	ルート、DNS、IPv6、他のVPN	システムプロキシの基本状態に戻し、通信制御を一つずつ戻す
サブスクリプション更新後に設定が消える	設定の取得元、クライアントの統合処理と上書き順序	クライアントがサポートする永続的な上書き先にカスタム設定を保存

VLESS、Hysteria2、TUIC、GEOSITEや、より高度な現代的ルール振り分けが必要なら、mihomoを比較対象にするのが適しています。基本的なプロキシ機能だけで十分な場合は、コアの機能表だけで決めず、GUIクライアントのメンテナンス状況、各OSとの統合、設定管理の方法も比較してください。

Clash評価ナビは、クライアント選びや設定に関する情報を提供するサイトであり、クライアントの開発元ではありません。実際の移行では、インストールしたコアのドキュメント、起動ログ、接続記録を基準にしてください。「設定を読み込める」「リクエストが成功する」「ルールが正しく適用される」「システム全体の通信が制御される」を別々の確認項目にすると、設定を一度にすべて置き換えるよりも原因を特定しやすくなります。

基本用語は用語クイックガイドをご覧ください。ルールとプロキシモードの確認方法は、利用ガイドのルール解説で紹介しています。