Clash Androidのバッテリー消費が激しいときの対処法｜バックグラウンド動作・ヘルスチェック間隔・省電力設定

通信転送による消費と待機中の異常を切り分ける

AndroidでClashを有効にすると、バッテリー使用量の一覧でVPNクライアントの割合が高くなることがあります。だからといって、クライアント自体が常に高負荷で動いているとは限りません。AndroidではVPN経由の通信がアプリ別の通信量や消費電力の推定に影響します。動画視聴やダウンロード、同期による通信負荷の一部がVPNアプリに計上される場合もあります。アプリの順位だけで判断せず、端末全体のバッテリー消費、画面の使用時間、ネットワークの種類、クライアントのログをあわせて確認しましょう。

この記事は、Clash Meta for Androidなど、Mihomoコアを使うAndroidクライアントを対象にしています。Clash Verge Revはデスクトップ向けクライアントです。サービスモードやシステムプロキシの設定を、そのままスマートフォンに当てはめることはできません。Androidでは通常、VpnServiceがローカルVPNインターフェースを作成し、通信を処理します。他のプラットフォームではバックグラウンド動作や設定メニューが異なるため、以下のAndroid向けバッテリー設定はiOSには適用できません。

比較できるバッテリー記録を取る

同じネットワークで3パターンを比較

Androidの「設定」→「バッテリー」→「バッテリー使用量」を開き、対象クライアントのアプリ詳細を確認します。システムによっては「電池使用量」や「アプリのバッテリー管理」と表示されます。テスト前後のバッテリー残量と、前景・バックグラウンドでの動作時間を記録します。モバイルネットワークのアクティブ時間が表示される場合は、それも記録しましょう。

1. 基準パターン：プロキシサービスを停止し、安定したWi-Fiに接続して画面をロックしたまま60分待ち、端末全体のバッテリー残量の変化を記録します。
2. 現在の設定パターン：プロキシサービスを再開し、同じWi-Fi、アプリの同期設定、画面ロック時間を保ちます。手動で速度測定は行いません。
3. 設定変更パターン：ヘルスチェック間隔を延ばす、またはバックグラウンド設定を変更するなど、一項目だけ変更して再度60分テストします。

テスト中は充電せず、サブスクリプションの取得、アプリの更新、音楽や動画の再生も同時に行わないでください。モバイル通信の電波が弱いと、モデムの消費電力がプロキシ処理を大きく上回ることがあります。安定したWi-Fiでのテストと、電波の弱い5G環境でのテストをそのまま比較しないでください。バッテリー残量は整数単位でしか表示されないため、60分の結果に差が出ない場合は3～6時間に延長し、複数回試してください。

このような短時間の順次テストでも、温度やバックグラウンド処理、バッテリー残量の範囲に影響されます。原因の方向性を探るには役立ちますが、特定の設定で必ず省電力になると証明できるものではありません。後から差を再現できるよう、各テストで使ったサブスクリプション設定とクライアントのバージョンを記録してください。

ヘルスチェック間隔：ノード数と重複チェックを確認

ヘルスチェックでは、指定したURLへの接続を通じてノードの利用可否や遅延を調べます。通常、チェックごとに接続を確立し、HTTPSの場合はTLSの通信も発生します。ノード数が多く、間隔が短いほどネットワーク通信の頻度は上がります。モバイル通信では、小さなリクエストが頻繁に発生することで無線モジュールの稼働時間が延びる場合もあります。

混同しやすい3種類の間隔を区別する

• proxy-providers 内の interval：リモートのノードプロバイダーを更新する間隔です。ノードの速度測定間隔ではありません。
• health-check.interval：ノードプロバイダーのヘルスチェック間隔です。単位は秒です。
• url-testやfallbackなどのプロキシグループ内にあるinterval：各グループが独自の仕組みでチェックを行う間隔です。providerの設定だけを変更しても、すべてのチェックが減るとは限りません。

たとえば、100個のノードを60秒ごとに一巡チェックする場合、「ノードごとに1回」という単純なモデルでは、1時間あたり約6,000回の試行になります。600秒に変更すると約600回です。この計算は規模感を示すためのもので、実際の送信回数を表すものではありません。実際の動作は遅延チェック、ノードの利用状況、タイムアウト、コアの実装にも左右されます。

まずは600秒に設定し、手動での連続測定は避ける

スマートフォンで普段使いする場合は、関連する自動チェック間隔をまず600秒に設定し、ノード障害時の切り替えが要件を満たすか確認しましょう。ネットワークが頻繁に変わる環境では300秒、接続先が固定で安定している場合は1,800秒も検討できます。間隔を長くすると障害の検知も遅くなり得るため、最長の間隔が常に最適とは限りません。

# 既存の proxy-providers 内で、該当するプロバイダーに統合します。
# 既存の type、url、path、サブスクリプション更新用 interval はそのままにします。
# この断片は、そのままインポートできる完全なサブスクリプションではありません。
proxy-providers:
  mobile:
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
      timeout: 5000
      lazy: true

intervalの単位は秒、timeoutの単位はミリ秒です。lazy: trueを設定すると、未使用のプロバイダーに対する定期チェックを減らせますが、すべてのプロキシグループのチェックが停止するわけではありません。元の設定でプロバイダー名がmobile以外の場合は、新しい項目を追加するのではなく、既存の項目を編集してください。サブスクリプションURLのない項目を新たに作成しないようにしましょう。

変更前に設定をバックアップしてください。サブスクリプション更新で上書きされないよう、クライアントが対応しているローカルオーバーライド機能を優先します。保存して設定を再読み込みしたら、ログを一時的に確認して読み込みに成功したことを確かめ、次回のチェック時刻を目安に変更が反映されたか確認します。省電力設定の効果を調べるために「すべてのノードをテスト」を連続で実行しないでください。テスト負荷が新たに加わります。

バックグラウンド動作：常時プロキシに必要な権限だけ許可する

AndroidのVpnService権限は「VPNを確立できるか」を決め、バッテリー設定は「バックグラウンドのプロセスをどう動かすか」を制御します。両者は別のものです。VPNの使用を許可していても、画面ロック後にメーカー独自のバックグラウンド管理で制限されることがあります。反対に、バッテリー制限を解除しても、無効なノードやDNSの設定ミスは解決しません。

切断の症状に合わせて設定する

• 常時プロキシを使用し、画面ロック後にサービスが終了する：アプリアイコンを長押し →「アプリ情報」→「バッテリー」または「アプリのバッテリー使用量」→「制限なし」に設定します。機種によっては「バックグラウンドでの実行」や「自動起動」も有効にする必要があります。
• サービスが安定し、画面ロック中も切断されない：まずは現在のバックグラウンド設定を維持します。関連アプリすべてに一律で権限を許可する必要はありません。
• 短時間だけ使う：作業が終わったらクライアント内でプロキシサービスを停止します。画面を閉じたり、最近使ったアプリの一覧からスワイプして消したりするだけでは、VPNが停止しないことがあります。

Android 13や14などでも、設定画面の名称や場所はメーカーによって異なります。設定内で「バッテリー最適化」「バックグラウンド実行」「自動起動」を検索して項目を探してください。最近使ったアプリの画面でのロックは一部メーカー独自の機能です。VpnServiceの権限を代替するものではなく、システムによるプロセス終了を完全に防ぐ保証もありません。

VPNを常時接続に設定している場合は、「設定」→「ネットワークとインターネット」→「VPN」から対象アプリの横にある設定ボタンを確認してください。「VPNなしの接続をブロック」を有効にすると、サービス停止時に通常のインターネット接続も遮断されることがあります。VPN以外の通信を明確に遮断したい場合に使う設定であり、省電力機能ではありません。

DNSとルール：タイムアウトの原因を調べ、Fake-IPへ安易に切り替えない

DNS設定の誤りは、Webページの読み込みが長時間終わらない、アプリが何度も更新される、ログに名前解決のタイムアウトが繰り返し記録される、といった症状に現れます。電力消費につながるのはリクエストや接続の再試行であり、「特定のDNSモードは本質的に電力を多く使う」というわけではありません。Fake-IPは合成アドレスを使ってドメインとの対応関係を保ち、後続の接続やルール判定に利用します。実IPモードに切り替えても、到達できない上流DNSサーバーの問題が自動的に解決するわけではありません。

1. まず発生時刻の関連を確認：クライアントの「ログ」画面で一時的にinfoレベルを使い、問題のあるアプリを開きます。DNSタイムアウト、接続タイムアウト、同じドメインへの接続失敗が繰り返し記録されていないか確認してください。
2. 上流サーバーへの到達性を確認：DNSサーバーに想定した経路で接続できるか確認します。特に、プロキシ経由でのアクセスが必要な暗号化DNSでは、プロキシノードのドメイン名がまだ解決できていないために、DNSへ接続できなくなっていないか確認してください。
3. システムのプライベートDNSを確認：Androidの「設定」→「ネットワークとインターネット」→「プライベートDNS」が、一部の名前解決経路に影響することがあります。元の設定を記録してから、一度に一項目だけ変更して比較してください。コア側のDNSとシステムDNSを同時に変更しないでください。
4. ルールの適用結果を確認：ルールは記載順に評価され、通常は最初に一致したルールで通信先が決まります。通信量の多いアプリが不安定なノードに誤って割り当てられると、接続を繰り返し直すことになります。まずルールかプロキシグループの選択を修正してください。

「名前解決を速くする」ためにDNSの上流サーバーを大量に追加しないでください。設定によっては複数サーバーへ同時に問い合わせるため、上流が増えてもリクエストが減るとは限りません。現在の設定で問題がない場合は、出所の不明なDNS設定を一式コピーするのではなく、誤った経路を減らすことを優先します。バッテリー持ちのテストでキャッシュを一括消去するのも避けてください。初回の名前解決や新しい接続が増えます。

アプリ別VPN、ログ、ネットワーク切り替えの使い分け

アプリ別VPNとDIRECTルールは別の仕組み

クライアントにアプリ別VPN機能がある場合、必要なアプリだけをVPNに接続できます。Androidのアプリ別VPNは、VPNインターフェースの段階で対象アプリを限定します。一方、DIRECTルールは通常、通信がコアに渡った後で直接接続するかを選びます。処理経路が異なるため、DIRECTルールを「クライアントを完全に経由しない設定」と考えることはできません。

「選択したアプリのみプロキシ」を使う場合は、ブラウザー、メッセージ通知、ログイン画面への遷移、ファイルのダウンロードを実際にテストしてください。アプリがシステムのダウンロード機能や別のアプリに処理を委ねることがあり、対象アプリを絞りすぎると関連する通信が異なる経路を通る場合があります。業務、金融機関、社内ネットワークで使う場合は、それぞれのネットワーク利用ルールにも従ってください。

調査後は診断による負荷を元に戻す

• 一時的に有効にしたdebugログは、infoまたはクライアントの既定レベルに戻します。ログレベルを変えても接続の問題は直りませんが、詳細なログは処理や書き込みの負荷を増やします。
• 常時表示する必要のない接続監視画面は閉じ、画面を点灯し続けて確認するのではなく、画面ロック中のテストを行います。画面の更新やディスプレイの消費電力が結果に影響します。
• サブスクリプションの自動更新頻度を確認します。頻繁な更新が不要なら、12時間または24時間ごとにすることを検討できます。これは600秒のヘルスチェックとは別の設定です。
• Wi-Fiとモバイルネットワークを切り替えた後は、以前の接続が再確立されるまで待ちます。電波の弱い場所だけで問題が起きる場合は、まず安定したWi-Fiで比較し、サブスクリプション全体をすぐに変更しないでください。

モバイル端末でVPNを使った通信の取り込みと、デスクトップのTUNモードは、どちらも仮想ネットワークインターフェースを使いますが、設定する場所は異なります。デスクトップ版の「システムプロキシを無効化してTUNを有効にする」といった手順を、そのまま適用しないでください。Androidではまず、VPNサービスの状態、アプリ別の対象範囲、使用中の設定が一致しているか確認します。

症状に合わせて設定を絞り、復元できる状態を保つ

調査を始める際の設定例：ルールモードを維持し、動作確認済みのノードを使います。関連する自動ヘルスチェックはまず600秒に設定し、画面ロック中に実際に切断が起きる場合だけバッテリー制限を解除します。調査が終わったら、通常のログレベルに戻します。これは比較の出発点であり、すべてのスマートフォンに適した固定値ではありません。

一度に変更する設定は一種類に絞り、変更時刻と元に戻す方法を記録してください。問題を報告する際は、スマートフォンの機種、Androidのバージョン、クライアントとコアのバージョン、ネットワークの種類、画面ロック中のテスト時間、機密情報を削除したエラーログを添えてください。サブスクリプションURL、アクセストークン、ノードの認証情報は公開しないでください。バッテリー消費ランキングのスクリーンショットより、再現可能な記録のほうが原因を特定しやすくなります。