Clashオープンソース・エコシステムの全体像：mihomo、Clash Verge、ClashXと各派生プロジェクトの関係

まずカーネル、クライアント、設定を区別する

Clashエコシステムで最も混乱しやすいのは、複数のプロジェクト名にClashが含まれていても、同じ層に属しているとは限らない点です。オリジナルClash、Clash.Meta、mihomoは主にプロキシカーネル、Clash Verge Rev、Clash Nyanpasu、ClashXなどはGUIクライアントに分類されます。サブスクリプションURL、YAMLファイル、ルールセットは、カーネルが読み込むデータです。プロジェクトの用途を判断する際は、画面の比較より先に、どの層に属するかを確認するほうが確実です。

カーネルが実際の通信処理を担う

カーネルはローカルのプロキシポートを待ち受け、プロキシサーバーへの接続を確立し、ルールに従って通信の行き先を決めます。主な処理には、YAML設定の解析、プロキシグループの管理、ドメイン名とIPルールの照合、DNSポリシーの実行、REST APIの提供、対応プラットフォームでのTUN通信の取り込みなどがあります。以下は、典型的なカーネル基本設定の例です。

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

external-controller: 127.0.0.1:9090
secret: "change-this-controller-secret"

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

ここで、7890はHTTPとSOCKS5で共用する混合ポート、9090はコントロールインターフェースのポート、1053はDNS待ち受けポートの例です。GUIクライアントは通常、コントロールインターフェースを通じてノード一覧の取得、プロキシグループの切り替え、接続履歴の確認を行います。画面上の「ノードを選択する」操作は、最終的にカーネルAPIの呼び出しへ変換されます。

GUIクライアントがライフサイクルとシステム連携を担う

サブスクリプション設定のダウンロード、更新、切り替え。
カーネルプロセスの起動、停止、監視。
システムプロキシの設定、またはTUN仮想ネットワークアダプターの作成。
プロキシグループ、ルール、接続、ログ、通信量統計の画面を提供。
自動起動、トレイ動作、カーネルパスなど、クライアント固有の設定を保存。

そのため、同じサブスクリプションでも、2つのクライアントで動作が異なることがあります。必ずしもサブスクリプションの内容が変わったとは限りません。カーネルのバージョン、DNSの初期値、TUNの実装、クライアントが追加する上書き項目、またはクライアントが一部の設定項目しか表示していないことが原因の場合もあります。

オリジナルClash、Clash.Meta、mihomoの継承関係

オリジナルClashが設定とAPIの基盤を築いた

Dreamacroが開発したオリジナルClashはGoで書かれ、このエコシステムの互換性を支える重要な基盤を形成しました。YAML設定、プロキシグループ、順番に照合するルールシステム、HTTPとSOCKSの待ち受けポート、外部コントロールAPIなどがその代表です。多くのクライアントは当初、これらのインターフェースを中心に開発されました。オリジナルリポジトリは2023年に保守を終了し、アーカイブされています。それ以降もオリジナルカーネルに依存すると、上流でのプロトコル対応、プラットフォーム互換性、ネットワークスタックの修正は受けられません。

かつてのClash Premiumは、追加機能を備えた独立した配布系統で、ルールセット、スクリプト、より完全なTUN機能などを提供していました。現在、新しいクライアントを選ぶ際に追いかけるべき現役のオープンソース本流ではありません。古い解説に登場するrule-providers、tun、scriptの各項目は、実際に使用するカーネルと照合して判断する必要があります。「Clash設定」という4文字だけで互換性を推測してはいけません。

Clash.Metaが従来の機能を拡張した

Clash.MetaはMetaCubeXコミュニティによって保守され、Clash設定とコントロールインターフェースとの互換性を起点に、プロトコル、DNS、ルール、リスナー、TUN機能を拡張しました。以前、多くの設定提供者が対応するサブスクリプションに「Clash Meta」と表示していました。こうしたサブスクリプションには、オリジナルClashが認識できないプロキシ種別や項目が含まれる場合があります。そのため、旧版ClashX、旧版Clash for Windows、オリジナルClashカーネルに直接読み込むと、解析に失敗したり、一部のオプションが警告なく無視されたりすることがあります。

mihomoはClash.Metaの後継名称

Clash.Metaは後にmihomoへ改称されました。名称の変更は、設定体系全体が作り直されたことを意味しません。一般的なproxies、proxy-groups、rules、proxy-providers、rule-providersの構造は引き続き使われています。移行時に重視すべきなのは、クライアントが現役のmihomoカーネルを使用しているか、カーネルのバージョンが設定要件を満たしているか、起動前にクライアントが設定を書き換えていないかです。

mihomoのバージョンは通常、v1.x.x形式で公開されます。問題を調べるときは、「Metaカーネル」とだけ書かず、完全なバージョン番号を記録してください。クライアントの「設定」→「カーネル」または「設定」→「バージョン」画面で確認できるのが一般的です。メニュー名はプロジェクトによって多少異なります。ログの冒頭には、バージョン、Goランタイム、対象アーキテクチャが表示されることもあります。例としてlinux-amd64、windows-amd64、darwin-arm64などがあります。

デスクトップクライアントの各派生は何を解決するのか

Clash VergeとClash Verge Rev

Clash VergeはTauriで構築されたクロスプラットフォームのデスクトップクライアントで、画面とプロキシカーネルが分離されています。元プロジェクトの保守終了後は、Clash Verge Revがコミュニティによる派生版としてmihomoへの対応を継続しています。名称は似ていますが、保守状況とカーネルの更新元は異なります。新規インストール時は、プロジェクト名にRevが明記されているか確認し、「設定」→「カーネル設定」で実際に読み込まれているmihomoのバージョンを確認してください。

Clash Verge Revは、Windows、macOS、Linuxで似た操作方法を使いたいユーザーに適しています。一般的な流れは、「サブスクリプション」→「新規作成」でURLを追加し、更新後に「プロキシ」画面でポリシーグループを選択し、「設定」でシステムプロキシまたはTUNモードを有効にする方法です。システムプロキシは、OSのプロキシ設定に従うアプリを主に対象とします。TUNモードは仮想ネットワークアダプターを通じてより多くの種類の通信を処理しますが、通常は管理者権限と正しいルーティング、DNS設定が必要です。

Clash Nyanpasu

Clash NyanpasuもクロスプラットフォームのGUIクライアントで、設定管理、カーネル管理、デスクトップ操作を重視しています。mihomoの代替品ではなく、カーネルのダウンロードや呼び出し、実行用設定の生成、カーネル状態の表示を担当します。使用時は「クライアントのバージョン」と「カーネルのバージョン」を分けて確認してください。画面プログラムだけを更新しても、プロキシカーネルが更新されたとは限りません。

Nyanpasuは、複数の設定、上書き、プロキシグループを管理したいユーザーに適しています。サブスクリプション更新後に動作が変わった場合は、「設定」で現在有効な項目、上書き内容、カーネルの選択、実行ログを順番に確認してください。コマンドラインのmihomoでは起動できる設定がNyanpasuで失敗する場合は、クライアントが結合した最終設定を重点的に確認し、元のサブスクリプションファイルだけを調べないようにします。

ClashX、ClashX Pro、ClashX.Meta

ClashXは比較的早い時期に登場したmacOSのメニューバークライアントで、操作入口がステータスバーのアイコンに集約されています。クラシック版はオリジナルClashカーネルを前提に設計されており、「システムプロキシとして設定」「出力モード」、プロキシグループの選択など、古いmacOS解説に登場するメニュー構成を理解するのに役立ちます。オリジナルカーネルがアーカイブされた現在、最新プロトコル、新しいルールセット機能、macOSの新しいネットワーク変更に依存する設定には、従来のClashXは適していません。

ClashX Proは過去の拡張配布系統であり、名前にProが付いているだけでmihomoを使用しているとは判断できません。ClashX.Metaは、Metaカーネルとの互換性を求める用途で登場した派生版です。3つはアイコンやメニューが似ている場合がありますが、カーネルの出所は同じではありません。設定を読み込む前に、「ヘルプ」→「このアプリについて」を開くか、起動ログを確認して、カーネル名とバージョンを確認してください。アプリのファイル名だけでは、特定のプロキシ種別に対応しているか判断できません。

Clash for Windows

Clash for Windowsはかつて広く使われたデスクトップクライアントですが、オープンソースプロジェクトではなく、2023年に保守を終了しています。古い解説の多くは、「Profiles」「Proxies」「General」「Connections」画面を例にしています。こうした解説から設定の考え方は理解できますが、画面のパスをそのままVerge RevやNyanpasuに当てはめないでください。

Clash for Windowsから移行する場合は、プログラムフォルダー全体をコピーせず、サブスクリプションURLまたは元のYAMLを優先して移行してください。旧フォルダーには、クライアントが生成した結合設定、キャッシュされたルールセット、ローカル上書きが残っている場合があります。新しいクライアントにサブスクリプションを再登録し、ポート、LANアクセス、TUN、DNS設定を項目ごとに再構築するほうが、差分を特定しやすくなります。

モバイル、ルーター、Webパネルの位置づけ

モバイルクライアントは独立した実装

AndroidやiOSのアプリがClash形式に対応していても、デスクトップ版と同じカーネルバイナリを直接実行するとは限りません。モバイルOSには、バックグラウンドプロセス、VPNインターフェース、DNS、電力管理に関する独自の制約があります。Androidクライアントは通常、システムVPN APIでTUNを構築し、iOSクライアントはNetwork Extensionに依存します。デスクトップの「システムプロキシ」スイッチに完全に相当する仕組みは、スマートフォンにはありません。

Clash Meta for Androidは、かつてよく使われたMeta系のモバイルクライアントですが、使い続けるか判断する際は、リポジトリのアーカイブ状態と最近のリリース履歴を確認してください。FlClashなど、mihomoの機能を利用できるプロジェクトもありますが、画面設定、設定の保存方法、システム連携はクライアントごとの実装です。複数端末で設定を共有する場合は、サブスクリプション本体を共有し、TUN、DNSの待ち受けアドレス、LANパラメーターなどプラットフォーム依存の項目は各端末に残すことをおすすめします。

OpenClashはOpenWrtのプラグイン層

OpenClashはOpenWrt環境で動作し、カーネルの配置、設定変換、ルール更新、ファイアウォール、DNS連携を担当します。デスクトップクライアントでも、単独のプロキシプロトコルでもありません。ルーターで通信を取り込むには、nftablesまたはiptables、ポリシールーティング、DNSハイジャック、LANアドレス帯などを扱う必要があり、デスクトップのシステムプロキシスイッチより複雑です。

たとえば、デスクトップで一般的なmixed-port: 7890は、ローカルアプリにプロキシ入口を提供するだけです。ルーターで透過的に通信を取り込むには、LAN端末から転送される通信も処理する必要があります。allow-lan: trueを有効にしても、他の端末がプロキシの待ち受けポートへ接続できるようになるだけで、ゲートウェイ転送、DNSの取り込み、ファイアウォールの許可が自動的に完了するわけではありません。

Yacd、MetaCubeXDはDashboardに分類される

Yacd、MetaCubeXDなどは外部コントロールパネルです。カーネルのREST APIとWebSocketに接続し、プロキシグループ、アクティブな接続、ルールのヒット状況、通信量データを表示します。パネル自体はプロキシ通信を処理せず、mihomoの代わりにもなりません。カーネルのコントロールアドレスが127.0.0.1:9090の場合、直接アクセスできるのはローカル端末だけです。LANから管理する必要がある場合は、待ち受けアドレスの変更に注意し、十分に強力なsecretとファイアウォールルールを設定してください。

サブスクリプション、設定、ルールセットがプロジェクト間でどう流れるか

サブスクリプションURLが返す内容は通常YAML設定ですが、エンコードされたノード一覧の場合もあります。クライアントは内容をダウンロードし、必要に応じて変換や上書きを行ったうえで、最終設定をカーネルに渡します。「Clashサブスクリプションに対応する」とは、少なくとも、ファイル形式を認識できること、そこに含まれるプロキシプロトコルを認識できること、DNSとルール項目を正しく実行できることの3つを意味します。

完全設定とProvider設定

完全設定では、ノード、プロキシグループ、ルールを1つのファイルに記述します。Provider方式では、ノードやルールをリモートリソースに分け、カーネルが定期的に更新します。以下の構成では、3600秒ごとにノードプロバイダーを更新し、指定したURLへアクセスしてヘルスチェックを行います。

proxy-providers:
  airport:
    type: http
    url: "https://example.invalid/subscription.yaml"
    path: ./providers/airport.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: "https://www.gstatic.com/generate_204"

proxy-groups:
  - name: PROXY
    type: select
    use:
      - airport

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

interval: 3600はサブスクリプションの更新間隔、health-check.interval: 600はヘルスチェックの間隔を指定します。両者は同じ設定ではありません。テストURLへの応答速度は、その宛先へのリクエスト時間を示すだけで、ダウンロード帯域幅とは異なります。ルールは上から順番に照合されるため、MATCHはフォールバックとして末尾に置いてください。

クライアントの上書きが最終結果を変える

ポートの上書き：クライアントがサブスクリプション内のmixed-portを、ローカルで指定したポートに変更する場合があります。
DNSの上書き：TUNを有効にすると、クライアントがdns-hijack、Fake IP、nameserver設定を追加する場合があります。
ルールの上書き：スクリプトや結合設定によって、既存のルールの前にDIRECT、ブロック、プロセスルールが追加される場合があります。
プロキシグループの上書き：クライアントがローカルの選択状態を保持し、サブスクリプション更新後も以前のノード名を指し続ける場合があります。

互換性の問題を調べるうえで最も価値があるのは、クライアントが実際にカーネルへ渡した最終YAMLです。クライアントに「設定」→「実行設定を表示」または「設定」→「設定フォルダーを開く」がある場合は、そのファイルを書き出し、元のサブスクリプションと比較してください。ログに記録された設定パスも、生成ファイルの場所を特定する手がかりになります。

TUN、システムプロキシ、カーネルの違い

システムプロキシの対象は、プロキシ設定を自分で読み取るアプリだけ

システムプロキシを有効にすると、クライアントは通常、OSのHTTPとHTTPSプロキシを127.0.0.1:7890へ向けます。ブラウザーや多くのデスクトップアプリはこの設定を読み取りますが、ゲーム、一部のコマンドラインプログラム、仮想マシン、独自のネットワークスタックを実装したソフトウェアは迂回する場合があります。カーネルが正常に動作し、ブラウザーへアクセスできても、すべてのプロセスがプロキシを経由しているとは限りません。

TUNは仮想ネットワークアダプターでIP通信を取り込む

mihomoのTUNモードは仮想ネットワークインターフェースを作成し、ルーティングとDNS設定を組み合わせて通信を受け取ります。設定例は一般に次のような構成です。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack: mixedは、カーネルが対応する混合ネットワークスタック方式を使用することを示します。auto-routeはルートの自動設定を要求し、auto-detect-interfaceはデフォルトの出口インターフェースを識別します。管理者権限、ネットワークアダプターのドライバー、ファイアウォールに求められる条件はOSによって異なります。WindowsでTUN切り替え後に完全に通信できなくなった場合は、まず必要な権限でクライアントが実行されているか確認し、次に他のVPN、Hyper-V、WSL、セキュリティソフトが作成したルートを調べてください。

クライアント間のTUN体験の違いは、mihomoそのものだけでなく、起動順序、ルートの削除、DNS注入、スリープ復帰処理に起因することが少なくありません。2つのクライアントを比較する際は、同じ設定、同じカーネルバージョン、同じネットワーク環境を使ってください。テストでは、画面に表示されるメモリ使用量だけでなく、起動時間、最初のDNS応答、デフォルトルートの変化、スリープ復帰後の接続状態を記録するとよいでしょう。

保守状況を判断する方法

プロジェクト名が引き継がれていても、開発が継続しているとは限りません。クライアントを選ぶときは、ダウンロードページのバージョン表記だけでなく、コードリポジトリ、リリースページ、依存するカーネルを合わせて確認してください。オリジナルClash、Clash for Windows、クラシック版ClashX、各種コミュニティ派生版の状況は、それぞれ異なります。

確認できる4つのサイン

最近のリリース：正式版の公開日、変更履歴、各プラットフォーム向けインストーラーが同時に生成されているかを確認します。
カーネルの出所：オリジナルClash、mihomo、またはクライアントに内蔵された別の互換カーネルのどれを使っているか確認します。
問題への対応：現在のWindows、macOS、Linuxのバージョンに関する問題が分類され、修正されているかを確認します。
アップグレード経路：クライアントの更新にカーネル更新も含まれるか、失敗時に手動でロールバックできるかを確認します。

バージョン番号はプロジェクトをまたいで直接比較できません。Clash Verge Rev 2.x、Nyanpasu 2.x、mihomo v1.x.xはそれぞれ別のソフトウェアで、数字の大小に継承関係はありません。不具合を報告する際は、クライアントの完全なバージョン、mihomoの完全なバージョン、OSのバージョン、CPUアーキテクチャ、現在のモード、重要なログを併記してください。たとえば「Windows 11 24H2、x64、クライアント2.x、mihomo v1.x.x、TUN mixedスタック」のほうが、「最新版が使えない」より原因を特定しやすくなります。

アプリ名だけでアーキテクチャを推測しない

macOSのインストーラーにはx64とarm64が同時に用意される場合があります。Appleシリコン搭載端末では、まずarm64ビルドを選んでください。Windowsではx64が一般的ですが、一部の新しい端末はarm64を使用します。LinuxではAppImage、deb、rpmに加えて、必要なシステムライブラリも区別する必要があります。アーキテクチャが合っていないと、変換レイヤー経由でアプリが起動できても、TUN補助プログラムやカーネルバイナリが失敗する場合があります。

利用シーンからプロジェクトを選ぶ

Windows、macOS、Linuxで統一した操作

3種類のデスクトップOSで近い設定管理方法を使いたい場合は、Clash Verge RevまたはClash Nyanpasuを優先して検討できます。選ぶ際は、使用中のOSでのTUN対応、設定の上書き機能、カーネルの更新方式、ログへの入口を比較してください。ブラウザーのプロキシだけを使う場合は、複雑なTUNオプションよりシステムプロキシの安定性が重要です。

macOSで軽快なメニューバー操作

メニューバー中心の操作を好む場合は、現在も保守され、mihomoの使用を明確にしているmacOSクライアントを検討できます。クラシック版ClashXを使い続ける場合は、カーネルの機能範囲を把握し、mihomo専用項目を含む設定の読み込みを避けてください。macOSのメジャーアップデート前には、新しいシステムのネットワーク権限とバックグラウンド起動方式にクライアントが対応しているか確認しましょう。

ルーターで家庭内端末を一括管理

テレビ、ゲーム機、IoT機器に個別のクライアントをインストールできない場合、OpenWrtとOpenClashの組み合わせは一般的な選択肢です。導入前に、ルーターのCPUアーキテクチャ、使用可能メモリ、フラッシュ容量、ファイアウォールの構成を確認してください。大規模なルールセット、多数の接続、複雑なDNSを有効にすると、単純なローカルポートプロキシより必要なリソースが大幅に増えます。

カーネルとリモートパネルだけが必要

サーバーや軽量なLinux環境では、mihomoを直接実行し、systemdでプロセスを管理して、MetaCubeXDなどのDashboardからコントロールポートへ接続できます。この方法では、設定ディレクトリ、ファイル権限、ログローテーション、更新を自分で管理する必要があります。コントロールインターフェースを信頼できないネットワークへ直接公開してはいけません。リモートアクセスには、ファイアウォール、リバースプロキシ認証、安全なトンネルなどの制限を設けてください。

旧クライアントから移行する手順

現在のパラメーターを記録：サブスクリプションURL、現在のプロキシグループ選択、ローカル上書き、待ち受けポート、LAN設定を保存します。
元の設定をエクスポート：サブスクリプションYAMLを優先して保存し、キャッシュ、ログ、クライアントデータベースを移植可能な設定として扱わないでください。
新しいクライアントをインストール：システムアーキテクチャを確認し、「設定」→「カーネル」でmihomoのバージョンを確認します。
まずシステムプロキシをテスト：初期値の7890またはクライアントに表示された実際のポートを使い、基本的なルールとDNSが正常に動作することを確認します。
次にTUNを有効化：有効化前後のルートとDNSの変化を記録し、通信できなくなった場合にすぐ戻せるようにします。
上書きを再構築：ルール、DNS、LAN設定を1項目ずつ追加し、変更するたびに再読み込みしてログを確認します。

古い設定にスクリプトモード、Premium専用項目、古いプロキシ種別が含まれている場合は、まずmihomoでの代替方法を確認してください。旧クライアントの結合設定を一度にすべてコピーするのは避けましょう。絶対パス、古いポート、古いネットワークアダプター名、プラットフォーム専用項目が含まれている可能性があります。

移行後は、3つの方法で確認できます。ブラウザーからシステムプロキシ経由でアクセスする、コマンドラインでhttp://127.0.0.1:7890を明示してアクセスする、TUNを有効にしてシステムプロキシを読み取らないプログラムをテストする、という手順です。3つの結果を比較すれば、サブスクリプション、システムプロキシ、TUNルーティングのどこに問題があるか切り分けられます。