Androidのプロキシアプリの電池消費が多いときの対処法｜電池の最適化・バックグラウンド実行・TUN設定

まず切り分ける：電池消費の増加、使用量の記録、バックグラウンド切断

Androidのプロキシアプリの電池消費が多いからといって、電池使用量の順位だけで原因を判断することはできません。AndroidのVpnServiceで通信を引き受けると、ネットワークの利用や関連する電池消費の一部がVPNアプリに計上される場合があります。計上方法はAndroidのバージョンやメーカー独自のシステムによっても異なります。使用量の順位が高くても、端末全体の電池をその割合だけアプリ単独で消費したとは限りません。

まず同じ条件で端末全体の電池残量の減り方を比べ、次に接続の安定性を確認し、最後にバックグラウンド権限や設定を見直しましょう。画面消灯後に通信が切れるだけなら、バックグラウンド制限を優先して確認します。待機中の電池消費も明らかに増えている場合は、ヘルスチェック、再接続、実際のバックグラウンド通信、モバイル回線の電波状況を調べましょう。両方の問題が同時に起きることもありますが、対処方法は異なります。

比較できる待機時の記録を取る

各回60分以上、変更する条件は一つだけ

同じ場所、同じネットワーク、近い電池残量で測定します。たとえば、どの回も残量80％前後から始めます。システム更新、写真のバックアップ、大容量ファイルのダウンロードを停止し、クライアントのリアルタイム接続画面を閉じて、画面を消灯します。1回目はプロキシサービスを停止し、2回目は同じサブスクリプションを有効にします。3回目は疑わしい設定を一つだけ変更します。各回60分以上観察し、負荷の低い環境では2～3時間に延ばします。

• 端末全体の変化を記録：開始時と終了時の電池残量、測定時間、画面点灯時間、充電の有無。
• ネットワーク環境を記録：Wi-Fiかモバイルデータか、電波が大きく変動したか、ネットワークを切り替えたか。
• クライアントの状態を記録：製品名とバージョン、カーネルのバージョン、設定名、アプリごとのルーティングの有無。
• 実行中の処理を記録：音楽再生、メッセージ受信、写真のバックアップ、テザリングの有無。

たとえば、2時間で残量が80％から76％になった回と、80％から73％になった回を比べると、平均の減少率はそれぞれ1時間あたり2ポイント、3.5ポイントです。これは計算方法の例であり、製品の実測値や合格基準ではありません。電池残量の表示には丸め誤差があるため、1回だけの1ポイント差では判断できません。測定を繰り返し、温度、電波状況、バックグラウンド処理の違いも除外してください。

電池の最適化から除外する：安定性に必要な場合だけ許可

AndroidのDoze、アプリの待機制限、メーカー独自のバックグラウンド管理は、バックグラウンド通信やタスクの実行に影響することがあります。クライアントを「制限なし」にすると、一部の電池制御の影響を抑えられますが、ノードのタイムアウト、DNSループ、誤ったルールが直るわけではなく、プロセスが終了しなくなる保証もありません。画面消灯後に切断する、サービスが繰り返し終了するといった現象がある場合に、バックグラウンド権限を重点的に確認しましょう。

Androidのバージョンに合わせてアプリの電池設定を探す

1. クライアントのアイコンを長押しして「アプリ情報」を開き、「電池」または「アプリの電池使用量」を確認します。
2. 一部のAndroid 13標準UIでは、「設定」→「アプリ」→「すべてのアプリを表示」→クライアント→「アプリの電池使用量」の順に進み、「制限なし」を選べます。ほかのバージョンでは「バックグラウンドでの使用を許可」などと表示される場合があります。選べる項目は端末によって異なります。
3. 一部のHyperOS端末では、「設定」→「アプリ設定」→「アプリ管理」→クライアント→「省電力ポリシー」から「制限なし」を選べます。この項目が見つからない場合は、設定画面で「省電力ポリシー」を検索してください。
4. Samsung端末では、「設定」→「バッテリー」→「バックグラウンドでの使用制限」を開き、クライアントが「スリープ中のアプリ」または「ディープスリープ中のアプリ」に入っていないか確認します。上位メニューの構成はOne UIのバージョンによって異なります。
5. 設定は一度に一つだけ変更し、画面を消灯して30～60分テストします。その後、通知領域のサービス表示、ネットワーク接続、ログが途切れていないかを確認してください。

「自動起動を許可」「最近使ったアプリでロック」「電池の最適化から除外」は、それぞれ異なる制御設定です。最近使ったアプリでロックしても、ワンタップで一括終了されにくくなるだけで、Androidが動作を保証するわけではありません。再起動後に自動接続する必要がある場合は、クライアントの起動時実行設定とシステムの自動起動権限も確認します。自動接続が不要なら、待機時のテストのためだけに有効にする必要はありません。

最適化から除外した後に端末全体の電池消費が増えた場合は、接続やログを確認してください。以前は制限されていた高頻度の処理が、継続して動き始めた可能性があります。最適化からの除外で変わるのは処理の実行機会であり、処理そのものの効率ではありません。

VPN常時接続とTUN：実際の通信経路を確認する

Android向けのClash系クライアントでは、通常VpnServiceで仮想ネットワークインターフェースを作り、カーネルや連携する転送コンポーネントで通信を処理します。デスクトップ向けの「TUNを無効にしてシステムプロキシだけを使う」という手順は、そのままスマートフォンには適用できません。AndroidのWi-Fiプロキシはネットワークごとに設定するもので、すべてのアプリが従うわけではなく、端末全体に適用される汎用的なシステムプロキシでもありません。

クライアント画面の「TUN」「VPNモード」「ネットワークスタック」は、異なる実装レイヤーを指す場合があります。製品によっては独立して無効にできるTUN設定がなく、VPNサービスを停止すると通信の引き受け自体が終了します。ネットワークスタックの選択肢もクライアントやカーネルのバージョンに依存するため、特定のスタックに変更すれば常に省電力になるとは限りません。

用途に合わせて通信の対象範囲を選ぶ

• 一部のアプリだけプロキシを使う：クライアントが「選択したアプリのみ」をサポートしている場合は、必要なアプリだけを対象にできます。設定画面の説明を読み、選択したアプリが「VPNを経由する」のか「VPNをバイパスする」のかを確認してください。
• ルールで通信を振り分ける：ルールモードを維持し、国内サービスやLAN内の宛先が想定どおりDIRECTルールに一致することを確認します。通信をVPNに通した後でDIRECTに振り分けても、VPNの処理経路をまったく通らないという意味ではありません。
• 接続を維持する：システムの「常時接続VPN」を検討できます。一部の標準Androidでは、「設定」→「ネットワークとインターネット」→「VPN」→対象の接続の設定アイコンから設定します。
• VPNを経由しない通信を防ぐ：必要な場合は「VPNなしの接続をブロック」を検討します。これは接続ポリシーであり、省電力設定ではありません。アプリのVPNバイパスやLANアクセスと併用する場合は、必ず実機で動作を確認してください。

サブスクリプション、ヘルスチェック、再接続：定期的な起動要因を探す

クライアントがアイドル状態でも、設定に定期処理がないとは限りません。サブスクリプションの自動更新、プロキシプロバイダーのヘルスチェック、url-testポリシーグループのテスト、使用中のアプリ自体のハートビートなどがバックグラウンド通信を発生させる場合があります。複数の機能が同じノードを重複してテストすることもあるため、クライアントの設定と実際に適用されている設定の両方を確認してください。

まず確認する4項目

1. ヘルスチェックの間隔：mihomoの設定では、プロキシグループやプロキシプロバイダーのヘルスチェックに指定するintervalの単位は通常、秒です。30秒なら1時間に120回、300秒なら12回の実行タイミングがあります。実際のリクエスト数はノード数、遅延チェック、実装方法にも左右され、電池消費の割合と直接結び付けることはできません。
2. 遅延チェック：対応している場合はlazy: trueを設定し、使用していないグループやプロバイダーの不要なチェックを減らせるか確認します。フィールドは該当する設定階層に記述してください。クライアントによる上書きで最終的な設定が変わることもあります。
3. サブスクリプションの更新：通常の利用で、サブスクリプションを毎分更新する必要はありません。プロバイダーの更新頻度に合わせ、数時間ごとまたは手動で更新するようにして、設定のダウンロード、解析、再読み込みが繰り返されるのを防ぎます。
4. 接続失敗時の再試行：ログにタイムアウトが続けて記録される場合は、まず安定して接続できるノードを選び、再接続が繰り返されるか確認します。速度測定の間隔を延ばしても、使用中のノードが継続的に接続不能になる問題は解決しません。

通信チェックを減らすために、自動選択の設定を一度にすべて削除するのは避けてください。まず短すぎるテスト間隔を、たとえば300秒に変更し、ノード切り替えの使い勝手と待機時の通信量を確認します。これは原因を調べるための出発点であり、すべてのサブスクリプションに共通する推奨値ではありません。サブスクリプション管理機能によって更新時に変更が上書きされる場合があるため、クライアントが対応する永続的な上書き方法を使い、更新後に実際の設定を確認してください。

DNS、ログ、バックグラウンド通信：継続的な動作を特定する

DNSエラーは通信経路を修正する。モード変更だけで済ませない

ログに名前解決のタイムアウトが繰り返し記録される場合は、DNSの上流サーバーに到達できるか、プロキシサーバーのホスト名を解決できるか、DNS通信自体が未確立のプロキシに依存していないかを確認します。mihomoのproxy-server-nameserverはプロキシノードのホスト名解決に利用できますが、既存のDNSルーティング設計との整合性も必要です。フィールドを一つ追加しただけで問題が解決したと判断しないでください。

Fake-IPは仮想アドレスを使ってドメインと接続の対応関係を維持する仕組みであり、それだけで電池消費の異常が起きるわけではありません。特定のアプリで実際に互換性の問題が起きた場合に限り、関連するフィルターや名前解決の設定を見直してください。Androidの「プライベートDNS」によって、アプリの名前解決経路がクライアントの設定と異なる場合もあります。切り替える前に元の設定を記録し、DNS関連の設定を複数同時に変更して原因が分からなくならないようにしましょう。

診断ログの記録時間を短くし、実際の通信元を確認する

• 通常利用ではクライアントの既定のログレベルを維持します。一時的にdebugを有効にする場合は、問題を再現できる5～10分間だけ記録し、その後元に戻してください。
• 接続一覧やリアルタイム速度画面を更新し続けて画面を点灯させた状態を、画面消灯時の待機結果として扱わないでください。
• 写真のアップロード、クラウドストレージの同期、動画の先読みなど、長時間続く通信がないか確認します。プロキシクライアントは、こうしたアプリの実際の通信を中継しているだけの場合があります。
• Wi-Fiとモバイルデータを比べてください。電波が弱かったり再接続が頻繁に起きたりすると、プロキシの設定を変えていなくても無線通信自体の電池消費が増えることがあります。

詳細な記録：ADBで電池とアイドル状態を確認する

デバッグに慣れているユーザーは、パソコンからADBを使ってシステムの記録を取得できます。以下のコマンドにroot権限は不要ですが、USBデバッグを有効にし、パソコンを承認する必要があります。出力される項目や確認できる情報はAndroidのバージョンによって異なり、個々のカウンターをクライアントの電池消費量に直接換算することはできません。

adb shell dumpsys battery
adb shell dumpsys batterystats --charged
adb shell dumpsys deviceidle

dumpsys batteryでは電池残量、充電状態、温度を確認できます。batterystatsではシステムが累積した電池関連の動作を確認できます。deviceidleでは端末のアイドル機能の状態を確認できます。通常の使用条件が変わるため、テスト目的で普段使いのスマートフォンを無理にアイドル状態へ移行させないでください。

USB接続中はスマートフォンが同時に充電される場合があるため、これらのコマンドはテストの前後に記録する用途に適しています。長時間の比較を安定して行うには、電源を外してから記録を始めてください。ワイヤレスデバッグも通信を発生させるため、負荷がゼロとは限りません。ログを共有する前に、公開したくないサブスクリプションURL、ノードの認証情報、アクセス先ドメイン、アプリのパッケージ名などを削除してください。

最終確認リスト：安定性と電池消費を分けて検証する

1. 基準を確認：同じネットワーク、同じ場所で、サービスの有効時と停止時を最低1回ずつ比較します。電池使用量の順位を、端末全体の電池減少量の代わりにしないでください。
2. バックグラウンド動作を確認：画面消灯後に切断する場合に限り、電池制限や自動起動などの権限を一つずつ許可し、変更内容を毎回記録します。
3. 通信を確認：必要に応じてアプリごとに通信を振り分け、不要なバックグラウンド通信を防ぎます。メッセージ、LAN、必要なアプリが引き続き正常に動作することも確認してください。
4. 設定を確認：ヘルスチェックの間隔、サブスクリプションの更新、ノード接続失敗時の再試行を見直し、設定更新後も上書きが有効か確認します。
5. 診断の終了を確認：通常のログレベルに戻し、リアルタイム画面を閉じてから、もう一度画面消灯時の動作をテストします。
6. 異常が続く場合は情報を添えて報告：スマートフォンの機種、Androidのバージョン、クライアントとカーネルのバージョン、再現時刻、ネットワークの種類、個人情報を伏せたログを伝えてください。

特定のアップデート後に限り、同じ条件で再現できる待機時の差が生じた場合は、そのバージョン変更を報告に含めてください。すべてのTUNやすべてのClash系クライアントの問題だと決めつけるのは避けましょう。クライアントを選ぶ際はダウンロードページで対応プラットフォームとメンテナンス状況を確認できます。設定の考え方は利用ガイドを参照してください。必要な接続の安定性を保ちながら、根拠をもとに特定できる余分な動作を減らすことが大切です。