Clash Meta Android版のバッテリー消費が多いときの対処法｜バックグラウンド実行と電池最適化

1. VPN常時接続とアプリの電池消費を切り分ける

AndroidのステータスバーにVPNアイコンが表示されていても、システムにVPNインターフェースが作成されていることを示すだけで、CPUが常に高負荷で動作しているわけではありません。Clash Metaなどmihomoを搭載したAndroidクライアントでは、通常、フォアグラウンドサービスの通知によってプロキシサービスを維持します。通知を非表示にしても、通信処理が自動で停止するわけではありません。通知が常に表示されているかではなく、同じ時間帯のバッテリー残量の変化、実際の通信量、ログを確認して消費電力を判断しましょう。

Androidのバッテリー使用量では、VPN経由の通信にかかった電力がVPNアプリに計上されることもあります。集計方法はOSのバージョンやメーカーによって異なるため、「アプリの電池使用量でクライアントが1位」というだけでは、カーネルの異常とは判断できません。写真のバックアップ、動画の先読み、システムアップデートなどの通信が、クライアントの接続一覧に継続的な通信として表示されることもあります。

まず記録しておきたい4つの項目

• OSとカーネル：「設定」→「デバイス情報」でAndroidのバージョンを記録します。クライアントの「バージョン情報」またはカーネル情報で、クライアントとmihomoのバージョンも確認してください。これらは別々のバージョン番号です。
• バッテリー消費を確認する時間帯：「設定」→「バッテリー」→「バッテリー使用量」で集計期間を確認し、充電前後のデータを混ぜないようにします。
• ネットワークの状態：Wi-Fiかモバイルネットワークか、電波の強さ、基地局の切り替わりが頻繁かを記録します。電波が弱いと、無線通信自体の電力消費がプロキシ処理を上回る場合があります。
• 発生している現象：継続的な発熱、画面消灯後の切断、ネットワーク切り替え後の再接続、ログ画面を開いたときだけ消費電力が増える、といった症状を区別します。

2. 時間を決めて消費電力を比較する

バックグラウンド権限、DNS、プロキシノードを一度に変更しないでください。原因を特定するには、1回のテストで変更する条件を1つに絞ります。電波が安定した同じWi-Fiを使い、ダウンロード中のアプリを終了し、画面の明るさとテスト時間もそろえましょう。以下の時間は切り分け用の目安であり、実測結果や標準的な消費電力を示すものではありません。

バッテリー残量のパーセント表示は大まかな値です。1回のテストで1ポイントしか差がなくても、設定の効果があったとは判断できません。条件をそろえて、さらに2回ほどテストしましょう。テスト中は充電せず、画面録画も行わないでください。プロキシを停止したときに「VPNなしで接続をブロック」が有効だと、基準値の測定中にインターネットへ接続できないことがあります。設定を記録したうえで一時的にオフにし、通常の接続状態と比較できるようにしてください。

接続一覧からバックグラウンド通信の原因を探す

クライアントの「接続」画面を開き、画面を消す前から通信量が増え続けている接続を確認します。まずクラウドストレージの同期、写真のバックアップ、アプリストアの更新を一時停止して再テストしてください。クライアントによってはアプリ名が表示されますが、接続先のドメイン名やIPアドレスしか表示されない場合もあります。共有CDNのドメイン名だけを根拠に、特定のアプリだと判断しないでください。放置中の通信量がほとんどないのに発熱が続く場合は、エラーによる再試行、速度測定タスク、ログを確認しましょう。

3. 電池最適化の対象外設定は切断対策。省電力設定ではない

クライアントを「制限なし」に設定する主な目的は、バックグラウンドでプロキシサービスが凍結・終了されるのを防ぐことです。消費電力が下がるとは限らず、バックグラウンドアプリの通信が長時間続く可能性もあります。画面消灯後にサービスが停止する、通知が何度も再表示される、画面点灯後に接続が集中して復旧するといった症状がある場合に、バックグラウンド制限を優先して確認してください。

メニューの場所はOSのバージョンや地域によって異なります。以下は一般的な設定経路です。見つからない場合は、システム設定で「電池の最適化」「バックグラウンドでの使用」「自動起動」などを検索してください。ホーム画面でクライアントのアイコンを長押しし、「アプリ情報」を開く方法が、通常もっとも確実です。

VPN常時接続とバックグラウンド権限は別々に確認

標準Androidでは通常、「設定」→「ネットワークとインターネット」→「VPN」→クライアント横の設定アイコンから確認できます。「常時接続VPN」は指定したVPNを維持する設定で、「VPNなしで接続をブロック」はVPNを経由しない通信を制限する設定です。どちらも省電力設定ではなく、サブスクリプションの失効を直す機能でもありません。クライアントが対応していない場合、設定項目を利用できないことがあります。

まず通常のバックグラウンド設定でクライアントが安定して動くことを確認し、そのうえで常時接続VPNが必要か判断しましょう。すべてのアプリを電池最適化の対象外にせず、常時動作が必要なクライアントだけを許可してください。設定変更後は、画面を消して60分間のテストを行い、続けてWi-Fiからモバイルネットワークに切り替えたときの復旧も確認します。

4. TUN、アプリの振り分け、再接続ループを確認する

Androidクライアントは通常、AndroidのVPNServiceを使ってシステムの通信を取り込みます。デスクトップクライアントがシステム権限でTUNデバイスを作成する場合とは仕組みが異なります。画面に表示される「TUN」「VPNモード」「ネットワークスタック」の意味は、クライアントによって独自に定義されている場合があります。Windowsのサービスモード設定をそのまま当てはめたり、すべてのAndroidクライアントでsystem、gvisor、mixedを切り替えられると考えたりしないでください。

まず通信を取り込むアプリを絞り、次にネットワークスタックを比較する

1. クライアントがアプリごとの通信振り分けに対応している場合は、ブラウザーと必要なアプリだけを対象にしたテスト範囲を作り、放置中の通信量が減るか確認します。VPNを使うアプリを複数同時に有効にしないでください。パケットキャプチャ、ファイアウォール、広告ブロックのアプリもVPN接続枠を使用する場合があります。
2. ルールモードのDIRECTは、通信の送信先に直接接続するという意味であり、その通信がVPNインターフェースを通らないとは限りません。アプリをVPNの対象から外すには、直結ルールを追加するだけでなく、クライアントのアプリ別バイパス機能を確認してください。
3. ネットワーク切り替え後もログにタイムアウトが出続ける場合は、まず接続可能と確認できている別のノードに切り替え、同じ接続先にアクセスできるか確認します。利用できないノードや到達不能なDNSサーバーが、再試行の繰り返しを引き起こすことがあります。
4. クライアントにネットワークスタックの設定項目がある場合に限り、互換性を1つずつ比較してください。どの端末でも消費電力が最小になるネットワークスタックはありません。切り替え後は、Web閲覧、メッセージアプリ、UDP通信、スリープからの復帰をあわせて確認しましょう。

バッテリーの表示を下げるためにVPNをオフにし、そのままアプリがプロキシ経由で通信していると思い込まないでください。HTTP混合ポートの7890はローカルの待ち受けポートにすぎません。ポートがあるだけでAndroidアプリが自動的に利用することはありません。アプリ側でプロキシを設定するか、クライアントのシステム通信取り込み機能を使う必要があります。

5. DNS、スニッフィング、ヘルスチェックのバックグラウンド負荷

DNSの機能を有効にしているだけの場合より、DNSリクエストが失敗して何度も再試行される状況に注意が必要です。クライアントのログでtimeout、DNS、network is unreachableを検索し、放置中もエラーが続いていないか確認します。DNSを変更する前に、スマートフォンの時刻が正しいことと、設定済みのDNSサーバーにネットワークから接続できることを確かめてください。

fake-ipは省電力専用の設定ではない

enhanced-mode: fake-ipは仮想IPアドレスでドメインとの対応を保持し、ルールによる判定をしやすくします。すべてのリクエストがリモートサーバーに送られるという意味ではありません。redir-hostも名前だけで省電力だとは判断できません。安易にモードを切り替えると、LAN機器の検出や実際の名前解決結果に依存するアプリに影響することがあります。互換性の問題として検証してください。

以下は設定項目の例であり、サブスクリプション設定の全体ではありません。223.5.5.5は暗号化されないDNSの例です。問い合わせの可視性は暗号化DNSと異なり、すべてのネットワークから到達できるとは限りません。既存の設定でnameserver-policy、proxy-server-nameserver、暗号化DNSを使用している場合は、名前解決に必要な設定を維持し、ブロック全体を置き換えないでください。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5

不要な速度測定の頻度を下げる

• ヘルスチェック：proxy-providers内のhealth-check.intervalと、url-test・fallbackグループのintervalを確認します。これらの間隔は通常、秒単位です。現在60秒なら、安定性に問題がないことを確認したうえで600秒に変更して比較できます。サブスクリプションの更新間隔と速度測定の間隔を混同しないでください。
• ノード数：ノード100個を60秒ごとにすべてチェックすると、理論上は1分あたり約100回のプローブが発生します。実際の回数は、必要に応じたチェックや利用状況にも左右されます。バックグラウンドのリクエストを抑えるには、何度も手動で「すべて測定」するより、測定対象のノードを減らすほうが効果的です。
• ドメインスニッフィング：現在のルールでドメインの補完にスニッフィングを使っていない場合は、クライアントのスニッフィング機能を一時的にオフにして再テストできます。ドメインの復元に依存するルールでは判定結果が変わる可能性があるため、消費電力だけでなく通信の振り分けも確認してください。
• ログレベル：トラブルシューティングが終わったら、log-levelをdebugからinfoまたはwarningに戻し、ログ画面を開き続けないようにします。画面を点灯したまま監視した状態を、普段の画面消灯時の消費電力と比較しないでください。

6. 症状ごとに設定を絞り込み、再現できる結果を残す

次の状態を確認できれば、切り分けを終える目安になります。バックグラウンド接続が安定している、放置中の通信元が特定できている、エラーログが繰り返し出ない、同じ条件で消費電力の差を再現できる、の4点です。すべての機種に共通する一定の割合を目指したり、バックグラウンド動作を維持するために省電力制限を一度にすべて無効にしたりしないでください。

異常が続く場合は、スマートフォンの機種名、Androidのバージョン、クライアントとmihomoのバージョン、使用ネットワーク、テスト時間、個人情報を伏せたエラー部分をまとめてください。特定のサブスクリプション設定だけで発生するのか、ノードを変更すると解消するのかも記録します。こうした情報があれば、クライアント、ルール設定、ネットワーク環境のどこに原因があるかを切り分けやすくなります。基本的な設定方法は入門ガイド、接続やDNSの詳しい確認方法はトラブル対処をご覧ください。