mihomoとオリジナルClashコアの違い｜対応プロトコル・ルールセット・設定項目

コアの違い：オリジナル版・Premium・mihomoを整理

mihomoは、旧Clash.Metaプロジェクトの後継として開発されているコアで、Clash Metaコアとも呼ばれます。ClashのYAML設定を引き継ぎながら、対応プロトコル、DNS、ルールセット、トラフィック制御機能を拡張しています。mihomo搭載クライアントへの移行は、単なる画面の変更ではありません。設定の読み込み、接続の確立、ルールの適用を担うプログラム自体が変わります。

「オリジナルClash」との比較では、Dreamacro/clashのオープンソースコアと、オリジナルのエコシステムにあるClash Premiumを分けて考える必要があります。両者の機能は同じではありません。特にTUNとルールプロバイダーは、「オリジナル版にはなく、mihomoだけにある」と一括りにはできません。オリジナルプロジェクトは2023年に開発が終了しましたが、旧版向けの解説やサブスクリプションのテンプレートは今も使われています。移行時は、実際に動作しているコアのバージョンを確認してください。

• クライアント：サブスクリプションの取り込み、トレイ表示、システムプロキシ、設定ファイルの生成などを担います。デスクトップ版には設定を管理する画面があります。
• コア：プロトコルのハンドシェイク、DNSクエリ、ルール照合、出力接続を処理します。画面に表示されるバージョンは、コアのバージョンとは限りません。
• サブスクリプション：設定全体を含む場合も、ノード一覧だけの場合もあります。内容を確認せず、同じプロバイダー項目に登録しないでください。

機能比較：対応プロトコルが増えても設定の互換性は別問題

この表は機能の範囲を示すもので、すべてのバージョンで利用できることを保証するものではありません。サーバー側の新機能、特定のトランスポートの組み合わせ、ルールセットの形式によっては、新しいmihomoが必要になる場合があります。「未対応のプロキシタイプ」と表示されたら、インストールパッケージ名にMetaとあるかだけで判断せず、クライアントで実際に動作しているコアを確認してください。

VLESS・Hysteria2への移行時に確認するポイント

VLESSのノードタイプはtype: vlessと記述します。サーバーがREALITYを使用している場合は、reality-opts、公開鍵、Short ID、サーバー名、クライアントフィンガープリントを正しく設定してください。flowもサーバー側の設定と一致させる必要があります。VMessノードのタイプだけをVLESSに変更しても、プロトコルは変換されません。

Hysteria2のノードタイプはtype: hysteria2と記述します。Hysteria 1とは設定形式が異なります。認証情報、ポート、SNI、obfs、帯域幅のパラメーターはサーバー側に合わせてください。また、利用するネットワークで該当するUDP通信が許可されている必要があります。TCPでWebサイトを開けても、Hysteria2のUDPハンドシェイクが通るとは限りません。

• サブスクリプション提供元に、mihomo対応の出力形式を用意してもらうのがおすすめです。設定全体を何度も手作業で修正するのは避けましょう。
• 証明書名や信頼チェーンのエラーを隠すために、全体設定でskip-cert-verify: trueを指定しないでください。
• ノード設定にはパスワード、UUID、認証トークンが含まれることがあります。ログを共有する前にこれらを伏せ、サブスクリプションURLのトークンも削除してください。

ルールセットの移行：provider・behavior・ファイル内容を区別する

proxy-providersはノードを提供し、rule-providersは照合条件を提供します。前者はポリシーグループのuseから、後者はRULE-SETルールから参照します。ノードのサブスクリプションURLをルールプロバイダーに設定しても、URLから取得できたとして、振り分けルールとしては使えません。

以下はローカルファイルを使った例です。設定ファイルとrulesディレクトリは、同じ設定作業ディレクトリに配置します。クライアントが専用のコア作業ディレクトリを使う場合は、実際の作業ディレクトリを基準にしてください。この例はルールファイルの読み込みのみを示しており、プロキシノードを含まず、外向きのプロキシ通信もできません。

メイン設定のルールプロバイダー

rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

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

rules/local-domains.yamlの内容

payload:
  - '+.example.com'
  - 'example.org'

behavior: domainの項目にはドメインパターンを記述します。DOMAIN-SUFFIX,example.comのような完全なルールを直接書くことはできません。behavior: classicalを使う場合は、payloadにDOMAIN-SUFFIX,example.comなど、対応する従来形式のルールを記述できます。適用するポリシーは外側のRULE-SETで指定します。

• domain：ドメインの照合に使います。ドメイン名だけのリストに適しています。
• ipcidr：192.168.0.0/16など、IPネットワークの指定に使います。ドメイン名は混在させないでください。
• classical：対応する従来形式のルールタイプに使います。ルールの記述形式は前の2種類とは異なります。

YAML、プレーンテキスト、MRSはそれぞれ異なる保存形式です。MRSはmihomoのバイナリ形式のルールセットで、domainとipcidrのbehaviorに対応します。オリジナルコアとの汎用的な受け渡し形式には適していません。移行時はbehavior、format、配信元から実際に返される内容を確認してください。拡張子を.yamlに変えても、ファイル内部の形式は変わりません。

ルールは記述順に照合されます。MATCHを先に置くと、後続のルールは適用されません。対象範囲の広いDIRECTルールをプロキシルールより前に置いた場合も、従来の振り分け結果が変わることがあります。ファイルを読み込めても、ルールの適用順が意図どおりとは限りません。

snifferによるスニッフィング：ドメイン情報を補う機能であり、通信の復号ではない

接続先がIPアドレスしか分からない状態でコアに渡されることがあります。mihomoのsnifferは、対応するHTTP、TLS、QUIC通信からドメイン名を取得し、ルール照合を補助できます。設定によっては接続先の書き換えも行われます。HTTPSを復号するプロキシではないため、TLSで暗号化された本文を読み取ることはできず、すべての接続からドメイン名を取得できるわけでもありません。

sniffer:
  enable: true
  override-destination: false
  sniff:
    HTTP:
      ports: [80, 8080]
    TLS:
      ports: [443]
    QUIC:
      ports: [443]

この設定例では、HTTPの検査対象を80・8080番ポート、TLSとQUICを443番ポートに限定し、接続先アドレスの書き換えを明示的に無効にしています。まずはスニッフィングとルール照合の結果を確認でき、接続先書き換えの影響も切り分けやすくなります。対象ポートを広げるかどうかは用途に応じて判断してください。「より網羅的に」という理由で、すべてのポートを検査するのは避けましょう。

特定のWebサイトでスニッフィングを有効にすると問題が起きる場合は、まずsniffer.enableを無効にし、ほかの条件を変えずに比較します。次に、該当ドメインをskip-domainに追加する必要があるか確認してください。TLSでECHなどが使われていると、取得できるドメイン情報が限られる場合があります。スニッフィングはDNSによる振り分けの代わりにはなりません。クライアントのDNS通信がシステム側へ迂回している場合は、DNS設定または通信制御経路で対処してください。

DNS・TUN：基本項目は引き継げても、動作条件の再確認が必要

旧設定にあるdns.enable、enhanced-mode: fake-ip、fake-ip-filterなどの設定は、mihomoでも引き続き利用できます。Fake-IPは予約アドレスとドメイン名を対応付け、後続の接続で元のドメイン情報を復元する仕組みです。「すべてのDNS通信がプロキシ経由になる」という意味ではなく、ブラウザーが独自に有効化した暗号化DNSを自動的に制御するものでもありません。

DNSの追加項目は単独でコピーしない

nameserver-policyは特定のドメインに指定したDNSサーバーを使わせる設定です。proxy-server-nameserverはプロキシノードのサーバードメインを名前解決するために使います。respect-rulesを有効にすると、DNSの上流接続にルーティングルールを適用できます。有効化後はプロキシノードのドメインをどの経路で解決するか確認してください。「プロキシ接続にはノードの名前解決が必要だが、名前解決にはプロキシ接続が必要」という循環依存を避ける必要があります。

移行の初期段階では、動作確認済みのDNSサーバーを維持し、ドメインの名前解決とルールの適用結果を確認してから、項目を一つずつ追加するのがおすすめです。2つのクライアントのDNS設定をまとめて貼り合わせないでください。同じキーが後から読み込んだ設定で上書きされたり、起動前にクライアントがリッスンアドレスやポリシーを追加したりする場合があります。

TUNの不具合はYAMLの構文だけが原因とは限らない

• 権限：仮想ネットワークアダプターの作成やルートの変更には、管理者権限、システムサービス、または適切なネットワーク権限が必要な場合があります。
• ルーティング：自動ルーティングはVPN、仮想マシンのネットワーク、ほかの通信制御ソフトとの調整が必要です。二重に通信を制御しないようにしてください。
• DNSの横取り：dns-hijackで53番ポートを指定しても、DoHやDoTのリクエストをすべて制御できるわけではありません。
• システムプロキシ：システムプロキシ設定に従うアプリが対象です。TUNは仮想ネットワークアダプター層で通信を制御するため、同じ設定ではありません。

トラブルシューティングでは、まずTUNを無効にし、指定したローカルプロキシポート経由でノードをテストしてから、TUNを個別に有効にしてください。「ノードが使えない」問題と「システムの通信制御に失敗する」問題を切り分けられます。ルーティングの不具合に対して、ノードのパスワードを何度も変更する必要もありません。

旧設定の移行：最小構成、ルール、通信制御の順に検証

移行は、高度な設定項目を一度にすべてコピーするところから始めないでください。元のクライアントのリッスンポート、動作モード、ポリシーグループの選択状態、コアのバージョンを記録し、元に戻せる設定コピーを作成します。以下の手順は、コアを手動で確認する場合にも、クライアントが生成する設定の問題を切り分ける場合にも使えます。

1. 実際のコアを確認する。単独で動作する環境ではmihomo -vを実行します。クライアント内で動作する環境では、コア情報または起動ログを確認し、クライアントとコアそれぞれのバージョンを区別してください。
2. 設定の構文を確認する。設定ディレクトリでmihomo -t -f ./config.yamlを実行します。ファイルプロバイダーが相対パスを使う場合は、コアの作業ディレクトリも確認してください。構文検査に通っても、リモートのノードに接続できるとは限りません。
3. ローカルの接続口を固定する。たとえばmixed-port: 7890を指定し、allow-lan: falseを維持します。7890はこの例で使うポートであり、すべてのクライアントに共通する既定値ではありません。
4. ノードを1つずつ検証する。利用できることが分かっているノードを1つ選び、ローカルプロキシ経由で接続先へリクエストします。その後に自動選択のポリシーグループを有効にし、ヘルスチェックやノード切り替えで問題が隠れないようにします。
5. ルールとDNSを戻す。ルールプロバイダーを1つずつ有効にし、接続ログで適用されたルール、ポリシーグループ、最終的な接続先ノードを確認します。Webページが開くかどうかだけで判断しないでください。
6. 最後にTUNとスニッフィングを有効にする。一度に変更する機能は1つに絞り、問題が起きる前後のログと有効な設定を保存してください。

mihomo -v
mihomo -t -f ./config.yaml
curl --proxy http://127.0.0.1:7890 --head https://example.com

上記のcurlコマンドは、ローカルにcurlをインストールした環境で、7890番ポートを明示してリクエストを送ります。Windows PowerShellでcurlが別のコマンドに割り当てられている場合は、curl.exeを使ってください。HTTPレスポンスが返ってくれば、そのリクエスト経路が動作していることは確認できますが、すべてのドメイン、UDP通信、TUN経由の通信が正常とは限りません。

旧形式の設定で優先して確認する項目

• 旧形式のキー名：古いテンプレートのProxy、Proxy Group、Ruleは、現在の設定構造に合わせてproxies、proxy-groups、rulesに整理してください。過去の互換処理には頼らないでください。
• ポリシーグループの参照：rulesから参照するグループ名が存在することを確認してください。大文字・小文字やスペースも一致させます。古いグループを削除した場合は、最後のMATCHも修正してください。
• プロトコル固有の項目：別のコアで使うJSON項目を、mihomoのYAMLにそのまま貼り付けないでください。同じプロトコルでも、設定体系によって項目の階層や名前が異なる場合があります。
• コントロールAPI：external-controllerとプロキシのリッスンポートは用途が異なります。ローカルからのみ管理する場合はループバックアドレスにバインドしてください。リモートアクセスが必要な場合は認証を設定し、アクセス可能なネットワークを制限します。

トラブル対処：設定の読み込み、接続、振り分けを分けて確認

mihomoの主な利点は、対応プロトコルと設定機能が拡張されることです。旧設定がどの環境でも自動的に同じ動作をするわけではありません。移行の成否は「画面にエラーが出ない」だけで判断せず、ノード接続、DNS名前解決、ルールの適用、システムの通信制御を個別に確認してから、通常のサブスクリプション更新に戻してください。クライアント選びはクライアント比較、初回インストールやシステム権限の設定は全プラットフォーム向けガイドをご覧ください。