まず対応OSで絞り、機能を比較
Clashクライアントは、まず使う端末と設定要件から選びましょう。WindowsとAndroidで使うなら、FlClashを試す候補にできます。Windows、macOS、Linuxで細かな設定を行うなら、Clash Verge Revも比較対象です。iPhoneやiPadを使う場合は、iOS対応クライアントを個別に確認してください。デスクトップ版と画面が似ていても、同じ名前のモバイルアプリが同等の機能を備えているとは限りません。
この記事ではクライアントの動作や機能を比較し、ノードの速度ランキングは扱いません。実際の速度は、ノードの出口、回線、接続先サービス、ローカルネットワークに左右されます。同じコアとサブスクリプションを使う場合、UIを変えても回線の混雑が直接解消されるわけではありません。比較すべきなのは、設定を正しく読み込めるか、想定どおりに通信を処理できるか、問題発生時に原因を特定しやすいかです。
| クライアント | 当サイトのダウンロード対象プラットフォーム | 優先して検討したい用途 | インストール前の確認事項 |
|---|---|---|---|
| Clash Plus | iOS、Android、Windows、macOS | iOSを含む複数端末での利用 | リリースごとのコア、サブスクリプション形式、プラットフォーム機能の違い |
| FlClash | Windows、macOS、Linux、Android | デスクトップとAndroidで近い操作感を求める場合 | CPUアーキテクチャ、ライセンス方式、設定の上書き |
| Clash Verge Rev | Windows、macOS、Linux | デスクトップでの設定管理、ルール編集、サービスモード | サービスのインストール状態と実際に適用されている設定 |
| Clash Nyanpasu | Windows | Windowsデスクトップ向けの別の管理UI | 選択したリリースのコアと機能の対応状況 |
| ClashX Meta | macOS | メニューバーからの操作を好むMacユーザー | Apple Silicon／Intel向けインストーラーと通信の処理方法 |
コアを比較：クライアント名だけでは互換性を判断できない
FlClashとClash Verge Rev：共通するコアの系譜
FlClashはFlutterでUIを構築し、Clash Metaコアを使用します。Clash Verge Revはmihomoコアを使用します。Clash Metaとmihomoは同じプロジェクトの発展系譜にあるため、ルール、プロキシグループ、一般的なプロトコル設定には共通点が多くあります。ただし、UIのバージョンや搭載コアのバージョン、クライアントが設定する実行パラメーターは異なる場合があります。
同じYAMLを読み込んでも、一方のクライアントでは起動し、もう一方でエラーになることがあります。その場合は、サブスクリプションが無効だとすぐに判断せず、コアのバージョンとエラーに表示された項目を確認してください。新しいプロトコルや設定項目には、より新しいコアが必要な場合があります。また、クライアントがポート、DNS、TUNなどを上書きし、元のサブスクリプションと実行時の設定が異なることもあります。
Clash Plus：使用するリリースごとに確認
「Clash」という名前だけで、Clash Plusのすべてのプラットフォームが同じバージョンのmihomoを使うとは限りません。他のクライアントの設定手順をそのまま当てはめるのも避けましょう。選ぶ際は、そのリリースのプロジェクト説明、コアの識別情報、対応プロトコルを確認し、実際のサブスクリプションで検証してください。特にiOSでは、通信の処理にシステムが提供する拡張機能を使う必要があります。デスクトップのサービスモード、管理者権限、仮想ネットワークインターフェースの設定とは同列に扱えません。
- 1つ目：バージョンを記録する。クライアントとコアのバージョンを別々に記録してください。問題を報告するときは「最新版」だけで済ませないようにしましょう。
- 2つ目：サブスクリプション形式を確認する。完全なClash YAML、ノードだけを含むデータ、
proxy-providersから参照するファイルは、それぞれインポート方法が異なります。 - 3つ目：起動エラーを確認する。未知の項目、未対応プロトコル、存在しないプロキシグループの参照は、それぞれ異なる互換性の問題を示します。
UIとサブスクリプション管理：よく使う操作の手順数を確認
FlClash：デスクトップとAndroidで近い操作感
FlClashは、デスクトップとAndroidで操作の習慣を共通化したいユーザーに向いています。サブスクリプション設定、プロキシの選択、接続状況、ログなどを共通のUI体系で利用できます。選ぶ際は、設定のインポート、プロキシグループの切り替え、接続状況の確認、エラーログの表示という4つの操作を続けて試してください。必要な画面を何度も探さずに済むなら、日々の管理負担を抑えやすくなります。
UIが似ていても、設定が端末間で自動同期されるわけではありません。同じサブスクリプションURLを使うことはできますが、ローカルの変更、プロキシグループの選択、アプリごとの通信振り分け、システムの許可設定は端末ごとに保存される場合があります。PCとスマートフォンで同じサブスクリプション名を付けても、同期されるわけではなく、見分けやすくなるだけです。
Clash Verge Rev：デスクトップの設定管理を重点的に確認
Clash Verge Revは、デスクトップのプロキシ環境を継続的に管理したいユーザーに向いています。サブスクリプションだけでなく、使用するバージョンの上書き、マージ、スクリプト処理の方法を確認し、カスタムルールをどの階層に配置するかも把握しましょう。リモートサブスクリプションから生成されたファイルを直接編集すると、次回の更新で置き換えられる可能性があります。ローカルの上書き設定を分けて管理すれば、変更を元に戻しやすくなります。
たとえば、DOMAIN-SUFFIX,example.org,DIRECTを最終的なフォールバックルールより前に置く場合、確認すべきなのは「ルール編集機能があるか」だけではありません。サブスクリプションの更新後もルールが残っているか、順序が正しいか、接続画面でそのルールへのマッチを確認できるかが重要です。ルールは通常、上から順に照合されるため、配置を変えると結果も変わる場合があります。
共通の手順でサブスクリプションを確認
- 「日常用」と「予備」の2つの設定を用意し、切り替えたときに現在有効な設定を判別できることを確認します。
- リモートサブスクリプションを手動で更新し、更新日時とエラーメッセージを確認します。プロキシグループが引き続き有効なノードを参照していることも確認してください。
- ローカルのカスタムルールを1つ追加し、サブスクリプションの更新後も残っていることを確認します。
- 設定を切り替えたら新しい接続を作成して検証します。既存のダウンロードや長時間接続だけで切り替え結果を判断しないでください。
TUNを比較：通信の処理範囲、権限、DNSを確認
システムプロキシは、システムのプロキシ設定に従うアプリに主に影響します。TUNは仮想ネットワークインターフェースとルーティングを使って通信を処理するため、システムプロキシを参照しない一部のアプリに適しています。ただし、TUNを有効にすればすべての通信を必ずプロキシ経由にできるわけではありません。実際の処理範囲は、ルーティング、バイパス設定、プロセスの除外、DNS、OSの制約にも左右されます。
FlClashとClash Verge RevはいずれもTUN関連機能を備えていますが、問題なく有効化できるかはOSやバージョンによって異なります。デスクトップでは、適切な権限やバックグラウンドサービスが必要になることがあります。AndroidではシステムのVPN許可を使って通信経路を確立するため、通常、同じVPN経路を使用する別のアプリとは競合します。iOSでは、そのアプリのVPN設定と拡張機能の実装を個別に確認してください。
| 項目 | システムプロキシのテスト | TUNのテスト |
|---|---|---|
| 対象アプリ | ブラウザーとプロキシを明示指定したコマンドラインツール | システムプロキシを参照しない別のアプリ |
| 許可状態 | システムプロキシのスイッチとローカルの待ち受けポートを確認 | サービス、仮想インターフェース、またはシステムVPNの許可を確認 |
| DNSの動作 | アプリがドメイン名の名前解決をどこに依頼するか確認 | DNSの処理、Fake-IP、フィルター設定を確認 |
| 終了後の復元 | 終了後にシステムプロキシが元の状態に戻ることを確認 | 終了後にルーティングと通常のインターネット接続が復旧することを確認 |
速度を比較するために、2つのクライアントのTUNを同時に実行しないでください。ルーティングやDNSの処理が干渉し、クライアントの違いではなく競合を測定することになります。先に一方のクライアントを終了し、システムのネットワーク接続が復旧したことを確認してから、もう一方を起動してください。企業VPN、仮想マシン、コンテナのネットワークも考慮しましょう。
公平に比較する：サブスクリプション、ノード、プロキシポートを統一
FlClashとClash Verge Revを比較する場合は、最低限、同じ端末、ネットワーク、設定、ノード、接続先を使います。テスト前にプロキシグループからノードを手動選択し、自動選択グループによってテストごとに出口が変わらないようにしてください。HTTPダウンロードとUDPアプリのテストは分けて記録しましょう。単一の遅延値だけでは性能全体を判断できません。
まず明示的なプロキシ接続を検証
以下のYAMLはテスト用パラメーターの例であり、完全な設定でも、すべてのクライアントのデフォルト値でもありません。ローカルのポートが使用中でないことを確認し、クライアントで同じ待ち受けパラメーターを設定してから、該当するコマンドを実行してください。UIでこれらの項目が上書きされる場合は、実際の実行パラメーターを基準にします。
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: infoここでの7890は、この例で指定したHTTP/SOCKS共通ポートです。次のリクエストはHTTPプロキシを明示的に指定するため、ブラウザーがシステムプロキシを参照するかどうかには依存しません。Windows PowerShellでは、古い環境のコマンドエイリアスとの混同を避けるため、curl.exeを使用してください。
# macOS / Linux
curl --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com/
# Windows PowerShell
curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com/このコマンドはプロキシ経由の接続とHTTPレスポンスを確認するもので、速度測定用ではありません。接続先サービスがHEADリクエストをどう処理するかも結果に影響します。接続が拒否された場合は、まず待ち受けポートを確認してください。上流がタイムアウトする場合は、ノードと回線を確認します。明示的なプロキシでは接続でき、TUNだけが失敗する場合は、サブスクリプションを何度も変更するのではなく、権限、ルーティング、DNSを優先的に調べましょう。
結果を記録し、根拠のない性能ランキングは作らない
- 3回連続でテストする。接続できたか、想定したルールにマッチしたかを各回記録します。速度テストでは、同じファイルと時間帯を使ってください。
- 2種類の時間を分ける。ノードの応答確認にかかった時間と、ファイル全体のダウンロード時間を別々に記録し、ひとつの「速度」として扱わないでください。
- 通信の処理方式を分けて比較する。まず明示的なプロキシをテストし、その後にTUNをテストします。一度に複数の条件を変更しないでください。
- 失敗時の状況を記録する。クライアントとコアのバージョン、ネットワークの種類、エラーの発生時刻を記録してから、ログで原因を調べます。
3つの利用シーンから候補を絞り込む
初心者：サブスクリプションの読み込みとルールモードを確認
WindowsまたはAndroidを使い始めた方は、まずFlClashで設定の読み込み、プロキシグループの切り替え、ログ画面を確認できます。ブラウザーの利用だけが目的なら、まずシステムプロキシとルールモードで基本動作を確かめてから、TUNを検討してください。グローバルモードを恒久的な解決策にしないようにしましょう。既存の通信振り分けを迂回し、直接接続するサービスの経路を変える可能性があります。
iPhoneまたはiPadを使う場合は、Clash Plusの該当する案内からインストール方法を確認できます。ただし、利用可能な地域、配布経路、サブスクリプションとの互換性、機能説明を事前に確認してください。デスクトップ版が特定の設定項目に対応していても、モバイル版も対応しているとは限りません。
複数端末ユーザー：UIの共通性と設定の共有を区別
Windows、macOS、Linux、Androidを組み合わせて使う場合は、FlClashを優先候補として検討できます。iOSを含む場合は、iOS向けクライアントを別途確認してください。共有するのはサブスクリプションの取得元や必要なルールにとどめ、デスクトップの設定一式をそのままスマートフォンにコピーするのは避けましょう。ポート、TUN、LANからの待ち受け、アプリごとの通信振り分けは端末ごとに管理してください。
復元可能なローカル設定を最低1つ保存し、サブスクリプションの更新に失敗した場合の対処手順も用意しましょう。複数端末で使う際に大切なのは管理の手間であり、各プラットフォームでスイッチの位置まで完全にそろえることではありません。
デスクトップ上級者：実行時設定と復旧のしやすさを比較
ルールの上書き、接続のトラブルシューティング、バックグラウンドサービスの管理が必要なら、Clash Verge RevとFlClashを重点的に比較しましょう。別のデスクトップ操作環境を好む場合は、Clash NyanpasuやClashX Metaも候補になります。確認手順は、最終設定の確認、ルールのマッチ状況の特定、設定の切り替え、サブスクリプションの更新、終了後のネットワーク復旧の順に固定するのがおすすめです。
Clash for WindowsとClash for Androidの元プロジェクトはすでにメンテナンスを終了しています。使い慣れた旧UIだけを理由に、新規インストールの第一候補にするのは避けましょう。古い設定は移行用の資料として利用できますが、移行前にコアの互換性、DNS、TUNの設定を改めて確認してください。クライアント選びで最も重要なのは、現在の端末で設定の読み込み、通信の処理、問題発生後の復旧を安定して行えることです。
インストール前に確認する5項目
- プラットフォーム：Windows、macOS、Linux、Android、iOSのどれを使うか確認し、適切なCPUアーキテクチャとインストール形式を選びます。
- コアの互換性：サブスクリプションで必要なプロトコルと設定項目を確認し、クライアントのバージョンをコアのバージョンと混同しないようにします。
- サブスクリプション管理：更新後も必要なローカルルールが保持され、実際に適用されている設定を確認できることを確かめます。
- 通信の処理方法：システムプロキシとTUNのどちらを使っているか把握し、接続画面やログから動作を確認できるようにします。
- ネットワークの復旧：クライアントを終了した後、システムプロキシ、VPNの状態、インターネット接続を確認してから次のテストを行います。
候補を絞ったら、まず1つのクライアントで一連の動作を検証してから、継続して使うか判断しましょう。サブスクリプションの読み込み、モード切り替え、TUNの許可について詳しく知りたい場合は設定ガイドをご覧ください。ルールとプロキシグループの参照関係については高度な設定をご覧ください。