スマホの Clash が異常に電池を消耗する時の対処法:Android バックグラウンド設定と省電力チェックリスト

電池2割減はまずクライアントを疑わない:問題を見極める3つの手がかり

スマホにプロキシをつなぎっぱなしで一晩過ごし、朝起きたら電池が20~30%減っていた──こうなると真っ先にクライアント自体を疑いたくなります。しかし、プロキシソフトの常駐消耗は主に3つの計測可能な要素から来ます。システムがバックグラウンドでの継続動作を許可しているか、ネットワーク層が頻繁に CPU を呼び起こしているか、そしてルールマッチングが余計な処理コストを消費していないか。どこに問題があるかを判断するには、まず3つの手がかりを確認します。

手がかり1:システム設定のバッテリー詳細を開き、Clash クライアントの「バックグラウンド稼働時間」が一晩分の時間に近いかを確認します。近ければシステムに制限されておらず継続的に稼働している状態で、これはプロキシの正常な動作であり異常ではありません。手がかり2:同じ時間帯の「ウェイクロック回数」や「アプリの異常動作」通知を確認します。回数が異常に多い場合は、探測間隔が短すぎる、あるいはルールのマッチングが不安定で頻繁な再接続が起きていることが多いです。手がかり3:プロキシを使わない状態の待機時消耗速度と比較し、差が5%以内であれば消耗の主因は他のバックグラウンドアプリであり、クライアント側の設定にこだわる必要はありません。

システムの省電力ポリシーが最大の変数:バックグラウンドホワイトリストを項目ごとに設定

Android は Doze 機構以降、各メーカーのカスタム OS がさらに積極的な省電力ポリシーを重ねており、これがプロキシの頻繁な切断、そしてそれに伴う再接続ラッシュを引き起こす最も一般的な原因です。仕組みは単純で、システムが App が長時間バックグラウンドかつ画面オフの状態にあると判定すると、ネットワークアクセスと CPU の起動を制限します。プロキシプロセスが凍結されると TUN 仮想ネットワークカードによるトラフィック転送も止まり、スマホが再びネットワークにつながるたびに接続を再構築する必要があります。この繰り返される再接続こそが本当の電力消耗の元凶です。

メーカーごとに設定項目や制限の強さが異なるため、以下を順に確認してください。

• MIUI(Xiaomi):設定 → アプリ設定 → アプリ管理 → Clash クライアントを探す → 省電力ポリシーを「制限なし」に設定し、「自動起動管理」の該当する制限も解除する。
• ColorOS / realme UI(OPPO/realme):バッテリー → アプリの電池使用管理 → クライアントを探す → バックグラウンド動作を許可 + 高負荷動作を許可、さらに「その他の設定」で「スリープ時の電力最適化」の対象からこのアプリを外す。
• OriginOS / Funtouch OS(vivo/iQOO):i管家 → アプリ管理 → 権限管理 → バックグラウンド高負荷動作、クライアントをホワイトリストに追加。同時に OS 標準の「スマート省電力」の対象からも外す。
• EMUI / HarmonyOS(HUAWEI):バッテリー → バッテリー設定の詳細 → アプリの起動管理、クライアントを「手動管理」に切り替え、自動起動・連動起動・バックグラウンド動作にチェックを入れる。
• One UI(Samsung):設定 → バッテリー → バックグラウンド使用の制限、クライアントを「スリープ状態のアプリ」または「ディープスリープアプリ」リストから外す。
• Android 標準 / Pixel:設定 → アプリ → クライアントを探す → バッテリー → 「バッテリー使用状況」を「制限なし」に変更する。

この設定がプロキシがバックグラウンドで安定稼働できるかをほぼ決定します。システムのホワイトリスト設定を行わないまま、クライアント内部の省電力調整だけを進めても対症療法にしかなりません。

TUN モード常駐と省電力のトレードオフ

TUN モードは仮想ネットワークカードで全体のトラフィックを引き受ける方式で、個々の App にプロキシ設定をする必要がなく互換性が最も高いですが、その代償として常駐のバックグラウンドサービスがネットワークインターフェースの変化を常時監視する必要があります。このサービス自体の消耗はごく小さく、本当に電池を圧迫するのは省電力ポリシーとの噛み合わせの悪さです。システムがバックグラウンドプロセスの起動を制限する一方で、TUN サービスは Wi-Fi からモバイルデータへの切り替えなどのネットワーク変化にいつでも応答する必要があり、この衝突によってサービスが強制終了・自動再起動を繰り返します。再起動のたびにルーティングテーブルの再構築と DNS の再解決が完全に行われ、これが消耗のピークになります。

全体透明プロキシが本当に必要ない(例えば一部の App だけを振り分けたい)場合は、TUN モードを無効にしてシステム VPN インターフェースやアプリ単位のプロキシ設定に切り替えることで常駐ネットワークサービスを1つ減らせます。ただし TUN による全体振り分けが必要、または UDP/ICMP トラフィックの捕捉が必要な場合は、TUN モードを維持したまま前節のシステムホワイトリスト設定をしっかり行うほうが、TUN を無効化するより実用的です。

探測間隔と並行探測:見落とされがちな消耗要因

ポリシーグループ設定の url-test タイプは一定間隔でノードへ遅延探測を行い、この間隔は interval フィールド(単位は秒)で制御されます。多くのサブスクリプションではこの値がデフォルトで短く設定されており(60秒以下など)、クライアントは1分ごとにネットワークモジュールを起動し、各ノードへ HTTP リクエストを送ることになります。夜間の待機時には本来ディープスリープに入るべきスマホが、こうした定期的な探測によって何度も呼び起こされ、積み重なると無視できない電力消費になります。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies: [ノード1, ノード2, ノード3]
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

interval を 300~600 秒に広げても大半の利用シーンでは明確な影響はなく、夜間の起動回数を大きく減らせます。ポリシーグループ内のノード数が多い場合、探測は並行して行われるため、ノードが多いほど1回あたりの所要時間と消耗も増えます。サブスクリプション内の数十個のノードを全部同じ自動探測グループに詰め込む必要はなく、よく使う5~10個程度に絞れば十分です。

ルールの複雑さが CPU を圧迫する:整理の仕方

ルールセクションのマッチングは上から順に1件ずつ比較されるため、ルール数が多く、かつマッチが後方にあるほど、1回の接続確立にかかる CPU サイクルは長くなります。数千行規模のコミュニティルールセットをルールリストの最前列に置き、大量のドメインを分類ルールセット(RULE-SET)ではなく文字列の完全一致で処理していると、新しい接続が発生するたびに長い比較処理を走らせることになります。バックグラウンド App の生存維持やプッシュのハートビートなど高頻度で接続が発生する状況では、CPU 使用率が頻繁に小さなピークを描くようになり、これらのピークの積み重ねも消耗の一部です。

整理の方針はシンプルです。マッチ率の高いルール(中国本土向けの直結ドメイン、よく使う振り分けドメインなど)をルールリストの前方に置き、平均的な比較回数を減らす。個別のドメインルールを1件ずつ積み上げるのではなく、整備済みの分類ルールセットを RULE-SET で参照する。明らかに重複している、または上位のルールで既にカバーされている項目を削除する。ルールセット自体は読み込みとインデックスの方式が最適化されているため、平文のルールを1件ずつ書くより効率が高く、ルール数を一桁減らせればマッチングコストもそれに応じて下がります。

そのまま実行できる省電力チェックリスト

以下の順で1つずつ確認すれば、クライアント自体が原因ではない消耗異常はほぼ排除できます。

1. システムのバッテリー設定を開き、Clash クライアントをバックグラウンド動作のホワイトリストに追加し、各メーカーのカスタム「スマート省電力」「スリープ最適化」の制限をすべて解除する。
2. 自動起動権限、連動起動権限が無効になっていないか確認する。バックグラウンドで凍結されたプロセスはホワイトリストに入れても自力で起動できないことがある。
3. 本当に TUN モードが必要かを確認する。全体振り分けが不要ならアプリ単位のプロキシに切り替えれば常駐サービスを1つ減らせる。
4. 設定ファイルを開き、url-test ポリシーグループの interval を 300 秒以上に調整し、定期的な起動頻度を減らす。
5. 自動探測グループ内のノード数を絞り、よく使うものだけを残して1回の探測にかかる並行処理コストを減らす。
6. ルールセクションの行数を確認し、優先的に RULE-SET でルールセットを参照し、マッチ率の高いルールをリストの前方に移動する。
7. プロキシを有効にする前後の待機時消耗速度を比較し、差が10%以上残っている場合は前述の各手順が効いているかを再確認する。