Clash Androidのバックグラウンド消費電力が大きい場合の対処法：省電力設定とバックグラウンド維持のバランス

まず、正常な常駐動作か異常な電池消費かを確認する

Clash、Clash Meta for Android、FlClashなどのクライアントは、AndroidのVpnServiceを使ってローカルVPNインターフェースを作成します。ステータスバーに鍵やVPNのアイコンが表示され続けても、インターフェースが有効であることを示すだけで、プロセッサーが常に高負荷で動作しているわけではありません。画面消灯後の安定した接続では、通常、フォアグラウンドサービス、少量の接続状態、必要なネットワークウェイクアップだけが維持されます。

異常な電池消費かどうかを判断するには、電池残量の減少、バックグラウンドでの動作時間、モバイルネットワークの状態を併せて確認します。電池使用量の画面でClashが上位に表示されただけでは、結論は出せません。その時間帯に主に動作していたネットワークアプリがClashだけなら、消費電力の割合が高くなるのは自然です。

条件を固定して8時間の基準値を測定する

電池残量を80%以上まで充電し、測定開始時刻を記録します。
同じWi-Fiまたはモバイルデータ環境を使い、測定中にネットワークを頻繁に切り替えないようにします。
動画再生、ゲーム、クラウドフォトの同期、システムアップデートなど、明らかに負荷の高い処理を停止します。
Clashの接続は維持したまま、手動の速度テストと設定編集画面を閉じ、画面をロックして8時間放置します。
測定終了後、「設定」→「バッテリー」→「バッテリー使用量」を開き、Clashの消費量、バックグラウンド動作時間、システムのアイドル時消費電力を記録します。

電池の状態が正常で容量約5000 mAhの端末を例にすると、安定したWi-Fi環境で画面をロックして8時間置いた際の減少が2%～5%程度なら、通常は個別対応する必要はありません。10%を超えて減少する場合や、電池使用量の画面でクライアントがバックグラウンドで高負荷動作を続けている場合は、遅延テスト、再接続ループ、サブスクリプション更新、TUNパラメータを確認します。チップ、電波強度、OSバージョン、プッシュ通知の数によって結果は変わるため、これらの数値は切り分けの目安であり、すべての端末に共通する基準ではありません。

遅延テストとサブスクリプションの確認頻度を優先的に下げる

バックグラウンドでの電池消費は、VPNインターフェースそのものよりも、周期的なネットワーク処理が原因であることが多いです。ポリシーグループのurl-test、fallback、ロードバランサーのヘルスチェックは、一定間隔でテスト先へアクセスします。ノードが多いほど、1回のテストで必要になるDNS問い合わせ、TCP接続、TLSセッションも増えます。80個のノードを毎分テストする場合と10分ごとにテストする場合では、バックグラウンドでのウェイクアップ回数が桁違いになることがあります。

自動速度テストの間隔を60秒から300～600秒に変更する

ポリシーグループのパラメータを編集できるクライアントでは、「設定」→「オーバーライド」または「設定」→「設定のオーバーライド」にあるヘルスチェック項目を確認します。メニュー名はクライアントによって異なります。ネットワーク環境が日常的に固定されている場合は、intervalを300秒に設定します。ノード数が50を超える場合は、まず600秒を試してください。Wi-Fiとモバイルネットワークを頻繁に切り替える端末では、無効なノードが現在のポリシーに長く残らないよう、300秒に設定します。

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

lazy: trueは、ポリシーグループが実際に使用されていないときに不要なヘルスチェックを減らす設定です。有効になるかどうかは、使用中のカーネルとクライアントがこの設定項目に対応しているかによって決まります。tolerance: 80を設定すると、2つのノードの差が数十ミリ秒しかない場合に頻繁に切り替わるのを防げます。頻繁な切り替えは接続を再構築するため、安定性にも電池消費にもメリットがありません。

手動速度テストをバックグラウンド監視として使わない

ノード一覧の「すべてテスト」は障害確認には適していますが、長時間繰り返し実行する用途には向きません。
1回のテストでは現在のポリシーグループを選択し、サブスクリプション内の全ノードを同時にテストする必要はありません。
テストのタイムアウトは5000 ms前後に設定します。長すぎるタイムアウトは、無効なノードの検出に余計な時間をかける原因になります。
速度テストを3回連続で実行した際のわずかな差は、通常、ネットワークの揺らぎによるものです。その結果だけを理由に、頻繁にノードを切り替える必要はありません。

サブスクリプションの自動更新は数時間～数日単位にする

サブスクリプションの内容は通常、分単位では変わりません。自動更新間隔を1440分、つまり1日1回に設定すれば、多くの利用場面をカバーできます。ノード提供元から短い間隔を明確に指定されている場合は、360分または720分に変更します。更新を15分ごとにすると、設定の再ダウンロード、YAMLの解析、ポリシーグループの再構築が繰り返され、ノードのヘルスチェックが実行されることもあります。

メーカー独自の省電力機能を調整し、プロセス終了後の再接続ループを防ぐ

Clashをバックグラウンドで強制的に制限すると、一見省電力に見えても、逆効果になることがあります。システムがフォアグラウンドサービスを終了すると、クライアントや自動化タスク、ネットワークの変化によって再び起動され、VPNインターフェースが再作成されます。その際、DNSや既存の接続も初期化が必要です。「終了→起動→再接続」が繰り返されると、安定して常駐させるよりもプロセッサーのウェイクアップとネットワークハンドシェイクが増えます。

Android標準環境とPixelシリーズ

「設定」→「アプリ」→「Clashクライアント」→「アプリのバッテリー使用量」を開き、バックグラウンド使用を「許可」に設定します。「最適化」「制限」「制限なし」の3段階が表示される場合、VPNを継続して使用するなら「制限なし」を選択します。Androidのバージョンによっては、「設定」→「アプリ」→「特別なアプリアクセス」→「バッテリーの最適化」に表示されることもあります。

XiaomiとHyperOS搭載端末

「設定」→「アプリ設定」→「アプリ管理」→「Clashクライアント」→「省電力ポリシー」を開き、「制限なし」を選択します。
システムの「セキュリティセンター」→「アプリ管理」→「権限」→「自動起動管理」を開き、クライアントの自動起動を許可します。
最近のタスク画面でクライアントのカードを長押ししてロックし、「すべてクリア」によるサービス終了を防ぎます。

Samsung One UI搭載端末

「設定」→「バッテリー」→「バックグラウンド使用量の制限」を開きます。
クライアントが「ディープスリープ中のアプリ」一覧に入っていないことを確認します。
長時間接続する場合は、クライアントを「自動的にスリープさせないアプリ」に追加します。

OPPO、OnePlus、realme端末

通常は「設定」→「アプリ」→「アプリ管理」→「Clashクライアント」→「バッテリー使用量管理」で「バックグラウンドアクティビティを許可」を有効にします。一部のバージョンでは、「設定」→「アプリ」→「自動起動」から自動起動も許可する必要があります。メニュー名はColorOSやrealme UIのバージョンによって変わるため、システム設定の上部で「バックグラウンドアクティビティ」または「バッテリー最適化」を検索してください。

対象外設定を終えた後は、自動クリーナーを重ねて使用しないでください。安定したバックグラウンド動作の目的は、1つのVPNサービスを低頻度で動かすことであり、数分おきにシステムがサービスを再作成する状態にすることではありません。変更前のログにサービス起動、ネットワーク変更、設定再読み込みが頻繁に記録されていた場合、対象外設定後はこれらが明らかに減るはずです。

用途に応じてTUNモード、システムプロキシ、DNSパラメータを選ぶ

AndroidのClashクライアントは通常、VpnServiceを通じて通信を処理しますが、クライアント内部ではTUNスタック、アプリ別ルーティング、DNS拡張、スニッフィングなどを個別に選べる場合があります。機能が多くても、すべてを有効にする必要はありません。省電力の調整は、実際に必要な通信だけを処理することを基準にします。

よく使うアプリだけをプロキシ経由にするなら、まずアプリ別ルーティングを設定する

ブラウザー、メッセージアプリ、少数のツールだけにプロキシが必要なら、「設定」→「ネットワーク」→「アクセス制御」または「設定」→「VPNサービス」→「アプリ別ルーティング」で対象アプリを選択します。ローカル動画プレーヤー、LANミラーリング、システムバックアップ、大容量ゲームのダウンロードを除外すると、プロキシカーネルで処理する必要のない接続を減らせます。

アクセス制御には通常、「選択したアプリのみ許可」と「選択したアプリを除外」の2つの方式があります。変更後は、プロキシを使うアプリと除外したアプリをそれぞれ1つずつ開いて確認します。意味が反対のリストを同時に有効にしたり、Androidのシステムコンポーネントを一括で除外したりしないでください。DNS問い合わせと実際の接続経路が一致しなくなる可能性があります。

TUNスタックは安定性を優先し、パラメータを一度に重ねて変更しない

mihomoカーネルでよく使われるTUNスタックには、system、gvisor、mixedがあります。選択できる項目は、クライアントとカーネルのバージョンによって異なります。systemはシステムのネットワークスタックを使う傾向があり、処理負荷は通常低めです。gvisorはユーザー空間のネットワークスタックを使うため、一部の互換性問題には有効ですが、処理経路は長くなります。mixedはプロトコルに応じて組み合わせて処理します。すべての端末で最も省電力になる固定の選択肢はありません。

クライアントのデフォルトスタックを維持し、8時間の静置テストを行います。
特定のアプリだけ接続できない、UDPに異常がある、接続が頻繁に切れるといった場合に限り、別のスタックへ切り替えます。
毎回1つのパラメータだけを変更し、古いログを消去してから再接続します。
ウェブページの表示速度だけでなく、電池残量、切断回数、ログに記録されたエラーを比較します。

DNSとスニッフィングの設定は必要最小限にする

fake-ipはドメインに対応するアドレスを返し、カーネルがその対応関係を使ってルールを照合します。これ自体が高い電池消費を意味するわけではありませんが、大量のルール、重複したDNS問い合わせ、到達できない上流DNS、継続的なタイムアウトはバックグラウンド動作を増やします。電池消費に異常がある場合は、ログにDNS timeout、fallbackの再試行、同一ドメインへの高頻度な問い合わせが繰り返し記録されていないか確認します。

ドメインスニッフィングは、接続からドメイン情報を復元する機能で、ドメインを直接取得できない通信に役立ちます。現在のルールで正しく照合でき、透過的な通信処理にも問題がないなら、設定項目を揃えるためだけに対象ポートやプロトコルの範囲を広げる必要はありません。不要な機能を無効化または縮小した後は、動画、ゲーム、メッセージ通知、LANアクセスが正常に動作するか確認してください。

mode: rule

dns:
  enable: true
  enhanced-mode: fake-ip
  ipv6: false

tun:
  enable: true
  stack: system
  auto-route: true
  strict-route: false

この設定例は、トラブル対応時に確認すべき項目を示すためのもので、既存のサブスクリプションをそのまま上書きするためのものではありません。一部のAndroidクライアントでは、TUNパラメータをGUI設定から生成し、サブスクリプション更新時に手動変更が上書きされることもあります。実際に変更する前に現在のProfileを複製し、コピー側でテストしてください。

ネットワーク切り替え、弱い電波、VPN同士の競合を確認する

モバイルネットワークの電波が弱いと、モデム自体の消費電力が増えます。さらにWi-Fiとモバイルデータを切り替えた後は、Clashが接続を移行または再構築する必要があります。そのため、通勤中、地下駐車場、デュアルSIMで電波が弱い環境における電池消費を、すべてプロキシクライアントの原因とは判断できません。テストでは同じ経路で「VPNをオフ」と「VPNをオン」の結果を比較し、画面の使用時間も近づけてください。

VPNインターフェースを使用する他のサービスを停止する

Androidでは通常、1ユーザーにつき主要なVPN接続を1つしか維持できません。ファイアウォール、トラッキング防止ツール、企業VPN、他のプロキシクライアントもVpnServiceを使用する場合があります。複数のアプリが順番に接続を要求すると、鍵アイコンが消えて再表示される、通知が繰り返し更新される、ネットワークが一時的に切れる、クライアントが再読み込みされるといった症状が現れます。

「設定」→「ネットワークとインターネット」→「VPN」で、現在アクティブなVPNを確認します。
他のVPN、ファイアウォール、ローカルフィルタリングサービスを一時的に停止し、2時間観察します。
2つのプロキシクライアントで「常時接続VPN」を同時に有効にしないでください。
「VPN未使用時の接続をブロック」を有効にしている場合は、クライアントを切り替える前にこの項目をオフにし、切り替え中に全通信が遮断されるのを防ぎます。

再接続ループのログパターンを確認する

クライアントの「ログ」画面を開き、レベルをinfoに設定します。通常の静置中は、ログの追加頻度は低いはずです。数十秒ごとにnetwork changed、start service、reload configuration、DNS timeout、接続タイムアウトが繰り返し表示される場合は、時系列で発生源を特定します。切り分け中もdebugレベルを長時間使うことはおすすめしません。詳細ログは書き込み量を増やし、重要なイベントを見つけにくくします。

画面消灯後だけ再接続する場合は、まず電池最適化とWi-Fiのスリープ設定を確認します。毎回60秒間隔で発生する場合は、ヘルスチェック間隔と自動化タスクを確認します。モバイルデータ通信時だけ発生する場合は、電波状態、デュアルSIMの切り替え、IPv6、通信事業者ネットワークへの到達性を確認してください。

実行しやすい省電力調整の手順

十数個のスイッチを同時に変更すると、比較条件が失われます。高頻度の処理から順番に調整し、1グループ変更するたびに少なくとも半日観察する方法が安全です。以下の順序なら、接続の信頼性と切り分けの効率を両立できます。

現在の設定を複製する。使用中のProfileをコピーし、カーネルバージョン、現在のノード、TUNスタック、DNSモードを記録します。
繰り返しの速度テストを停止する。ヘルスチェック間隔を300～600 sに変更し、対応している場合は遅延検出を有効にします。
サブスクリプションの確認頻度を下げる。自動更新を720～1440 minに変更し、手動更新後に設定が正常に読み込まれることを確認します。
バックグラウンドの対象外設定を行う。バックグラウンド動作、自動起動、フォアグラウンドVPNサービスを許可し、ディープスリープの対象から外します。
VPNの競合をなくす。VpnServiceを使用する他のアプリを停止し、アクティブなクライアントを1つだけにします。
通信の取り込み範囲を縮小する。アプリ別ルーティングで、プロキシが不要な大容量通信アプリを除外します。
最後にTUNを調整する。前の手順で改善しない場合に限り、system、mixed、またはクライアントが提供する他のスタックを1つずつ比較します。

調整後に確認する基準

画面をロックして8時間置いても、周期的な切断通知が表示されない。
ログで、短い固定間隔の設定再読み込みやサービス起動が繰り返されない。
電池使用量に表示されるバックグラウンド動作時間が、実際のVPN利用時間と一致している。
メッセージ通知、ブラウザー、ターミナルアプリ、LANアクセスが想定どおりに振り分けられる。
Wi-Fiとモバイルデータを切り替えた後、クライアントを手動で再起動しなくても数秒以内に接続が復旧する。

すべての手順を終えても静置時の電池消費がVPNをオフにした基準値より明らかに高い場合は、少数のノードと基本ルールだけを含むテスト用設定を新しく作成します。テスト用設定が正常なら、原因は元のサブスクリプションにあるポリシーグループ、ヘルスチェック、ルール規模にある可能性が高いです。テスト用設定でも異常が続く場合は、クライアントのバージョン、システムファームウェア、端末のネットワークモジュールとの互換性を検討します。クライアントを更新する前に現在のバージョンと設定のバックアップを記録し、更新後は同じ条件で再測定して、変更に効果があったか判断してください。