Android版Clashのバックグラウンドで電池が減るときの対策｜電池最適化の対象外設定とバックグラウンド維持

電池消費の増加とバックグラウンド終了を切り分ける

Androidのプロキシクライアントは、長時間動作中にVPNインターフェースを通るパケットを処理し、ルールに応じた振り分けやDNS照会、必要な接続の維持を行います。電池消費は実際の通信量や電波状況、速度テスト、コアの設定によって変わります。ステータスバーにVPNアイコンが表示されていても、端末が常に高負荷とは限りません。

もう一つよくあるのが、画面ロック後にプロキシが切断され、ロック解除後に復旧するケースです。この場合は速度テストの頻度を下げる前に、まずバックグラウンド制限を確認しましょう。クライアントを電池最適化の対象外にするのは、バックグラウンドで動作しやすくするためで、電池消費を直接減らす設定ではありません。動作を許可すると、システム上のバックグラウンド稼働時間が長く記録されることもあります。

再現・比較できる待機テストを行う

システムに表示される「アプリの電池使用率」は、端末全体の電池残量の減少率とは異なります。たとえば端末の電池が合計10ポイント減り、その間の消費の30%をあるアプリが占めていても、そのアプリが電池を30ポイント減らしたという意味ではありません。一部のシステムでは、VPN経由の通信もプロキシアプリの使用量として計上されるため、消費の分類方法は一律ではありません。

一度に変更する項目は一つだけ

1. システムの「設定」→「電池」→「電池使用量」または「電池の使用状況」で、開始時の残量、クライアントのバックグラウンド稼働時間、ネットワークの種類を記録します。
2. 同じWi-Fiと近い開始残量を使い、システム更新、クラウド写真のバックアップ、大容量ファイルのダウンロードを止めて、画面をロックしたまま60分間確認します。
3. 終了時の残量、通信が途切れたか、端末が発熱したか、クライアントの送受信量を記録します。通信量を確認できる画面がない場合は、システムのアプリ別データ使用量を確認してください。
4. 速度テストの間隔を60秒から600秒に変えるなど、変更する項目は一つだけにして同じ条件で観察します。短時間のネットワーク変動を結論と取り違えないよう、少なくとも2回繰り返してください。

ここで示した60分はテスト時間の目安であり、実機で測定した結果ではありません。電池残量は整数で表示されるため、短時間では差が見えないことがあります。より長く確認する場合は、夜間の待機テストも追加してください。モバイル回線とWi-Fiは別々に比較し、電波が弱い環境での再接続による消費を、すべてプロキシコアのせいにしないようにしましょう。

速度テストとヘルスチェック：繰り返しの確認を減らす

「すべて速度テスト」を手動で一度実行するだけなら、通常は単発の処理です。一方、プロキシグループの自動テストやプロキシプロバイダーのヘルスチェックは、定期的に実行される場合があります。設定にurl-testやfallbackのグループ、ヘルスチェックが有効なproxy-providersが複数含まれている場合は、画面上のスイッチ一つだけで判断せず、対象を個別に確認してください。

間隔を60秒から600秒に変更した場合

候補ノードが30個あるグループで、60秒ごとに各ノードを1回ずつ確認すると仮定した場合、単純計算で1時間あたり約1,800回の探測になります。600秒間隔なら約180回です。これは頻度を把握するための概算です。実際の回数は遅延実行、タイムアウト、接続の再利用、コアの実装などで変わり、電池消費が同じ割合で減ることを示すものではありません。

以下はmihomoのプロキシプロバイダー設定の一部です。ヘルスチェックの項目例であり、そのままインポートできる完全な設定ではありません。

health-check:
  enable: true
  url: https://www.gstatic.com/generate_204
  interval: 600
  timeout: 5000
  lazy: true

• interval: 600の単位は秒、timeout: 5000の単位はミリ秒です。混同しないでください。
• lazy: trueを設定すると、そのプロキシプロバイダーが使われていない間、定期チェックが省略される場合があります。動作は使用中のコアの実装に依存し、すべての通信が止まるわけではありません。
• 例に使う探測先は、現在のネットワークとプロキシの出口からアクセスできる必要があります。タイムアウトが続く場合は、間隔を短くして再試行するのではなく、アドレスに到達できるかを調べてください。
• ノードを手動で選べるselectグループでは、速度テストを手動で実行してからノードを選ぶ方法があります。ただし、障害時に手動で切り替える必要があります。

障害時の自動切り替えと探測頻度の低減にはトレードオフがあります。600秒は調整を始める際の目安で、すべてのネットワークに適するとは限りません。サブスクリプション管理機能によっては更新時にローカルの変更が上書きされます。クライアントのオーバーライドや永続化設定を優先し、更新後に実際に適用された設定を確認してください。

DNS・ルール・ログ：異常な再試行を確認する

DNS照会自体は通常のネットワーク処理です。確認が必要なのは、同じドメインの名前解決が繰り返し失敗する、暗号化DNSの接続を確立できない、またはDNSリクエストの送信先への接続に未完了の名前解決が必要で、再試行を繰り返すようなケースです。この場合、接続画面に同じ宛先が何度も表示され、ログにもタイムアウトや名前解決失敗が繰り返し記録されます。

次の順番で確認する

1. クライアントの「ログ」画面で一時的にinfoレベルを選び、1～2分間確認します。繰り返しエラーが出ているのがDNS、ノード接続、ヘルスチェックのどれかを切り分けてください。
2. DNSの上流サーバー、選択中のプロキシノード、関連するルートに到達できるか確認します。DNSリクエストをプロキシ経由に設定している場合は、まずそのプロキシが接続できることを確かめてください。
3. mihomoでrespect-rulesを有効にしている場合は、コアのドキュメントにあるproxy-server-nameserverの要件を確認し、プロキシノードのドメイン解決がプロキシ自身に依存しないようにしてください。
4. 出力が続くdebugログは停止します。原因の特定が終わったら、クライアントの既定レベルに戻すか、対応している場合はwarningを使用してください。

電池消費を抑える目的で、DNSモード、上流サーバー、ルール一式を同時に変更しないでください。何が効果をもたらしたのか判断しにくくなります。fake-ipはDNSと接続を対応付ける仕組みで、省電力専用のスイッチではありません。redir-hostに変更しても、消費電力が下がるとは限りません。まずクライアントに対応した設定を使い、具体的なエラーを解消しましょう。

ルールの数だけで良し悪しは決まりません。ルールが多いという理由だけで必要なルールを削除すると、本来は直接接続する大容量通信までプロキシ経由になり、かえって処理負荷が増えることがあります。必要な通信だけを振り分ければ不要な転送を減らせますが、変更後はルール名だけで判断せず、アプリが実際にどの経路を使うか確認してください。

電池最適化の対象外設定とメーカー別のバックグラウンド維持

画面ロック後も継続して通信する必要がある場合に限り、バックグラウンド制限を段階的に解除してください。まずクライアントの電池設定でバックグラウンド動作を許可し、画面をロックしてテストします。それでも終了する場合は、自動起動やタスクの固定を確認しましょう。以下は一般的な設定場所です。OSのバージョン、地域、機種によってメニュー名は異なります。見つからない場合は、設定画面で「電池の最適化」「自動起動」「バックグラウンド動作」などを検索してください。

最近使ったアプリ画面での「ロック」は補助的な機能にすぎず、電池最適化の対象外設定とは異なります。また、すべてのシステム制限を解除できるわけではありません。省電力モードや超省電力モード、システムのクリーナー、バックグラウンド通信制限もVPNサービスに影響することがあります。それぞれ個別に確認し、端末全体の電池管理を一度にすべて無効にしないでください。

常駐通知・VPN・TUNモードの違い

Androidクライアントは通常、システムのVpnServiceを使って仮想ネットワークインターフェースを作成し、対象となるアプリの通信をコアに渡して処理します。システムプロキシのアドレスを使うデスクトップ版とは仕組みが異なるため、デスクトップ版の「TUNをオフにしてシステムプロキシだけを使う」という設定をAndroidにそのまま当てはめることはできません。また、AndroidのVPNアイコンは、特定のリモートプロキシプロトコルを使っていることを示すものではありません。

サービス通知は維持し、更新頻度を下げる

動作中のVPNサービスは通常、フォアグラウンドサービス通知を表示します。静的な通知自体は主な電池消費の原因ではありません。毎秒の速度更新、統計の継続的な計算、ログの大量出力などが追加の負荷になり得ます。クライアントに「リアルタイム通信量」「通知の速度表示」「更新間隔」などの設定があれば、まず速度のリアルタイム表示をオフにするか、更新間隔を1秒から5秒に延ばして変化を確認してください。

通常のバックグラウンド設定の代わりに、通知を強制的にブロックしないでください。Android 13以降の通知権限、VPNサービスの状態、メーカー独自のバックグラウンド維持設定は、それぞれ別の項目です。通知を非表示にしてもサービスが停止するとは限りません。動作状況を確認するには、クライアントのサービス状態とシステムのVPN画面を確認してください。

「常時接続VPN」の有効化は慎重に

一部のシステムでは、「設定」→「ネットワークとインターネット」→「VPN」からクライアント横の設定ボタンを開き、「常時接続VPN」を有効にできます。これはVPNの利用状態を維持するための設定で、省電力機能ではなく、ノードの障害も解決しません。「VPNなしの接続をブロック」を有効にすると、VPNが使えない間は対象の通信が遮断されます。接続できなくなる可能性を理解したうえで設定してください。

また、一般的な使い方では、同時に有効にできるVPNサービスは通常一つです。ローカルVPNを使う広告ブロッカー、パケットキャプチャツール、ほかのVPNクライアントがプロキシクライアントと競合し、接続先が切り替わることがあります。サービスが何度も切断される場合は、バックグラウンド権限を追加する前に、こうした競合がないか確認してください。

設定変更後の確認と元に戻す方法

優先順位は、異常な通信やエラーを調べ、繰り返しの速度テストやログの負荷を減らし、最後に画面ロック後の切断状況に応じてバックグラウンド維持を設定する、という流れです。待機中の安定性を重視するなら、電池残量だけでなく、必要なアプリが速やかに通信できるかも確認しましょう。

• 待機：同じネットワークで60分間の比較を行い、開始・終了時の電池残量と通信量を記録します。システムのアプリ別電池消費ランキングだけで判断しないでください。
• ネットワーク切り替え：Wi-Fiからモバイルデータ通信に切り替え、さらにWi-Fiに戻します。クライアントが接続を復旧できるか、ログにエラーが続いていないか確認してください。
• 画面ロック：普段必要なメッセージ受信、同期、Web接続が行えるか確認します。バックグラウンドで動くアプリ自体もシステムの制限を受ける場合があります。
• 設定の更新：サブスクリプションの更新後に、ヘルスチェックの間隔、DNS、ログレベルを再確認し、永続化したオーバーライドが引き続き適用されているか確認します。
• 元に戻す：探測頻度を下げたことで障害時の切り替えが遅くなった場合は、間隔を短く戻します。電池最適化の対象外にしても安定性が改善しない場合は、不要な権限を取り消してください。

通信がほとんどない状態でも明らかな発熱が続く場合は、クライアント、コア、OSのバージョンと短時間のエラーログを記録し、該当プロジェクトに報告してください。ログを公開する前に、サブスクリプションURL、トークン、ノードの認証情報、個人のアクセス履歴を削除しましょう。設定のインポートや基本的な使い方は利用ガイドをご覧ください。接続に関するよくある問題はFAQのトラブルシューティングをご確認ください。