Clashのオープンソースエコシステムを整理：mihomoコアとFlClash、Clash Verge Revなどのクライアントの役割

まずは4つの層を整理：コア、クライアント、設定、接続サービス

Clashをダウンロードしようと検索すると、mihomo、FlClash、Clash Verge Rev、Clash for Windowsなどが見つかります。ただし、これらは同じ役割のソフトではありません。選ぶ前に、プロキシを動かすコアが必要なのか、サブスクリプション管理やシステム設定を備えたクライアントが必要なのかを確認すると、誤ダウンロードや移行時の混乱を防げます。

FlClashをインストールしても、すぐに接続先が使えるとは限りません。通常は有効な設定を取り込み、プロキシグループから出口を選ぶ必要があります。逆に、サブスクリプションが有効でも、長期間更新されていない古いコアでは、含まれるプロトコルや設定項目を認識できないことがあります。

Clash、Clash Meta、mihomoの関係

Clashはエコシステムの出発点であり、クライアント全般を指す名称ではない

ClashはGoで開発されたルールベースのプロキシプロジェクトで、広く使われるYAML設定とルール記述の基礎を築きました。歴史的にはClash Premiumも存在し、オープンソース版とは機能の範囲が完全に同じではありません。古い解説にあるTUN、ルールセット、スクリプトの説明は、当時使われていたコアを確認する必要があります。すべてのClash系プロジェクトに共通する機能とは限りません。

2023年11月頃、Clash本家や一部関連クライアントの公開プロジェクトでは、開発終了やリポジトリの削除などの変化がありました。現在も古いインストーラーやミラーは見つかりますが、「起動できる」ことと「新しいプロトコルやOSに継続して対応している」ことは別です。新しい設定を使う場合は、まず対象プロジェクトとメンテナンス状況を確認しましょう。

Clash Metaは後にmihomoへ名称変更

Clash MetaはClashエコシステムから派生したプロジェクトで、後にmihomoへ名称が変更されました。古いドキュメントや設定解説、一部の画面には今もMetaという表記が残っています。「Metaコア」と書かれていたら、mihomoのどのバージョンを指しているのか確認しましょう。

mihomoはプロトコル、DNS、ルール、TUNなどの機能を拡張していますが、元のClashのファイル名を変えただけの同一プログラムではありません。設定項目の対応状況は、実際に動作しているmihomoのバージョンと公式ドキュメントで確認してください。また、クライアントがYAMLに対応していても、mihomoの拡張構文をすべて解釈できるとは限りません。

• 古い解説にClashとある場合：設定エコシステム全般のことか、Clash本家のコアを指すのかを確認しましょう。
• サブスクリプションにMetaとある場合：設定で実際に使われているプロトコル、ルール、DNS項目を確認しましょう。
• インストーラーにFlClashとある場合：これはGUIクライアントの名称です。コアのバージョンは別途確認してください。

FlClashとClash Verge Rev：対応OSと使い方の違い

FlClashとClash Verge RevはいずれもGUIクライアントであり、サブスクリプションサービスではありません。まずOSで候補を絞り、設定管理やシステム連携の要件を比べましょう。以下は各プロジェクトの対応プラットフォームの概要です。実際にダウンロードできるアーキテクチャやインストーラー形式は、各リリースを確認してください。

AndroidとiOSは名称だけで同じものとして扱えない

FlClashにはAndroid版がありますが、iOS向けの公式インストーラーもあるとは限りません。Clash Verge RevもAndroidクライアントではありません。iOSでは対応する別のクライアントを選び、サブスクリプション形式、ルール構文、ネットワーク拡張機能を確認してください。Android用APKやデスクトップ向けインストーラーをiOSで使うことはできません。

同じOSでもプロセッサのアーキテクチャを確認

macOSではAppleシリコンとIntel搭載機でarm64版とx64版をそれぞれ確認してください。Androidでは通常、arm64-v8aとarmeabi-v7aを区別します。Linuxではディストリビューションに適したパッケージ形式も確認が必要です。ダウンロード前にシステムのデバイス情報でアーキテクチャを確認し、ダウンロードページで対応するクライアントを選びましょう。

UIの技術スタックだけで、接続速度や安定性が決まるわけではありません。接続先サービスの品質、ネットワーク経路、使用プロトコル、DNS、ルールの適用結果のほうが、通信に直接影響することが多くあります。クライアントを比較する際は、異なるサブスクリプションの結果ではなく、同じ設定とネットワーク環境で試してください。

同じmihomoコアなのに、設定を取り込んだ結果が異なるのはなぜ？

サブスクリプションURLがプロキシ一覧だけを返すとは限りません。完全なYAMLを返す場合もあれば、クライアント側で解析するノード情報を返す場合や、リクエストのパラメーターによって異なる形式を返す場合もあります。「サブスクリプションを取得できる」「設定を解析できる」「接続できる」の3段階を分けて確認すると、違いの原因を特定しやすくなります。

1. コアのバージョンが異なる：クライアントに同梱されているmihomoのバージョンは異なる場合があります。新しい設定項目が古いコアでエラーになったり、想定どおり動作しなかったりすることがあります。
2. 設定の処理方法が異なる：クライアントによっては、上書き、マージ、サブスクリプション処理機能を使ってDNS、ポート、ルール、プロキシグループを変更します。元のサブスクリプションが同じでも、最終的な設定が同一とは限りません。
3. プロキシグループの選択が異なる：ルールが同じ名前のプロキシグループを参照していても、クライアントに保存された選択先が異なる場合があります。グループを開いて、現在の接続先を確認してください。
4. 実行環境が異なる：システムプロキシ、TUNの権限、ファイアウォール、既存のVPN、DNSキャッシュによって通信経路が変わることがあります。

最小限のルール例で設定の依存関係を確認

以下はルール部分のみで、単独で動作する完全なサブスクリプションではありません。使用するには、PROXYという名前のプロキシグループがすでにあり、利用可能な出口が設定されている必要があります。ルールは上から順に照合され、一致すると後続のルールは評価されません。

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

example.orgはドメインサフィックスルールの例です。no-resolveは、このIPルールのためにドメイン名の解決を新たに行わない指定であり、クライアント全体のDNSを無効にするものではありません。取り込み後にPROXYが見つからないというエラーが出た場合は、クライアントを何度も再インストールするのではなく、プロキシグループの定義を確認してください。

システムプロキシ、混合ポート、TUNはそれぞれ何をする？

クライアントはシステム設定との連携を担い、コアは受け取った接続を実際に処理します。たとえば混合ポート7890では、mihomoが同じポートでHTTPとSOCKS5のプロキシリクエストを受け付けられます。クライアントでシステムプロキシを有効にすると、OSのプロキシ設定が該当する入口を指すようになります。このポート番号は例です。実際の値は現在の設定を確認してください。

mixed-port: 7890
allow-lan: false
mode: rule

この例のallow-lan: falseは、ほかのLAN内デバイスがこの入口経由でプロキシを利用することを許可しません。自分の端末だけで使うなら、接続確認のためだけにLANアクセスを有効にする必要はありません。また、システムプロキシを設定しても、すべてのアプリが対象になるわけではありません。システムプロキシを参照しないアプリは、直接インターネットに接続することがあります。

TUNは通信を取り込む方式で、接続先のノードではない

TUNは仮想ネットワークインターフェースを通じて通信をコアに渡すため、システムプロキシに従わない一部のアプリでも利用できます。デスクトップでは通常、管理者権限やサービスコンポーネント、OSからの許可が必要です。Androidでは通常、システムのVPNインターフェースを使って通信を取り込みます。必要な権限やOSによる制限は、それぞれ異なります。

TUNを有効にしても、無効なサブスクリプションが直るわけではなく、適切なDNSやルーティング設定の代わりにもなりません。同じ端末上の別のVPN、仮想NIC、セキュリティソフトと競合する場合もあります。有効化後にプリンター、LANサービス、ドメインへのアクセスに問題が出たら、すべてのノードをすぐに変更するのではなく、ルートの除外設定とDNSの処理を確認しましょう。

• ブラウザーは使えるのに、特定のアプリだけ失敗する：まず、そのアプリがシステムプロキシを参照するか確認し、その後でTUNを検討しましょう。
• 2つのクライアントを交互に試す：7890を同時に使用したり、システムプロキシを何度も書き換えたりしないよう、先に使っていたクライアントを終了してください。
• TUNを有効にしてから問題が発生した：無効時と比べて、権限、ルート、ほかのVPNを確認してください。サブスクリプションとルールを同時に変更しないようにしましょう。

古いクライアントから移行する：確認できる結果を残す4ステップ

移行では、古いプログラムのフォルダー全体をコピーするのではなく、再利用できる設定とクライアント固有の状態を分けて扱うことが大切です。古いクライアントのデータベース、キャッシュ、設定ファイルは、新しいクライアントで認識されない場合があります。上書きすると、かえって問題が増えることもあります。

1. 必要な情報を保存する。サブスクリプションURL、自作の設定、自分で追加したルールをバックアップし、使用中のポート、プロキシグループの選択、DNS設定を記録します。サブスクリプションURLにはアクセストークンが含まれる場合があるため、公開スクリーンショットに載せないでください。
2. まず基本設定で動作確認する。古いクライアントを終了し、FlClashでサブスクリプションを取り込んで、現在使う設定を選びます。まず解析エラーがないか確認し、システムプロキシを使って普段利用するサイトに接続します。最初からTUNや独自の上書き設定を有効にする必要はありません。
3. 設定を一つずつ戻す。ルール、DNS、LANアクセス、TUNの順に必要な機能を有効にし、毎回一項目だけ変更します。問題が発生したら、その項目の設定とログを確認してください。
4. 実行環境を記録する。クライアントのバージョン、mihomoのバージョン、OS、エラーメッセージ、再現手順を残します。クライアントとコアのバージョンは別の番号体系なので、相互に置き換えて考えることはできません。

完全なYAMLを使っていた場合は、まずその構造を維持したまま移行し、クライアントによる上書き項目を調整できます。ノード一覧だけを取り込んでいた場合は、新しいクライアントがプロキシグループやルールをどう生成するか確認してください。画面を変えれば、古いクライアントのローカルルールもサブスクリプションから自動的に引き継がれるとは限りません。

名称の新旧ではなく、用途に合わせて選ぶ

• WindowsとAndroidの両方で使う：FlClashを候補にし、両OSで必要なプロトコル、設定の処理方法、権限の条件を確認しましょう。
• 主にデスクトップで複数の設定を管理する：FlClashとClash Verge Revの設定切り替え、上書き、システム連携を比べ、自分の操作スタイルに合うものを選びましょう。
• ルーター、サーバー、自動化環境で使う：mihomoを直接実行する方法も検討できます。ただし、設定、プロセス、ログ、アクセス権限を自分で管理する必要があり、GUIクライアントが不要な場合もあります。
• 開発終了した古いクライアントを使い続ける：新しいサブスクリプションを解析できるか、現在のOSに対応しているかを確認してから、移行計画を立てましょう。

選定は、OSの対応状況、コアの機能、サブスクリプションとの互換性、通信の取り込み方法、最後にUIの好みの順で確認すると実用的です。対応OSを比較する場合はクライアント比較をご覧ください。設定を取り込んでも接続できない場合は、トラブルシューティングを参考に、設定エラー、システムプロキシ、DNSの問題を切り分けましょう。「クライアント選びの問題」と「現在の設定の問題」を分けて対応できます。