Clash、mihomo、Verge Rev の関係とは:オープンソース系譜を整理

Clashのエコシステムに初めて触れる人の多くは混乱します。「Clash ダウンロード」で検索すると名前の異なる十数種類のソフトが出てきて、画面デザインも違い、GitHubリポジトリも別々のアカウントに分散しています。この混乱は偶然ではなく、明確な歴史的経緯があります。原作者がリポジトリをアーカイブした後、コミュニティがバトンを引き継いで今の構図が形成されました。この流れを理解すれば、なぜ一部のクライアントは更新が活発で、一部はすでに更新停止しているのか、そしてプラットフォームごとにどれを優先すべきかが見えてきます。

最初のClashプロジェクトはDreamacroが開発し、Go言語で書かれていました。核心思想は「ルールベースのトラフィック振り分け」です。設定ファイルにドメインやIPレンジがどのプロキシノードを通るかを記述し、内核がルールを順に照合してトラフィックを転送します。この設計は後続の全ての分岐に完全に継承され、エコシステム全体を理解する基礎となっています。

2023年頃、原始リポジトリは外部要因によりアーカイブ(archive)され、リポジトリは読み取り専用状態となり、新しいコミットを受け付けなくなりました。これは当時Clash内核に依存していた全てのGUIクライアントにとって大きな打撃でした。内核が更新されなくなるということは、新しいプロトコル対応、新しいルール文法、セキュリティ修正が公式版に反映されないことを意味します。コミュニティはすぐに2つの対応策を打ち出しました。

• 旧内核を継続利用する:一部のクライアントはアーカイブ前の最終バージョンをベースにそのまま凍結し、新機能を追わない方針をとりました。長期使用するとプロトコルの非対応問題に徐々に遭遇します。
• コミュニティ維護の分岐内核へ切り替える:これが現在アクティブなプロジェクトで広く採用されているルートで、本稿で重点的に紹介するmihomoです。

mihomoは旧Clash Metaプロジェクトが改名して継続したもので、コミュニティチームによってメンテナンスされ、現在最もアクティブで更新頻度の高いオープンソース内核です。原版Clashのルールベース振り分けを土台に、以下の機能を補完・強化しています。

• TUNモード:システムのネットワーク層に仮想ネットワークカードを構築し、全トラフィックを一括制御します。個別アプリごとのプロキシ設定に依存せず、システムプロキシ設定に対応していないプログラムにも効果があります。
• より充実したプロトコル対応:VMess、VLESS、Trojan、Hysteria、Hysteria2、TUICなどのプロトコルが順次補完され、対応速度は更新停止前の原版内核より明らかに速いです。
• ルールセットの拡張:GEOSITE、GEOIPなどのリモートルールセット形式に対応し、サブスクリプション提供者が地域やサービスごとにルールを分類・維持しやすくなり、クライアント側で1件ずつドメインを列挙する必要がなくなりました。
• スクリプトと上級戦略:Scriptタイプのルールとより柔軟なポリシーグループの入れ子機能を提供し、複雑な振り分けシナリオに対応します。

強調しておきたいのは、mihomo自体はGUIを持たない内核プログラムだという点です。日常的に使う各種クライアント(Verge Rev、FlClash、Nyanpasuなど)はいずれもmihomoの上に構築されたGUIの外殻であり、設定管理、ノード表示、サブスクリプション取り込み、トラフィック統計といったインタラクション層の機能を担っています。実際にプロキシと振り分けロジックを実行しているのは内核そのものです。

内核が統一された後、各GUIクライアントの違いは主に開発言語、UIフレームワーク、対象プラットフォームに表れています。以下、プロジェクトごとに特徴を整理し、用途に応じた選択に役立てます。

Verge Rev(clash-verge-rev)

Tauriフレームワークで開発され、フロントエンドはWeb技術スタック、バックエンドはRustで書かれており、従来のElectron製クライアントよりも軽量です。現在Windows、macOS、Linuxの3プラットフォームで最も規則的に更新されているデスクトップクライアントの一つです。設定ファイルはビジュアル編集とYAMLソース編集の両モードを切り替え可能で、初心者と手書き設定に慣れたユーザーの両方に対応します。ポリシーグループ、接続詳細、ログパネルなどの情報表示も充実しています。

FlClash

Flutterフレームワークをベースに開発され、最大の特徴はクロスプラットフォームでのコード共通化度が高いことです。同一のUIコードからWindows、macOS、Linux、Androidの複数プラットフォーム向けクライアントをビルドでき、見た目のスタイルが各プラットフォームで統一されています。複数の異なるOS端末を切り替えて使う必要があり、操作感を統一したいユーザーにとっては、画面に再適応するコストを減らせます。

Nyanpasu(clash-nyanpasu)

同じくTauriフレームワークを基盤としていますが、UIデザインではアニメーションとテーマのカスタマイズ性をより重視しており、設定ファイルのビジュアル管理とサブスクリプションの自動更新に対応しています。技術選定はVerge Revに近いものの、画面デザインや一部の操作感で異なる方向性を取っており、個性的な見た目を好むユーザーに向いています。

モバイル端末とその他のプラットフォーム

Androidプラットフォームでは、FlClash以外にもmihomo内核を基盤とした複数の独立クライアントが存在し、いずれもTUNモードでの全体プロキシとアプリ別振り分けに対応しています。iOSプラットフォームの選択肢は比較的限られており、多くのクライアントはApp Store経由で配布され、UIスタイルはシステム標準のデザイン規範に近く、設定管理もサブスクリプションリンクのワンタップ取り込みを重視した方式になっています。

主流クライアントはすべて最終的にmihomoまたは互換内核を呼び出して設定を解析するため、YAML形式の設定ファイルとサブスクリプションリンクはこれらのクライアント間でほぼそのまま相互利用できます。標準的な設定ファイルには通常、以下のような核となるフィールドが含まれます。

port: 7890
socks-port: 7891
mode: rule
log-level: info
proxies:
  - name: "サンプルノード"
    type: vmess
    server: example.com
    port: 443
proxy-groups:
  - name: "自動選択"
    type: url-test
    proxies: ["サンプルノード"]
rules:
  - DOMAIN-SUFFIX,example.com,自動選択
  - MATCH,DIRECT

つまり、あるクライアントから別のクライアントに移行する際も、通常はプロキシノードを再設定する必要はなく、既存のサブスクリプションリンクやローカル設定ファイルをそのまま取り込めば継続して使用できます。本当に注意が必要な差異は、クライアント固有のUI設定項目に集中しています。例えばシステムプロキシのオン・オフ方式、TUNモードの有効化手順、ログ保持ポリシーなどで、これらは外殻層の機能であり、内核を切り替えても自動的には引き継がれません。

1. 対応プラットフォームの範囲を確認する

   まず自分がカバーしたいシステムを明確にします。Windows単体のみか、Windows、macOS、Androidを同時に併用するかによって選択が変わります。マルチプラットフォームで使う場合は、同一プロジェクトのクロスプラットフォーム版を優先すると、設定ファイルをクライアント間で変換する手間が減ります。

2. プロジェクトの更新頻度を確認する

   GitHubリポジトリページで直近のリリース(Release)日時を確認しましょう。長期間更新のないクライアントは画面が正常に開けても、内核が古すぎて新しいプロトコルやルール文法を解析できない場合があります。

3. TUNモードの対応を確認する

   単一アプリのプロキシではなく全体のトラフィック制御が必要な場合、対象クライアントがTUNモードに明確に対応しているかを確認し、システム側で対応する権限付与を完了させます(Windowsでの管理者権限、macOSでのネットワーク拡張機能の許可など)。

4. 既存の設定ファイルを保管しておく

   クライアントを変更する前に、現在のサブスクリプションリンクとローカルルールをエクスポートまたはバックアップしておくと、新クライアントのインストール後にそのまま取り込め、ノード情報を再整理する手間を避けられます。

整理すると、明確な判断の流れが見えてきます。Clashがルールベースの振り分けアーキテクチャを確立 → mihomoがコミュニティ主導の内核として継続的にプロトコルと機能を更新 → Verge Rev、FlClash、Nyanpasuなどのクライアントがmihomoの上にそれぞれの画面と操作体験を構築、という流れです。クライアント選びは本質的には1枚の外殻を選ぶ行為であり、内核が同じで設定ファイルが共通であれば、クライアント間の移行コストは非常に低くなります。本当に時間をかけて比較する価値があるのは、UIが自分の操作習慣に合っているか、対象プラットフォームが安定してサポートされているか、そしてプロジェクトが今も活発にメンテナンスされているかどうかです。