Clashのオープンソースエコシステム解説：mihomoコアとMacクライアントの関係

Clashエコシステムを構成する3つの層

Mac用のClashを検索すると、mihomo、Clash Meta、ClashX Meta、Clash Verge Revなど、さまざまな名称が見つかります。これらは同じ役割ではありません。ネットワーク通信を処理するもの、設定画面を提供するもの、ドメインやIPのルールだけを提供するものがあります。選ぶ前に役割を整理すれば、クライアントを替えるべきか、コアを更新すべきか、設定を見直すべきか判断しやすくなります。

レイヤー	主な役割	確認する場所
プロキシコア	プロキシ接続を確立し、DNS・ルール照合・ポリシーグループの選択を処理	コア情報、起動ログ、実行中の設定
GUIクライアント	サブスクリプション管理、設定切り替え、システムプロキシ設定、接続状況の表示	クライアント設定、サブスクリプション管理、サービス管理
ルールと設定	マッチ条件、ノード定義、通信の出口を指定	YAML、ルールプロバイダー、サブスクリプションの内容

実際の通信経路は通常、「アプリの通信 → システムプロキシまたはTUN → コア → ルールとポリシーグループ → 出口」です。GUIはこの経路を制御しますが、GUI自体がプロキシプロトコルを実装しているわけではありません。同じコアでも、クライアントが異なれば設定画面やサブスクリプションの上書き方法、権限管理が異なる場合があります。

オリジナルのClash、Clash Meta、mihomo

オリジナルコアと派生プロジェクト

オリジナルClashの公開プロジェクトは、2023年に公開メンテナンスを終了しました。過去の資料ではClash Premiumにも触れられますが、機能はオリジナルのオープンソースコアと完全には一致しません。古い解説でPremiumの機能とされているものが、現在のコアで使えるかどうかは、「Clash」という名称だけでは判断できません。

Clash MetaはClashから派生したプロジェクトで、後にmihomoという名称が採用されました。そのため、設定解説にある「Metaコア」とプロジェクトのドキュメントにある「mihomo」は、同じ技術的な系譜を指すことがよくあります。一方、古いクライアント名に「Meta」が残っていても、同梱コアの新旧を示すとは限りません。

名前が似ていても設定項目を共用できるとは限らない

mihomoはproxies、proxy-groups、rulesなど、ClashのYAML設定の多くを引き継ぎ、プロトコルやルール機能を拡張しています。ただし、互換性には方向性があります。一般的な基本設定は引き続き使える可能性がありますが、mihomo独自の拡張項目を含む設定は、古いコアでは動作しないことがあります。

サブスクリプションの読み込みに失敗したら、まずログに未対応のプロキシタイプ、無効な項目、存在しないポリシーグループへの参照がないか確認します。
設定の読み込みに成功しても、その時点での解析を通過しただけです。実際のリクエストに適用されるルールと出口を確認してください。
特定のプロトコル、ルール形式、TUN機能が必要な場合は、使用するコアのドキュメントと実際のビルドを確認してください。

GUIを替えれば必ず機能が向上するわけではありません。新しいクライアントでも、別のコアを採用していたり、古い実行設定が残っていたりすれば、同じ問題が起こる可能性があります。切り分けの際は、クライアント名・コア名・設定の取得元をそれぞれ記録しましょう。

Mac用GUIクライアントの役割

ClashX Meta、Clash Verge Rev、FlClashなどは、macOS向けのGUIを提供してきましたが、操作性や設定管理の仕組みはそれぞれ異なります。以下は役割を把握するための概要であり、現在のメンテナンス状況や機能を網羅した一覧ではありません。インストール前に、各プロジェクトのリリース情報とシステム要件を確認してください。

クライアントのタイプ	主な使い方	選ぶ際の確認事項
ClashX Meta	macOSのメニューバーからプロキシや設定を管理	同梱コア、設定画面、権限の許可・インストール方法
Clash Verge Rev	独立したウィンドウでサブスクリプション、接続、実行設定を管理	設定の上書き方法、サービスモード、コア設定
FlClash	クロスプラットフォームのGUIからmihomoの設定を管理	macOS版のシステム要件、設定管理、TUNの設定画面

システムプロキシはクライアントとmacOSの連携機能

macOSのシステムプロキシは通常、この設定に対応したアプリをローカルの待ち受けポートへ接続します。macOS Ventura以降では、「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」から、HTTP・HTTPS・SOCKSの項目を確認できます。設定するポートはコアの実際の待ち受けポートと一致させてください。他のデバイスの設定をそのまま使うことはできません。

たとえば、コアでmixed-port: 7890を設定した場合、ローカルプロキシのアドレスは127.0.0.1:7890にできます。ここでの7890は例であり、すべてのクライアントの既定値ではありません。ターミナルのツールがシステムプロキシを使うかどうかはツールごとに異なるため、ブラウザーでの接続結果だけではターミナルの通信経路を判断できません。

TUNにはコアの機能とシステム権限が必要

TUNは仮想ネットワークインターフェースを使い、ルーティングされたIP通信を受け取ります。対象範囲はシステムプロキシとは異なります。Macではクライアント側で権限の許可、ルーティング設定、DNSとの連携も必要です。コアがTUNに対応していても、すべてのGUIに同じスイッチやサービスのインストール手順、障害復旧の機能があるとは限りません。

サブスクリプション・ルールセット・ポリシーグループの関係

サブスクリプションURLは設定を配布する入口であり、内容の形式が固定されているわけではありません。完全なYAMLやノードプロバイダーの内容が返される場合もあれば、別形式からの変換が必要な場合もあります。あるクライアントで読み込めても、別のクライアントで同じ方法が使えるとは限りません。

ノードプロバイダーproxy-providers: ファイルまたはリモートソースからノード一覧を読み込み、ポリシーグループから参照できるようにします。ノードの接続方法はプロトコルのパラメーターで決まります。
ルールプロバイダーrule-providers: マッチ条件のセットを読み込みます。ルールはリクエストの特徴を判定するもので、プロキシノードを提供するものではありません。
ポリシーグループproxy-groups: ノードや他のポリシーグループをまとめ、手動選択、自動テスト、フェイルオーバーなどの出口選択方法を提供します。

たとえば、業務サービスのドメインをまとめたルールセットに対し、RULE-SETで一致したリクエストを「業務用出口」ポリシーグループに渡し、そこから使用するノードを選びます。ルールセットをダウンロードしても、プロキシ回線が自動的に使えるようになるわけではありません。対応するポリシーグループやノードがなければ、通信経路は完成しません。

ルールセットの形式と指定項目を一致させる

mihomoのルールプロバイダーでよく使われるbehaviorは、domain、ipcidr、classicalです。ドメイン一覧、IPネットワーク一覧、ルールタイプ付きの一覧は、自由に混在させられません。formatはYAML、テキスト、MRSなどの保存形式を表します。MRSで使用できるbehaviorにも制約があるため、利用するコアのドキュメントで確認してください。

ルールリポジトリのファイル内容と使い方を確認してから、プロバイダーの項目を設定します。
ルールリポジトリの分類名は整理のためのものであり、個々の利用環境に合うとは限りません。
ルールは上から順に照合されます。前方の広い条件に一致すると、後方の詳細なルールまで判定されないことがあります。
最後のMATCHは、それ以前のルールに一致しなかったリクエストの行き先を決めます。転送先を明示してください。

設定ファイルで見るコアとクライアントの役割

以下はローカル環境で動作を確認するための最小構成例です。DIRECTのみを使用するため、リモートのプロキシ接続は確立しません。待ち受けポート、ポリシーグループ、ルールの関係を確認する用途に使えます。リモートの出口が必要な場合は、信頼できる設定から実際のノードを追加してください。この例をそのまま使えるサブスクリプションとして扱わないでください。

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

proxy-groups:
  - name: 手動の出口
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,手動の出口
  - MATCH,DIRECT

mixed-portはコアが待ち受けるポートで、HTTPとSOCKSのプロキシリクエストを同じポートで受け付けます。この設定だけでmacOSのシステムプロキシが変更されることはありません。
allow-lan: falseは、プロキシの入口へのLANからのアクセスを制限します。共有が必要な場合は、待ち受けアドレスとファイアウォールもあわせて確認してください。
mode: ruleはルールに基づいて出口を選ぶ設定です。クライアントでモードを切り替えると、実際の実行状態が元のファイルと異なる場合があります。
「手動の出口」はポリシーグループ名です。ルール内の参照名と一致しないと、設定を読み込めない場合があります。
MATCH,DIRECTはフォールバックルールです。ここでは残りのリクエストを直接接続するため、一般的なリモートプロキシの構成ではありません。

クライアントは起動前にサブスクリプション、ローカルの上書き設定、画面上の設定を統合することがあります。そのため、「ダウンロードしたYAML」と「コアが最終的に受け取るYAML」は異なる場合があります。トラブル対処では、サブスクリプションの原文だけでなく、クライアントの実行設定プレビューやエクスポート機能を探し、ログと照らし合わせてください。各項目の説明はYAML設定ガイドで確認できます。

Macクライアントの選び方と移行時の確認事項

用途に合わせて選ぶ

主にブラウザーを使う：まずシステムプロキシ、設定の切り替え、終了後にプロキシが解除されることを確認します。TUNを有効にする必要がない場合もあります。
コマンドラインや開発ツールをよく使う：各ツールのプロキシ設定や環境変数への対応を確認してから、TUNによる一括転送が必要か判断します。
複数のサブスクリプションや複雑な振り分けを使う：ローカル上書き、ルールプロバイダーの管理、実行設定の確認、ログの絞り込み機能を重点的に確認します。
メニューバーでの操作を重視する：よく使うポリシーグループや設定をすぐに切り替えられるか、コア情報を確認する手段があるかを確認します。

移行は4つの手順で確認

元の設定とローカルの変更をバックアップする。ルールの順序、ポリシーグループの選択、ポート、DNS設定を記録します。診断情報を共有する際は、サブスクリプションのトークンやノードの認証情報を削除してください。
アーキテクチャとシステム要件を確認する。Appleメニューの「このMacについて」でチップとmacOSの情報を確認し、プロジェクトが提供するApple Silicon版、Intel版、またはユニバーサル版に合ったインストーラーを選びます。
2つのコアが同じ入口を取り合わないようにする。古いクライアントを終了し、システムプロキシまたはTUNを無効にしてから、新しいクライアントを起動します。ログにアドレスの使用中と表示された場合は、古いプロセスがまだ待ち受けていないか確認してください。
基本機能から順に確認する。まず設定の読み込みとシステムプロキシを確認し、その後TUN、DNSの上書き、自動更新を有効にします。一度に変更する設定は1種類に絞り、元に戻せる設定を残してください。

サブスクリプションの更新で置き換わる内容は、クライアントの設定管理方式によって異なります。ダウンロードしたファイルを直接編集すると、次回の更新で変更が失われる可能性があります。長期的に残したいローカルルールは、クライアントが正式にサポートする上書きレイヤーに置き、統合順序も確認してください。

オープンソースプロジェクトの入手元と問題の切り分け

オープンソースのリポジトリ、クライアントのインストーラー、サブスクリプションサービスは、それぞれ別の提供元です。コアのソースコードを確認できても、同じ名称のインストーラーがそのプロジェクトから配布されているとは限りません。サブスクリプションを正常に読み込めても、提供元がクライアントの開発者と関係しているとは限りません。ダウンロード前に、プロジェクトの運営組織、リポジトリのリンク、リリース情報、インストーラーの対応OSを確認してください。

症状	まず確認する箇所	問い合わせ時に添える情報
ウィンドウが開かない、またはサブスクリプションのボタンでエラーが出る	クライアントの画面と設定管理のレイヤー	システム情報、操作手順、個人情報を伏せたエラー情報
未対応のプロトコル、または設定の解析に失敗する	コアの対応範囲と設定形式	コア情報、最小構成の設定、起動ログ
特定のドメインが意図しない出口を通る	ルールの順序、DNSの名前解決、ポリシーグループ	一致したルール、宛先アドレス、選択された出口
特定のノードだけ接続できない	ノードのパラメーター、リモートサービス、通信経路	エラーの種類、接続時刻、個人情報を伏せたノードの種類

設定全体より、最小限の再現手順のほうが役立ちます。まずポリシーグループを1つと必要なルールだけ残し、無関係な上書き設定を外して再試行してください。ログを公開する前に、サブスクリプションURL、認証情報、LAN内アドレス、アクセス履歴が含まれていないか確認します。通常、これらをすべて公開する必要はありません。

最終的な選択は、次の3点で判断できます。コアが必要なプロトコルとルールを処理できるか、クライアントが設定を安定して管理できるか、macOSから想定どおりに通信を受け取れるか。クライアント名だけを比べるより、3つの層を個別に検証するほうが、再利用しやすい構成を見つけられます。