コア解説 読了目安 13分

mihomoとオリジナルClashの違い：機能・設定互換性・選び方

2種類のコアについて、設定機能、ルール対応、クライアントとの関係を比較し、移行前に確認すべき項目を解説します。

比較対象：コア・クライアント・設定ファイル

Clashとmihomoの違いを考えるときは、まず「コア」と「クライアント」を分けて考える必要があります。コアはYAMLの読み込み、プロキシ接続の確立、DNS解決、ルール判定、ローカル待受ポートの開放を担当します。一方、デスクトップやモバイルのクライアントは、サブスクリプション管理、システムプロキシの切り替え、ログ確認、設定編集、サービスのインストールなどの画面を提供します。クライアントがmihomoコアを採用していても、すべての設定がメイン設定ファイルに書き込まれるとは限りません。逆に、設定に特定の項目が存在していても、クライアント画面に対応するスイッチが用意されているとは限りません。

ここでいう「オリジナルClash」は、主にDreamacroプロジェクトから生まれたクラシックなオープンソースコアと、その一般的な設定基準を指します。過去には機能の異なるPremiumビルドも存在したため、Clashという名称が付いたすべてのバージョンを同じ機能セットとして扱うことはできません。mihomoはClash Metaから続くコアの派生系で、従来の設定構造を基盤に、プロキシプロトコル、ルールタイプ、DNSの挙動、TUNによるトラフィック取り込み、外部リソース管理などを拡張しています。

共通する基盤は今も明確です。設定は通常YAMLを使い、プロキシノードはproxies、プロキシグループはproxy-groups、振り分けルールはrulesに記述し、動作モードはmodeで制御します。mixed-port、allow-lan、log-level、external-controllerなども、用途はおおむね共通しています。基礎構造が似ているため、多くのクラシックな設定をmihomoで読み込めますが、「起動できる」ことと「挙動が完全に同じ」ことは別です。

主要機能の違い：プロトコルからトラフィック取り込みまで

クラシックなClash設定は、主にHTTP、SOCKS5、Shadowsocks、VMess、Trojan、Snellなどのプロキシタイプを中心に構成されます。mihomoは一般的なタイプを維持しつつ、VLESS、TUIC、Hysteria2、WireGuardなどにも対応・強化しており、一部のプロトコルではトランスポート層、TLSフィンガープリント、UDP、多重化に関する細かなパラメータも利用できます。サブスクリプションにこれらの新しいタイプが含まれている場合、クラシックなコアでは、フィールド名を変更するだけで接続できるとは限りません。対応するプロトコル実装そのものが存在しないためです。

確認項目 クラシックClashの基本設定 mihomoで一般的に利用できる機能
基本構造 ポート、ノード、プロキシグループ、DNS、ルール 一般的な基本構造に対応し、さらに拡張
プロキシプロトコル クラシックなプロキシタイプが中心 より多くの新しいプロトコルとトランスポートパラメータに対応
ルール体系 ドメイン、IP、ポート、プロセスなどの一般的なマッチング ルールセット、論理演算、より多様なメタデータ判定を追加
DNS 基本的なnameserverとfake-ip設定 より細かな振り分け用DNSや専用の上流設定に対応
TUN 具体的なビルドによって異なり、クラシックなオープンソース版は機能が限られます TUN、ルーティングの取り込み、プロトコルスニッフィング設定を継続的に整備
リソースデータ GEOIP、ドメイン、外部リストが中心 GeoIP、GeoSite、ASN、ルールセットと組み合わせて使うことが多い

トラフィック識別も違いが表れやすい部分です。mihomoは設定によりプロトコルスニッフィングを有効化し、宛先IPしかない接続でも実際にアクセスするドメインを補助情報としてルール判定に利用できます。さらに、プロセス名、プロセスパス、インバウンドタイプ、ネットワークタイプ、宛先ポートを組み合わせた振り分けも可能です。TUNによる取り込み、透過プロキシ、アプリごとの細かなトラフィック分離に適した機能ですが、設定は複雑になります。スニッフィング範囲、除外ドメイン、ポートリストを誤って設定すると、アクセス先と想定したルールが一致しないことがあります。そのため、拡張項目をすべて一度に有効化するのは避けてください。

外部コントロールインターフェースの基本概念は両方のコアで似ており、クライアントは通常、コントロールポートを通じて接続、ログ、プロキシグループの状態を取得します。ただし、コントロールAPIの具体的な項目や機能はコアのバージョンによって変わります。旧クライアントの画面で新しいmihomoを起動できても、新たに追加されたプロキシグループ情報を表示できない場合があります。逆に、新しいクライアントを古いコアに接続すると、ボタンは表示されても操作が反映されないことがあります。コアとクライアントの組み合わせは、配布元が提供する構成に従って使用してください。

設定互換性の範囲：解析・実行・結果の一致を分けて確認

設定の互換性は3つの段階に分けて確認できます。第1段階は構文解析です。YAMLのインデント、リスト、データ型が正しく、コアが項目を認識できるかを確認します。第2段階はリソースの利用可否です。プロキシノード、ルールセット、Geoデータ、DNSの上流サーバーを読み込めるかを確認します。第3段階は実行時の挙動です。同じリクエストが同じプロキシグループに入り、DNSが想定どおりの結果を返し、システムのトラフィックが実際に対応するインバウンドを通るかを確認します。移行時に「設定の読み込みに成功した」と表示されただけでは、後半2つまで確認したことにはなりません。

以下は、両方のコアでよく見られる基本構造です。実際のノードパラメータは使用する設定ソースに合わせてください。この例では、項目同士の関係を示しています。

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

proxies:
  - name: example-node
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - example-node
      - DIRECT

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

mihomoへ移行する場合、クラシックな項目はそのまま残し、必要に応じて拡張項目を追加できることが多いです。反対方向の移行はより厳しくなります。設定内の新しいプロトコルノード、rule-providers、sniffer、拡張DNS項目、論理ルール、mihomo専用のプロキシグループパラメータなどは、旧コアに拒否されたり、設計どおりに実行できなかったりする可能性があります。「認識できない項目」を削除すれば直るとは限りません。削除した部分が、ノード接続の確立やルールの正しい判定に必要な条件である場合があるためです。

メイン設定とクライアント側の上書き設定も区別する必要があります。多くのGUIクライアントは、コアを起動する前に、コントロールポート、実行ディレクトリ、TUNスイッチ、キー、DNSの上書き、システムプロキシポートなどのローカル設定を統合します。ユーザーが編集したYAMLは、最終設定の一部にすぎない場合があります。互換性の問題を調べるときは、クライアントから実際の実行設定をエクスポートまたは確認し、ログでコアが最終的に読み込んだパスを確認してください。読み込まれていないファイルを編集し続けることを避けられます。

移行時に見落としやすい項目

  • proxy-providersとrule-providersのパス、URL、更新間隔、動作タイプ。
  • プロキシグループ内で参照するノード名とプロバイダー名、ルール末尾で参照するプロキシグループ名。
  • external-controller、認証キー、クライアントのコントロールインターフェースアドレス。
  • geodata-mode、Geoデータの読み込み方式、対応するリソースファイルの有無。
  • DNSのenhanced-mode、fake-ip-range、フィルターリスト、上流サーバーのグループ。
  • TUNのプロトコルスタック、自動ルーティング、DNSハイジャック、インターフェース除外設定。

ルール対応：タイプが増えても優先順位が変わるわけではありません

Clash系コアのルールは通常、上から順に判定され、マッチした行で指定されたプロキシグループを使用します。mihomoはより多くのルールタイプを追加していますが、「より具体的なルールが自動的に優先される」仕組みに置き換わったわけではありません。広い範囲に一致するDOMAIN-SUFFIXを完全一致のDOMAINより前に置けば、前者が先にリクエストを捕捉する可能性があります。MATCHを早い位置に置くと、後続のルールは実行されません。

一般的なルールにはDOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、IP-CIDR6、GEOIP、DST-PORT、SRC-IP-CIDR、PROCESS-NAME、MATCHがあります。mihomo環境では、GEOSITE、RULE-SET、NETWORK、PROCESS-PATH、論理演算を組み合わせたルールもよく使われます。利用できるタイプは、コアのバージョンに対応するドキュメントと起動ログを基準に確認してください。

RULE-SETは、それ自体で新しいルールを生成するものではありません。rule-providersで定義した外部ルールセットを参照します。ルールセットでよく使われる動作タイプにはdomain、ipcidr、classicalがあります。domainはドメイン項目、ipcidrはIPネットワーク、classicalはルールタイプを含む従来形式の項目に適しています。動作タイプと実際の内容が一致しない場合、ファイルのダウンロードに成功しても、項目を想定どおり読み込めないことがあります。

rule-providers:
  private-domains:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/private-domains.yaml
    url: https://example.com/private-domains.yaml
    interval: 86400

rules:
  - RULE-SET,private-domains,DIRECT
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,PROXY

no-resolveは、ルール判定時にドメインを自動解決させたくないIP系ルールでよく使われます。接続全体でDNSが不要になるわけでも、DNSモジュールを無効にするわけでもありません。そのルールを判定するときに解決を発生させるかどうかだけに影響します。すべてのルールに機械的に付けても、あらゆる場面で速度が向上するわけではなく、解決結果に依存する判定経路を変えてしまう可能性もあります。

プロセスルールの利用可否もOSによって完全には同じではありません。デスクトップOSではプロセス名やパスを取得しやすい一方、モバイルOSでは権限やネットワークスタックの制約により、クライアントが同じ情報をコアへ渡せない場合があります。PROCESS-NAMEに依存するデスクトップ設定をスマートフォンへ移行する場合は、ルール文が同じなら結果も同じだと考えず、ドメインやIPルールを補助として用意してください。

DNSとTUN：違いを誤解しやすい領域

通常のシステムプロキシは、HTTPまたはSOCKSプロキシを明示的に使用するアプリの通信を主に受け取ります。TUNモードは仮想ネットワークインターフェースを通じて、より広い範囲の接続を取り込みます。mihomoのTUN設定でよく使われる項目にはenable、stack、auto-route、auto-detect-interface、dns-hijackがあります。これらが機能するかどうかは、OSの権限、ルーティングテーブル、ファイアウォール、クライアントのサービス、ほかのVPNソフトが同時にトラフィック取り込み機能を使用していないかどうかにも左右されます。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

この設定例は項目同士の関係を示すもので、すべての端末がそのまま採用すべき固定解ではありません。mihomoのバージョンによって対応するTUNプロトコルスタックの選択肢が変わる場合があり、クライアントが関連項目を自動生成することもあります。クライアントがすでにTUNを管理している場合、サブスクリプション設定に別のパラメータセットを重ねて記述すると、更新のたびに上書きされたり、ローカルのルーティング設定と競合したりする可能性があります。

DNSのfake-ipモードは、まずアプリに予約アドレス範囲のマッピングアドレスを返し、その後コアが実際のドメインと関連付けてルール判定を行います。透過的なトラフィック取り込みでドメイン情報を維持しやすい一方、LAN機器の検出、一部のゲーム、特定の認証処理、実際のDNS応答に依存するプログラムではfake-ip-filterへの追加が必要になることがあります。redir-hostは処理経路が異なり、互換性もシステムやアプリによって変わります。モードは項目数だけで比較せず、実際の障害状況に基づいてテストして選んでください。

mihomoには、nameserver-policy、proxy-server-nameserver、direct-nameserverなど、より細かなDNSの振り分け設定もあります。前者では特定のドメインに指定した上流サーバーを使わせ、後2者ではプロキシサーバーのアドレスと直結先で異なる名前解決経路を指定できます。DNS経路の混在を減らせる一方、設定を誤るとループが発生することがあります。たとえばプロキシサーバーのドメインを解決する際、そのDNS自体がまだ確立していないプロキシ経由のアクセスを必要とするケースです。

オリジナルClashからmihomoへ移行する確認手順

安全に移行するには、正常に動作している設定のコピーから始め、唯一のファイルに変更を重ね続けないでください。まず基本的なプロキシ接続を確認し、その後にルールセット、DNS、TUNを追加すれば、障害がノード接続、ルール判定、システム側の取り込みのどこにあるかを素早く切り分けられます。

  1. 現在の実行情報を記録する。 元のコアバージョン、クライアントバージョン、待受ポート、システムプロキシの状態、DNSモード、利用可能なプロキシグループを保存します。移行後に挙動が変わった場合、比較材料になります。
  2. YAML構造を確認する。 インデントにスペースだけを使っているか、ノード名とプロキシグループの参照名が完全に一致しているか、ポートが数値になっているか、真偽値が意図せず文字列になっていないかを確認します。まず解析エラーを解消し、その後でネットワークエラーに対応してください。
  3. 最小構成で接続テストを行う。 既知の動作ノードを1つ、selectタイプのプロキシグループを1つ、少数のルールだけを一時的に使用します。ローカルの混合ポートにアクセスできることを確認してから、完全なサブスクリプションやプロキシプロバイダーを読み込んでください。
  4. ルールリソースを項目ごとに戻す。 各プロバイダーのダウンロード状態、ファイルパス、behavior、formatを確認します。ルールセットの更新に失敗したときは、プロキシグループが存在するかだけでなく、ログで読み込まれた項目数も確認してください。
  5. DNSを個別に検証する。 プロキシサーバーのドメイン、直結するドメイン、プロキシが必要なドメインをそれぞれ確認します。ドメインだけ失敗し、IPアドレスへの直接アクセスが正常なら、問題はノードのプロトコルよりDNS経路にある可能性が高いです。
  6. 最後にTUNを有効にする。 ほかのVPNやトラフィック取り込みツールを先に終了し、管理者権限とサービスコンポーネントが正常であることを確認してから、ルーティングテーブル、DNSハイジャック、LANアクセスを確認します。通常のシステムプロキシは使えるのにTUNだけ使えない場合は、OS側の設定を重点的に調べてください。
  7. 最終的に有効な設定を確認する。 クライアントが上書き、スクリプト、設定のマージに対応している場合は、統合後の結果を確認します。サブスクリプション更新後も、ローカルのルールやDNS変更が維持されているか再確認してください。

ログに出るエラーの種類から、原因の範囲を絞り込めます。unknown fieldや設定解析エラーは、項目とバージョンの不一致を示すことが多いです。ルールプロバイダーのダウンロード失敗なら、URL、ネットワーク経路、保存先を確認します。接続タイムアウトの場合は、プロキシサーバーの名前解決、トランスポートのハンドシェイク、ルーティング、ルール選択をさらに切り分けてください。複数のエラーが同時に出たからといって、ポート、DNS、ノード、TUNを一度に変更しないでください。まとめて変更すると比較できる基準を失います。

選び方：設定の入手元と必要な機能を基準にする

現在の設定がクラシックなプロトコル、シンプルなプロキシグループ、少数のドメインルールだけで構成され、クライアントとコアの組み合わせも長期間安定しているなら、互換性のあるクラシック環境を使い続けることで変更コストを抑えられます。ただし、プロジェクトのメンテナンス状況、OSのアップデート、クライアントの対応状況には注意が必要です。特にコントロールインターフェース、システムプロキシサービス、証明書コンポーネントが正常に連携できるかを確認してください。

サブスクリプションにVLESS、TUIC、Hysteria2など新しいノードタイプが含まれている場合や、GeoSite、ルールプロバイダー、論理ルール、プロトコルスニッフィング、細かなDNS振り分け、継続的に保守されているTUN機能に依存する設定なら、mihomoのほうが適しています。その場合は、使用するコアのバージョンを明記したクライアントを選び、クライアント、コア、設定構文が相互に対応するバージョン範囲にそろえてください。

選ぶ際に項目数の多さを追い求める必要はありません。一般的なデスクトップユーザーなら、安定したシステムプロキシ、更新可能なサブスクリプション、分かりやすいプロキシグループで主要な用途を満たせます。ゲームのUDP、LAN共有、コンテナネットワーク、プロセス単位の振り分け、全体的なTUN取り込みが必要な場合は、使用するOS上での実装を重点的にテストしてください。同じYAMLでも、Windows、macOS、Linux、Android、iOSでは権限やネットワークフレームワークの違いにより挙動が変わることがあります。

選択前に確認する4項目

  • サブスクリプション内のノードプロトコルが、移行先のコアに対応しているか。
  • ルールがmihomo専用タイプ、Geoデータ、外部ルールセットに依存していないか。
  • クライアントが必要なTUN、サービスモード、システムプロキシ設定を管理できるか。
  • 設定の更新機能がローカルの上書き設定とカスタムルールを保持するか。

設定管理の観点では、mihomoは拡張中のルールやプロトコル要件を扱うのに適しており、クラシックなClash設定は、ポート、プロキシグループ、上から順に判定するルールの仕組みを理解する重要な基礎です。移行の要点は、古いファイルに項目を増やすことではありません。プロトコル実装、リソースファイル、DNS経路、システム側の取り込み方式を一つずつ確認することです。最小限の動作設定を保管し、変更のたびに検証できるようにすると、複雑な設定をそのままコピーするより安定した結果を得やすくなります。

よくある質問

オリジナルClashの設定をそのままmihomoに入れられますか？

一般的な基本設定は高い互換性を持つことが多いものの、古いビルド固有の項目、Geoデータのパス、DNSの挙動、クライアント側の上書きを確認する必要があります。設定の読み込みに成功した後も、ノード接続とルール判定をテストしてください。

mihomoの設定をクラシックなClashで使えますか？

デフォルトで互換性があるとは考えないでください。新しいプロトコル、拡張ルール、ルールプロバイダー、スニッフィング、TUN、DNSの拡張項目を認識できない可能性があります。エラー項目を削除しても、元の挙動が維持されるとは限りません。

コアを変更したらすべてのノードがタイムアウトします。まず何を確認すべきですか？

まずノードのプロトコルが対応しているかを確認し、次にプロキシサーバーのドメインを解決できるか、システム時刻が正しいか、プロキシグループで有効なノードが選択されているかを確認します。TUNモードだけが失敗する場合は、権限、ルーティング、DNSハイジャックを調べてください。

クライアントとコアのバージョンは完全に同じである必要がありますか？

バージョン番号が同じである必要はありません。ただし、クライアントがそのコアの起動パラメータ、コントロールインターフェース、設定機能に対応している必要があります。クライアントの配布元が提供する、または互換性を明記しているコアの組み合わせを優先してください。

Clashをダウンロード