Clash GUIクライアントの選び方｜Clash Verge Rev・FlClash・Android版を比較

端末と通信の制御方法から選ぶ

PCだけで使うなら、まずClash Verge RevとFlClashのデスクトップでの操作性を比べましょう。Androidスマートフォンでも使う場合は、画面を切り替える際の学習コストを抑えやすいFlClashを試すのがおすすめです。ゲームやコマンドライン、システムプロキシに従わないアプリでも通信を制御したい場合は、クライアントのTUN対応状況とシステム権限を確認してください。画面の見た目だけで選ぶのは避けましょう。

GUIクライアントはサブスクリプションの読み込み、設定画面、コアの起動、接続状況の表示を担います。mihomoコアは設定の解析、ルールの適用、プロキシ接続の確立を行います。同じコア、同じノードとルールで使う場合、クライアント名だけで通信速度を判断することはできません。違いが表れやすいのは、権限管理、設定のマージ、更新方法、トラブルシューティングの手順です。

• デスクトップで常時使用：サービスモード、自動起動、トレイ操作、スリープ復帰後の接続を確認します。
• PCとスマートフォンで同じサブスクリプションを使用：設定形式、グループ名、各端末で対応する項目を確認します。
• ルールを頻繁に編集：ローカルの上書き設定が保持されるか、最終的に適用される設定を確認できるかをチェックします。
• ブラウザーでの利用が中心：まずシステムプロキシを確認し、切り分ける要素を減らすためTUNは有効にしないでおきます。

Clash Verge Rev・FlClash・Android版を比較

まず対応OSを確認し、次に操作性や設計方針を比べましょう。以下では利用方法を比較し、画面の好みを性能の順位に置き換えていません。インストールする配布パッケージのアーキテクチャ、最低システム要件、コアのバージョンは、各パッケージの説明を確認してください。

デスクトップで細かく設定するなら、まずClash Verge Rev

ルールの編集、ログの確認、複数のサブスクリプションの調整を頻繁に行う場合は、Clash Verge Revの操作フローを試してみましょう。設定項目の数より、サブスクリプションの元データ、ローカルでの変更、実際に適用される設定を明確に区別できるかが重要です。更新後もカスタムルールが想定どおり適用されるなら、継続利用に向いています。

PCとAndroidを行き来するなら、まずFlClash

PCとスマートフォンで似た操作感を使いたい場合は、FlClashを試してみましょう。ただし、画面が似ていてもシステム権限は同じではありません。デスクトップのシステムプロキシやサービスのインストールと、AndroidのVPN許可やバックグラウンド制限は、それぞれ別に設定が必要です。サブスクリプションを読み込めても、すべての端末で通信が制御されているとは限りません。

mihomoコアとサブスクリプションの互換性を確認

まず、クライアントのバージョンと実際に動作しているコアのバージョンを記録します。クライアントのバージョン情報画面や起動ログで確認してください。クライアントのバージョン番号をmihomoのバージョンと混同しないようにしましょう。プラットフォームごとにパッケージ化や更新のタイミングが異なるため、この記事では一律に「最新バージョン」を指定しません。

サブスクリプションを読み込めない、未知の項目があると表示される、特定のプロトコルで接続できない場合は、まず出力形式を確認し、次にコアが該当項目に対応しているか調べます。サブスクリプションによっては、サーバー側でClashまたはmihomo向けの出力形式を選ぶ必要があります。別形式のノード一覧をそのまま貼り付けても、クライアントが解析できるとは限りません。

1. 同じ有効なサブスクリプションを読み込み、設定の検証に通ること、プロキシグループとノードの数が内容と一致することを確認します。
2. TLS、SNI、トランスポート方式、UDP対応など、サーバーで必要なプロトコルパラメーターを確認し、内容が分からない項目を独断で削除しないでください。
3. ノードを1つ切り替え、明確なテスト先にアクセスし、接続ログに表示されるルールと送信先を確認します。
4. 解析エラーが出た場合は、エラー全文とコアのバージョンを保存して設定の説明と照合します。問題を覆い隠すために、複数のクライアントを次々と切り替えるのは避けましょう。

サブスクリプションの更新とローカルの上書き設定を区別する

サブスクリプションを更新すると、リモート設定の内容が置き換わることがあります。長期的に残したい直結ドメイン、DNSの調整、ルールは、クライアントが明示的にサポートするローカル上書きやマージ機能に設定しましょう。クライアントごとにマージ順序やスクリプトインターフェースが異なる場合があるため、移行後は改めて動作を確認してください。クライアントのデータディレクトリ全体を、別のクライアントへそのまま上書きしないでください。

TUN対応を比較：権限と復旧手順を確認

TUNは仮想ネットワークインターフェースとルーティング設定を使って、条件に合う通信を制御します。通常はシステムプロキシより広い範囲を扱えますが、有効にしたからといってすべての接続が必ずプロキシを通るわけではありません。除外ルート、アプリごとの振り分け、直結ルール、ほかのVPNによって実際の経路は変わります。通信を制御することと、プロキシノードを経由することは別です。

デスクトップ：サービスを確認してからTUNを有効にする

Windowsでは、クライアントにバックグラウンドサービスのインストールや有効化が必要か確認します。macOSやLinuxでは、クライアントの説明に従ってネットワーク設定に必要な権限を付与してください。管理者権限を常時使うことは、通常のトラブルシューティングの代わりにはなりません。有効化に失敗したら、まずログに権限、インターフェース作成、ルート設定のエラーがないか確認し、そのうえでサービスの再起動を検討します。

• 2つのプログラムが同時にルートを変更しないよう、ほかのクライアントのシステムプロキシとTUNを先に無効にします。
• TUNを有効にしたら、ブラウザー、コマンドライン、実際に使うアプリをそれぞれテストします。
• スリープからの復帰またはネットワークの切り替えを行い、DNSと接続が復旧することを確認します。
• TUNを無効にしてクライアントを終了し、通常のネットワーク通信ができることを確認します。

Android：VPNの許可とバックグラウンド制限を確認

Androidでは通常、システムのVPNインターフェースを使って通信を制御します。同じユーザーまたは仕事用プロファイルでは、通常この種のVPNを2つ同時に有効化できません。初回接続時にシステムの許可を確認してください。画面ロック後に接続が切れる場合は、アプリのバッテリー設定、バックグラウンド実行の許可、常時表示通知を確認します。特定のアプリだけを除外する場合は、クライアントの設定がアプリ単位で通信の制御対象から外すものなのか、ルールで直結させるものなのかを確認してください。両者の働きは異なります。

UDPが必要なゲームや音声アプリでは、ノード、プロトコル、サーバーがUDP転送に対応しているかも確認します。クライアントがTUNに対応していても、サーバー側の機能まで補えるわけではありません。速度測定は成功するのにアプリが使えない場合は、遅延テストを繰り返すのではなく、実際の接続ログを確認してください。

同じポートとルールで試す

2つのクライアントに同じ条件を設定すると、操作性の違いを比較しやすくなります。同じサブスクリプション、ノード、ルールモード、テスト先を使い、クライアントは1つずつ起動してください。以下は設定の理解を助ける部分的なYAML例です。そのまま実行できる完全なサブスクリプションではなく、クライアントが自動生成する項目を上書きする必要もありません。

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

ここでの7890はHTTPとSOCKS5を利用できる混合ポートの例です。実際のポートはクライアントの表示に従ってください。使用中の場合は、7897など空いているポートに変更し、アプリ側のプロキシアドレスも合わせて変更します。allow-lan: falseは、LANにプロキシの入口を公開しない設定です。まずはローカル環境で確認する場合に適しています。

スイッチの表示だけでなく、コマンドラインで接続先を確認する

プロキシの入口を有効にしたら、ターミナルで次のコマンドを実行してHTTPプロキシ経由の通信を確認できます。Windowsのコマンドラインではcurl.exeを明示して実行してください。ほかのOSでは、インストール済みのツール名を指定します。例では当サイトを接続先にしていますが、1回のリクエスト結果だけですべてのアプリの通信状況を判断しないでください。

curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://clash67.com/

このコマンドはプロキシを明示的に使うため、ローカルのプロキシ入口は確認できますが、TUNが機能している証明にはなりません。TUNを検証するには、プロキシ指定の引数を外し、アプリ自体や環境変数に別のプロキシが設定されていないことを確認してから、クライアントの接続ログで接続先、ルール、送信先を確認します。ルールが直結を選んでいる場合、リクエストに成功してもプロキシノードが使えるとは限りません。

4項目を記録してから選ぶ

1. 読み込み：サブスクリプションを更新できるか、エラーから具体的な原因を特定できるか。
2. 通信の振り分け：接続画面に接続先、適用されたルール、実際の送信先が表示されるか。
3. 復旧：クライアントの再起動やネットワーク切り替え後に、設定と接続が想定どおり戻るか。
4. メンテナンス：サブスクリプション更新後もローカルルールが保持され、問題発生時にバックアップから復元できるか。

利用シーンに合わせてクライアントを選ぶ

PC中心で設定を頻繁にメンテナンスする

まずClash Verge Revを試し、設定編集、上書き、サービス管理の使い勝手を確認しましょう。FlClashの操作フローのほうが合う場合は、FlClashを選んでも問題ありません。どちらも一般的なmihomo設定に対応できるなら、画面の装飾よりも「エラーをすぐに見つけられるか」を重視してください。

Android中心でPCはときどき使う

まずFlClashのAndroid版でアプリごとの通信振り分けとバックグラウンド接続の維持を確認し、その後デスクトップ版の操作性を比べましょう。古いAndroidクライアントでサブスクリプションを読み込めても、現在のサブスクリプションに含まれるすべてのプロトコルや拡張設定に対応しているとは限りません。メンテナンス状況、リリースノート、実際のコア情報を確認してから使い続けるか判断してください。

安定した設定から移行する

まず元の設定をエクスポートまたはバックアップし、混合ポート、DNSモード、プロキシグループの選択、ローカルルールを記録します。旧クライアントを終了してから新しいクライアントを起動し、まずシステムプロキシを確認してください。必要な場合にのみTUNを有効にします。新しいクライアントが安定して動作してから旧サービスと自動起動の設定を削除すれば、移行に失敗した場合の切り戻し手段を残せます。