まずはコア・クライアント・設定の3層を理解する
Clashを検索すると、コアのリポジトリ、デスクトップ版のインストーラー、スマートフォンアプリ、サブスクリプションの設定方法などが一緒に表示されます。これらは同じ種類のものではありません。エコシステムを理解するには、名前にClashが含まれているかより、各プロジェクトがどの層を担うのかを把握することが大切です。
| レイヤー | 役割 | 主な内容 |
|---|---|---|
| プロキシコア | 接続の受け付け、DNSの解決、ルールの照合、アウトバウンド接続の確立 | Clash、mihomo |
| GUIクライアント | サブスクリプションのインポート、ポリシーの選択、コアの管理、システムとの連携 | Clash Verge Rev、FlClash |
| 設定・サブスクリプション | ノード、プロキシグループ、ルール、実行パラメーターの定義 | YAML設定、リモート設定URL、プロキシプロバイダー |
コアはネットワーク要求を処理する実行レイヤー、クライアントはボタンや一覧、設定画面を提供し、設定は接続の処理方法をコアに指示します。クライアントをインストールすると、通常は対応するコアも利用できますが、クライアント名とコア名が同じとは限りません。
Clash・Clash Meta・mihomoの系譜
Clash：オリジナルプロジェクトと総称としての使われ方
狭義のClashは、Dreamacroが開発を始めたルールベースのプロキシコアを指します。YAML設定でプロキシノード、プロキシグループ、DNS、ルーティングルールを管理し、GUIはコントロールインターフェースを通じて接続状況の確認やポリシーの切り替えを行えます。日常会話では「Clash」が同種のクライアントや設定形式の総称として使われることもあるため、チュートリアルの「Clashをインストール」は、必ずしもオリジナルコアを直接実行する意味ではありません。
オリジナルのオープンソース版Clashと、歴史上のClash Premiumも区別が必要です。Premiumは別の歴史的なリリース系列で、機能はオリジナルのオープンソースコアと同一ではありません。古いチュートリアルでTUN、スクリプト、ルールプロバイダーが扱われている場合は、対象の系列とバージョンも確認してください。特定の機能を「Clash」と名の付くすべてのソフトに当てはめることはできません。
Clash Meta：Clashから派生したコアプロジェクト
Clash MetaはClashから発展したコミュニティ主導のフォークです。既存の設定構造を多く引き継ぎながら、プロトコル対応、DNS、ルーティング、TUNなどの機能を拡張してきました。ここでいうMetaはコアプロジェクトの名称であり、別途購入が必要なクライアント版ではありません。また、Metaと付くアプリがすべて同じチームによって開発されているわけでもありません。
mihomo：Clash Metaの後継名称
Clash Metaは後にmihomoへ改称され、関連開発はmihomoプロジェクトで続いています。古いドキュメントや設定コメント、一部クライアントの画面では、今も「Metaコア」と表記されることがあります。「Clash Meta対応」と「mihomoを使用」という表現を見たら、まず実際のコアのバージョンを確認しましょう。通常は同じプロジェクトの系譜を指しており、両方を同時にインストールする必要があるわけではありません。
- プロジェクトの系譜：オリジナルのClash → コミュニティフォークのClash Meta → 後継名称のmihomo。
- クライアントとの関係：異なるGUIプロジェクトが同じコアを組み込むことがあります。インストーラーや操作画面は各プロジェクトが個別に開発・管理します。
- 互換性の判断：名称はプロジェクトを見分ける手がかりにすぎません。各フィールドへの対応状況は、実際に動作しているコアのバージョンで決まります。
2023年にオリジナルプロジェクトや一部クライアントの公開メンテナンス体制に変化があった後も、新たなコミュニティフォークが開発を続けています。だからといって「すべてのClashクライアントの更新が止まった」とは言えません。また、新しいクライアントを、元のプロジェクトが自動的に改称して引き継いだ公式後継とみなすこともできません。メンテナンス元は、プロジェクトのリポジトリやリリース履歴、開発者の説明で確認してください。
Verge・Verge Rev・FlClashはそれぞれどの層？
Clash Verge、Clash Verge Rev、FlClashはいずれもGUIクライアントに分類されます。画面から設定をインポートしたり、ポリシーを切り替えたり、ログを確認したりできます。実際のプロキシ処理は、クライアントが起動するコアが担います。
| プロジェクト名 | エコシステム上の位置づけ | 選ぶ際の確認事項 |
|---|---|---|
| Clash Verge | 旧世代のデスクトップクライアント | Revのリリース履歴と混同しない |
| Clash Verge Rev | Vergeの路線を引き継ぐコミュニティ製デスクトップクライアント。mihomoを使用 | システム要件、コアのバージョン、サービスモードの説明 |
| FlClash | Flutter製のマルチプラットフォームクライアント。mihomoを使用 | 対象プラットフォームのインストーラーと必要な権限 |
| Clash for Windows | 旧世代のデスクトップクライアント。開発終了 | 古い手順と現在のシステムとの互換性 |
| Clash for Android | 旧世代のAndroidクライアント。元のプロジェクトは開発終了 | 後発のコミュニティプロジェクトと混同しない |
クライアント名に含まれるプラットフォーム名だけでは、リリース対象を判断できません。たとえばClash for Windowsの過去のリリースはWindowsだけを対象としていたわけではなく、デスクトップクライアントでもAndroid版が提供されるとは限りません。ダウンロード時は、その時点のリリースに記載されたOSとアーキテクチャを確認してください。
同じmihomoを使っているのに、なぜ設定画面が違う？
サブスクリプションの保存、トレイメニュー、自動起動、サービスのインストール、設定のオーバーライドはクライアントごとに実装されるためです。コアのバージョンが同じでも、クライアントによって設定ディレクトリやサブスクリプションの更新方法は異なります。あるアプリの「設定」→「サブスクリプション更新」という手順を、別のアプリにそのまま当てはめることはできません。同じ名前のメニューが見つからない場合は、「設定」「Profiles」やクライアントのドキュメントで該当する項目を探してください。
設定の互換性は、フィールドと読み込み方法を確認
mihomoはClashエコシステムで一般的なYAML構造を引き継いでいますが、「インポートできる」ことと「すべてのフィールドが有効になる」ことは別です。基本的なプロキシグループやドメインルールは比較的移行しやすい一方、新しいプロトコル、DNSの拡張機能、TUNのパラメーターはバージョンに左右されます。古いコアでは新しい設定の読み込みに失敗したり、認識できない項目が無視されたりする場合があります。実際の挙動はログで確認してください。
基本フィールドで設定の構造を確認する
以下は一般的な設定とルールの例で、接続可能なノード情報は含みません。ローカルの混合プロキシポートを明示的に7890に設定し、接続先をローカルホストに限定しています。すべてのクライアントで共通の初期値というわけではありません。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,DIRECTmixed-portはHTTPとSOCKSをまとめたプロキシの入口です。mode: ruleはルールに従ってポリシーを選択することを示します。例の最後のルールは直結のフォールバックなので、これだけでプロキシ接続が作られることはありません。実際の設定でProxyという名前のポリシーグループを参照する場合は、そのグループを設定内で定義する必要があります。名前と大文字・小文字も一致させてください。
完全なサブスクリプションとプロキシプロバイダーは別の入力形式
- 完全な設定のサブスクリプション：
proxies、proxy-groups、rules、DNS設定などを含む場合があります。通常はクライアントの設定一覧にインポートします。 - プロキシプロバイダー：通常は
proxy-providersで参照し、既存のプロキシグループから利用します。単独では完全な実行設定でない場合があります。 - 単一ノードの共有リンク：クライアント側での解析または変換が必要です。任意の共有リンクをYAMLのトップレベルに貼り付けても使えるわけではありません。
「同じサブスクリプションがAでは使えるのにBでは使えない」場合、まずBが同じ入力形式を受け付けるか確認し、その後にコアのバージョンを比較してください。ブラウザーでリンクをダウンロードできるからといって、クライアントがそのまま読み込める完全な設定とは限りません。
システムプロキシとTUN：通信を取り込む仕組みであり、別のコアではない
システムプロキシとTUNは「アプリの通信をどうコアに渡すか」を解決し、ルールモードは「取り込んだ通信をどのポリシーで処理するか」を決めます。これらは別々の設定項目です。TUNを有効にしてもルールモードは引き続き利用でき、動作には有効なノード、DNS、ルーティングの設定も必要です。
システムプロキシ：OSの設定に従うアプリをローカルポートに接続
Windows 11を例にすると、「設定」→「ネットワークとインターネット」→「プロキシ」で状態を確認できます。クライアントで有効な混合ポートが7890なら、システムプロキシには該当するローカルアドレスとポートを指定してください。以前使っていたクライアントの7897や別の値をそのまま使うものではありません。これらの数値は設定によって異なるため、チュートリアルの画面だけで現在のポートを判断しないでください。
すべてのプログラムがシステムプロキシに従うわけではありません。ブラウザーでは使えるのに特定のターミナルツールでは使えない場合、まずそのツール独自のプロキシ設定や環境変数を確認してください。すぐにコアの障害と判断する必要はありません。
TUN：仮想ネットワークインターフェースとルーティングで通信を取り込む
TUNを使うと、システムプロキシに従わないアプリの通信も取り込めますが、正常に動作するかはシステム権限、ルーティング設定、DNS処理、既存のネットワーク環境に左右されます。デスクトップクライアントでは、先にサービスのインストールや権限の昇格が必要な場合があります。Androidでは通常、システムのVPNインターフェースを使い、ユーザーによる許可が必要です。プラットフォームごとに異なる権限設定をそのまま流用しないでください。
- TUNに切り替える前に、通常のプロキシ接続とノードが正常に動作することを確認してください。2種類の問題を同時に切り分けずに済みます。
- ルーティングの競合を特定しやすいよう、他のVPN、仮想ネットワークアダプター、セキュリティソフトの状態を記録しておきましょう。
- UDPが使えるかどうかは、ノードのプロトコル、サーバー、アウトバウンド経路にも左右されます。TUNを有効にするだけでUDPに対応するわけではありません。
クライアントの選定・移行で確認する5つの手順
- プラットフォームとアーキテクチャを確認する。まずWindows、macOS、Linux、Androidのどれを使うか確認し、x64やARM64などインストーラーの表記を照合します。macOSではAppleメニュー→「このMacについて」でチップ情報を確認できます。
- プロジェクトを特定する。正式名称、リポジトリの所有者、リリース履歴を照合します。特にClash VergeとClash Verge Rev、オリジナルのモバイルプロジェクトとコミュニティフォークを区別してください。
- クライアントとコアの両方のバージョンを記録する。「バージョン情報」、コア管理画面、起動ログなどで確認します。画面の場所はバージョンによって異なります。クライアントを更新しても、コアが同時に更新されるとは限りません。
- 設定をインポートしてから、ノードを個別にテストする。設定が正常に読み込まれたことを確認し、ログに未対応フィールド、存在しないプロキシグループ、ポートの競合などがないか調べてから、実際のWebアクセスを試してください。
- 最後に自動化の設定を移行する。接続が安定してから、自動更新、自動起動、オーバーライド、TUNを設定してください。一度に変更する要素を増やしすぎないようにしましょう。
コアを単独で実行する場合は、ターミナルで次のコマンドを実行するとバージョンを確認できます。現在のディレクトリに該当する実行ファイルが必要です。GUIクライアントを使っている場合、バージョン確認のために別のコアをインストールする必要はありません。
# Linux / macOS：コアファイルがあるディレクトリで実行
./mihomo -v
# Windows PowerShell：コアファイルがあるディレクトリで実行
.\mihomo.exe -vトラブルシューティングでは「最新版」とだけ書かず、実際の出力を記録してください。OSのバージョン、設定の入手元や形式、接続方法、具体的なエラー内容も記録します。ログを共有する前に、サブスクリプションURLのトークン、ノードのパスワード、コントロールインターフェースのキーを削除してください。
よくある質問：似た名称を見分けるには
mihomoをインストールしたら、クライアントも必要ですか？
必ずしも必要ではありません。コマンドラインや設定ファイルに慣れているユーザーは、コアを直接実行し、起動やシステムとの連携を自分で管理できます。画面からサブスクリプションを読み込み、ポリシーを切り替えたり接続状況を確認したりしたい場合は、GUIクライアントが便利です。どちらも別の使い方であり、2つを重ねてインストールする必要はありません。
コアをmihomoに変えれば、古い設定は必ず使えますか？
プロジェクトの系譜だけでは保証できません。フィールドの互換性に加えて、相対パス、ルールファイルの形式、クライアントのオーバーライド、権限も確認してください。移行後は実際の読み込みログとルールの適用状況を確認し、設定一覧に名前が表示されたことだけを成功の目安にしないでください。
古い名称の「Meta」を見かけたら、サブスクリプションを新しく探す必要がありますか？
名称が変わっただけでサブスクリプションを変更する必要はありません。現在のコアがサブスクリプションの出力形式、プロトコル、フィールドに対応していない場合に限り、出力形式や設定を調整してください。まず具体的なエラーを確認し、不要な変換でサブスクリプションの認証情報を漏らさないようにしましょう。
クライアントとコアを混同しないためには？
クライアントの正式名称とバージョン、コアの名称とバージョン、設定の種類、ローカルプロキシのポート、システムプロキシまたはTUNの状態を簡潔に記録しておきましょう。ソフトを切り替えたりログを調べたりするとき、この5項目があれば「画面の問題」「設定の問題」「ネットワーク接続の問題」を切り分けやすくなります。
続けて読む場合は、用語集でプロキシグループやFake-IPなどの用語を確認するか、設定フィールドの説明で具体的なパラメーターを調べてください。クライアント選びではプラットフォームとメンテナンス状況を、互換性の確認ではコアと実際の設定を見ます。この2つを分けて考えると、エコシステム内の名称を混同しにくくなります。