Clash Androidのバッテリー消費が異常に多いときの対処法：バックグラウンド維持・メーカーの省電力機能・VPN常時接続

まずバッテリー消費の原因を切り分ける

Androidのステータスバーに鍵やVPNのアイコンが表示されても、システムがVPNServiceの通信経路を維持していることしか分からず、Clashのコアが高負荷で動き続けている証拠にはなりません。mihomoのコア、クライアント画面、モバイル通信、Wi-Fiスキャン、プロキシ経由のアプリは、それぞれ別の電池使用項目として計上されます。調査前に「一晩で20％減った」という現象を、再現可能なデータに分解しましょう。

比較できる8時間テストを行う

1. バッテリーを80％以上まで充電し、ゲーム、クラウドフォトのバックアップ、システムアップデートを停止します。
2. 現在のネットワーク種別、電波強度、Clashのモード、選択中のノード、設定の更新日時を記録します。
3. 1日目はClashを終了し、画面をロックしたまま8時間放置して、減少した割合を記録します。
4. 2日目は同じ場所でClashを有効にし、同じWi-Fiとノードを使って、再び8時間放置します。
5. 「設定」→「バッテリー」→「バッテリー使用量」を開き、Clash、Androidシステム、モバイルネットワーク、主なアプリの使用割合をそれぞれ確認します。

たとえば、Clashを終了した状態で8時間に3％、有効にすると6％減った場合、追加の3ポイントをプロキシ経路とその復帰処理にかかる概算コストとみなせます。2回の結果が4％と19％で、「モバイルネットワーク」が最上位なら、すぐにプロキシルールを変更せず、まず電波の弱さやWi-Fi切断を確認してください。

システムツールでバックグラウンド動作を確認する

Android 14とAndroid 15ではメーカーによってメニュー名が変わりますが、通常は「設定」→「バッテリー」→「バッテリー使用量」からClashを開き、フォアグラウンド時間とバックグラウンド時間を確認できます。バックグラウンド時間が一晩に近いことは、VPN常時接続では正常な状態です。異常の目安は、画面ロック後もCPU使用率が高い、端末が温かい状態を保つ、またはClashの消費グラフが連続して急上昇することです。

ADB環境がある場合は、パソコンからシステム統計も確認できます。以下のコマンドでクライアント設定が変更されることはありません。

adb shell dumpsys batterystats
adb shell dumpsys deviceidle
adb shell dumpsys connectivity
adb shell dumpsys vpn_management

Androidのバージョンによって利用できるサービス項目は異なります。最後のコマンドでサービスが見つからないと表示された場合は、前の2つだけで構いません。画面ロック中のウェイクアップ回数、ネットワーク動作、Dozeの状態を重視し、一時的なCPU値だけで判断しないでください。

まず高頻度の速度テストと自動更新を止める

バッテリー消費の原因は、通常の通信転送ではなく、クライアントがバックグラウンドでURL-Test、サブスクリプション更新、ノードのヘルスチェックを繰り返しているケースも少なくありません。速度テスト1回で、プロキシグループ内の複数ノードに接続することがあります。1グループに80ノードあり、間隔を60秒にすると、理論上は1時間に数千回の接続試行が発生する可能性があります。電波が弱い環境では、タイムアウトと再試行によって無線通信モジュールの稼働時間がさらに延びます。

プロキシグループの速度テスト間隔を確認する

現在の設定を開き、type: url-test、type: fallback、type: load-balanceを含むプロキシグループを探します。よく使われる項目は次のとおりです。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - ノードA
      - ノードB
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

interval: 600は600秒ごとにチェックする設定で、スマートフォンの常時接続には60秒より適しています。mihomoのlazy: trueを使うと、プロキシグループが長時間使われていないときに不要な検出を減らせます。各項目がクライアントの設定エディターで保持されるかどうかは、書き出したYAMLを基準に確認してください。サブスクリプションによっては、更新のたびにローカルの変更が上書きされます。

クライアントによってメニュー名は異なります。よくある入口は「設定」→「現在の設定」→「上書き」、または「設定」→「サブスクリプション」→「自動更新」です。画面上でサブスクリプションの更新間隔しか設定できない場合、プロキシグループの速度テスト間隔は設定の提供元またはローカルの上書き設定で変更します。

ルールの規模とDNS処理の負荷を抑える

Clashのルール照合は、スマートフォンの常時接続における主な消費電力ではありません。ただし、設定ファイルが大きすぎる、ルールセットを頻繁に更新する、DNS問い合わせが何度もフォールバックするといった状況では、メモリ使用量とネットワークの復帰処理が増えます。複数のルールを重複して読み込んでいる場合や、実際の通信判定に使わないproviderを大量に有効にしている場合に起きやすい問題です。

重複ルールと過剰な更新を減らす

設定ログを開き、起動時に読み込まれるrule-providerの数を確認します。同じドメイン集合を、リモートルールセット、インラインのDOMAIN-SUFFIX、スクリプトによる上書きの3通りで重複させないでください。リモートルールセットの更新周期は内容の変化頻度に合わせます。広告や一般的なドメインリストなら12～24時間で通常は十分で、位置情報データベースを毎日更新しても実用上のメリットはありません。

rule-providers:
  common-direct:
    type: http
    behavior: domain
    interval: 86400
    path: ./ruleset/common-direct.yaml

interval: 86400は24時間を表します。ルールプロバイダーのダウンロードはクライアントまたはコアが開始するため、頻繁な更新はネットワークを復帰させ、ストレージへの書き込みも発生させます。設定が1時間ごとの更新になっていて、ルールファイル自体が数週間変わらないなら、周期をそのまま延長してください。

DNSのループと失敗時の再試行を確認する

DNS設定の異常は、ウェブページの初回表示が遅い、ログにtimeoutが繰り返し出る、待機中もクライアントが名前解決を続ける、といった形で現れます。Fake-IPモードはルールによる振り分けに適しており、それ自体が高消費電力という意味ではありません。確認すべきなのは、nameserverに到達できない、fallbackが何度もタイムアウトする、DoHアドレスが自身のドメイン名を先に解決する必要があるため依存関係が循環するといった問題です。

• ドメイン形式のDoHサーバーには、到達可能なbootstrapの名前解決経路を設定します。
• システムのプライベートDNS、ブラウザーのセキュアDNS、Clash DNSに同種の転送を何層も重ねないでください。
• LAN内のDNSが、スマートフォン上のClashの待受ポートへ問い合わせを戻していないことを確認します。
• ログに3秒や5秒のタイムアウトが繰り返し出る場合は、到達できない上流DNSを先に置き換えてください。単純に同時接続するサーバー数を増やすのは避けます。

一般的なmixed-portは7890ですが、AndroidクライアントがVPNServiceで通信を引き受ける場合、通常はアプリ側でこのポートを手入力する必要はありません。ブラウザーに127.0.0.1:7890を追加設定したうえでシステムVPNも使うと、通信経路が複雑になる可能性があります。部分的なプロキシをテストしている場合を除き、アプリの通信は1つの入口だけを通してください。

TUN、VPNService、常時表示アイコンの使い分け

AndroidのClash系クライアントは通常、システムのVPNServiceで仮想ネットワークインターフェースを作成し、通信をmihomoのコアに渡します。ステータスバーにVPNアイコンが表示され続けるのはシステムの動作です。プロキシを有効にしている間は、このサービスが存在し続ける必要があります。通知を無理に隠したり、プロセスを凍結したり、定期的にバックグラウンドを終了させたりすると、かえってトンネルの再構築が頻発することがあります。

一日中常時接続する価値があるケース

• メッセージ、コラボレーション、開発サービスを常にルールどおりに振り分けたい。
• Wi-Fiとモバイルデータを頻繁に切り替えるため、プロキシ経路を自動復旧したい。
• 直連ルールがあり、通信の大半が中国本土のトラフィックとして遠隔ノードを経由しない。
• クライアントで速度テストとサブスクリプション更新の周期を適切に設定している。

固定したアプリで短時間だけプロキシを使うなら、必要なときだけ有効にするほうが省電力です。一日中常時接続する価値は接続の継続性にあり、通信速度が上がることではありません。Clashを終了するとシステムはVPNインターフェースを解除します。再度有効にしたとき、既存のTCP接続が再構築されることがありますが、正常な動作です。

通常のVPNと「常時接続VPN」

Android標準設定では通常、「設定」→「ネットワークとインターネット」→「VPN」→Clashの項目にある歯車ボタンから「常時接続VPN」を確認できます。メーカー独自のシステムでは、「接続と共有」→「VPN」などに配置されている場合もあります。有効にすると、システムはこのVPNアプリを継続的に起動しようとします。同時に「VPNなしの接続をブロック」を有効にすると、Clashの起動に失敗した際、ほかのアプリが完全にオフラインになる可能性があります。

TUNモードはより広範囲のTCP・UDP通信を引き受けるため、システムのHTTPプロキシに従わないアプリに適しています。Androidクライアントでは、VPNServiceが通常すでにTUNの接続を担っているため、デスクトップ版の「システムプロキシ＋TUN」という組み合わせをそのまま適用しないでください。クライアントに「LANをバイパス」「選択したアプリのみプロキシ」「アプリごとのプロキシ」がある場合は、それらで処理範囲を絞ることを優先します。

メーカー別のバックグラウンド許可設定

システムによるバックグラウンド終了と、常時高いバッテリー消費は正反対の問題です。許可リストの目的はプロセスが誤って終了されるのを防ぐことで、すべての権限を無条件に許可することではありません。まず自動起動とバックグラウンド動作を許可し、24時間様子を見ます。画面ロック後もトンネルが切れる場合に限り、バッテリー最適化を追加で調整してください。

システムのバージョン、地域、端末モデルによってメニュー名は変わります。該当する項目が見つからない場合は、設定の検索欄で「バッテリー最適化」「バックグラウンド動作」「自動起動」を検索してください。変更後に画面を30分ロックし、別の端末からスマートフォンへメッセージを送ります。その後、Wi-Fiとモバイルデータを一度切り替え、VPNアイコンとネットワーク接続が途切れないか確認します。

最近使ったアプリ画面の「アプリをロック」は、ワンタップの一括終了を防ぐだけで、システムのバッテリー許可リストの代わりにはなりません。逆に、Clashを許可リストへ追加した後も最近使ったアプリを頻繁に手動で消去すると、フォアグラウンドサービスが中断されることがあります。安定した設定では、このように互いに干渉する操作をできるだけ減らしてください。

ログから異常な接続と再起動ループを特定する

画面ロック後に端末が熱くなる場合は、Clashのログ画面を開き、時刻順に並べ替えます。通常の待機中でも、少数の接続、ルールセットの確認、ネットワーク変更の記録は発生します。異常時は、同じエラーが数秒おきに繰り返されることが多いです。

繰り返し記録される4種類のエラーを確認する

1. DNS timeout：上流の名前解決先に到達できず、コアが待機しながら別のサーバーを試しています。
2. connection refused：ローカルポートまたはリモートサービスが接続を拒否しており、アプリが短い間隔で再試行しています。
3. network changed：Wi-Fiの電波状態が悪い、またはデュアルSIMのデータ通信切り替えによってトンネルが繰り返し再構築されています。
4. provider update failed：サブスクリプションまたはルールセットのアドレスに到達できず、更新周期も短すぎます。

まずログレベルをinfoに保ちます。debugやtraceはログ書き込みが増えるため、短時間の再現確認に限って使ってください。5～10分記録したら通常のレベルに戻し、エラーが発生した時刻、ネットワーク種別、該当アプリを保存します。

アプリごとのプロキシも切り分けに使えます。まずClashの処理対象をブラウザーだけにして、画面ロック後の状態を確認します。消費電力が正常に戻ったら、ソーシャル、動画、同期ツールを段階的に追加してください。あるグループを追加した後にバックグラウンド接続が明らかに増えた場合は、そのアプリ群のプッシュ通知、自動再生、クラウドバックアップ、ポーリング設定を確認します。プロキシは接続を転送しますが、通信の発生頻度は通常、各アプリが決めています。

低リスクから影響の大きい順に確認する手順

十数個のスイッチを同時に変更しないでください。どの手順が効いたのか判断できなくなります。次の順番で実施し、各手順を少なくとも8時間の待機サイクルで観察します。

1. Clashを終了した状態と有効にした状態の待機時基準を作り、追加で減った割合を確認します。
2. URL-Testの間隔を600秒以上に延ばし、サブスクリプション更新を12～24時間に変更します。
3. クライアントの遅延パネルを閉じ、ログレベルをinfoに戻します。
4. DNS timeout、providerの更新失敗、ネットワーク切り替えのループを確認します。
5. 重複するルールセットを整理し、ルールプロバイダーの周期を86400秒に変更します。
6. アプリごとのプロキシで、バックグラウンド接続を継続的に発生させているアプリを特定します。
7. Clashのバックグラウンド動作と自動起動を許可し、省電力機能によるサービスの繰り返し終了を防ぎます。
8. 一日中の接続が本当に必要な場合に限り、システムの「常時接続VPN」を有効にします。

最後に、クライアントのバージョンと設定の互換性も確認します。mihomoベースのクライアントをアップデートした直後に古い設定でクラッシュや再起動ループが起きる場合は、まず設定を書き出し、ノード1つ、プロキシグループ1つ、基本のMATCHルールだけを含む最小構成を新しく作成します。最小構成で待機が正常なら、原因は元の設定に絞れます。最小構成でも異常が続く場合は、クライアントのバージョン、システムのVPN権限、メーカーのバックグラウンド制御を確認します。

Androidでプロキシを常時接続する適切な目標は、VPNServiceが安定し、画面ロック後も接続が途切れず、速度テストと更新が低頻度で実行され、端末が継続的に発熱しないことです。バックグラウンド時間が長いことは、高消費電力と同じではありません。VPNアイコンが常に表示されても故障とは限りません。比較テスト、ログ、項目ごとの変更で原因を特定するほうが、プロセスを何度も終了するより早く安定した結果にたどり着けます。