Clash Android版の異常なバッテリー消費を分析:バックグラウンド保持・TUNモード・メーカー省電力機能のトレードオフ
モバイル端末でプロキシを使うとバッテリー消費が増えやすい原因は、主にバックグラウンドでのウェイクアップとTUNモードにあります。よくある消費要因を分析し、バックグラウンド動作方針・ルール簡略化・各メーカーの省電力ホワイトリスト設定について具体的な提案をまとめました。
まず異常か感覚の違いかを見分ける
Android端末でプロキシを使い始めると「端末がより熱くなり、消費も増えた」と感じることがありますが、これが必ずしもプロキシアプリ自体の問題とは限りません。まずは基本的な区別を行い、調査の方向を間違えないようにしましょう。システム設定内のバッテリー使用状況を開き、Clash系アプリの消費割合が他の常駐アプリ(チャットアプリやメールクライアントなど)と比べて明らかに高いかどうかを確認します。一桁台のパーセンテージであれば、通常のプロキシ転送によるオーバーヘッドの範囲内である可能性が高いです。一方、常に消費上位3位以内に入り、画面オフ後も高い割合を維持している場合は、異常とみなすべきです。
また「消費」と「発熱」も区別する必要があります。発熱は短時間の高負荷によることが多く、サブスクリプションをインポートした直後やノードの一括速度測定を行っている数分間などに発生します。一方、消費は長時間スケールでの累積的な消耗であり、主にバックグラウンド駐留時の挙動を見るべきです。本稿で取り上げるのは、バックグラウンドで継続的に動作している状態での消費問題であり、短時間の高負荷による発熱ではありません。
主な消費要因は3つ:ウェイクアップ・TUN・ルールマッチング
バックグラウンドのウェイクアップ頻度
Clash系クライアントはプロキシサービスと確立済みの接続を維持する必要があるため、システム側では常駐が必要なプロセスとしてマークされます。クライアント自体やシステムのスケジューリングが頻繁にCPUをウェイクアップしてハートビートチェック、接続の保持、サブスクリプションの期限確認を行う場合、実際の通信が発生していなくても、それなりのバッテリー消費が蓄積されます。この項目は「端末を放置して使わない」夜間のシナリオで最も顕著に現れます。一晩置いておくと、プロキシを入れていない場合よりも明らかにバッテリー残量が減っており、原因はほぼウェイクアップ頻度に絞り込めます。
TUNモードによるシステムレイヤーでの引き受け
TUNモードはシステムのネットワーク層に仮想ネットワークカードを構築し、端末上のすべてのアプリの通信をまずClashのコアに引き込んで処理し、ルールに従って振り分け・転送します。この方式はカバー範囲が広く互換性も高く、プロキシを回避するアプリがほとんど発生しませんが、その代償として1パケットごとにカプセル化・カプセル解除・ルールマッチングという追加のオーバーヘッドが発生します。Androidでは、TUNモードはさらにシステムのVPNサービスフレームワークとのやり取りも伴い、この連携自体にも一定のリソース消費が発生します。スマートフォンのCPU性能や放熱余地はPCと比べてはるかに劣るため、このオーバーヘッドが増幅されて消費や発熱として現れます。
ルールセットの規模とマッチングの複雑さ
ルールによる振り分けでは、各接続の宛先ドメインやIPをルールリストと1件ずつ照合する必要があり、ルールセットが大きく階層が複雑になるほど、1回のマッチングにかかる時間が長くなります。サブスクリプションに付属するルールセットの中には数千件のルールに加え複数のリモートルールセット(rule-providers)を含むものもあり、クライアントはバックグラウンドで設定した周期に従ってこれらのルールセットの更新を取得する必要があります。取得と解析の処理自体もCPUとネットワークを消費します。容量の大きいルールセットを複数同時に読み込んでいる場合、バックグラウンドの維持コストは明らかに上昇します。
まずTUNモードがオンになっているかを確認し、次にルールセットの数と更新頻度を見て、最後にシステムの省電力ポリシーが保持機能を誤って停止させていないかを調査します。これらが重なっている場合は、この順序で変数を一つずつ無効化し、どれが消費に最も影響しているかを個別に検証することをお勧めします。
バックグラウンド動作方針のトレードオフ
Androidのバックグラウンド管理機構自体が「アプリの生存を保証する」ことと「バックグラウンド消費を制限する」ことのバランスを取ろうとしており、プロキシ系アプリはまさにこの矛盾の狭間にあります。プロキシは長期間バックグラウンドで接続を維持しなければ効果を持続できませんが、システムの省電力ポリシーはバックグラウンドプロセスを制限する方向に働きます。ここに絶対的な正解はなく、使い方に応じたトレードオフしかありません。
- 日常の軽い利用:Webページの閲覧やニュースを見るだけであれば、プロキシを常時バックグラウンドで接続維持させる必要はありません。使わないときは手動でプロキシサービスを切断し、バックグラウンドのウェイクアップ回数を減らすのが最も直接的な省電力策です。
- 接続を維持する必要があるシナリオ(メッセージ通知の受信や長時間の常時起動など):クライアントをシステムのバックグラウンドホワイトリストに追加し、省電力制限を回避できるようにする必要がありますが、それに伴う電力消費は明確なトレードオフであり、不具合ではないと理解しておく必要があります。
- 特定のアプリだけでプロキシを利用する:クライアントがアプリ別ルールやパッケージ名単位の振り分けに対応している場合、実際にプロキシが必要なアプリだけをTUN経由にし、残りのアプリは直接接続にすることで、全体のルールマッチングと転送負荷を大幅に下げられます。
使い方の頻度に合わせて選び、シナリオを問わず一律で最も攻めた設定や最も保守的な設定にしないことをお勧めします。
ルール簡略化:バックグラウンド常駐の負担を減らす
サブスクリプションに付属するルールセットの多くは「網羅型」の設計になっており、あまり使われない多くのシナリオまでカバーしています。ほとんどのユーザーにとって、ルールセットを簡略化することはバックグラウンドのマッチングと更新にかかるコストを直接下げることにつながります。実行可能な方向性は以下の通りです。
- クライアントに読み込まれているrule-providersの数を確認し、長期間使っていないカテゴリのルールセット(特定地域のサービス向けルールなど、ほとんどアクセスしないもの)を統合または削除する。
- ルールセットの更新間隔(interval)を適度に延ばす。毎日更新を取得する必要はなく、ほとんどのルールセットの実際の変更頻度は高くないため、3〜7日間隔にしておけば通常十分です。
- 同時に読み込む策略グループ(policy group)の数を減らす。グループ内の自動速度測定(url-test)自体が定期的に探査リクエストを発生させるため、グループが多いほどバックグラウンドの定期タスクも増えます。
- 複数のサブスクリプション元から重複したルールセットが交差して取り込まれていないか確認する。重複したルールはマッチング速度を落とすだけで実際の効果は増えません。
rule-providers:
reject:
type: http
interval: 259200 # デフォルトより頻繁ではなく、3日に1回更新
behavior: domainルールセットを調整した後は、1〜2日ほどバッテリー使用量の変化を観察してから、さらに簡略化を続けるかどうかを判断することをお勧めします。一度に削り過ぎて、本来プロキシを通すべき通信が漏れてしまうことを避けましょう。
各メーカーの省電力ポリシー下でのホワイトリスト設定
Android搭載端末を展開する主要メーカーの各システムは、標準Androidをベースに独自の省電力・プロセス管理ポリシーを重ねています。これらのポリシーは、ユーザーが気づかないうちにプロキシサービスのプロセスを終了させることが多く、結果としてプロキシが「いつの間にか切れる」、あるいは接続を維持しようと再起動を繰り返して逆に消費が増える、といった事態を引き起こします。以下は代表的な設定箇所です。具体的なメニュー文言はシステムバージョンによって多少異なる場合があります。
| メーカー系OS | 関連設定項目 | 推奨アクション |
|---|---|---|
| MIUI / HyperOS | 省電力ポリシー・自動起動管理・バックグラウンドロック | 「制限なし」に設定し、自動起動を許可、タスク一覧で長押しロック |
| EMUI / HarmonyOS | 電池・アプリ起動管理 | 「自動管理」をオフにし、自動起動・連動起動・バックグラウンド動作を手動で許可 |
| ColorOS / OxygenOS | 電池・アプリ消費管理 | 「バックグラウンド動作を許可」に設定し、ディープスリープ制限をオフ |
| Funtouch OS / OriginOS | 電池・バックグラウンド高消費 | 許可リストに追加し、当該アプリへの「スマート省電力」制限をオフ |
| One UI (Samsung) | 電池・バックグラウンド使用制限 | 「スリープ中のアプリ」リストから除外し、「監視対象外」に設定 |
クライアントをホワイトリストに追加すると、バックグラウンドでの強制終了や接続断の確率は明らかに下がりますが、これは電力消費の一部を安定性と引き換えにしていることを理解しておく必要があります。前節の省電力ポリシーとは相互に制約する関係にあります。合理的な方法は、本当に長時間端末を起動させたままにする必要があるならホワイトリストに追加し、時々しか使わないならシステム標準の省電力制限を維持して、使うときだけ手動でオンにすることです。
一部メーカーのシステムに搭載されている「超省電力モード」や「極限省電力モード」は、ホワイトリスト外のすべてのアプリのネットワークアクセスを強制的に遮断します。このモードでは、プロキシクライアントがホワイトリストに入っていても、システム全体のネットワークポリシーによって制限されて正常に通信できない場合があります。このような状況に遭遇したら、まず端末が現在超省電力モードになっていないかを確認してください。
TUNモードを使わない方がよいケース
TUNモードは唯一の選択肢ではありません。端末の発熱や消費が日常利用に明らかに影響している場合は、システムプロキシモード(プロキシが必要なアプリやブラウザ側で個別にプロキシアドレスを設定する方式)への切り替えを検討し、カバー範囲の一部を犠牲にしてシステムレイヤーのオーバーヘッドを下げるという判断もできます。システムプロキシモードでは、プロキシを明示的に設定したアプリのみが転送対象となり、それ以外のアプリは一切影響を受けないため、マッチングと転送の総量がかなり小さくなります。
このトレードオフは、ブラウザや少数のアプリでのみプロキシが必要な場合、端末の性能が低めで発熱に敏感な場合、あるいは一時的な利用でグローバルなカバー範囲を求めていない場合に適しています。逆に、端末上のすべてのアプリをカバーする必要がある場合(例えば、一部のアプリにハードコードされたドメイン検出があり、グローバルプロキシを回避すると機能に異常が出るケースなど)は、TUNモードの方が依然として確実な選択です。この場合、消費増加は受け入れるべきコストであり、力を入れるべきは前述のルール簡略化とホワイトリスト設定であって、TUNを使うかどうかで悩むことではありません。
一通りの調査フローの提案
- システムのバッテリー使用状況を開き、消費割合が本当に異常かどうかを確認する(本稿冒頭の判断基準を参照)。
- TUNモードがオンになっているか確認し、1日試験的にシステムプロキシモードに切り替えて消費量の差を観察する。
- 現在読み込まれているルールセットの数と更新間隔を点検し、長期間使わないカテゴリを削除し、更新周期を延ばす。
- 策略グループ内の自動速度測定の探査頻度を確認し、不要な定期探査タスクを減らす。
- メーカーの省電力ポリシー設定が適切かどうかを確認する:長時間の常時起動が必要ならホワイトリストに追加し、時々の利用ならシステム標準の制限を維持する。
- 調整後1〜2日のバッテリー曲線を観察し、消費が適正な範囲まで下がったかを確認してから、さらに調整するかどうかを判断する。
この順序で一つずつ調査すれば、消費異常の原因をおおむね特定の箇所に絞り込むことができ、「プロキシソフトが電力を消費する」と大まかに結論付けずに済みます。多くの場合、消費問題の根本原因はルールセットの肥大化やバックグラウンドのウェイクアップ過多であり、この2点を調整する方がTUNモードを使うかどうかで悩むよりも効果的です。