· コア解説 · 読了時間：約12分

mihomoとオリジナル版Clashの違い｜Mac向け機能比較

mihomo（旧Clash Meta）で追加されたプロトコルやルール、設定項目をオリジナル版Clashと比較。Macクライアントのカーネル更新後も旧設定を使えるか解説します。

カーネル・GUIクライアント・サブスクリプションを区別する

MacでClashクライアントを選ぶ際は、まず実際に動作しているカーネルを確認しましょう。GUIクライアントはメニューバーからの操作、サブスクリプション管理、システムプロキシの切り替え、権限の処理を担います。カーネルは設定の解析、プロキシ接続、ルール判定、DNS処理を行います。画面上の名称が似ていても、対応プロトコルが同じとは限りません。また、クライアントを更新してもカーネルが同時に更新されるとは限りません。

mihomoはClash Metaプロジェクトから発展したプロキシカーネルです。旧チュートリアルに記載されたMeta設定や、サブスクリプションサービスのClash Meta出力は、多くの場合この系統を指します。ただし、利用するmihomoのバージョンでサポートされる設定項目を確認してください。オリジナル版Clashの公開リポジトリは2023年にメンテナンスを終了しており、過去のインストーラーに後続のプロトコル対応が自動で追加されることはありません。

Macユーザーが確認すべき3つの項目

  • クライアントのバージョン：アプリのメニューにある「このアプリについて」で確認します。GUIや管理機能の確認に使います。
  • カーネルのバージョン：クライアントのカーネル情報画面または起動ログで確認します。mihomoの名称と完全なバージョン番号を記録してください。確認場所はクライアントによって異なります。
  • サブスクリプションの出力形式：Clash共通設定なのか、Clash Meta／mihomo向け設定なのかを確認します。どちらも拡張子がYAMLだからといって、設定項目まで完全に同じとは限りません。

機能比較：実際の使い方に関わる違い

比較項目 オリジナル版Clash mihomoとMacでの利用への影響
基本的なプロキシプロトコル Shadowsocks、VMess、Trojanなど、従来から使われている方式に対応。対応範囲はバージョンによって異なります。 従来の多くの方式を引き継ぎ、新しいプロトコルやトランスポートにも対応しています。
VLESSとReality オリジナルのオープンソース版カーネルは、この組み合わせに対応していません。 対応するノードを処理できますが、サーバー側の認証、トランスポート、TLS設定を一致させる必要があります。
Hysteria2とTUIC オリジナルのオープンソース版カーネルは、これらのノード形式に対応していません。 対応しています。ただし、ネットワークでUDP通信が許可されている必要があります。
ルールとルールセット ドメインやIPなどの基本ルールに対応。Premiumにはルールセット機能もあります。 論理ルール、マッチ条件、ルールセット形式が拡張されています。複雑な設定では各項目の対応状況を確認してください。
TUNによる通信の取り込み オリジナルのオープンソース版カーネルとTUN対応のPremiumを混同しないでください。 TUN設定に対応しています。Macではクライアントによるサービスのインストールや権限処理も必要です。
DNSとトラフィックの識別 DNSやfake-ipなどの基本機能を備えています。 DNSポリシーやスニッフィング設定が充実していますが、デフォルトで有効にすれば必ず高速になるわけではありません。

アップグレードのメリットは、必要な機能から判断しましょう。サブスクリプションに従来型のノードしかなく、ブラウザーがシステムプロキシ経由で問題なく動作しているなら、カーネルを変更しても速度が大きく変わるとは限りません。一方、VLESSやHysteria2を含むサブスクリプションを使う場合や、より細かなルーティング条件が必要な場合は、カーネルの対応状況によって設定の読み込みや接続の可否が直接左右されます。

プロトコルの拡張：新しいノードを旧カーネルで使えない理由

VLESS、Reality、トランスポートはそれぞれ別の設定

VLESSはプロキシプロトコル、Realityは関連するTLSセキュリティ方式の設定、WebSocketやgRPCはトランスポート方式です。サブスクリプション内のtype: vless、reality-opts、networkは、それぞれ異なる役割を持ちます。VLESSに対応していても、任意のReality設定で接続できるわけではありません。公開鍵、Short ID、サーバー名、フロー制御の設定をサーバー側と一致させる必要があります。

オリジナル版カーネルで未対応のプロキシタイプと表示された場合、ノード名の変更、プロキシグループの切り替え、システムプロキシの有効化では解決できません。そのタイプに対応したカーネルを使うか、サーバーが実際に対応している別のノードをサブスクリプションサービスに用意してもらう必要があります。type: vlessを無理にvmessへ書き換えても形式変換にはならず、プロトコルの不一致が起きるだけです。

Hysteria2とTUICはネットワーク環境にも左右される

これらのプロトコルはQUICをベースとしており、UDP通信が必要です。mihomoが設定を解析できることは、プロトコルを実装しているという意味にすぎません。現在接続しているWi-Fi、社内ネットワーク、上位ファイアウォールなどでUDPが制限されていれば、タイムアウトすることがあります。「ほかのノードは使えるのに、この種類だけ失敗する」場合は、まず別のプロトコルで接続を試し、その後ポート、認証情報、ネットワーク制限を確認してください。

  • 読み込み時にエラーが出る：まずカーネルのバージョン、ノードタイプ、設定項目を確認してください。DNSを先に変更する必要はありません。
  • 読み込みは成功するがハンドシェイクに失敗する：サーバー側の設定、Macのシステム時刻、ノードへの到達性を確認してください。
  • 接続できるが一部の通信に失敗する：UDP、ルールの適用状況、DNS、パスMTUを順に確認し、すぐにカーネルの性能の問題と決めつけないでください。

ルールの拡張：既存ルールは維持し、新しいルールは意味を確認

従来から使われているDOMAIN、DOMAIN-SUFFIX、IP-CIDR、MATCHは、mihomo設定でも重要なルールです。通常、ルールは上から順に評価されます。先に一致したルールが適用されると、後続の同種ルールはその接続の出先を決めません。移行では、ルールのテキストを残すだけでなく、順序を維持することが重要です。

論理ルールとプロセスによる照合

mihomoでは論理式で複雑な条件を組み合わせられ、プロセスに関連する照合機能も利用できます。ドメイン、ネットワーク種別、プロセスなどの条件を組み合わせる際に便利ですが、プロセスの識別結果はOS、トラフィックの入口、実行権限に左右されます。Macでは、ルールにPROCESS-NAMEと書いただけで、すべての接続のプロセス情報を確実に取得できるわけではありません。接続の詳細画面で実際の識別結果を確認してください。

プロキシグループ名も設定内の参照先です。ルール末尾で指定したポリシー名は、設定内に存在していなければなりません。サブスクリプション更新でグループ名が変わったのにローカルルールに古い名前が残っていると、設定の検証に失敗することがあります。移行時はルール部分だけでなく、rules、proxy-groups、proxiesも合わせて確認してください。

ルールセットはmihomo独自の機能ではない

rule-providersを使うと、ルールを個別のリソースに分け、RULE-SETから参照できます。Clash Premiumにも同様の機能があり、mihomoでは形式やルール表現がさらに拡張されています。ルールセットを確認するときは、動作タイプ、内容の形式、ダウンロード先、実際のファイル内容を合わせて確認してください。

設定項目の移行：TUN、DNS、スニッフィングを個別に確認

TUNはルールモードでもグローバルプロキシでもない

TUNは仮想ネットワークインターフェースを使って、ルーティング対象のトラフィックを受け取ります。ルールモードは、受け取ったトラフィックの出先を決めます。TUNを有効にしても、ルールに応じて直接接続できます。「すべての通信を取り込む」とは入口の対象範囲を指し、すべてのサイトが同じプロキシノードを経由するという意味ではありません。

macOSでは、tun.enable、tun.auto-route、tun.dns-hijackなどの項目を、クライアントのサービス管理と連携させる必要があります。クライアントによっては、実行用設定を生成する際にこれらの項目を書き換えることがあります。移行時はまず通常のシステムプロキシで動作を確認し、その後TUNを個別に有効にすると、ノードの問題と権限・ルーティングの問題を切り分けやすくなります。

DNS：fake-ipを引き継ぐ場合は除外設定も確認

dns.enhanced-modeのfake-ipは、ドメインに合成アドレスを割り当て、カーネル側で対応関係を管理する機能です。通常のパブリックDNSアドレスではありません。従来のClashにも同じ仕組みがあります。mihomoでの主な拡張はポリシーや処理オプションであり、DNSモジュール全体が新機能になったわけではありません。

旧設定にfake-ip-filterがある場合、移行時は必要なローカルドメインの除外ルールを残し、利用中のバージョンでフィルターモードがどう解釈されるか確認してください。LAN内のデバイス名を解決できない、キャプティブポータルの認証に失敗する、特定のアプリだけ異常が起きる場合は、DNSログも確認しましょう。すべてのドメインを除外リストに追加するのは避けてください。

スニッフィング：ドメインの識別を補助し、HTTPSの本文を復号する機能ではない

snifferは、観測可能なプロトコルのハンドシェイク情報から接続先ドメインの識別を補助します。すべての接続のドメインを必ず取得できるわけではなく、ルート証明書をインストールして通信を復号する機能でもありません。暗号化されたハンドシェイク、アプリの動作、プロトコルの違いによって識別結果は制限されます。旧設定を移行する際は、「機能をそろえる」ためにすべてのスニッフィング設定を一度に有効にすることはおすすめしません。

旧設定はそのまま使える？3つの段階で確認

一般的なノード、基本的なプロキシグループ、従来のルールを使う旧Clash設定は、多くの場合、移行の出発点として利用できます。ただし、「YAMLとして解析できる」「カーネルが設定項目を受け付ける」「アプリで実際に通信できる」はそれぞれ別の段階です。クライアントにインポート成功と表示されただけで確認を終えないでください。

  1. 構造：インデント、重複キー、リスト形式を確認します。YAMLのインデントにはスペースを使います。特殊文字を含むパスワードや名前は適切に引用符で囲んでください。
  2. カーネル：ノードプロトコル、ルールタイプ、項目の組み合わせが利用中のバージョンに対応しているか確認します。認識されない項目が無視される場合もあり、検証を通過してもすべての機能が有効とは限りません。
  3. 実行状況：実際に使われている設定、待ち受けポート、DNSの結果、接続に適用されたポリシーを確認し、GUIクライアントによる設定の上書きも考慮します。

ローカルで設定を検証する

実行可能なmihomoファイルとローカル設定を用意できている場合は、ターミナルで該当するディレクトリに移動し、次の2つのコマンドを実行できます。例ではファイル名にmihomoとconfig.yamlを使っています。実際のファイル名に合わせてください。GUIクライアントを使う場合は、アプリ内の設定チェック機能を優先し、アプリケーションパッケージ内のファイルは変更しないでください。

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

1つ目のコマンドで実際に動作しているカーネルのバージョンを確認し、2つ目でそのカーネルが設定を読み込めるか検証します。どちらも、すべてのリモートノード、ルールセットのダウンロード、Webサイトへのアクセスまで確認するものではありません。リモートリソースの利用にはネットワーク接続やローカルキャッシュも関係するため、実行後のログも確認してください。

サブスクリプションの更新とローカル編集を分けて管理

サブスクリプションからダウンロードしたファイルを直接編集すると、次回の更新で変更が上書きされることがあります。元のサブスクリプション設定を残し、クライアントが対応するオーバーライドやマージ機能でローカルルールを追加する方法が安全です。マージ順序はクライアントによって異なるため、最終的な実行設定を確認し、ルールが末尾に追加されるのか、前方に挿入されるのかを確かめてください。

Macでの移行手順：まずシステムプロキシ、次にTUNを確認

  1. 戻せる設定を保管する。現在のサブスクリプションとローカルオーバーライドをエクスポートし、システムプロキシのポート、プロキシグループの選択、旧カーネルのバージョンを記録します。移行前に旧クライアントを終了し、2つのプロセスがポートを奪い合ったり、システムプロキシを同時に変更したりしないようにしてください。
  2. チップとインストーラーを確認する。Appleメニューから「このMacについて」を開き、「チップ」または「プロセッサ」を確認します。AppleシリコンMacには通常arm64版、Intel Macにはx64版のインストーラーを選びます。アーキテクチャはプログラムの実行方式に影響しますが、YAMLの基本構文は変わりません。
  3. 設定を読み込み、ログを確認する。未対応のプロキシタイプ、存在しないプロキシグループ、ルールセットの読み込みエラーを先に解消してください。この段階では、TUN、スニッフィング、複雑なDNSオーバーライドを同時に有効にしないでください。
  4. システムプロキシを確認する。macOS Ventura 13以降では、「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」の順に開きます。アドレスとポートがクライアントの実際の待ち受け設定と一致しているか確認してください。
  5. ルールの適用を確認する。直接接続する想定のサイトとプロキシ経由の想定のサイトを開き、クライアントの接続画面で適用されたルールと出先を確認します。Webページが表示されても、ルーティングが正しいとは限りません。
  6. 必要に応じてTUNを有効にする。クライアントが求める権限の付与やサービスのインストールを済ませてから、ターミナル、ほかのアプリ、LANへのアクセスをテストします。問題が起きたらTUNを無効にし、システムプロキシでの結果と比較してください。

ポートを明示してテストし、ターミナルの動作をカーネルの不具合と混同しない

ここでは、現在の設定で混合プロキシポートが7890に設定されているものとします。クライアントに別のポートが表示されている場合は、実際の値に置き換えてください。このコマンドはHTTPプロキシを明示的に指定するため、ターミナルがmacOSのシステムプロキシ設定を読み取るかどうかに左右されません。

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

HTTPレスポンスが返れば、明示的に指定したプロキシ経由のリクエストが宛先に届いたことは確認できます。ただし、すべてのアプリがプロキシを経由していることや、リモートノードを使ったことまでは証明できません。出先はルールで決まります。127.0.0.1:7890に接続できない場合は、サブスクリプションをすぐに変更せず、まずローカルの待ち受け状態とポートを確認してください。

TUNをテストする際は、プロキシを明示するオプションを付けずにリクエストし、ターミナルにHTTP_PROXY、HTTPS_PROXY、ALL_PROXYが設定されていないか確認してください。設定されていると、環境変数で指定されたプロキシをリクエストが引き続き経由し、テスト結果が不正確になることがあります。

mihomoへのアップグレードが必要か判断する

  • サブスクリプションが新しいプロトコルを使用している：まずカーネルがVLESS、Reality、Hysteria2、TUICに対応しているか、設定項目が利用中のバージョンで使えるかを確認します。
  • より多くのアプリの通信を取り込みたい：カーネルの機能一覧だけでなく、クライアントのmacOS向けTUNサービス管理、権限要求、障害復旧の機能も比較してください。
  • 複雑なルーティングが必要：論理ルール、プロセス識別、ルールセット形式を確認し、重要なルールは実際のアクセスで検証してください。
  • 現在の環境が安定している：移行前にバックアップを取り、既存の確認項目を残してください。カーネルを更新しても、ノードの品質、ネットワーク環境、設定の正しさが保証されるわけではありません。

Macユーザーが安全にアップグレードするには、GUIクライアントが実際に使っているカーネルを確認し、対応するサブスクリプション形式を選び、設定を検証したうえで、システムプロキシ、DNS、TUNを1つずつ確認します。mihomoはプロトコルやルーティング機能を拡張しますが、それらを実際の接続に活かせるかどうかは、サーバー設定、クライアントとの連携、Macのネットワーク設定が一致しているかに左右されます。

設定項目の意味をさらに確認するには、サイト内のプロトコルガイドをご覧ください。ポートの競合やシステムプロキシが元に戻らない場合は、ヘルプセンターのトラブルシューティング手順から原因を確認できます。

Clash Mac版インストーラー