コア選び 読了目安 13分

Clashのコアバージョン比較：オリジナルPremium・Clash Meta・mihomoの違い

3世代のコアの関係を整理し、対応プロトコル、ルール拡張、GEOSITEとTUNの違いを比較。各プラットフォームに適したコア選びも解説します。

まず名称を整理：3つのバージョンが並行して更新されているわけではない

Clashクライアントは通常、グラフィカルインターフェース、コア、設定ファイルの3つで構成されます。インターフェースはサブスクリプションの読み込み、ノード切り替え、ログ表示を担当し、コアはプロキシ接続の確立、ルール解析、DNSポリシーの実行、通信の取り込みを担います。クライアント名が同じでも、使用するコアが同じとは限りません。機能の対応範囲を判断する際は、アプリ名だけでなくコア名とバージョンを確認しましょう。

オリジナルのClashは、Dreamacroが公開したオープンソースのコアで、HTTP、SOCKS、混合プロキシポート、プロキシグループ、基本的なルールマッチングなどに対応していました。Clash Premiumは、作者がこのコアを基に公開した強化版で、TUN、ルールセット、スクリプト、より包括的な通信取り込み機能などが追加されました。元プロジェクトのリポジトリが2023年にメンテナンスを終了したため、現在はオリジナル版もPremiumも継続的な機能更新の基準としては適していません。

Clash Metaは、コミュニティがClashからフォークして開発した強化コアです。Clashの設定構造を引き継ぎながら、プロトコル、ルール、DNS、TUN、プロキシグループの機能を拡張しました。その後、正式名称はmihomoに変更されています。つまりClash Metaとmihomoは主に旧称と現行名の関係であり、完全に別の新コアではありません。古いクライアントではMetaと表示される場合がありますが、新しいバージョン、ドキュメント、プロセス名ではmihomoが使われることが多くなっています。

名称とメンテナンスの関係

名称 位置づけ 現在の選定での意味
オリジナルClash 初期のオープンソース基盤コア 古い設定の確認や基本構文の理解には適していますが、新規構築の第一候補にはおすすめしません
Clash Premium 作者が公開した強化ビルド 古いデスクトップクライアントでよく使われ、既存設定との互換性を重視します
Clash Meta コミュニティ強化ブランチの旧称 多くの機能はmihomoに引き継がれています
mihomo Clash Metaから改称された継続メンテナンス中のプロジェクト 新しいプロトコル、拡張ルール、完全なTUN機能が必要なデバイスに適しています

プロトコル対応の違い：まずサブスクリプションの転送方式を確認

コアがサブスクリプションを読み込めることと、そこに含まれるすべてのノードへ接続できることは別です。変換後のサブスクリプションは通常、proxiesの配列になり、各ノードにはtype、サーバーアドレス、ポート、認証情報などが含まれます。未対応のタイプがあると、読み込み時にエラーで停止する場合もあれば、そのノードだけがスキップされる場合もあります。その結果、サブスクリプションの更新は成功してもノード数が減ることがあります。

オリジナル版とPremiumの基本対応範囲

オリジナルのClashは、当時一般的だったShadowsocks、VMess、Trojan、Snell、SOCKS5、HTTPなどに主に対応していました。Premiumの強みはTUN、ルールセット、実行機能にあり、後から登場したすべてのプロキシプロトコルに対応しているわけではありません。新しいフィールドを含むサブスクリプションを古いPremiumクライアントへ読み込むと、unsupported proxy typeやフィールド解析エラーが発生する可能性があります。

mihomoの拡張対応範囲

mihomoは一般的なClashのノード構造との互換性を保ちながら、VLESS、Reality、Hysteria 2、TUIC、WireGuard、ShadowTLSなどのタイプや転送方式の組み合わせを継続的に追加しています。具体的なフィールドはコアのバージョンによって変わります。たとえばVLESS Realityでは通常、servername、reality-opts、公開鍵、短い識別子などを使用し、Hysteria 2ではサーバーポート、認証情報、TLSサーバー名などが必要です。古いコアがこれらのフィールドを認識できない場合、ノード名を変更するだけでは解決しません。

  • サブスクリプションがShadowsocks、VMess、Trojan中心なら、3種類のコアで基本的な接続能力が重なる部分は多くなります。
  • VLESS Reality、Hysteria 2、TUICを含む場合は、クライアントにmihomoが組み込まれているかを直接確認しましょう。
  • WireGuardノードを使う場合は、「プロキシノードのタイプ」と、システム上で単独動作するWireGuardアプリを区別してください。設定画面が異なります。
  • ノード対応はクライアントの実装にも左右されます。コアが機能を備えていても、グラフィカルインターフェースにフィールド編集項目がなければ、YAML設定から指定する必要があります。

ルール機能の違い：基本構文は互換でも、拡張フィールドは相互利用できない

3者はいずれも、上から順に評価し、最初に一致したルールで処理を止めるClashのルールモデルを引き継いでいます。DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、末尾のフォールバックルールは高い互換性があります。差が出るのは、ルールセット、プロセス判定、インバウンド条件、地理データの読み込み方式です。

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - DOMAIN-KEYWORD,video,Media
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Final

この設定例は一般的な原則を示しています。ドメインルールはIPの解析が必要なルールより前に置き、LANアドレスは直接接続します。no-resolveは、IP-CIDRルールによるDNS解析の自動実行を避けるために使います。最後はMATCHで未一致の接続を処理します。古い設定にはFINALを使うものもありますが、移行時は対象コアのドキュメントに合わせ、対応する記法へ統一してください。

RULE-SETとルールプロバイダー

Premiumは、ルールセット機能によって長大なルール一覧の管理問題に対応しました。Metaとmihomoではrule-providersがさらに普及し、ローカルファイルやリモートURLからdomain、ipcidr、classicalなどの形式を読み込めます。設定時はルールファイルの内容だけでなく、behaviorと内容形式が一致しているかも確認が必要です。ドメイン一覧をipcidrとして宣言しても、コアが自動判定して修正することはありません。

rule-providers:
  private-domain:
    type: file
    behavior: domain
    path: ./rules/private-domain.yaml

rules:
  - RULE-SET,private-domain,DIRECT
  - MATCH,Final

リモートのルールプロバイダーには、url、interval、キャッシュパスが含まれる場合もあります。更新間隔は通常秒単位で、たとえば86400は24時間を意味します。ルールファイルは頻繁に更新すればよいとは限りません。公開の地理リストなら1日1回で十分なことが多く、過度な更新は起動処理とネットワークリクエストの負荷を増やします。

プロセスとインバウンドのマッチング

mihomoは、PROCESS-NAME、PROCESS-PATH、NETWORK、IN-PORT、SRC-IP-CIDR、論理結合ルールなど、より豊富な条件に対応しています。プロセスマッチングはOSの権限や実装方式に依存するため、Android、Windows、macOSで利用範囲が完全に同じではありません。モバイルOSの制限が大きい場合は、ドメインルールとIPルールを使うほうが安定しやすいでしょう。

GEOSITEとGEOIP：名前は似ていても対象が異なる

GEOIPは、接続先IPが属する地域に基づいて判定します。接続先がドメイン名だけの場合、地域を判断するためにコアが先にIPを解決することがあります。一方、GEOSITEは、検索サービス、ストリーミング、特定地域のドメイン集合など、あらかじめ整理されたドメイン分類データに基づいて判定します。リアルタイムでサイトの所在を検索する機能でも、ウェブページの内容を分析する機能でもありません。

オリジナルのClashは、早い段階からGEOIPなどの基本的な地理判定に対応していました。Premiumと後続のブランチでは、利用できるデータやルール形式が拡張されています。mihomoはGeoIP、GeoSite、各種形式のデータファイルを組み合わせて利用できますが、ファイル形式、ダウンロード先、設定項目は対象バージョンに合わせる必要があります。ルール行だけがあり、データファイルがない場合は、起動ログにリソース読み込み失敗が表示されることが多いです。

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Final

上の例では、まずドメイン分類で広告関連の集合を処理し、次に中国本土でよく使われるドメインを直接接続へ振り分け、その後GEOIPでIPが判明した接続を補完的に処理しています。順序は自由に入れ替えられません。広範囲なGEOSITE,cn,DIRECTを、プロキシ接続が必要な特定ドメインのルールより前に置くと、具体的なルールが一致する機会を失う可能性があります。

地理データでよくある確認ポイント

  1. クライアントの「設定」→「コア」または「概要」で、実際に動作しているのがPremium、Meta、mihomoのどれかを確認します。
  2. 設定ディレクトリを開き、GeoIPとGeoSiteのデータファイルが存在するか、更新日時が適切かを確認します。
  3. 「設定」→「ログ」でgeo、rule、providerを検索し、ファイルが読み込まれていることを確認します。
  4. 対象ドメインをより具体的なDOMAINまたはDOMAIN-SUFFIXルールに入れてテストし、地理分類そのもののずれを切り分けます。
  5. クライアントのコア更新後に、地理データも同時に更新されているか確認します。通常、両者は別の画面や操作から管理されます。

TUNモードの違い：取り込み範囲はコア・権限・システムルートで決まる

システムプロキシは、HTTPまたはSOCKSプロキシ設定に従うアプリにのみ影響します。ゲーム、コマンドラインプログラム、一部のストアアプリ、独自ネットワークスタックを使うソフトはシステムプロキシを回避することがあります。TUNモードは仮想ネットワークインターフェースを通じて、より多くのTCP・UDP通信を取り込むため、デスクトップやモバイル端末で通信を一括して振り分けたい場合によく使われます。

オリジナルの基盤コアは主にプロキシポートを中心に動作します。PremiumではTUNが重要な強化機能として追加されました。mihomoはTUN設定を引き継ぎ、さらに拡張しています。代表的なフィールドにはenable、stack、auto-route、auto-detect-interface、strict-route、dns-hijackがあります。対応する値はバージョンによって変わる場合があるため、古い設定を移行する際は、現在のコアが出力するエラーを基準にしてください。

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

auto-routeは必要なルートを自動的に追加します。auto-detect-interfaceは現在の出口ネットワークインターフェースを識別します。strict-routeは通信の迂回を減らし、dns-hijackは指定されたDNSリクエストをコアで処理します。例のany:53は、宛先ポート53のDNS通信を取り込む設定です。ただし、現在のシステムに適しているかは、ローカルDNS、LAN機器、ほかのVPNソフトとの組み合わせを確認して判断してください。

TUNスタックの選び方

  • system：OSのネットワークスタックにより大きく依存します。一般に直接的な性能が得られやすく、デスクトップで最初に試す選択肢に適しています。
  • gVisor：ユーザー空間のネットワークスタックで一部の接続を処理します。互換性が異なる場合があり、特定のUDP通信やアプリで問題があるときの比較テストに使えます。
  • mixed：通信の種類に応じて組み合わせて処理します。利用できるか、具体的にどう動くかはmihomoのバージョンによって異なるため、古い設定の移行後は起動ログを確認してください。

TUNを有効にしてインターネットに接続できなくなっても、コア自体が使えないとは限りません。まずTUNを無効にし、通常のシステムプロキシで接続できることを確認します。次に管理者権限、仮想NIC、デフォルトルート、DNSを確認してください。WindowsではほかのVPN仮想NICとの競合、macOSではシステム拡張またはVPN権限、Androidでは有効なVPNサービスが1つだけになっているかを重点的に確認します。

DNS動作の違い：Fake-IP設定はルールとTUNと合わせて確認

Clash系コアでよく使われるDNS強化モードにはfake-ipとredir-hostがあります。Fake-IPは、まずアプリに予約済みアドレスを返し、接続時に元のドメイン名へ戻すことで、ドメインルールを早い段階でマッチングできるようにします。一部の環境では再解析を減らせますが、実際のLANアドレスに依存する機器の検出、プリンター、ゲームプラットフォーム、社内ネットワークのドメインに影響する場合があります。

mihomoは、Fake-IPフィルター、DNS分流、フォールバック解析、nameserver-policyなどを組み合わせるための、より多くの機能を提供します。設定が複雑になるほど、各DNSグループの用途を明確にする必要があります。すべてのドメインを複数の上流DNSへ同時に渡しても、必ずしも速くなるとは限らず、結果が一致しなくなることもあります。家庭内ネットワークでは、まず主要なリゾルバー1組、直接接続ルール1組、必要なFake-IP除外項目から始めるとよいでしょう。

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

この例では、コアのDNSを1053番ポートで待ち受け、198.18.0.1/16をFake-IPのアドレス範囲として使っています。この範囲をノードサーバーの実アドレスとみなしてはいけません。ログに198.18.x.xへの接続が表示された場合は、ドメインとのマッピングを確認して判断し、すぐに誤った宛先だと決めつけないでください。

設定の互換性：起動できるだけでは第一歩にすぎない

Clash MetaとmihomoはClashのYAML構造をできる限り引き継いでいますが、互換性は双方向ではありません。基本的なClash設定はmihomoで読み込める可能性が高い一方、mihomo独自の新しいプロトコル、ルールタイプ、DNS拡張フィールドを使う設定は、オリジナル版やPremiumへそのまま渡せません。クライアントが保存時に設定を書き換える場合もあるため、手動編集の前に「サブスクリプションが生成した設定」と「ローカル上書き設定」を区別してください。

Premiumからmihomoへ移行するチェックリスト

  1. 元のクライアントで使っていた混合ポート、LANアクセス設定、動作モード、現在選択中のプロキシグループを記録します。
  2. 元のYAMLを複製して保存し、新しいクライアントへサブスクリプションを読み込みます。唯一の設定ファイルを直接上書きしないでください。
  3. まずTUNを無効にし、7890などのローカルプロキシポートで正常に接続できるかだけをテストします。
  4. ログに廃止予定のフィールド、重複キー、ルールセットの読み込み失敗、プロキシタイプのエラーがないか確認します。
  5. DIRECT、REJECT、ノード選択グループ、自動速度テストグループを一つずつテストし、ルールの動作が想定どおりか確認します。
  6. 最後にTUNとDNSハイジャックを有効にし、ブラウザー、コマンドライン、ゲーム、LAN機器を個別にテストします。

自動速度テストグループでも体感に差が出ることがあります。一般的なurl-testは指定URLへ定期的にアクセスし、接続時間に基づいてノードを選びます。テスト間隔を300にすると、5分ごとに検査します。遅延が最小でもダウンロード速度が最速とは限りません。通常のテストはDNS、TCP、TLS、または小さなHTTPリクエスト1回程度しか確認せず、長時間接続の帯域や混雑時間帯の輻輳までは反映しないためです。

proxy-groups:
  - name: Auto
    type: url-test
    proxies:
      - Node-A
      - Node-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

tolerance: 50は、候補ノードの遅延差が小さいときに頻繁な切り替えを抑える設定です。会議、ダウンロード、長時間の再生では、テストのたびに数ミリ秒を追うより安定した接続のほうが重要です。コア移行後にノードの切り替えが明らかに増えた場合は、ルールだけを調整せず、テストURL、間隔、許容差を確認してください。

プラットフォーム別のコア選び

WindowsとmacOS

新規インストールでは、mihomoの使用を明記し、コアのバージョン表示とログ画面を備えたクライアントを優先してください。デスクトップではTUN、プロセスルール、ルールプロバイダーが必要になることが多く、mihomoの対応範囲はより充実しています。インストール後は「設定」→「コアバージョン」、「設定」→「サブスクリプション」、「ログ」の順に確認し、画面上のバージョンと実際のコアが別々に更新されていないかを確認しましょう。

古いクライアントがPremiumを使い、現在のサブスクリプションが基本プロトコルだけなら、短期的には動作し続ける可能性があります。しかしOSのアップデート、地理データの失効、新しいノードタイプの追加が起きると、トラブル対応の負担は徐々に増えます。移行前にルールとポート設定を保存し、mihomoクライアントで一つずつ復元するほうが、古いコアに新プロトコルを継ぎ足すよりも効率的です。

Android

AndroidクライアントはシステムVPNインターフェースを通じて通信を取り込みます。デスクトップのシステムプロキシ設定よりも、アプリ自体がmihomoを統合しているかどうかが重要です。選ぶ際はコアの説明、アプリ別プロキシ、IPv6、UDP、バックグラウンド動作の方針を確認してください。システム上で同時に動作できる主要VPNサービスは1つだけなので、Clash系クライアントと別のVPNやDNSフィルターアプリが同時に通信を取り込むことは難しい場合があります。

iPhoneとiPad

iOSでは通常、mihomoという名前の独立したコアプログラムを直接インストールするのではなく、Clash設定または近いルール体系に対応したネットワークツールを使います。アプリごとに実装が異なるため、設定ファイルの拡張子だけで完全な互換性を判断することはできません。読み込む前に、アプリの説明で対応プロトコル、ルールタイプ、TUNの動作を確認してください。特にVLESS Reality、Hysteria 2、複雑なrule-providersには注意が必要です。

ルーター、NAS、コマンドライン環境

ルーターやNASでは、CPUアーキテクチャ、メモリ使用量、起動方式、ファイアウォールとの統合が重視されます。コアをダウンロードするときは、amd64、arm64など実際のアーキテクチャに合わせてください。コマンドラインで起動した後は、バージョンコマンドやコントロールインターフェースでコアの種類を確認し、7890、9090、1053などのポートが既存サービスと競合していないか調べます。メモリの少ない機器では、ルールプロバイダーの数と更新頻度を抑えましょう。

利用シーン おすすめの選択 優先して確認する項目
デスクトップクライアントの新規導入 mihomo TUN権限、コアバージョン、サブスクリプションのプロトコル
古い設定を引き続き使う Premiumとの互換性を確認してから移行を計画 ルールセット、スクリプト、旧フィールド
Androidのアプリ別プロキシ mihomoを統合したクライアント VPN権限、バックグラウンド制限、UDP
iOSへの設定読み込み アプリの実際の互換範囲に合わせて選択 プロトコル、ルールプロバイダー、システムVPNの制限
ルーターとNAS アーキテクチャに合うmihomo アーキテクチャ、メモリ、ルートとポートの競合

最終判断：新旧の名称ではなく、必要な機能で選ぶ

オリジナルのClashは設定、プロキシグループ、ルール体系の基礎を築きました。Premiumは当時重要だったTUNと高度なルール機能を補い、Clash Metaはコミュニティ開発を引き継いでmihomoの名称でメンテナンスを続けています。一般ユーザーはMetaとmihomoを相反する2つの技術として扱う必要はありません。重要なのは、クライアントに内蔵された実際のバージョンと設定の互換範囲です。

Shadowsocks、VMess、Trojanの基本ノードだけを使い、システムプロキシに依存する場合、古いコアとmihomoの使用感は一見近いことがあります。VLESS Reality、Hysteria 2、TUIC、完全なルールプロバイダー、GEOSITE、プロセスルール、より細かなTUN・DNS制御が必要なら、現在の基準としてmihomoが適しています。

コアを決めたら、「通常のプロキシ接続 → 基本ルール → DNS → TUN → 拡張ルール」の順に確認します。機能を1段階追加するたびにログを確認し、ポート、モード、テスト結果を記録してください。クライアントの更新やサブスクリプション構造の変更があっても、問題がノード、ルール、DNS、システムルートのどこにあるかをすばやく特定できます。

Clashクライアントをダウンロード Windows、macOS、モバイル版を確認