Android版Clashのバッテリー消費が多いときの対処法｜バックグラウンド実行と電池の最適化

Android版Clash系クライアントは、VPN経由のネットワーク通信を継続的に処理します。バッテリー使用量の上位に表示される、画面ロック中に接続が切れる、端末が熱くなるといった場合は、まず原因を3つに分けて考えましょう。通信処理そのものによる消費、VPN通信に対するシステムの電力集計、バックグラウンドで終了した後の再接続です。それぞれ対処法が異なるため、通知を消したり、すべてのバックグラウンド権限を許可したりするだけでは原因を特定できません。

まずバッテリー使用量を確認し、同じ条件で比較する

「設定」→「バッテリー」→「バッテリー使用量」を開き、現在使っているプロキシクライアントを確認します。機種によっては「電池使用量」などの名前になっています。集計期間、画面オン・バックグラウンドの時間、電池残量の変化、Wi-Fiとモバイルネットワークのどちらを使ったかを記録しましょう。クライアントが「今回の集計期間の電池使用量の30%」を占めていても、バッテリー容量全体の30%を消費したという意味ではありません。

VPNはほかのアプリの通信を中継します。Androidのバージョンやメーカーによって通信量・消費電力の集計方法が異なるため、クライアントが上位に表示されても、コアが常に高負荷で動作しているとは限りません。大容量ファイルのダウンロード、クラウド写真のアップロード、動画再生でも順位が上がることがあります。

画面ロック中のテストを2回行い、基準を作る

1. ダウンロード、動画再生、システム更新を停止し、電波の安定した同じWi-Fiを使います。端末の温度を近づけ、充電しながらのテストは避けてください。
2. クライアントを起動し、利用可能なノードを1つ選んで画面をロックします。60分後に、開始時と終了時のバッテリー残量、接続が切れたか、クライアントの通信量が増えたか、ログにエラーがあるかを記録します。
3. 条件を近づけてクライアントを停止し、もう一度60分間画面をロックします。2回のテスト中は、ほかのアプリや同期タスクもできるだけ同じ状態に保ちましょう。
4. 差が1ポイント程度なら、観察時間を延ばしてもう一度テストします。バッテリー残量の表示は大まかな値のため、短時間の差だけでは結論を出せません。

記録例：「プロキシ有効：82% → 79%；プロキシ無効：81% → 79%」。これは記録方法の例であり、実測結果や合格基準ではありません。複数回のテストで再現する余分な消費と、再接続・タイムアウト・異常な通信量が同時に起きているかを確認しましょう。

VPNの常時通知とバックグラウンドサービスの役割

Androidでは通常、VPNによる通信の引き継ぎに VpnService を使って仮想ネットワークインターフェースを作成します。VPNサービスを継続して動作させるには、通常、フォアグラウンドサービスとして実行し、システムに通知を表示する必要があります。通知自体が主な電力消費源ではありません。消費の主な要因は、データ処理、暗号化・復号、ネットワークの起動、接続の再試行です。

• ステータスバーのVPNアイコン：システムにVPN接続があることを示しますが、現在のノードが使えるとは限りません。
• クライアントのサービス通知：動作状態や通信速度、切断ボタンなどを表示します。速度表示の更新頻度が高すぎる場合は、クライアントが対応していれば更新間隔を長くできます。
• バックグラウンド実行の権限：アプリが画面の前面にないときもサービスを動作させるための設定です。通知を表示するかどうかとは別の制御です。

Android 13以降では通知の実行時権限が導入されていますが、フォアグラウンドサービスに関するシステム要件はなくなっていません。アプリの通知をオフにしても省電力になるとは限らず、サービスが安定する保証もありません。原因を調べる間はサービス状態の通知を表示したままにし、画面ロック後もサービスが動作しているか確認しましょう。

「常時接続VPN」はバックグラウンド動作を保証する設定ではない

一般的な設定場所は「設定」→「ネットワークとインターネット」→「VPN」→対象クライアントの設定アイコンです。「常時接続VPN」や「VPNなしの接続をブロック」といった項目が表示される場合があります。前者はVPNの使用状態を維持し、後者はVPNが使えないときに通信を遮断します。どちらも、接続できないノードや誤ったDNS設定を直すものではありません。

電池の最適化対象外にする場合は、使用中のクライアントだけにする

電池の最適化対象外にする設定はバックグラウンド制限への対策であり、直接消費電力を下げるものではありません。目指すのは、サービスが終了した後に接続を何度も作り直す状況を防ぐことです。アプリがCPUを長時間起動状態に保つことではありません。画面ロック中に接続が切れる、サービスが終了する、システムにバックグラウンド制限が表示される場合に限り、設定を一つずつ変更して再テストしましょう。

標準Android・Pixelでよくある設定場所

1. クライアントのアイコンを長押しし、「アプリ情報」→「アプリのバッテリー使用量」を開いてバックグラウンドでの使用を許可します。「制限なし」があれば、バックグラウンド制限が原因かを確認する際に選択できます。
2. 古いバージョンでは「設定」→「アプリ」→「特別なアプリアクセス」→「電池の最適化」が設定場所の場合があります。表示対象を「すべてのアプリ」に切り替え、クライアントを選んで「最適化しない」に設定します。
3. ホーム画面に戻り、プロキシを有効にして画面をロックします。15分後にロックを解除し、サービスが動作し続けているか、新しい接続を確立できるか確認しましょう。

Androidのバージョンによって表示される設定場所は異なり、どちらか一方しかない場合もあります。両方のメニューを探して設定を重ねる必要はありません。「制限なし」にしても切断する場合は、すべてのアプリを最適化対象外にするのではなく、ノード、ネットワーク、ログを確認してください。

メーカー独自のシステムで確認する項目

OSのアップデートで設定名が変わることがあるため、設定内の検索を使いましょう。別メーカーの画面画像と同じボタンを探す必要はありません。最近使ったアプリの画面でアプリを「ロック」しても、一括終了を防げるだけの場合があり、電池の最適化設定の代わりにはなりません。また、自動起動の権限を許可しても、クライアント自体の「起動時に開始」が有効になるとは限りません。再起動後も接続したい場合は、クライアントにその機能があるかも確認してください。

画面ロック中に切断し、バッテリー消費も増える場合は、まず再接続の繰り返しを調べる

サービスが動作していても接続に失敗し続ける場合、バックグラウンド権限を許可すると失敗の再試行が長く続くだけのことがあります。クライアントの「ログ」画面を開き、まず info レベルに設定して、画面ロック前後の時刻を確認します。タイムアウト、ドメイン名の名前解決失敗、接続リセット、コアの再起動が繰り返し記録されていないか調べましょう。

• サービスの再起動：画面ロック後に通知が消え、ロック解除後に起動メッセージが再び表示される場合は、バックグラウンド制限やクライアントのクラッシュを優先して確認します。
• ノードのタイムアウト：サービスは終了していないのに、同じノードへの接続が何度も失敗する場合は、利用できることを確認済みの別ノードに切り替えて、同じ条件でテストします。
• ネットワークの切り替え：Wi-Fiからモバイルネットワークに切り替えたときに接続が途切れる場合は、ネットワーク切り替え処理、電波の弱さ、トンネルの再確立を確認します。電池の最適化が原因だとすぐに判断しないでください。
• 特定アプリの再試行：同期アプリ1つだけが通信を繰り返す場合は、そのアプリのバックグラウンドアップロードと適用されるルールを確認します。

診断中はノードを1つに固定し、自動切り替えによる変数を減らします。多数のノードに対してヘルスチェックを行う設定では、間隔が短すぎるとバックグラウンド通信が増えます。たとえば100個のノードを30秒ごとにテストすると、理論上は1時間に約12,000回のテストリクエストが発生します。実際の回数はクライアントや遅延読み込み、プロキシグループの使用状況によって異なります。

対応する設定があるクライアントでは、不要な高頻度チェックを300秒または600秒に変更し、切り替えの使い勝手を確認できます。この数値がすべてのクライアントに共通する設定項目だとは限りません。サブスクリプションで管理された設定は更新時にローカル変更が上書きされる場合があります。変更を維持するには、クライアントが対応するオーバーライド機能を使いましょう。

TUNとDNS：重複した通信の取り込みと名前解決の再試行を減らす

AndroidのVPN通信取り込みは、デスクトップ版のTUNスイッチとは異なる

デスクトップ向けの解説では、「システムプロキシ」と「TUNモード」を別の設定として比較することがよくあります。一方、Androidクライアントは通常、VPNインターフェースを使って通信を取り込みます。mihomoベースのクライアントでは、TUNのプロトコルスタックや関連項目が表示される場合もありますが、動作はクライアントの実装によって異なります。「TUNをオフにすれば省電力になる」と単純に考えると、プロキシによる通信の取り込みまで止まることがあります。

• まずはクライアントの標準プロトコルスタックを使いましょう。互換性の問題がログやプロジェクトのドキュメントで示されている場合に限り、個別に切り替えてテストしてください。
• 別のローカルVPN、ファイアウォール、通信フィルターアプリが同時に有効になっていないか確認します。一般的な個人設定では、VpnService を使うVPNを2つ同時に維持できません。
• クライアントがアプリごとの通信取り込みに対応している場合は、プロキシを使う必要のない通信量の多いアプリを対象外にできます。変更後は、そのアプリが想定どおり直接通信するか確認してください。

DNSではモード名よりタイムアウトを先に確認する

Fake-IPはマッピング用の仮想アドレスを先に返し、Redir-Hostは実際のアドレス解決を伴います。主な違いは名前解決と接続の処理経路にあり、モード名だけでどちらが省電力かは判断できません。まず確認すべきなのは、上流DNSに接続できない、暗号化DNSの接続に何度も失敗する、プロキシとDNSリゾルバーの間で依存関係が循環しているといった問題です。

1. ログに DNS timeout や名前解決の失敗が繰り返し記録されていないか確認し、失敗するドメインが同じバックグラウンドアプリから発生しているかを調べます。
2. 「設定」→「ネットワークとインターネット」→「プライベートDNS」を確認します。カスタムのホスト名を設定している場合は、一時的に「自動」に戻して比較テストし、必要に応じて元の設定に戻してください。
3. クライアントが使う上流DNSに現在のネットワークから接続できるか確認します。上流DNSをドメイン名で指定している場合は、名前解決に使える経路も必要です。まだ確立されていないプロキシ接続にリゾルバーが依存しないようにしてください。
4. 変更は一度に1か所だけにし、画面ロック中の動作と初めてWebページを開くときの両方を再テストします。DNS、ノード、ルールを同時に変えると、どの変更が効いたのか判断できません。

プライベートDNSとクライアントのDNSの具体的な連携は、Androidのバージョンや通信の取り込み方法によって異なります。常に一方が他方を上書きすると考えないでください。調査が終わったら、一時的に有効にした debug ログを通常のレベルに戻し、頻繁に更新される接続監視画面を閉じましょう。診断ツール自体の処理負荷を抑えられます。

安定して使うためのバックグラウンド設定

テストが終わったら、効果のあった設定だけを残しましょう。日常の設定は「VPNによる通信の取り込みは1つ、利用可能なノード、適切な間隔のヘルスチェック、接続できるDNS、クライアントに必要なバックグラウンド権限のみ許可」から始め、必要に応じて機能を追加します。バックグラウンド動作を維持するためにCPUを起動し続ける補助アプリを入れたり、省電力のためにサービスを何度も強制停止したりするのは避けてください。

変更後の確認項目

1. 画面ロック後の復帰：まず15分間ロックして簡単に確認し、その後1時間観察します。ロック解除後は、開いたままのページを見るだけでなく、新しいWebページを開いてください。
2. ネットワークの切り替え：Wi-Fiからモバイルネットワークへ切り替え、再びWi-Fiに戻します。接続が再確立され、ログにタイムアウトが長時間連続して記録されないことを確認します。
3. バックグラウンド通知：普段使っているメッセージアプリで通知を受信できるか確認し、アプリ自体のバックグラウンド制限とVPNの切断を区別します。
4. バッテリーの再測定：最初のテストと同じ条件で消費量を記録し、少なくとも2回繰り返します。短時間のテスト1回だけで設定の効果を判断しないでください。
5. 再起動後の確認：起動時の接続が必要な場合は、端末を再起動してロックを解除し、クライアントの設定、システムのVPN状態、実際に通信できるかを確認します。

クライアントのサービスが安定し、ログにも問題がないのに、モバイルネットワークでWi-Fiより明らかに電池を消費する場合は、電波強度、5Gの切り替え、上流回線の品質も確認しましょう。プロキシを停止しても発熱が続く場合は、システムのバッテリー画面に戻り、ほかのアプリやハードウェアの状態を調べてください。プロキシの消費と端末全体の消費を分けて検証すれば、関係のない設定を何度も切り替えずに済みます。