Android版Clashクライアントおすすめ5選：主要アプリを比較して選ぶ

結論から見る：クライアントの違いは画面だけではない

AndroidでClashクライアントを選ぶとき、最初に確認すべきなのはテーマカラーではなく、コア、設定形式、メンテナンス状況です。同じサブスクリプションを別のクライアントに読み込んでもノード数は一致することがありますが、利用できるプロトコル、ルールセットの読み込み方式、TUNの適用範囲、DNSの挙動は異なる場合があります。クライアントの画面はサブスクリプション管理、システムVPNの許可、状態表示を担い、ノードの解析とルールの実行を担当するのはコアです。

通常のサブスクリプションを読み込んですぐ使いたいなら、操作手順が短く、コア情報が明確なClash Plusが候補です。Mihomoの拡張フィールドを使う場合や、TUN、Fake-IP、ルールセット、オーバーライドを細かく調整したい場合は、Clash Meta for AndroidとFlClashを比較するとよいでしょう。Android、Windows、macOSで似た操作感を保ちたいなら、FlClashのクロスプラットフォームUIが移行しやすい選択肢です。Surfboardは対応形式のサブスクリプションをすでに持っているユーザー向けで、すべてのClash YAMLが完全互換だと考えてはいけません。Clash for Androidは主に旧端末や過去の設定を確認するための基準であり、新規インストールの長期運用には向きません。

5つのクライアントの位置づけ

コアのバージョンとプロトコル対応を比較する方法

アプリのバージョンとコアのバージョンは別々の番号です。たとえばクライアントにアプリバージョン2.xが表示され、コアの画面には別途Mihomo v1.19.xと表示されることがあります。設定の対応可否を判断するときは、後者を主な基準にします。画面にサブスクリプションボタンが追加されたからといって、コアにも新しいプロトコルが追加されたとは限りません。逆に、コアがすでに対応している新しいフィールドでも、グラフィカルな設定画面にスイッチが用意されておらず、YAMLやオーバーライド設定からのみ有効化できる場合があります。

Clash Plus：短い操作手順

Clash Plusは、サブスクリプション、プロキシ、起動操作といった日常的な手順をまとめて扱える点が特徴です。一般的には「設定」→「設定を新規作成」→「URLから読み込む」と進み、その後「プロキシ」でプロキシグループを選び、ホーム画面に戻ってVPNを起動します。サブスクリプションにproxy-groups、rules、rule-providers、dnsが含まれている場合は、読み込み後にプロキシグループ、ルール数、DNSの設定をそれぞれ確認してください。ノード一覧が表示されたかだけで判断してはいけません。

このタイプのクライアントは、1日に一度程度ノードを切り替え、ruleモードを使い、基盤パラメータを頻繁に変更しない端末に適しています。インストールパッケージを選ぶ際はCPUアーキテクチャも確認しましょう。近年の主流スマートフォンは通常arm64-v8aを採用していますが、古い端末ではarmeabi-v7aの場合があります。アーキテクチャが合わないパッケージを選ぶと、Androidは実行時に自動変換するのではなく、通常そのままインストールを拒否します。

Clash Meta for Android：パラメータを確認しやすい

Clash Meta for AndroidはMihomoの設定体系を対象としており、mixed-port、allow-lan、external-controller、TUNスタック、DNSの拡張モードを確認したい場合に適しています。一般的な確認手順は「設定」→「コア」で現在のコア名とバージョンを確認し、その後「設定」→「ネットワーク」または設定のオーバーライド画面でTUNとDNSのパラメータを確認します。メニュー名はバージョンによって変わりますが、コア情報はアプリ内で確認できる必要があります。

サブスクリプションでsniffer、geodata-mode、rule-providers、またはMihomo拡張プロトコルを使っている場合は、まずここで構文を検証してください。起動に失敗したら、ログに最初に出るerrorを確認するほうが、ノードを何度も切り替えるより効果的です。よくある原因には、ルールセットURLにアクセスできない、プロキシグループが存在しないノード名を参照している、YAMLのインデントが誤っている、旧フィールドが現在のコアと互換性を持たない、といったものがあります。

FlClash：クロスプラットフォームでの一貫性

FlClashは、クロスプラットフォームのUIで設定、プロキシグループ、接続、ログを整理します。Androidとデスクトップで画面構成が近いため、スマートフォンとPCを同時に管理するユーザーに適しています。一般的な手順は「設定」→「追加」でサブスクリプションを読み込み、「プロキシ」でポリシーを選び、「ツール」または「設定」でコア情報を確認します。学習した操作を複数デバイスで応用できるのが利点である一方、Android専用の簡易クライアントより画面階層は多くなります。

クロスプラットフォームだからといって、設定状態が自動同期されるわけではありません。スマートフォンとPCはそれぞれローカル設定を保存するため、サブスクリプションの更新時刻、プロキシグループの選択、オーバーライド項目が異なる場合があります。サブスクリプションの更新間隔は24時間に統一し、各デバイスで自動更新を個別に確認することをおすすめします。新しい設定に切り替えた後は、現在有効な設定名も確認し、片方だけ更新されてもう片方が古いスナップショットを使い続ける事態を避けてください。

Surfboard：まず形式の対応範囲を確認

Surfboardはモバイル向けのルールプロキシツールですが、任意のClash YAMLをそのままMihomoに実行させるものではありません。サービス提供元がClash、Surge、Surfboardなど複数のサブスクリプション入口を用意している場合は、Surfboardと明記された入口を選びます。Clash YAMLしか提供されていない場合は、ノードプロトコル、プロキシグループ、ルールを対象バージョンが認識できるか先に確認してください。

検証は「読み込み成功」で終わりにできません。少なくとも3点を確認します。ノード数がサブスクリプション側と大きく違わないか、プロキシグループが完全に表示されるか、ルールモードで直結ドメインとプロキシ対象ドメインが想定どおり処理されるかです。元の設定がrule-providers、スクリプト、Mihomo専用フィールドに依存している場合、直接読み込むとフィールドが無視されたり、挙動が変わったりすることがあります。

Clash for Android：過去の基準

Clash for Androidはかつて広く使われたAndroid向けフロントエンドですが、元のプロジェクトはすでにメンテナンスを終了しています。古いスマートフォンには動作するバージョンやローカル設定が残っている可能性があるため、移行時の参考にはなります。移行ではアプリのデータディレクトリ全体をコピーするのではなく、サブスクリプションURL、プロキシグループの選択、アプリのバイパスリスト、カスタムオーバーライドをエクスポートまたは記録することが重要です。

旧版の設定で従来のClashフィールドを使っている場合は、まずメンテナンス中のMihomoクライアントに読み込み、ログを項目ごとに確認します。旧クライアントと新クライアントを同時に起動しないでください。Androidでは通常、同時にアクティブにできる一般的なVPNサービスは1つだけです。2つ目のクライアントを起動すると、先に接続していたクライアントが置き換えられるか、中断されます。

サブスクリプションの互換性はノード数だけで判断できない

有効な互換性テストでは、少なくともノード解析、プロキシグループ、ルール、DNS、TUNの5項目を確認します。ノード一覧が表示された時点で互換性ありと判断すると、最も重要なトラフィック分岐の違いを見落としやすくなります。以下は、クライアントが実際に解析する階層を理解するための、一般的なMihomo設定の骨格です。

mixed-port: 7890
mode: rule
allow-lan: false

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

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

mixed-port: 7890は、ローカルプロキシポートへ明示的に接続するアプリにのみ影響します。AndroidでVpnServiceからTUNを起動すると、クライアントはより多くのアプリの通信をコアへ送るため、各アプリに127.0.0.1:7890を個別入力する必要はありません。クライアントがコントロールポートも公開している場合、一般的な値は9090ですが、アクセス制御を理解しないままLANリスニングを有効にするのは避けてください。

5項目の読み込みチェック

1. ノード解析：よく使うノードが不明なタイプとして表示されていないことを確認します。少なくとも異なるプロトコルのノードを2つ無作為にテストし、それぞれ遅延テストと実際のWebアクセスを行います。
2. プロキシグループ：select、url-test、fallbackなどのグループが存在し、グループ内の参照が完全であることを確認します。ノードが存在してもプロキシグループが空なら、ルールは有効な出口を取得できません。
3. ルールの読み込み：ログでルールセットのダウンロード結果を確認します。リモートのrule-providerの初回読み込みに失敗すると、クライアントが末尾のMATCHへフォールバックし、すべての通信が同じ経路を通ることがあります。
4. DNSの挙動：ドメイン名と直接IPアドレスを分けてテストします。ドメイン名だけ失敗してIPではアクセスできる場合は、DNSリスナー、Private DNS、Fake-IP、システムキャッシュを確認し、ノードを替え続けないでください。
5. TUNの適用：ブラウザー、ターミナル、アプリストア、システムプロキシを参照しないアプリを1つテストします。ブラウザーだけ使える場合は、通常は明示的なプロキシだけが有効で、他の通信にはTUNが適用されていません。

UI、消費電力、バックグラウンド安定性の実測項目

UIの「使いやすさ」は、測定できる手順に置き換えて考えます。クライアントを開き、サブスクリプションを更新し、プロキシグループを選び、VPNを起動してログを確認するまでを1回の切り替えとします。4〜6回のタップで完了すれば、日常利用には十分です。複雑なクライアントにある追加画面は、接続詳細、オーバーライド、コアパラメータのためのもので、プロキシ速度が速いことを意味しません。

再現可能なテスト方法

テスト端末は Android 15、arm64-v8a、メモリ 8 GB に固定し、ほかの VPN と Private DNS を無効にします。テスト用設定には 240 個のノード、8 個のプロキシグループ、ローカルおよびリモートのルール約 14000 件を含めます。各クライアントをコールドスタートで 3 回起動し、アイコンをタップしてからプロキシグループを操作できるまでの時間を記録します。VPN 起動後は 30 分間放置し、その後のバッテリー消費量と再接続回数を記録します。

• コールドスタートが2.0 s未満：日常の切り替えで遅さを感じにくい。
• コールドスタートが2.0–4.0 s：大規模な設定でも許容範囲。
• バックグラウンドで30 min放置中に何度も切断・再接続する：まずシステムのバッテリー最適化を確認し、すぐにコアが原因だと決めつけない。
• 継続的な遅延テストの間隔が60 s未満：ネットワークのウェイクアップ回数が増え、モバイル通信では影響が大きくなります。
• ログを長時間debugに設定したままにしない：トラブル対応が終わったらinfoまたはwarningに戻します。

端末が異なる場合、消費電力の絶対値を直接比較することはできません。メーカーのバックグラウンド制御、基地局の電波状況、ノードのRTT、アプリの通信量によって結果が変わります。より信頼できる方法は、同じスマートフォン、同じ設定、同じネットワークで連続テストすることです。画面消灯から約5分でクライアントが停止する場合は、Androidの「設定」→「アプリ」→対象クライアント→「アプリのバッテリー使用量」を開き、バックグラウンド権限を許可に変更します。一部のシステムでは「設定」→「バッテリー」→「バックグラウンド使用の制限」で深いスリープの対象から外す必要もあります。

TUNパラメータの選び方

Androidユーザーの多くは、stack: mixedとauto-route: trueから始められます。特定のアプリで接続異常が起きた場合は、systemまたはgvisorを個別に試し、一度に変更するパラメータは1つにします。複数のスイッチを同時に変えると、ログを比較できなくなります。厳格なルーティングを有効にした後は、LANデバイス、テザリング、IPv6が想定どおり動作するかも確認してください。

Androidでは、全体的なバイパスよりアプリ単位のトラフィック分岐が適しています。一般的な手順はクライアントの「設定」→「ネットワーク」→「アクセス制御」または「アプリ別プロキシ」で、プロキシを使うアプリ、または除外するアプリを選びます。決済、LAN制御、企業認証アプリは直接接続が必要な場合がありますが、対象リストは実際のネットワークで確認し、他人のリストをそのままコピーしないでください。

用途別の最終選択

初めて使うなら：Clash Plus

目的がサブスクリプションの読み込み、ノードの選択、システムVPNの確立であれば、Clash Plusは日常的な設定画面に近い階層で操作できます。選ぶ際は、インストールパッケージのアーキテクチャ、Androidの最低対応バージョン、アプリ内に表示されるコアバージョンを確認してください。読み込み後はruleモードを維持し、まずサブスクリプションに含まれるルールを使い、大量のオーバーライドをすぐに追加しないようにします。

複雑なMihomo設定：Clash Meta for Android

拡張プロトコル、ルールセット、DNS、TUNスタック、ログの詳細を確認する必要がある場合は、Mihomoコアの状態を明確に表示できるクライアントを優先します。設定を管理する側は、ノード1つ、プロキシグループ1つ、ルール3つだけを残した最小テスト設定も用意すると、サブスクリプション側の問題とクライアント側の問題を切り分けやすくなります。

スマートフォンとPCを併用：FlClash

クロスプラットフォームで使うユーザーは、画面の位置や操作モデルが揃っていることを重視しがちです。FlClashは統一された入口として適していますが、サブスクリプションの更新とローカルオーバーライドは各端末で確認する必要があります。デスクトップではシステムプロキシ、AndroidではVpnServiceを使う場合があり、通信の取り込み方は異なります。PCで正常に動作したからといって、スマートフォンのTUNも必ず正常だとは限りません。

サービス提供元に専用入口があるなら：Surfboard

サブスクリプション管理画面にSurfboard形式が明記され、主な目的がモバイルでのルール分岐であれば、対応する入口をそのまま使えます。管理画面にClashまたはMihomo設定しかない場合は、まず小規模なテストでプロキシグループ、ルール、DNSの挙動を確認してから、長期利用するか判断してください。

旧版Clash for Androidを使い続けている：移行を計画

旧クライアントが動き続けていることは、新しい環境の基盤として適していることを意味しません。移行前に有効なサブスクリプション、プロキシグループの選択、アプリのバイパスリストを記録し、新しいクライアントへ改めて読み込みます。2つのクライアントを同時に起動しないでください。ブラウザー、ターミナル、ストリーミング、LANアクセスのテストが完了してから、旧設定を削除します。

インストール後10分で行うチェックリスト

1. 「設定」→「概要」または「コア」を開き、アプリのバージョンとコアのバージョンを記録する。
2. サブスクリプションURLから設定を読み込み、手動で一度更新する。
3. ノード数、プロキシグループ数、ルールセットの読み込み状態を確認する。
4. ruleモードを選び、末尾に利用可能なフォールバックルールがあることを確認する。
5. クライアントを起動し、Androidに表示されるVPN接続リクエストを許可する。
6. 直結サイトとプロキシ経由サイトを1つずつ開き、ルールの適用記録を確認する。
7. システムプロキシを参照しないアプリをテストし、TUNによる取り込みが有効か確認する。
8. 画面をロックして10分後に再びネットワークへアクセスし、バックグラウンド維持を確認する。
9. ログレベルをinfoに戻し、高頻度の自動速度テストを停止する。
10. 元のサブスクリプション入口を保持し、一時的にエクスポートしたYAMLを長期更新元にしない。

Android版Clashクライアントに、あらゆる設定に適した唯一の答えはありません。軽量な日常利用、複雑なコアパラメータ、クロスプラットフォーム管理、専用サブスクリプション形式には、それぞれ適した選択肢があります。同じ設定で10分間のテストを行ってから、起動手順、ログの読みやすさ、バックグラウンドでの安定性を比較するほうが、クライアント名だけを見るより確実です。

クライアントと設定の入口

対応するAndroidインストールパッケージを選ぶか、サブスクリプションの読み込み、VPNの許可、初回接続の手順を確認してください。

ダウンロードページへ 使い方を見る