Clashの仕組みとクライアントの違い｜mihomo・Clash Verge Revを解説

まずは3つの役割を整理：コア、クライアント、設定

Clashは、すべてのインストーラーを指す単一の製品名ではありません。オリジナルのClashはプロキシコア、mihomoはClash Metaから発展したコアプロジェクトです。Clash Verge RevやFlClashなどは、コアを利用するGUIクライアントです。機能が使えるかどうかは、クライアントのバージョン、実際に動作しているコア、読み込まれる設定を合わせて確認する必要があります。

役割の境界を見ると違いが分かります。コアはYAMLを解析し、接続を処理してDNSやルールによる振り分けを実行します。クライアントはサブスクリプションを管理し、プロキシグループを表示してシステムプロキシを切り替え、コアのプロセスやサービスを起動します。サブスクリプションの提供元は、ノード情報や設定一式を配布します。3者は関連していますが、同じ開発・保守主体ではありません。

レイヤー	代表例	主な役割
プロキシコア	Clash、mihomo	ポートの待ち受け、設定の解析、ルール判定、上流への接続
GUIクライアント	Clash Verge Rev、FlClash	設定のインポート、プロキシグループの選択、システム連携、ログ表示
設定・サブスクリプション	YAMLファイル、サブスクリプションURL	ノード、プロキシグループ、ルール、更新手段を提供

プロジェクトの変遷：オリジナルClash、Clash Meta、mihomo

オリジナルコアの開発終了は、エコシステム全体の停止を意味しない

2023年11月ごろ、オリジナルのClashプロジェクトは公開メンテナンスを終了しました。それ以前には、オープンソース版とは機能が完全には一致しないクローズドソースの派生版、Clash Premiumも存在しました。古い記事で「ClashはTUNに対応」とだけ書かれている場合、派生版やプラットフォームの条件が省略されていることがあります。任意の旧バージョンにそのまま当てはめることはできません。

メンテナンスが終了すると、プロトコル対応やOSとの互換性、問題修正を今後も元のプロジェクトから提供されるとは期待できません。古いプログラムが動作する場合はありますが、「起動できること」と「日常的に使うネットワークコンポーネントとして適していること」は別です。移行時は、インストーラー名の知名度より現在のメンテナンス状況を重視しましょう。

Clash Metaはmihomoの旧プロジェクト名

Clash MetaはClashエコシステムから派生して開発され、後にmihomoへ名称が変更されました。古い文書にある「Metaコア」と新しい文書にある「mihomoコア」は、通常、同じプロジェクトの系譜を指しており、同時にインストールする2つのコンポーネントではありません。名称が変わっても、旧フィールド名や旧バイナリ名、クライアント上の表示がすぐに統一されるわけではありません。

mihomoはClash形式のYAML設定と制御インターフェースを引き継ぎ、対応プロトコルやルーティング機能を拡張しています。ただし、ここでいう「引き継ぎ」はエコシステムの保守と機能開発の継続を指します。オリジナルチームからの公式な譲渡を意味するものではなく、新旧の設定が完全に互換であるとも限りません。

プロジェクトの変遷：
オリジナルClash ── 派生開発 ── Clash Meta ── 名称変更 ── mihomo

統合関係：
Clash Verge Rev ── 管理・呼び出し ── mihomo
FlClash         ── 統合・呼び出し ── mihomo

入力データ：
サブスクリプションまたはローカルYAML ── クライアントで処理 ── 実行時設定 ── コアで読み込み

この図はプロジェクトとコンポーネントの関係を示したもので、クライアント間で同じUIコードを共有していることを示すものではありません。似たコアを使っていても、設定のマージ方法、サービスの管理方法、プラットフォームへの対応はクライアントごとに異なる場合があります。

クライアントの役割：Clash Verge RevとFlClashの違い

Clash Verge Rev：デスクトップUIとシステム連携

Clash Verge Revは、Windows、macOS、Linux向けのデスクトップクライアントで、mihomoコアを採用しています。サブスクリプション一覧、トレイメニュー、プロキシグループの選択、接続履歴などはクライアントのUIが担います。接続に使うプロキシやルールの判定は、実行中のコアが処理します。

クライアントの「サービスモード」は通常、バックグラウンドコンポーネントに必要な権限を与え、コアやネットワーク機能を管理するためのものです。プロキシプロトコルの一種ではなく、有効にすればすべての通信が自動的にプロキシ経由になるわけでもありません。通信を取り込めるかどうかは、システムプロキシ、TUN、ルーティング、アプリ側の接続方法にも左右されます。

FlClash：クロスプラットフォームUIとモバイル連携

FlClashはFlutterで開発され、mihomoコアを使用するクライアントプロジェクトです。デスクトップやAndroidなどに対応しています。AndroidではシステムのVPNインターフェースを通じて通信を取り込みますが、これはデスクトップでシステムプロキシを変更する方法とは異なります。画面上の起動ボタンが似ていても、必要なシステム権限は同じではありません。

FlClash、FlClashsのように名前が似たプロジェクトを見つけた場合は、名称だけで同一プロジェクトと判断せず、配布元、メンテナー、リリース履歴を個別に確認しましょう。対応プラットフォームも各プロジェクトのリリース情報を確認してください。似た名前の別プロジェクトに機能説明を流用することはできません。

旧クライアントの名称だけではコアの情報は分からない

Clash for Windows：メンテナンスは終了しています。過去のインストーラーには異なるコアが含まれている場合があり、現在のmihomoクライアントと同一視できません。
Clash for Android：元のプロジェクトはメンテナンスを終了しています。AndroidのVPN権限は通信を取り込むための条件にすぎず、旧コアにないプロトコル機能を補うものではありません。
その他のデスクトップクライアント：まずプロジェクトの説明でコアの種類を確認し、次にインストーラーに含まれる実際のコアのバージョンを確認しましょう。名称にClashが含まれているかどうかだけでは判断できません。

クライアントを選ぶ際は、まずクライアント比較を確認し、利用OSに合わせてダウンロードページへ進んでください。「現在のプラットフォームで動作する」「コアが設定に対応している」「システム連携の方式が適切である」の3つを満たす必要があります。

YAML設定がサブスクリプションからコアへ届くまで

サブスクリプションURLは設定の取得元であり、プロキシプロトコルではありません。URLの応答は、YAML一式の場合もあれば、ノード一覧や別形式の場合もあります。クライアントに直接インポートできるかは対応する入力形式によって決まり、コアが読み込めるかは生成された設定がコアのフィールドやプロトコル要件を満たすかによって決まります。

データを取得：クライアントでサブスクリプションをダウンロードするか、ローカルのYAMLファイルを読み込みます。
設定を処理：クライアントがオーバーライド、マージ、スクリプト、共通設定などを適用し、実行用ファイルを生成する場合があります。
コアに読み込む：コアが最終設定を読み込み、リスナーを作成してプロキシ、DNS、ルールを初期化します。
通信を取り込む：アプリがプロキシポートに接続するか、TUNなどの入口から通信をコアへ送ります。
通信を振り分ける：ルールモードでは、コアがルールを順番に照合し、該当するプロキシグループで接続を処理します。

以下は各フィールドの役割を示すための最小構成例で、リモートプロキシノードは含まれていません。通常の通信はすべて最終的に直接接続されるため、リモートプロキシが使えることを示す例ではありません。ポート7890と9090は例示用であり、すべてのクライアントに共通する固定のデフォルト値ではありません。

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

external-controller: 127.0.0.1:9090
secret: "local-doc-demo-rotate-before-use"

proxy-groups:
  - name: Route
    type: select
    proxies:
      - DIRECT
      - REJECT

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

mixed-portはHTTPとSOCKSを兼ねるプロキシの入口です。アプリの通信はここからコアに入ります。
external-controllerは制御APIの待ち受けアドレスで、状態の取得や選択の変更に使います。ブラウザーに設定するプロキシポートではありません。
proxy-groupsはプロキシグループを定義します。選択肢を表示するのはクライアント、現在の選択を保持して実行するのはコアです。
rulesは照合順序を定義します。末尾のMATCHは、それ以前のルールに一致しなかった通信を処理します。

サブスクリプションの元データではポートが7890なのに、クライアントが別のポートで待ち受けている場合は、まずクライアントの共通設定やオーバーライドを確認してください。次回更新で上書きされるサブスクリプションファイルを何度も編集するのではなく、実行時の設定を調べて原因を切り分けましょう。フィールドの意味はYAMLマニュアルで確認できます。

システムプロキシ、TUN、プロトコル対応はそれぞれ何で決まる？

システムプロキシはアプリの通信入口であり、コアの機能を拡張するものではない

システムプロキシを有効にすると、OSのプロキシ設定に従うアプリが指定ポートへリクエストを送信します。独自に直接接続するプログラムや、システムプロキシを参照しないコマンドラインツール、一部のゲーム通信などは取り込まれない場合があります。この場合、GUIのテーマを変えたり同じサブスクリプションを再インポートしたりしても、アプリの接続方法は通常変わりません。

TUNにはコアの機能に加え、クライアントとOSの権限も必要

TUNは仮想ネットワークインターフェースを通じてIP通信を取り込みます。コア側の対応に加えて、クライアントがインターフェースを正しく作成し、権限とルートを管理してDNSを連携させる必要があります。Windowsのサービス権限、Linuxのネットワーク管理権限、AndroidのVPN許可は、いずれもこの仕組みに必要なプラットフォーム条件です。

TUNを有効にしても「すべての接続がリモートノードを経由する」わけではありません。通信がコアに入った後も、ルールによってDIRECTが選択されたり、ルートの除外やアプリ別の振り分け設定が影響したりします。TUNのスイッチが有効かだけでなく、取り込み対象とルールの判定結果も確認しましょう。

新しいプロトコルは主にコアで決まり、設定方法はクライアントも確認

ノードの種類が使えるかどうかは、まずコアが対応しているか、ノードのパラメーターが正しいかで決まります。古いコアが新しいプロトコルに遭遇すると、未対応のプロキシタイプや設定の読み込みエラーが表示されることがあります。GUIクライアントの更新に伴ってコアも更新される場合がありますが、クライアントとコアのバージョン番号は別々に管理されています。

逆に、コアがフィールドに対応していても、クライアントの設定画面にその項目があるとは限りません。YAMLへの記述やオーバーライドで追加する必要がある機能もあります。画面から保存すると設定が書き換えられる場合は、独自フィールドが削除されないことも確認してください。

クライアント選びとトラブルシューティング：コンポーネントごとに確認

「同じサブスクリプションが別のクライアントでは使える」という場合、すぐにノードの品質が原因だと決めつけないでください。コア、オーバーライド、DNS設定が異なるほか、通信の入口自体が別方式である可能性もあります。次の順番で比較すると、違いを見つけやすくなります。

2つのバージョンを記録：クライアントとコアのバージョンをそれぞれ記録します。「バージョン情報」、コア管理画面、起動ログなどで確認できます。具体的なメニュー名は使用中のリリースによって異なります。
読み込み結果を確認：まず設定の解析エラー、未対応のプロキシタイプ、存在しないプロキシグループ名などを探します。設定の読み込みが完了していない段階では、外部IPを確認しても診断にはなりません。
通信の入口を確認：システムプロキシとTUNのどちらを使っているか確認します。明示的なプロキシ指定でテストする場合は、説明記事の値をそのまま使うのではなく、実際の待ち受けポートを指定してください。
ルールとプロキシグループを確認：接続ログで適用されたルール、プロキシグループ、最終的なノードを確認します。ルールが直接接続を指定している場合、接続元のローカルIPが表示されるのは正常です。
最後にDNSとネットワークを比較：設定が同じでも、名前解決の結果、IPv6のルート、上流ネットワークが異なればアクセス結果も変わります。

実際の混合ポートが7890の場合、ターミナルでプロキシを明示してリクエストすれば、アプリがシステムプロキシに従っているかどうかを切り分けられます。Windowsでcurlが別のコマンドとして解釈される場合は、curl.exeを使ってください。

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

このコマンドで確認できるのは、指定したHTTPプロキシ経由で1回リクエストした結果だけです。TUNが他のアプリの通信を取り込んでいることや、リモートノードが使われたことまでは証明できません。コアの接続ログも合わせて確認してください。DIRECTに一致した場合、リクエストはローカルネットワークから接続先へ直接送られます。

古い設定から移行する：必要なフィールドを残し、機能を一つずつ復元

メンテナンスが終了したクライアントからmihomoクライアントへ移行する際は、まず元の設定とカスタムルールをバックアップし、有効なサブスクリプションで最小限の接続を確立しましょう。新しいクライアントの実行ディレクトリ全体を上書きしたり、古いサービスファイルと新しいコアのバイナリを混在させたりしないでください。

まずプロトコルを確認：サブスクリプションの出力が現在のコア向けか、ノード名とプロキシグループの参照先が一致しているかを確認します。
次にルールを移行：まず必要最小限の明確なルールを戻し、適用結果を確認してからルールセットや複雑な振り分けを追加します。
最後にDNSとTUNを移行：この2つはOSやLAN環境の影響が大きいため、古い設定をそのまま流用するのは避けましょう。
通信の二重取り込みを避ける：新しいクライアントをテストする際は古いクライアントを終了し、古いサービスがプロキシポートや仮想インターフェースを引き続き使用していないか確認します。

エコシステムからクライアントを選ぶ際に大切なのは、名称が完全に同じ代替ソフトを探すことではなく、役割ごとに判断することです。プロトコルや設定との互換性はコアの機能で、プラットフォームとの連携はクライアントの機能で、実際の動作は実行時設定とログで確認します。この3つを分けて考えれば、プロジェクト名の変更、クライアントの派生版、設定の移行を一貫した手順で確認できます。