AndroidでClashを起動すると電池の減りが異常に速い？バックグラウンド動作と省電力設定の確認リスト

Android版のClashクライアントは通常、システムのVPNインターフェースを通じて通信を処理します。ステータスバーに鍵アイコンが表示された後は、接続、DNSクエリ、ルール照合を継続的に処理するため、バッテリー使用量にバックグラウンド動作が長時間記録されるのは正常です。確認すべきなのは異常な増加です。待機1時間で5%以上減る、本体が継続的に発熱する、夜間8時間で15%以上減る、またはネットワーク切り替え後にアプリが何度も再起動するといった場合は、原因を切り分けます。

電池消費は、システムのバッテリー一覧に表示されるアプリ別の割合だけで判断できません。たとえば一定時間の総消費量が4%で、Clashがその30%を占めていても、実際の消費は約1.2ポイントです。総消費量が25%に達して初めて、同じ割合でも優先的に対処する価値があります。確認前に総バッテリー残量、画面使用時間、ネットワーク種別、テスト時間を記録し、設定は一項目ずつ変更してください。

まず電池消費がクライアント由来かネットワーク環境由来かを判断する

3つのテストで問題を切り分ける

すぐに再インストールするより、条件をそろえた3種類の比較テストを行う方が効果的です。各テストは45～60分以上続け、画面の明るさ、ネットワーク、前面で動かすアプリを同じにします。

Clashをオフ：システム本来の電池消費を記録し、モバイル回線の電波、Wi-Fi、他のアプリ自体に異常がないか確認します。
Clashをオンにして待機：動画を再生したり速度テストを実行したりせず、VPN常駐による増分だけを観察します。
Clashをオンにして通常使用：Web閲覧、メッセージの送受信、または画質を固定した動画再生を行い、高トラフィック時の状態を確認します。

たとえばClashをオフにすると1時間あたり1.5%減り、オンにして待機すると2.2%減る場合、差分の0.7ポイントは通常許容できる範囲です。オンにした後に1時間あたり6%減り、本体温度も30℃から38℃へ上がるなら、遅延テスト、接続リトライ、ログ、DNSを確認してください。モバイルデータの電波が1～2本しかない場合、モデムは送信出力を上げるため、プロキシをオフにしても電池を大きく消費することがあります。

Androidのバッテリー履歴を確認する

標準AndroidやPixelでは、「設定」→「バッテリー」→「バッテリー使用量」を開き、クライアントの前面・バックグラウンド時間を確認します。システムによって直近24時間を集計する場合と、最後に満充電した時点から集計する場合があります。比較するときは、必ず同じ集計期間を使ってください。

バックグラウンド時間は長いが、1時間あたりの電池変化が小さい：VPNサービスが正常に常駐している可能性が高いです。
バックグラウンド時間が長く、CPU使用状況と温度も上昇している：速度テスト、ログ、再接続を優先的に確認します。
Clashの使用割合は高くないのに「モバイルネットワークの待機」が高い：まず電波環境を確認します。
画面をオフにすると接続が頻繁に切れる：多くの場合、メーカー独自のバックグラウンド制限が原因で、カーネルの高負荷とは限りません。

遅延テストの頻度とプロキシグループを確認する

クライアントの「自動速度テスト」は一度きりの処理ではありません。URL-Test、Fallback、Load-Balanceグループは、一定間隔でテストURLにアクセスし、ノードの遅延や可用性を判定できます。サブスクリプションに80ノードあり、3つのプロキシグループがそれぞれ独立して確認すると、1回のチェックで100件以上の接続が発生することがあります。間隔を30秒に設定すると、待機中もネットワークとCPUが繰り返し起動します。

チェック間隔を実用的な範囲に調整する

普段のモバイル利用では、まず600秒、つまり10分を設定します。ネットワークの変化が少ない場合は900秒まで延ばせます。障害時の切り替えを速くしたいFallbackグループだけは300秒にしても構いませんが、すべてのプロキシグループを30秒や60秒で動かすのは避けてください。「すべてを速度テスト」を手動で実行すると接続が一斉に作られるため、確認中は連続操作しないでください。

proxy-providers:
  mobile-nodes:
    type: http
    url: https://example.invalid/subscription
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
      lazy: true

interval: 86400はサブスクリプションプロバイダーの更新間隔を秒単位で指定し、ヘルスチェックのinterval: 600はノードの検査間隔を指定します。用途は異なります。mihomoが対応するlazy: trueを使うと、未使用プロバイダーへの能動的なチェックを減らせますが、クライアントのバージョンと設定形式がこの項目に対応している必要があります。

重複する自動選択グループを減らす

設定内にある複数のURL-Testグループが、同じノード群を含んでいないか確認します。「自動選択」「ストリーミング自動」「ダウンロード自動」がすべてのノードを対象にすると、各グループが独自の検査状態を維持します。モバイルでは汎用の自動グループを1つ残し、特定サービスには固定ノードまたは長い検査間隔を使うとよいでしょう。ノード数を120個から、普段使う15～30個に絞るだけでも、1回あたりの検査規模を減らせます。

TUNの常駐とシステムVPNの負荷

AndroidクライアントのTUNは通常、システムのVpnService上に構築されます。アプリが仮想ネットワークインターフェースのパケットを読み取り、mihomoカーネルへ渡して処理します。1つのアプリだけにHTTPプロキシを設定する場合と比べ、TUNはより多くのアプリやプロトコルを対象にするため、バックグラウンドサービスが常駐する必要があります。ただしAndroidのClash系クライアントの多くはもともとVPNインターフェースに依存しています。画面上の「TUN」スイッチの意味はクライアントの実装によって異なるため、デスクトップのシステムプロキシの概念をそのまま当てはめないでください。

まず処理対象のアプリを絞る

クライアントに「アプリごとのプロキシ」「アプリプロキシ」「アクセス制御」がある場合は、ブラウザー、チャットツール、プロキシが必要なアプリだけを選択できます。銀行、地図、カメラの同期、LAN経由の画面共有など、明らかに直接接続するアプリは除外できます。これによりカーネルを通過する接続が減り、VPNを検知して何度もリトライするアプリの問題も避けやすくなります。

ホワイトリスト方式に切り替える前に、システムコンポーネントがプロキシ経由の通信に依存していないか確認してください。アプリストア、WebView、ダウンロードマネージャーは、独立したシステムプロセスから接続することがあります。変更後は、Webページの表示、ファイルのダウンロード、メッセージ通知、アプリの更新をテストし、ブラウザーだけが通信できるかで判断しないでください。

不要な常時機能をオフにする

LAN共有：スマートフォンを他の機器のプロキシサーバーとして使わない場合は、「LAN接続を許可」をオフにします。
外部コントローラー：リモートパネルを使わない場合は、コントローラーを127.0.0.1:9090に限定し、すべてのネットワークインターフェースで待ち受けないようにします。
トラフィックパネルの更新：確認中はリアルタイム接続画面を閉じます。接続数や速度を毎秒更新すると、前面でのCPU使用量が増えます。
詳細ログ：普段はwarningまたはerrorを選びます。debugログは短時間の原因特定向けで、終日有効にするものではありません。
テザリング共有：スマートフォンのテザリング経由でプロキシを共有しない場合は、関連する転送オプションをオフにします。

mixed-port: 7890
external-controller: 127.0.0.1:9090
log-level: warning
allow-lan: false

mixed-port: 7890はローカルHTTPとSOCKSの混合ポートにすぎず、それ自体が大量の電池を継続的に消費するわけではありません。注意すべきなのは、他のアプリがポートへ絶えずアクセスしていないか、またコントロールパネルが接続データを継続的に取得していないかです。

ルール、DNS、スニッフィングを簡素化する

ルール数がそのまま電池消費に比例するわけではありません。mihomoはルールのインデックスを作成するため、数万件のドメインルールでも安定稼働後に大きな負荷が出るとは限りません。よりよくある原因は、ルールプロバイダーの頻繁な更新、設定の繰り返しリロード、DNSリクエストのループ、またはスニッフィングとアプリ独自の暗号化DNSの干渉です。

ルールプロバイダーは1時間または1日単位で更新する

広告、ストリーミング、地域別ルールは通常、毎分更新する必要がありません。よく使うルールプロバイダーは43200秒または86400秒に設定できます。更新時にはファイルのダウンロード、内容の解析、ルールの置き換えが行われるため、複数のプロバイダーを短い間隔で同時更新すると、待機中にも周期的なCPU使用率のピークが発生します。

rule-providers:
  direct-list:
    type: http
    behavior: domain
    format: mrs
    interval: 86400
    path: ./ruleset/direct.mrs
    url: https://example.invalid/rules/direct.mrs

バイナリ形式のルールを使うと読み込みサイズを減らせますが、ルールソースと現在のmihomoのバージョンに互換性があることが前提です。インポート後にルールの読み込みに失敗した場合は、クライアントが対応するYAML、text、mrs形式に戻してください。ファイル拡張子を変えるだけでは解決しません。

DNSループと重複した名前解決を確認する

クライアントのDNSがローカルアドレスを指し、上流の暗号化DNSも誤って同じローカルポートへ戻されると、クエリループが発生することがあります。ログにtimeout、context deadline exceeded、exchange failedが連続して表示され、待機中もスマートフォンが発熱するのが典型的な症状です。まずクライアントのデフォルトDNS設定を使い、その後カスタム上流を1つずつ追加してください。

通常のDNSは53番ポート、DoTは853番ポート、DoHは通常443番ポートを使います。
Bootstrap DNSはDoHサーバーのドメインを直接解決できる必要があり、まだ確立していないプロキシチェーンに依存してはいけません。
安定した上流を1つと予備を1つ用意すれば、通常は十分です。10台以上のサーバーを同時に設定する必要はありません。
Fake-IP、Redir-Host、スニッフィングの設定を変更した後は、古い接続をいったん削除してクライアントを再起動してください。

ドメインスニッフィングは、接続に対応するドメインをカーネルが識別し、ドメインルールを適用するのに役立ちます。ただしスニッフィングを必要としない設定では、対象ポートやプロトコルをすべて広げても効果があるとは限りません。ログにsniff failedが繰り返し表示される場合は、まずクライアントのデフォルトのスニッフィング範囲に戻し、1時間の電池消費とルールのヒット状況を観察します。

メーカー独自のバックグラウンド制御で再起動ループを防ぐ

「Clashを起動すると電池が減る」というケースの多くは、システムがVPNサービスを繰り返し終了し、その後クライアントが「常時接続VPN」や自動起動機能によって再起動されることが原因です。完全な再起動のたびに設定、ルール、DNSキャッシュが再読み込みされます。数分おきにこの処理を繰り返す方が、安定して常駐させるより電池を消費し、メッセージの遅延やWebページの一時的な切断も招きます。

標準AndroidとPixel

「設定」→「アプリ」→「すべてのアプリを表示」→クライアントを選択→「アプリのバッテリー使用量」を開き、バックグラウンド使用を許可します。「最適化」と「制限なし」が表示される場合、接続が頻繁に切れるときは、まず1日「制限なし」でテストしてください。常駐時間はわずかに増える可能性がありますが、強制終了と再起動の繰り返しを防げます。

Xiaomi HyperOS

一般的な手順は「設定」→「アプリ設定」→「アプリ管理」→クライアントを選択→「バッテリーセーバー」→「制限なし」です。その後、アプリ情報または権限管理で「自動起動」も確認します。最近のタスク画面でアプリをロックするだけでは、バックグラウンド制御の代わりにはなりません。HyperOSのバージョンによってメニュー名は多少異なる場合があります。

OPPO、OnePlus、realme

ColorOS系では通常、「設定」→「アプリ」→「アプリ管理」→クライアントを選択→「バッテリー使用量」でバックグラウンド動作を許可できます。「設定」→「バッテリー」→「その他の設定」にあるスリープ待機最適化も確認してください。夜間だけ切断する場合は、まずスリープ関連の項目をテストします。

Samsung One UI

「設定」→「バッテリー」→「バックグラウンド使用制限」を開き、クライアントが「ディープスリープ中のアプリ」に入っていないことを確認します。長時間接続する場合は「自動的にスリープしないアプリ」に追加できます。同時に「設定」→「接続」→「その他の接続設定」→「VPN」で現在のVPN設定も確認してください。

システムのVPN設定を競合させない

Androidの「常時接続VPN」は、プロキシを継続的に動作させたい場合に適しています。「VPNを使用しない接続をブロック」は、より厳格な設定です。VPNの再起動中は、すべてのネットワーク通信が停止する可能性があります。クライアント自体が不安定な状態で両方を有効にすると、通信切断がさらに目立ちます。確認中はまず厳格なブロックをオフにし、通常のVPNだけを残して接続が安定することを確認してから、必要に応じて戻してください。

順番に実行する省電力設定リスト

以下では、リスクが低く効果が分かりやすい項目から順に紹介します。各項目を変更したら少なくとも60分観察し、夜間の電池消費を確認する場合は6～8時間通してテストしてください。

連続した手動速度テストを停止し、自動ヘルスチェックを600秒に設定する。
サブスクリプションの更新間隔を86400秒、ルールプロバイダーを43200秒または86400秒に設定する。
重複する自動選択グループを削除し、普段使うノードを15～30個に絞る。
ログレベルをdebugからwarningに変更し、リアルタイム接続画面とトラフィックパネルを閉じる。
LAN共有、テザリング転送、不要な外部コントローラーの待ち受けをオフにする。
アプリごとのプロキシを有効にし、プロキシが必要なアプリだけを処理対象にする。
デフォルトDNSに戻してテストし、カスタムDoH、DoT、Fake-IP設定の問題を切り分ける。
システム設定でクライアントのバックグラウンド動作を許可し、VPNサービスの再起動ループを防ぐ。
Wi-Fiとモバイルデータを別々にテストし、弱い電波によるモデムの電池消費を確認する。
最後にクライアントのバージョン変更や、設定を整理して再インポートする方法を検討する。

さらに詳しく調べる場合はADBを使う

Androidのデバッグツールに慣れている場合は、まずバッテリー統計をリセットし、決めた手順でテストしてから結果を出力します。スマートフォンでは開発者向けオプションとUSBデバッグを有効にし、コマンドはパソコンで実行します。

adb shell dumpsys batterystats --reset
adb shell dumpsys batterystats
adb shell dumpsys activity services

1つ目のコマンドは現在のバッテリー統計をリセットするため、テスト開始前に実行します。2つ目はウェイクアップ、ネットワーク、プロセスの動作を確認するためのものです。3つ目ではVPNサービスが繰り返し作成されていないか確認できます。比較するのは、同じクライアントの変更前後におけるウェイクアップ回数と稼働時間です。異なる機種の絶対値をそのまま比較しないでください。

発熱や電池減りが続く場合に確認する異常

基本的な最適化を終えても待機1時間で5%以上減る場合は、ログのタイムラインを確認します。同じエラーが継続している場合は、アプリ別の消費割合だけを見るより原因特定につながりやすいです。

ノード接続がタイムアウト：現在のノードに到達できず、クライアントまたはアプリがリトライを続けています。安定したノードへ切り替え、失敗するノードを自動グループから外します。
サブスクリプションの解析に失敗：サブスクリプションの内容とクライアントの形式が互換性を持たず、バックグラウンド更新が毎回失敗しています。まず自動更新を一時停止し、サブスクリプション形式を確認します。
ルールファイルのダウンロードに失敗：ルールURLへのアクセスにプロキシが必要なのに、プロキシがまだ確立していないため、起動時にリクエストを繰り返している可能性があります。
DNSがタイムアウト：到達可能な上流へ変更し、プライベートDNS、クライアントDNS、ブラウザーのセキュアDNSが重複して処理していないか確認します。
VPNサービスが繰り返し起動：他のVPN、通信高速化アプリ、ファイアウォール、ローカルフィルタリングアプリをオフにします。Androidでは通常、同時に有効にできるVpnServiceは1つだけです。
設定が頻繁にリロード：設定ディレクトリをファイル同期ツールが継続的に書き換えていないか確認し、変更検知による繰り返し読み込みを防ぎます。

クライアントを更新する前に現在の設定をエクスポートし、再現条件を記録してください。FlClashなどmihomoベースのクライアントでは、カーネルの更新によって互換性の問題が修正されることがありますが、新旧バージョンではTUN、DNS、ルールの動作が異なる場合があります。更新後はまず基本的なサブスクリプションを1つだけインポートしてテストし、旧バージョンで使っていた実験的なパラメーターをすぐにすべて追加しないでください。

目標は、システムのバッテリー画面からClashを完全に消すことではありません。バックグラウンド動作の変動を小さくし、画面オフ後も本体が発熱せず、VPNが再起動を繰り返さず、通常の待機時に追加で消費する電池を1時間あたり約0.5～1.5ポイントに抑えることです。実際の結果は、バッテリーの劣化状態、5Gの電波、ノードの遅延、通信量にも左右されます。同じスマートフォンで変更前後を比較してください。