Android版Clash Metaのバッテリー消費が激しいときの対策｜バックグラウンド動作・電池の最適化・TUN設定

まずは通信による消費、バックグラウンドでの再起動、電池使用量の計上先を切り分ける

まずスマートフォン全体の電池の減り方を確認し、次に電池使用量画面でのClash Metaの順位を見ます。AndroidのVPNは他のアプリの通信をまとめて処理するため、通信の一部がVPNアプリの使用量として計上される場合があります。「電池消費の1位」だからといって、常にコアがCPUを使い切っているとは限りません。ダウンロード、クラウド写真のバックアップ、動画再生、モバイル回線の電波が弱い環境は、プロキシ処理自体より電池を消費することがあります。

Clash Metaはクライアントやコアに関連する名称で、mihomoは一般的なコアの名称です。Androidクライアントによって設定画面、設定の上書き方法、バックグラウンドサービスの実装は異なります。調査前にクライアントとコアのバージョン、Androidのバージョン、現在の設定名を記録してください。Linuxのsystemdによる常駐設定やTUN権限のコマンドを、そのままスマートフォンに適用しないでください。

条件をそろえて2回分のデータを記録する

1. 安定したWi-Fiに接続し、電波状況、画面の明るさ、バックグラウンド同期の設定をそろえます。ダウンロードやバックアップは一時停止し、起動直後、システム更新中、充電後の発熱時は避けてください。
2. 画面を消した状態で60分間記録し、開始・終了時の電池残量、接続の切断有無、端末の温度をメモします。プロキシを無効にした比較テストでも、アプリの負荷は同じにします。ネット接続ができず同期が止まった場合、その結果をそのまま比較することはできません。
3. 同じアプリを使い、同じ時間だけ画面点灯状態でもテストします。動画の画質、ゲームのフレームレート、ネットワーク方式を変更した場合は、基準値を取り直してください。

たとえば、記録上で80%から77%に減り、時間が60分なら、そのテストでの低下は3ポイントです。これは計算例であり、Clash Metaの実測値や基準値ではありません。電池残量の表示には丸め誤差があるため、1回のテストで1%減っただけでは効果を判断できません。最低2回繰り返し、発熱、再接続の回数、通知の遅れもあわせて記録しましょう。

ヘルスチェック：間隔を延ばしてから重複測定を見直す

ノードの測定ではネットワークリクエストが発生します。ノード数が多く、間隔が短いと、ブラウジングしていなくても定期的に通信が発生します。モバイル回線では、こうしたリクエストによって無線モジュールが低消費電力状態から頻繁に復帰することもあります。まずproxy-providersのヘルスチェックを確認し、次にurl-testやfallbackなどのグループで同様の測定が重複していないか確認してください。

以下は既存のProvider項目に追加する部分設定であり、サブスクリプション全体ではありません。該当項目にあるtype、url、pathとヘルスチェック用のurlはそのまま残してください。測定先には到達性を確認済みのアドレスを使い、例に合わせるためだけに安易に変更しないでください。

interval: 86400
health-check:
  enable: true
  interval: 900
  lazy: true

たとえば、80個のノードを60秒ごとに測定していて、毎回すべての測定が実行される場合、1時間で理論上約4800回のノード測定が発生します。900秒に変更すると約320回です。この計算には再試行、初回読み込み、手動測定は含まれず、実際のHTTPリクエスト数や節電率を示すものでもありません。ノードが不安定なら、まず300秒に設定し、切り替え速度とバックグラウンド通信のバランスを調整してください。

• サブスクリプションの更新とノード測定は別々に調整します。設定を毎日更新していても、ノードのチェックが1日1回になるわけではありません。それぞれのintervalは別の階層にあります。
• 重複するチェックを減らします。同じノード群を複数の自動選択グループが参照している場合は、各グループの設定も確認してください。Providerだけ変更しても、すべての自動測定が止まるとは限りません。
• 実際に適用されている設定を確認します。クライアントの上書き設定、サブスクリプションの更新、画面上の設定によって、ファイルの内容が上書きされる場合があります。再読み込み後、実行中の設定やログでチェック頻度を確認してください。

ログ、パネル、失敗時の再試行：バックグラウンド通信を抑える

普段はinfoを使い、電池消費の調査中はwarningも試して、詳細ログを保存する時間を短くします。debugは問題を再現するときに短時間だけ使う設定で、一晩中有効にする用途には向きません。ログの出力量は接続数やクライアントの実装によって変わります。ログレベルを変えれば決まった割合で節電できる、という意味ではありません。

log-level: warning

更新が続く接続一覧、リアルタイムの速度グラフ、外部コントロールパネルを閉じます。画面消灯後もクライアントがこれらの表示を更新するかどうかは、実装によって異なります。まずパネルを終了してから再測定してください。温度が明らかに下がった場合は、画面更新、ログ書き込み、通信量のどれが影響したのかをさらに切り分けます。

詳細ログは数分だけ有効にして、繰り返し発生するイベントを確認する

• 接続タイムアウトが繰り返し発生する：まず安定した別のノードに切り替え、再試行が減るか確認します。タイムアウトを短くしても、必ずしも省電力になるとは限りません。失敗後に何度も再接続すると、かえって通信が増えることがあります。
• DNSリクエストの失敗が繰り返し発生する：上流DNSに到達できるか、無効なノード経由になっていないか、名前解決のループが起きていないか確認します。上流DNSの数を際限なく増やして対処しないでください。
• 設定の読み込みやコアの起動が繰り返される：測定間隔をさらに短くするのではなく、バックグラウンド制限、クライアントのクラッシュ、自動切り替えスクリプトを優先して確認します。

ログを共有する前に、サブスクリプションURL、認証情報、ノードのパスワード、アクセス先ドメインを削除してください。切断から復旧までの状況が分かる範囲で十分で、通常は一日分の全ログは必要ありません。接続が安定したら、ログレベルを普段の設定に戻してください。

電池の最適化の対象外設定：バックグラウンド動作を安定させるもので、省電力機能ではない

対象外にすると、システムによるバックグラウンド動作の制限を緩和できます。画面消灯後の通信切断、VPNの終了、定期タスクの遅延には有効な場合がありますが、電池消費を自動的に減らすものではありません。クライアントが安定して動いているなら、「省電力」のために自動起動、バックグラウンド動作、高消費電力の権限をすべて許可する必要はありません。

一方、システムに停止させられてから何度も起動し直すと、VPNの確立、ドメインの名前解決、ノードへの接続が繰り返され、電池を消費します。「画面を点けるとすぐ復旧するが、消灯後数分で切断される」場合は、まずサービスを安定させてから、ヘルスチェックなどの定期処理を見直してください。

上記は一般的なメニュー名です。Androidのバージョン、地域別ファームウェア、メーカーのバージョンによって名称が異なる場合があります。見つからないときは、アプリアイコンを長押しして「アプリ情報」を開くか、システム設定で「電池の最適化」「バックグラウンドでの使用」「自動起動」を検索してください。最近使ったアプリ画面でのアプリ固定は、一部メーカー独自の補助機能にすぎず、電池関連の権限設定の代わりにはなりません。

AndroidのVPNとTUN：まずVPNの対象にするアプリを決める

Androidクライアントは通常、システムのVpnServiceで仮想ネットワークインターフェースを作り、データをプロキシコアに渡します。Linuxでtun.enableを有効にし、ルートを設定してネットワーク権限を付与する手順とは異なります。画面上の「VPNモード」が、直接編集できる同一のYAML設定に対応するとは限りません。

ブラウザー、チャットアプリ、プロキシ設定に対応していないアプリをまとめて振り分ける場合は、VPNによる接続が便利です。手動プロキシに対応した少数のアプリだけを接続する場合は、「ローカルプロキシポート」とVPNモードを比較できます。ただし、クライアントがプロキシサービスだけを起動できるか、対象アプリが実際にそのプロキシを使うか確認してください。

VPNの対象範囲を絞る際に確認する3つのポイント

1. プロキシ不要の通信はアプリ単位で除外します。クライアントの「アクセス制御」または「アプリ別プロキシ」で対象アプリを選び、「選択したアプリのみプロキシを使用」なのか「選択したアプリを除外」なのか確認してください。リストの意味を取り違えると、VPNの対象範囲がまったく逆になります。
2. ルールのDIRECTはVPNの迂回を意味しません。データがいったん仮想インターフェースに入り、その後コアが直接接続を判断する場合があります。アプリ単位の除外は通常それより前に行われますが、実装やDNSの挙動は実機で確認してください。
3. ローカルポートはVPN全体の代わりにはなりません。たとえば127.0.0.1:7890は、クライアントがそのポートで実際に待ち受けている場合にだけ使えます。AndroidのWi-Fi用HTTPプロキシはすべてのアプリやUDPをカバーするものではなく、モバイル回線にも自動で適用されません。

処理を1段減らすためだけに、安易にVPNを無効化しないでください。必要なアプリを洗い出し、通知、Webページ、音声通話、モバイル回線への切り替えを順に確認します。クライアントによってはユーザー空間のネットワークスタックを選べますが、名称や対応範囲は現在のバージョンで確認してください。すべての端末で最も省電力なスタックはありません。切り替え後はVPNを再接続し、UDP、IPv6、ドメインの名前解決を再テストしてください。

システムの「常時接続VPN」と「VPNを使わない接続をブロック」は、主に接続ポリシーを設定するもので、性能を最適化する機能ではありません。後者を有効にすると、VPNから除外したアプリが直接接続できなくなる場合があります。アプリ別の除外を試す前にこの2項目を確認し、システムによる遮断をルールの不具合と誤認しないようにしましょう。

システムの電池使用量とADBでバックグラウンド動作を確認する

まず「設定 → バッテリー → バッテリー使用量」を開き、プロキシクライアントの前面・バックグラウンドでの動作時間と、その時間帯の通信量を確認します。表示方法はメーカーによって異なります。バックグラウンド時間が長いだけではサービスが常駐していたことしか分からず、異常の証拠にはなりません。安定したネットワークで画面を消していても発熱が続く場合は、無限ループや大量の再試行をさらに調べてください。

パソコンがある場合は、USBデバッグを有効にして接続を許可した後、以下の読み取り専用コマンドを実行できます。ADBはAndroid SDK Platform-Toolsに含まれており、これらの確認にroot権限は不要です。出力が長くなることがあるため、パソコンに保存し、プロセス名、UID、時間帯で検索すると便利です。

adb devices
adb shell pm list packages | grep -i clash
adb shell dumpsys battery
adb shell dumpsys batterystats --charged > battery-session.txt
adb shell dumpsys deviceidle > deviceidle-session.txt
adb shell dumpsys connectivity > connectivity-session.txt

grepはパソコン側で出力を絞り込むコマンドです。Windows PowerShellではSelect-String clashに置き換えられます。パッケージ名にclashが含まれない場合、最初の検索では結果が出ないことがあります。パッケージ一覧全体から、実際に使っているクライアントのパッケージ名を探してください。別のクライアントのパッケージ名をそのまま使って統計を解釈しないでください。

• dumpsys battery：電池残量、充電状態、温度の項目を確認します。温度は通常、摂氏の10倍の値で表示されます。端末の出力形式に合わせて解釈してください。
• batterystats --charged：該当する充電統計期間の開始以降の記録を表示します。直近60分だけを切り出したレポートでも、正確なハードウェアの消費電力測定でもありません。
• dumpsys deviceidle：アイドル状態と関連する対象外設定を確認します。出力1つから節電量を直接計算できるわけではありません。
• dumpsys connectivity：VPNと下位ネットワークの状態を確認する際に役立ちます。確認できる情報はAndroidのバージョンによって異なり、出力にネットワーク識別情報が含まれる場合もあります。

USB接続中は同時に充電されることがあり、電池消費の比較に影響します。動作状況の記録と電池の減り方の測定は分けて行い、充電中の電池残量の変化を画面消灯時の消費量として扱わないでください。これらのファイルを共有する前に、ネットワーク名、アドレス、アプリの使用情報も確認してください。

症状に合わせて設定を絞り込み、普段の使い方で再確認する

最終的に、安定して使える設定を保存します。ヘルスチェックは900秒から試し、サブスクリプションの更新頻度は必要に応じて設定します。詳細ログは問題を再現するときだけ有効にし、常駐が必要なクライアントに限ってバックグラウンド権限を付与してください。ノードの故障に気づくのが遅い場合は、チェック間隔を少しずつ短くしましょう。数十秒ごとの全ノード測定に戻す必要はありません。

調整後は、画面消灯中の通知、Wi-Fiとモバイル回線の切り替え、音声通話、再起動後の接続状態を順に確認してください。省電力と安定性の両方を検証する必要があります。発熱やCPU使用率の高さが続く場合は、クライアントとコアのバージョン、OSのバージョン、最小限の再現設定、短時間のログを添えて報告してください。設定項目の意味は設定リファレンス、基本的な接続の問題はトラブルシューティングで確認できます。