Clashのスマホでの電池消耗が早い原因を調査:バックグラウンド動作の方針と省電力設定の手順
モバイル端末でClash利用時に電池消耗が目立つ問題について、ルール複雑度・接続キープアライブ・ログレベル・バックグラウンド方針の4方向から原因を特定し、実践しやすい改善手順を紹介します。
調査の考え方:「処理量が多い」のか「動作時間が長い」のかを見分ける
モバイル端末で電池消耗の異常を感じたら、いきなり個別設定をいじる前に、まず原因を大きく2つに分けて考えることが大切です。1つ目はカーネル自体が「処理量が多い」パターンで、ルール項目が多い・ログレベルが高い・リクエスト処理の経路が長いなどが原因で、接続確立時にCPUが余分な演算を毎回行うことになります。2つ目は「動作時間が長い」パターンで、本来ならOSがプロセスをスリープさせたり動作を抑えたりするはずなのに、キープアライブ設定や省電力ホワイトリストの設定が適切でないために、画面消灯後もClashクライアントが通常優先度のまま動き続けてしまうケースです。この2つの要因が重なることが、「プロキシを有効にすると本体が熱くなり、半日で電池が半分減る」といった報告のほとんどの実態です。以下ではルール複雑度・接続キープアライブ・ログレベル・バックグラウンド方針の4つの観点から順に切り分けていきます。一度に全部の設定を変えるのではなく、順番に確認していくことをおすすめします。そうすることで、どの変更が実際に効果があったのかを後から把握しやすくなります。
ルール複雑度:ルールセットが大きいほどマッチング負荷が高くなる
ClashおよびClash Meta(mihomo)カーネルは、通信が発生するたびにルールファイルを上から順に照合し、いずれかのルールに一致するか、最終的にMATCHにフォールバックするまで処理を続けます。ルールファイルの項目数が多く、しかも一致するルールが後方にあるほど、1回のマッチングで消費するCPUサイクルが増えます。モバイル端末はバックグラウンドで常時、多数のアプリが細かい短時間接続(プッシュ通知のハートビート、統計送信、画像のプリロードなど)を発生させているため、その一つ一つが数百〜数千行のルールを最後まで走査しないと振り分け先が決まらない状態だと、積み重なる消費電力は決して小さくありません。
- 手書きのドメインルールを1件ずつ列挙するより、
GEOIPやルールセット(RULE-SET)を優先的に使いましょう。ルールセット内部はインデックス最適化が施されているため、単純な線形列挙よりマッチング効率が明らかに高くなります。 - ヒット頻度が最も高いルール(例:中国本土向け直接接続ドメイン、よく使うアプリのドメインなど)は上位に配置し、高頻度の通信が何度も比較処理を受けないようにしましょう。
- 長期間ヒットしていない、または重複しているカスタムルールは削除し、ルールファイルを軽量化することで1回のマッチング経路を短くしましょう。
注意
注意
「手間を省きたいから」といって、すべてのドメインを1つの手書きルールファイルにまとめて最後尾に置くのはおすすめできません。これではほとんどの通信がルールチェーンを最後まで走査することになり、モバイル端末で見落とされがちな電池消耗の要因の一つになります。
接続キープアライブ:ハートビートと長時間接続がもたらす電力コスト
一部のノードやクライアントは、レイテンシを抑えたり再接続の頻発を避けたりするために、TCP Keep-Aliveやアプリケーションレベルのハートビートパケットを有効にし、小さなデータを定期的に送信して接続を維持しています。この仕組みはWi-Fi環境では影響が限られますが、モバイルネットワークでは、ハートビートを送るたびにベースバンドモジュールがスリープ状態から呼び起こされる可能性があり、そのベースバンドの起動に伴う消費電力は、ハートビート自体のデータ量よりもはるかに大きくなります。クライアントの接続アイドルタイムアウトが短すぎたり、ハートビートの間隔が頻繁すぎたりすると、バックグラウンドに長時間残っている接続が端末を何度も呼び起こし、「画面を消してもすぐに電池が減っていく」という現象を引き起こします。
- クライアントの接続アイドルタイムアウト設定を確認し、短くするのではなく適切に延長することで、無意味な再接続やハートビートの頻度を減らしましょう。
- 不要な「接続を常時維持」系の設定は無効にしましょう。特に長期間使っていないノードグループについては、長時間接続を維持する必要はありません。
- 自動速度測定機能を使っている場合は、測定間隔を適切に延ばすか、必要時のみ実行する方式に切り替えることで、定期タスクによる端末の頻繁な起動を避けましょう。
ログレベル:デバッグレベルの出力は常に負荷をかけ続ける
ログレベルは、カーネルが動作中に記録する情報の詳細度を決めるもので、一般的には低い方から silent、error、warning、info、debug の順になります。レベルが高いほど、カーネルが整形・書き込みし、場合によってはローテーション保存するログ量も増えます。このI/O処理や文字列処理はモバイル端末でもCPUとストレージへの書き込み帯域を消費するため、見落とされがちな電池消耗の要因です。具体的な問題を調査している場合を除き、debugレベルを常時有効にしておくことはおすすめしません。
| ログレベル | 出力内容 | 適した用途 |
|---|---|---|
silent | ログを出力しない | 日常的な長期利用、省電力を優先したい場合 |
error | エラー情報のみ記録 | 日常利用、問題発生時の追跡も兼ねたい場合 |
warning | エラーと警告情報 | たまに発生する異常の調査 |
info | 接続確立とルールヒットの概要 | 振り分け問題の一時的なデバッグ |
debug | 呼び出しチェーンの詳細すべて | 短時間の詳細な障害調査、使い終わったらすぐ元に戻す |
log-level: silent
設定ファイルのlog-levelをdebugやinfoからsilentやerrorに戻すことは、最も手軽で効果的な省電力対策の一つで、多くのユーザーにとって使用感にほとんど影響を与えません。
バックグラウンド方針:省電力ホワイトリストとキープアライブ機構のせめぎ合い
AndroidシステムはVpnServiceインターフェースを利用して仮想ネットワークカードを構築し、全体の通信を引き受ける仕組みになっています。つまりClashクライアントは長期間バックグラウンドプロセスとして存在し続けなければ、プロキシ接続を維持できません。しかし各メーカーのカスタムOS(特に中国製ROM)は総合的なバッテリー持ちを重視して、バックグラウンドプロセスに対してより積極的なスリープ・フリーズ・強制終了の方針を取ることがあります。Clashクライアントが省電力ホワイトリストや自動起動リストに追加されていない場合、システムが定期的にプロセスをフリーズしてから接続を再構築する、という動作を繰り返すことがあり、この「フリーズ→再接続」の繰り返し自体が大きな電力消耗要因となり、通信の切断やカクつきも顕著になります。
- システムのバッテリー設定でClashクライアントを「制限なし(無制限)」のバックグラウンド動作ホワイトリストに追加しましょう。単に省電力モードをオフにするだけでは不十分です。
- クライアントの常時通知表示はそのままにしておきましょう。これはVpnServiceが正常に動作している証であり、無理に通知を消すとシステムがプロセスを回収してしまう可能性があります。
- アプリの自動起動権限がオンになっていることを確認しましょう。画面ロック後にプロセスが完全に終了してしまうと、再起動時にむしろ多くの電力とデータ通信量を消費することになります。
おすすめの進め方
上記4項目は「ルールの軽量化 → 接続キープアライブの調整 → ログレベルの引き下げ → バックグラウンドホワイトリスト設定」の順に一つずつ実施し、変更ごとに半日〜1日ほど電池の消耗曲線を観察することをおすすめします。そうすることで、自分の端末にとってどの対策が効果的だったかをより明確に判断でき、一度に多くを変更して原因を特定できなくなる事態を避けられます。
よくある質問
TUNモードをオフにすれば省電力になりますか?
TUNモードは全体の通信を引き受けるため、理論上はシステムプロキシ単体設定より処理する接続数が増えます。TUNモードを有効にした後に電池消耗の異常が発生した場合は、まずシステムプロキシモードに切り替えて比較調査するとよいですが、TUNモード自体が必ず電力を多く消耗するわけではなく、ポイントはやはりルール複雑度とキープアライブ方針が適切かどうかにあります。
ノードを切り替えると電池消耗に影響しますか?
ノード自体の遅延やパケットロス率は再接続の頻度に影響します。遅延が高く接続が不安定なノードはクライアントの再試行を頻発させ、間接的に電池消耗を増やす原因になります。まずは接続が安定したノードを優先的に選び、上記の4つの設定と合わせて最適化することをおすすめします。