AndroidでClashを使うと電池の減りが早い？バックグラウンド維持・バッテリー最適化・設定の見直し

まず「通常の通信による消費」か「バックグラウンドでの再起動」かを切り分ける

条件をそろえて比較してから、バッテリー最適化の対象外に設定しましょう。スマートフォンでプロキシを有効にすると、通信の転送や暗号化・復号、ルール判定が加わるため、電池の消費が増えるのは自然です。一方、画面消灯後も発熱が続く、数分おきにサービスが再起動する、モバイル通信で待機中の電池消費が明らかに増える場合は、原因を切り分ける必要があります。制限を一度にすべて解除すれば切断は解消するかもしれませんが、電池消費の原因までなくなったとは限りません。

Android版Clashクライアントは通常、VpnServiceでローカルVPNインターフェースを作成し、選択したアプリの通信をコアに渡して処理します。これはリモートVPNサービスの契約とは別の仕組みです。ステータスバーに鍵のアイコンが表示されても、すべての通信がリモートのプロキシノードを経由するとは限りません。ルールでDIRECTに振り分けられた通信もローカルで転送される場合がありますが、リモートノードは経由しません。

待機中の記録を2回取り、基準値を確認する

「昨日はプロキシを有効にし、今日は無効にした」といった終日の電池残量だけで判断しないでください。アプリの更新、電波状況、画面の明るさも結果に影響します。まずは次の短時間の比較を行い、必要に応じてテスト時間を延ばしましょう。

1. 環境を記録：スマートフォンの機種、Androidのバージョン、クライアントとコアのバージョン、Wi-Fi／モバイル通信の別、開始時と終了時の電池残量を書き留めます。バージョンは通常、クライアントの「このアプリについて」から確認できます。
2. 条件をそろえる：同じWi-Fi、同じ場所、近い電池残量でテストします。システム更新、クラウド写真のバックアップ、大容量ファイルのダウンロードを一時停止し、充電しながら測定しないでください。
3. 1回目はプロキシを無効にする：VPNサービスが停止したことを確認し、画面を消して60分間待機させます。電池残量とバックグラウンドの通信状況を記録します。
4. 2回目はプロキシを有効にする：アプリの状態を同じに保ち、ノードとルールモードを固定してから、60分間待機させます。この間、「すべてのノードを速度テスト」は実行しないでください。
5. 設定を1つだけ変えて再測定：たとえばヘルスチェックの間隔だけを延ばし、ほかの設定は変えずに測定します。少なくとももう一度繰り返し、システムの電池残量表示の丸め誤差を改善効果と取り違えないようにしましょう。

たとえば、プロキシ無効時は80%から79%、有効時は80%から77%になった場合、この2回のテストで差が2ポイントあったとしか言えません。すべてのスマートフォンで1日あたりどれだけ消費するかを推定することはできません。ここで示した数値は記録方法の例であり、クライアントの実測値ではありません。1時間では差が小さすぎる場合は3時間に延ばしてください。モバイル通信の電波が弱い場合は別にテストし、Wi-Fiの結果と混ぜないでください。

バックグラウンド動作：必要な場合だけバッテリー最適化の対象外にする

対象外設定はバックグラウンドでの停止を抑えるためのもので、省電力機能ではありません。画面消灯後に通信が切れる、サービスが終了させられる、何度も起動し直す場合に限り、まずこの設定を見直してください。常駐通知が表示されているだけでは、クライアントが高負荷で動き続けている証拠にはなりません。コアが繰り返し初期化されていないか、接続が頻繁に作り直されていないかを確認しましょう。

Android 14での設定例

標準に近いAndroid 14を例にすると、「設定」→「アプリ」→「すべてのアプリを表示」→Clashクライアント→「アプリのバッテリー使用量」と進み、「制限付き」になっていないか確認します。プロキシを常時使う場合は「制限なし」を試してください。OSの更新によって「バックグラウンドでの使用を許可」など表示名が異なることがあるため、実際の画面に従ってください。

• メーカー独自のバッテリー管理：設定画面で「バッテリー最適化」「バックグラウンド動作」「自動起動」などを検索します。アプリの起動管理機能がある場合は、常時プロキシが必要なクライアントだけに許可し、すべてのアプリを制限対象外にする必要はありません。
• 最近使ったアプリのロック：一部のシステムにはアプリカードをロックする機能があります。手動でアプリを終了するときに誤って閉じるのを防げますが、Android共通のバックグラウンド維持機能ではなく、バッテリー設定の代わりにもなりません。
• 通知とサービスの状態：クライアントの動作状態が見えるようにしておきましょう。Android 13以降では、通知の権限とフォアグラウンドサービスの動作は別の設定です。通知が消えたことだけを根拠にVPNが停止したと判断しないでください。
• 省電力モード：まず、問題がシステムの省電力モード使用中に限って発生するか確認します。テスト中は設定を統一し、一方だけ省電力モードを有効にするといった比較は避けてください。

「常時接続VPN」が必要か確認する

標準的なAndroidでは、「設定」→「ネットワークとインターネット」→「VPN」→対象の設定の横にある歯車アイコンから確認できます。クライアントが対応していれば、「常時接続VPN」と「VPNを使わない接続をブロック」が表示されます。後者はVPNが利用できないときにネットワーク通信を遮断する機能で、ノードの安定性を高める設定ではありません。有効にする前に、切断時の動作を確認してください。システムが仕様どおりに通信を遮断した状態を、DNS障害と誤認しないようにしましょう。

Androidでは通常、各ユーザーまたは仕事用プロファイルで、VpnServiceを使うサービスを同時に1つだけ実行できます。別のVPN型ファイアウォール、フィルター、プロキシアプリを起動すると、現在のサービスが置き換えられることがあります。切断と再接続を繰り返す場合は、バックグラウンド権限をさらに増やすのではなく、競合するアプリがないか確認してください。

ヘルスチェック：まず確認頻度を下げ、必要ならノードを変更する

ノードのチェックでは実際にネットワークリクエストが送信されます。ノード数が多い状態で間隔を短くすると、無線ネットワークの起動や通信の頻度が増えることがあります。特にモバイル通信では、短い間隔でリクエストを繰り返すと無線モジュールが長く動作状態を保つ可能性があります。影響はネットワークや端末によって異なるため、リクエストごとの通信量だけでは判断できません。

mihomoでは、プロキシプロバイダーのヘルスチェックはproxy-providersの下にあるhealth-checkで設定します。以下は既存のプロバイダー定義に追加する部分的な設定例で、完全な設定ファイルではありません。mobile-poolは既存のプロバイダー名に置き換え、既存のtype、URL、pathなどの項目は残してください。

proxy-providers:
  mobile-pool:
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
      lazy: true

• interval: 600：ヘルスチェックの間隔は600秒です。まずは300～600秒程度に設定して様子を見ましょう。最新の遅延時間を表示するために、数十秒ごとにチェックする必要はありません。
• lazy: true：プロバイダーのノードを使用していない間は、定期チェックをスキップします。使用中と判定される条件は、プロキシグループからの参照や実際の使用状況によって異なります。
• url：現在のネットワークから到達でき、ノードでもアクセス可能な、応答の軽いテスト用URLを選びます。URLに到達できないと誤判定につながるため、チェック間隔を短くしても解決しません。

回数の目安を計算してみましょう。1回のチェックで50ノードを調べ、間隔が60秒の場合、理論上は1時間あたり最大約3,000回のノードチェックが発生します。間隔を600秒にすると約300回です。この計算から実際の電池消費量の倍率はわかりません。また、遅延チェックやタイムアウト、ほかのプロキシグループによるチェックも考慮していませんが、設定内で同じ処理が重複していないか確認する手がかりになります。

url-testやfallbackなど、プロキシグループ側のintervalと、クライアントの自動一括速度テストも確認してください。プロバイダーのチェックとプロキシグループのチェックが同時に動作する場合があります。proxy-providersのintervalはサブスクリプションの更新間隔で、ここで扱うヘルスチェックの間隔はhealth-check.intervalです。変更する階層を間違えないようにしてください。

DNSと接続の再試行：繰り返し通信する原因を解消する

DNSの上流サーバーは数が多ければ安定するというものではありません。特定の上流サーバーに長時間到達できない場合や、まだ名前解決が終わっていないプロキシ接続に依存してDNSリクエストを送る場合、アプリが再試行を繰り返すことがあります。ログにi/o timeoutやcontext deadline exceededが続けて記録されたら、対象ドメイン、接続先、発生時刻を記録してください。こうしたエラーは接続やプローブが原因の場合もあるため、エラーメッセージだけでDNS障害と断定できません。

1. 想定した経路が1つだけになっているか確認：クライアントのDNS、Androidの「プライベートDNS」、ほかのフィルターアプリを確認します。標準的なAndroidでは「設定」→「ネットワークとインターネット」→「プライベートDNS」から確認できます。複数箇所を同時に変更しないでください。
2. プライベートDNSを一時的に比較：プロバイダーのホスト名を手動設定している場合は、元の値を記録してから一時的に「自動」に切り替え、現在のVPN経路と競合していないか確認します。テスト後は必要に応じて元の設定に戻してください。
3. mihomoの設定項目を確認：dns.nameserverはデフォルトのDNS上流サーバー、dns.proxy-server-nameserverはプロキシノードのドメイン名解決に使います。後者が必要かどうかは、既存の設定とコアのドキュメントを確認して判断してください。内容をよく確認せずに追加しないようにしましょう。
4. 繰り返しの原因を確認：同じアプリが解決できないドメインに何度もアクセスしている場合は、実際に適用されているルール、ノードの出口、DNSの応答を確認してください。キャッシュを繰り返し消すだけでは解決しません。

fake-ipとredir-hostはDNSの処理方式であり、省電力モードではありません。方式を切り替えるとアプリとの互換性やキャッシュの動作は変わりますが、電池消費が減るとは限りません。現在問題なくウェブサイトにアクセスできているなら、節電だけを目的にDNS設定を大きく変える必要はありません。まず明確なタイムアウトや重複リクエストを解消しましょう。

ルール、TUN、ログ：不要な処理を減らす

ルールモードでも通信がローカルVPNを経由することがある

mode: ruleはルールに基づいて通信の出口を選びます。DIRECTはリモートのプロキシノードを経由しないという意味にすぎません。アプリの通信がAndroidのローカルVPNに入った後も、コアによる処理が行われる場合があります。そのため、「ルールモードにすれば電池を消費しない」とは言えません。ただし、すべての通信を不必要にリモートへ送る場合と比べ、適切に直接接続すれば余分な経路や一部の暗号化処理を減らせます。

クライアントに「アプリごとのプロキシ」や「アプリを除外」する機能があれば、実際の用途に応じて通信を捕捉する範囲を狭められます。ただし、その画面が許可リスト方式なのか除外リスト方式なのかを確認してください。両者の意味は逆です。アプリを除外すると通常、そのアプリの通信はこのプロキシルールの制御を受けなくなるため、接続要件を確認してから変更しましょう。

デスクトップ版TUNの省電力設定をそのまま適用しない

スマートフォンではもともとVPNインターフェースで通信を処理することが多いため、デスクトップの「TUNを無効にしてシステムプロキシだけを使う」という設定を、Android共通の代替手段として考えないでください。ほかの動作モードに対応しているかどうかはクライアントによって異なります。tun.stackの選択肢や動作も、コアや組み込み方によって変わります。項目名だけで選ばず、同じネットワークと使用条件で互換性と電池消費をテストしてください。

調査後は通常のログレベルに戻す

詳細ログを長時間有効にすると、処理とストレージの負荷が増えます。原因を調べる間だけ一時的に詳細ログを有効にし、問題を再現したら必要な部分をエクスポートして、最終的な有効設定のlog-levelをinfoまたはクライアントの元のレベルに戻してください。待機テスト中に、バックグラウンドで接続一覧のリアルタイム更新や速度テストの繰り返しを実行したり、ログ画面をスクロールしたりしないでください。

設定変更後の確認手順

最後に次の手順で確認しましょう。特定のバッテリー使用率の数字を下げるだけでなく、バックグラウンドで安定して動作すること、通信が正常なこと、待機時の消費が許容範囲であることを確かめます。

1. まずバックグラウンド動作を確認：画面を消して30分待ってから点灯し、VPNサービスが動作しているか、通信が正常に復旧するか、ログに再起動が繰り返し記録されていないか確認します。
2. 次に設定を確認：ヘルスチェックの間隔が最終設定に反映されていること、自動一括速度テストが再開していないこと、サブスクリプション更新後も変更が維持されていることを確かめます。
3. 電池消費を再測定：前述の60分間、同じ条件で比較する方法で電池残量の減りと異常な通信を記録します。結果のばらつきが大きい場合は、設定項目をさらに増やすのではなく、測定時間を延ばしてください。
4. 最後に通常の設定へ戻す：一時的に有効にした詳細ログを無効にし、不要なテスト用権限を元に戻します。バックグラウンド動作の安定に本当に必要な設定だけを残してください。

モバイル通信の電池消費がWi-Fiより明らかに多い場合は、電波状況とノードまでの通信経路を確認してください。特定のノードだけタイムアウトが続く場合は、利用可能なノードに固定して再測定します。クライアントを変えても問題が続くなら、システムのネットワーク設定やバックグラウンドアプリも確認しましょう。特定のコアだけを原因と決めつけないでください。

設定のインポート手順を確認する場合は使い方ガイドをご覧ください。オーバーライドが反映されない、DNSがタイムアウトする、ルールの通信先が想定と異なる場合は、詳細設定で項目ごとに確認してください。ログを共有する前に、サブスクリプションURL、アクセストークン、ノードのパスワード、個人の接続履歴を削除してください。