Clash Android バッテリー消耗が早い時の対処法:バックグラウンド動作設定と省電力チェックリスト

まず消耗源を特定する:システムのバッテリー統計の見方

設定を変更する前に、電池消耗が本当にClash自体によるものか、それとも購読ノードの接続品質が悪くて再接続を繰り返しているだけなのか、あるいは別のアプリがバックグラウンドを占有しているだけなのかを確認しましょう。Android標準のバッテリー統計でおおよその方向性がわかります。「設定 → バッテリー → アプリごとの電池使用量」を開き、対象のClashクライアント(Clash Meta for Android、FlClash、Clash Verge などAndroid派生版はアプリ名が異なるので、実際にインストールしたアプリ名で探してください)を見つけて、「バックグラウンド動作時間」と「ウェイクアップ回数」の2つの指標を確認します。

ウェイクアップ回数が通常より明らかに多い場合(目安として、ヘルスチェックを有効にしている状態なら1時間あたり数十回程度が正常で、数百回を超えるようなら要注意)、ヘルスチェック間隔が短すぎるか、ノードプール内に無効なノードが多く残っていて繰り返し探索されている可能性が高いです。バックグラウンド動作時間自体は長いのにウェイクアップ回数が少ない場合は、TUNモードがネットワーク層に常駐していることによる持続的な消費電力である可能性が高く、特定のタスクの異常が原因ではないと考えられます。

ヘルスチェック間隔と探索頻度:Clashを不必要に「通話」させ続けない

Clash と Clash Meta(mihomo コア)の設定では、url-test と fallback タイプのプロキシグループに interval フィールド(単位は秒)があり、グループ内のノードに対してどのくらいの頻度で遅延測定を行うかを決めています。この値を小さくするほど低遅延ノードへの切り替えは敏感になりますが、その代償として通信モジュールがより頻繁にウェイクアップ・リクエスト送信・応答待ちを行う必要があります。モバイル通信では、探索1回ごとにベースバンドのウェイクアップが発生する可能性があり、これが積み重なると明確な電池消耗につながります。

proxy-groups:
  - name: 自動選択
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - ノードA
      - ノードB

PC向け購読設定でデフォルトで指定される interval は60〜120秒程度が一般的で、常時給電されているPCでは問題ありませんが、そのままスマートフォンに適用するとやや過剰です。モバイル端末では 300秒以上 に設定し、tolerance(許容誤差、単位はミリ秒)を50〜100に設定することで、ノードの遅延がわずかに揺れただけで不要な切り替え判定が発生するのを防げます。購読がリモート管理されていてこのフィールドを直接編集できない場合は、クライアントの「オーバーライド」または「ローカル上書きルール」機能を使って、intervalだけを上書きする設定を追加し、他の振り分けルールには影響を与えないようにできます。

• バックグラウンドで長時間待機し、切り替えの敏感さをそれほど重視しない場合:interval は300〜600秒に設定。
• 頻繁にフォアグラウンドで使用し、遅延に敏感な用途(ゲーム加速など)の場合:60〜120秒を維持しつつ、相応の電池消耗を受け入れる。
• ノードプールに無効なノードが長期間残っている場合:まず購読やフィルタリングルールを整理すること。間隔を長くするだけでノードプールの品質問題を隠そうとしないでください。

TUNモード常駐の代償と代替案

TUNモードはシステムのネットワーク層に仮想ネットワークカードを構築し、デバイスの全通信を一括して引き受けます。個々のアプリがシステムプロキシ設定を守っているかどうかに依存しません。この仕組みによってカバー範囲が広がりDNS処理もより徹底されますが、代償として仮想ネットワークカード自体が常にアクティブな状態を保つ必要があり、Androidの省電力戦略とは元々相性が悪いです。システムが通信モジュールをスリープさせたがるほど、TUNは通信モジュールをウェイクアップさせてパケットを処理する必要が生じ、両者のせめぎ合いの結果、消耗が激しいのに動作も不安定になりがちです。

日常的な使用シーンで、プロキシを通すのが主にブラウザと少数のアプリだけであれば、TUNモードを常時有効にして全体を引き受ける必要はありません。システムプロキシモードに戻し、本当に全体を引き受ける必要があるとき(あるアプリがシステムプロキシ設定を回避する場合や、UDP/DNS層の処理が必要な場合など)だけ一時的にTUNモードを有効にするのがおすすめです。両モードの本質的な違いは「アプリが自発的に従うかどうか」と「ネットワーク層での強制的な引き受け」にあり、詳しい仕組みの違いは、当サイトのTUNモードとシステムプロキシの違いを解説した別記事でより完全な比較を確認できます。

ログレベルとGUI更新:見落としがちな隠れた消耗ポイント

ログレベル設定では、debug レベルはすべての接続確立とルールマッチングの過程を記録するため書き込み頻度が非常に高く、特にルール数が多く並行接続数が多いシーンでは、継続的なディスク書き込みと文字列処理そのものがCPUサイクルを消費します。日常使用時はログレベルを info かそれより低い warning に戻し、具体的な問題を調査する必要があるときだけ一時的に debug に切り替え、調査が終わったら忘れずに戻すことをおすすめします。

log-level: info
# 問題調査時は一時的にdebugに変更し、使い終わったら忘れずに戻す

もう一つ見落とされがちなのが、クライアントUIのリアルタイム更新です。一部のAndroidクライアントのメイン画面にはリアルタイム通信量グラフや接続リストのスクロール更新があり、バックグラウンドに切り替わってもクライアントが正しく描画リソースを解放していない場合、画面合成関連のプロセスを継続的にウェイクアップさせ続けてしまいます。クライアント設定に「バックグラウンド時は画面更新を停止」「省電力モード」といったスイッチがあるか確認し、有効になっているかチェックしてください。また、通知バーが1秒ごとに通信量の数字を更新する設定になっていないかも確認しましょう。この高頻度な通知更新は想像以上に電池消耗に影響するため、通知設定で更新頻度を数秒おきに落とすか、リアルタイムの数字を表示せず接続状態のみ表示する形に変更するとよいです。

メーカー独自のバックグラウンド制限:設定が合っていないと逆に消耗が増える

中国本土の主要なAndroidメーカー(Xiaomi、HUAWEI、OPPO、vivoなど)は、それぞれ独自のバックグラウンド管理戦略をシステムに組み込んでいます。個別に許可設定をしないと、バックグラウンド制限機能がプロセスを頻繁に「フリーズ→復帰」させてしまい、その都度ノードへの再接続やTUN仮想ネットワークカードの再構築が発生するコストは、プロセスを普通にバックグラウンドに常駐させておくよりも消耗が大きくなります。設定の方向性はおおむね共通していますが、具体的な入口名称はメーカーごとに異なります。

• Xiaomi(MIUI/澎湃OS):設定 → アプリ設定 → アプリ管理 → 対象クライアントを選択 → 省電力戦略で「制限なし」を選択し、同時に「自動起動管理」内の追加のブロック項目も解除する。
• HUAWEI(EMUI/HarmonyOS):設定 → バッテリー → アプリ起動管理 → 対象アプリの「自動管理」を無効にし、自動起動・連動起動・バックグラウンド動作の3項目を手動で有効にする。
• OPPO(ColorOS):設定 → バッテリー → アプリ電池使用量管理 → 対象クライアントを「バックグラウンド動作を許可」に設定し、「省電力モードのホワイトリスト」にも追加する。
• vivo(OriginOS/Funtouch OS):iマネージャー → アプリ管理 → 権限管理 → バックグラウンド高消耗 → 対象クライアントを許可に設定する。

注意していただきたいのは、これらの設定は本質的に「バックグラウンドでの正常な常駐を許可する」ものであり、「無制限に電池を消費してよい」というものではない点です。クライアントをホワイトリストに追加した後も、前のセクションで説明したヘルスチェック間隔・TUN使用範囲・ログレベルの調整は依然として必要です。そうしないと、元々消耗の激しい設定をそのまま許可してしまうことになり、電池寿命はむしろ悪化します。両方セットで対応する必要があり、どちらか一方だけでは不十分です。

省電力と安定動作を両立させる設定チェックリスト

これまでのセクションで触れた調整点を、優先度の高い順に並べた実行チェックリストとしてまとめます。

1. 購読ノードプールがきれいな状態か確認し、まず長期間無効なノードを削除して、ヘルスチェックが無効なノードに対して探索を繰り返す無駄をなくす。
2. url-test / fallback グループの interval を300秒以上に設定し、tolerance は50〜100ミリ秒を維持する。
3. 必要のない場面ではTUNモードを常駐させず、全体の引き受けや特殊なDNS処理が必要なときだけ一時的に有効にする。
4. ログレベルは通常時 info かそれ以下を維持し、問題調査時のみ一時的に debug に切り替え、終わったら速やかに戻す。
5. クライアントのリアルタイム更新通知を無効化または頻度を下げ、「バックグラウンド時に画面更新を停止」のスイッチがあれば有効にする。
6. 端末メーカーに合わせてバックグラウンド制限の許可設定を完了させ、4項目(自動起動・連動起動・バックグラウンド動作・省電力ホワイトリスト)を一度にまとめて設定し、1つでも漏れるとプロセスがシステムに再度フリーズされてしまうので注意する。

---

ヘルスチェック間隔とTUN使用範囲を調整した後もノードで大規模なタイムアウトや接続異常が続く場合、問題はすでに電池消耗の範囲を超えており、ノードや購読自体に問題がある可能性があります。購読の有効性・端末の時刻ズレ・ポート使用状況といった、より根本的な原因を順に確認していくとよいでしょう。