スマホのプロキシアプリがバッテリーを消費する原因と対策｜バックグラウンド設定

まず切り分ける：プロキシの電池消費、通信量の計上、バックグラウンドでの切断

スマホでプロキシを有効にしたあと、バッテリー使用状況でクライアントの割合が増えても、プロキシのコアが常に高負荷で動作しているとは限りません。AndroidのVPNサービスやiOSのネットワーク拡張は、ほかのアプリからの通信を処理します。この通信がシステム上でどう計上されるかは、OSのバージョンや端末の実装によって異なります。アプリのランキングだけで判断せず、端末全体の電池残量の減り方、実際の通信量、発熱を確認しましょう。

よくある誤解は、画面ロック中にバックグラウンド動作が止まった状態を「省電力できた」と捉えることです。ロック後に通知が遅れ、ロック解除後にノードへ再接続する場合、電池の減りが遅くなったように見えても、ネットワークサービスが停止しているだけかもしれません。不要な起動や再試行を減らしつつ、必要な接続を維持することが大切です。

症状から最初に確認することを決める

• 画面ロック中も明らかに発熱する：通信の送受信が続いていないか、ノードの再接続を繰り返していないか、速度測定や大量のエラーログが発生していないか確認します。
• モバイル通信中だけ電池消費が大きい：電波強度とネットワークの切り替わり回数を比べます。電波が弱いと、無線通信にかかる電力がプロキシの処理自体を上回ることがあります。
• 画面ロックからしばらくすると通信が切れる：まずAndroidのバッテリー制限、またはiOS VPN拡張の切断履歴を確認します。最初にDNSを変更する必要はありません。
• バッテリー使用割合は高いが、端末全体の待機時の減り方は正常：設定はそのままにして、同じ条件での電池残量の減少量を引き続き確認します。

60分間の比較テストで、バッテリー使用割合だけを見た調整を避ける

スマホの機種、OSのバージョン、クライアントとコアのバージョン、ネットワークの種類、使用中のノードを記録します。バージョンはクライアントの「バージョン情報」で確認し、「最新版」とだけ記録しないでください。テスト中はWi-Fi、ノード、画面の状態、バックグラウンドアプリを固定し、OSのアップデート、写真のバックアップ、大容量ダウンロードを一時停止します。設定は毎回ひとつだけ変更してください。

1. サブスクリプションとルールの更新を済ませ、初回読み込みと接続が落ち着くまで5分待ちます。
2. 画面をロックした状態で60分間放置し、開始時と終了時の電池残量、プロキシの通信量、切断回数、端末の温度感を記録します。
3. 自動速度測定を60秒から600秒に変更するなど、変数をひとつだけ調整し、同じ条件でもう一度テストします。
4. 少なくとも2回繰り返します。1時間あたりの差が1ポイント程度なら、電池残量の表示が整数に丸められる影響を避けるため、3時間に延長してください。

たとえば開始時が80%、終了時が77%なら、この1時間で端末全体の電池残量が3ポイント減ったことを示します。「プロキシが3%消費した」という意味ではありません。以下の記録表は記入例であり、特定機種での実測結果ではありません。

プロキシをオフにすると、アプリへの接続可否が変わります。バックグラウンド通信が止まることもあれば、再試行が繰り返されることもあるため、最初の測定は基準として使うもので、プロキシの消費電力だけを厳密に分離する実験ではありません。公開ログにサブスクリプションURL、ノードのパスワード、アクセス履歴の全体を残さないでください。

自動速度測定と重複するルール更新を減らす

どの機能が自動的に接続を開始するか確認する

ポリシーグループの自動選択、ノードプロバイダーのヘルスチェック、ホーム画面での遅延更新は、それぞれ接続テストを行う場合があります。1回のヘルスチェックで転送されるデータは通常わずかですが、数百のノードを短い間隔で繰り返し確認すると接続数が増え、モバイル通信の無線モジュールが頻繁にアクティブになります。クライアント画面で定期速度測定をオフにしても、設定内のヘルスチェックまで無効になるとは限りません。

• 速度測定の間隔：まず600秒に設定して様子を見ます。ネットワークが安定している場合は1800秒も試せます。間隔を長くすると、障害の検知が遅れる可能性があります。
• ノード数：自動テストの対象を減らし、実際に使う地域やポリシーグループだけを残します。サブスクリプション内の全ノードを毎回確認する必要はありません。
• 手動の速度測定：トラブルシューティング時に使い、全ノードの測定を連続して実行しないようにします。テスト自体が余計な負荷にならないよう注意してください。

mihomoのノードプロバイダーでは、health-check.intervalを秒単位で指定します。health-check.lazyを有効にすると、プロバイダーのノードを使用していないときに通常の周期でチェックするのを避けられますが、すべての接続テストが止まるわけではありません。ポリシーグループのurl-testには独立したintervalがあるため、こちらも確認してください。モバイルクライアントによっては、これらの項目を画面から変更できません。

サブスクリプション更新、ルールのダウンロード、ヘルスチェックを区別する

サブスクリプション更新はノード設定の取得、ルールプロバイダーの更新は振り分けルールのダウンロード、ヘルスチェックはノードの接続確認を行います。それぞれ別の機能です。ノードとルールの更新を1日1回（86400秒）に設定する方法は、一般的な使い方の目安になります。サービス提供元からより短い間隔を指定されている場合は、必要に応じて調整してください。

「ルールを常に最新にする」ために60秒ごとに更新するのは避けてください。更新をすべて無効にすることもおすすめしません。アプリ側の定期更新と、設定されたプロバイダー側の定期更新が重複していないか確認しましょう。サブスクリプションの変更頻度が高く、更新ごとにコアが再読み込みされる場合は、ログを見て周期的な再接続が起きていないか確認します。上書き設定を保存して調整したあとは、サブスクリプションの更新後に最終的な適用設定を確認してください。

DNSと接続の再試行：キャッシュより先にエラーを修正

DNSクエリだけが継続的な電池消費の原因になることは通常ありません。確認したいのは、名前解決に失敗してリクエストが繰り返されていないか、上流DNSに接続できるか、プロキシサーバーのホスト名を解決できるか、DNSリクエストが誤ってプロキシの入口に戻りループしていないかです。同じドメインが短時間に何度も現れ、タイムアウトや接続失敗、ノードの頻繁な切り替わりを伴うことがあります。

1. ログを開き、一時的にレベルをinfoにして2～5分確認します。原因を特定したら連続監視を終了し、詳細ログを長時間有効にしたままにしないでください。
2. 同じWebサイトにWi-Fiとモバイル通信からそれぞれ接続してテストします。片方のネットワークだけで失敗する場合は、まずそのネットワークから上流DNSに接続できるか確認してください。
3. DNSの上流への通信が直通かプロキシ経由か、またノードのホスト名をどの経路で名前解決するかを確認します。mihomoのproxy-server-nameserverはプロキシノードのホスト名を解決するための設定で、通常のドメインすべてに使うDNSサーバーとは異なります。
4. ループやタイムアウトを修正してから電池消費を比較してください。上流DNSの変更、名前解決モードの切り替え、ルーティングの調整を同時に行わないでください。

DoHやDoTは暗号化された名前解決を提供しますが、あらゆる方式より省電力になるわけではありません。接続の再利用、上流の応答時間、失敗時の再試行が結果に影響します。また、「上流DNSは多いほど安定する」と考えるのも避けてください。並行して問い合わせる実装では、上流を増やすとリクエスト数が増えることがあります。

Androidのバックグラウンド動作を維持する：必要なサービスだけ制限を解除

Androidのプロキシは通常、VpnServiceを使ってローカルVPNインターフェースを作成します。継続して動作している場合は、通常、フォアグラウンドサービスの通知が表示されますが、大量の通信が行われているとは限りません。Doze、アプリのスタンバイ制限、メーカー独自のバックグラウンド管理は接続に影響する場合があります。動作はAndroidのバージョン、クライアントの実装、メーカーの設定によって異なります。

Android 14・15の設定例

標準に近いAndroidを例にすると、「設定」→「アプリ」→「すべてのアプリを表示」→プロキシクライアント→「アプリのバッテリー使用量」と進み、「バックグラウンドでの使用を許可」や「制限なし／最適化／制限」などの設定を確認します。項目名や階層はOSのバージョンによって異なる場合があります。アプリのアイコンを長押しして「アプリ情報」を開き、ページ内で「バッテリー」を検索する方法もあります。

• 接続が安定している：まずは「最適化」のままにします。バックグラウンド動作を維持するために、あらかじめすべての権限を許可する必要はありません。
• 画面ロック後に切断が再現する：プロキシクライアントだけを「制限なし」に変更し、画面ロックを使って再テストして、本当に改善するか確認します。
• 再起動後に自動で起動しない：クライアントの自動起動設定と、メーカー独自の自動起動やバックグラウンド動作の許可を確認します。
• 省電力モードで異常が起きる：省電力モードのオン・オフを切り替えて個別にテストし、差を記録します。システムの省電力機能をすべて一度に無効にしないでください。

バッテリー最適化の対象から除外すると、一部のバックグラウンド制限を減らせますが、コアが通信を処理するための計算量は減りません。すべてのアプリを対象外にするのも避けてください。ほかのバックグラウンド処理が増え、端末全体の待機時消費電力が上がることがあります。最近使ったアプリの画面でアプリをロックする機能は、一部メーカーの補助機能であり、サービスが動作しているかの確認には代わりません。

「VPNを常時接続」とVPN未接続時の通信遮断について

一部の端末では、「設定」→「ネットワークとインターネット」→「VPN」→対象のVPNの設定から「VPNを常時接続」を有効にできます。利用できるのはクライアントが対応している場合に限ります。「VPN未接続時の接続をブロック」は通信を遮断する機能です。VPNサービスに障害が起きると端末全体がインターネットに接続できなくなる場合があり、省電力機能ではありません。有効にする前に、切断後の復旧方法を確認してください。

デバッグ環境がある場合は、Androidプラットフォームツールで状態を確認できます。以下のコマンドは情報を読み取るだけで、バッテリーの設定は変更しません。

adb shell dumpsys deviceidle
adb shell dumpsys battery

前者は端末のアイドル状態に関する情報を確認するコマンドで、後者はバッテリー状態のスナップショットを表示します。どちらも特定のプロキシコアの正確な消費電力は示しません。USB接続中は充電状態やアイドル条件が変わるため、ケーブルを接続した状態の結果を通常の待機時の結果と見なさないでください。

iOSのバックグラウンド設定：VPN拡張とオンデマンド接続を確認

iOSのプロキシクライアントでは通常、メインアプリで設定を行い、Network ExtensionのVPN拡張が通信を処理します。メインアプリが画面に表示されていなくても、VPN拡張が停止しているとは限りません。メインアプリを常に開いておくことも、動作を維持するために必要な方法ではありません。拡張のクラッシュ、設定の再読み込み、システムのリソース制限などでサービスが中断することがあるため、クライアントのログも確認してください。

まずシステムのバッテリー使用状況を確認する

iOS 18の場合、「設定」→「バッテリー」を開き、「過去24時間」と「過去10日間」を比較します。異常が見られる時間帯をタップし、画面の使用状況とバックグラウンドでの動作を確認してください。異常がインターネット共有、電波の弱い場所での移動、大量の動画通信と重なっている場合は、プロキシを調整する前にそれらの条件を見直します。

• Appのバックグラウンド更新：VPN拡張の動作許可とは別の機能です。この設定を有効にしても、拡張が終了しなくなるわけではありません。
• 低電力モード：システムのさまざまなバックグラウンド動作が調整されますが、VPNが必ず停止するとは限りません。接続に変化があるか、端末ごとに確認してください。
• オンデマンド接続：クライアントのオンデマンドルールが、Wi-Fiとモバイル通信の切り替え時に接続と切断を繰り返していないか確認します。
• ほかのVPN設定：「設定」→「一般」→「VPNとデバイス管理」で確認できます。管理対象の端末では組織のポリシーに従い、管理用の設定をむやみに削除しないでください。

iOSには、Androidの「アプリのバッテリー使用量：制限なし」に相当する共通の例外設定はありません。大規模なルールセットで特定クライアントの拡張が頻繁に再起動する場合は、不要なルールプロバイダーを減らし、詳細ログをオフにして、保守版にアップデートしてから再起動履歴を確認します。メモリ使用量だけを根拠に、電池消費の原因を断定しないでください。

TUN、ルールによる振り分け、最後に確認する項目

スマホのローカルVPNによる通信の取り込みと、デスクトップクライアントのTUN設定は、単純に同じものとして扱える機能ではありません。AndroidやiOSのクライアントは通常、仮想ネットワークインターフェースを使って通信します。デスクトップ向けの手順をそのまま適用し、別のVPNサービスを重ねて動かさないでください。多くの一般的な個人利用環境では、同じユーザーの通信を2つの独立したVPNが同時に自由に取り込むこともできません。

ルールモードでは、接続を直通にするかプロキシ経由にするかを決められます。ただし、直通の通信もクライアントのVPNデータ経路を通る場合があるため、「DIRECTに一致した」からといって処理負荷が完全になくなるわけではありません。一部のAndroidクライアントではアプリごとにVPNを迂回できますが、これはルールで直通にすることとは異なります。迂回するアプリがプロキシを必要とせず、ネットワークアクセスの要件にも合っていることを確認してから使ってください。

この順番で仕上げる

1. 通常の通信に戻す：同期、ダウンロード、電波の弱さ、頻繁なネットワーク切り替えがないか確認します。
2. 定期処理を減らす：速度測定はまず600秒に設定し、ルールとサブスクリプションの更新は必要に応じて調整します。たとえば1日1回が目安です。
3. 繰り返す失敗を修正する：DNS、ノードへの接続性、エラーログを確認し、継続的なタイムアウトを自動切り替えで覆い隠さないようにします。
4. 実際に発生しているバックグラウンド制限だけを解消する：Androidでは必要に応じてバッテリー制限を解除し、iOSでは拡張のログとオンデマンド接続の条件を確認します。
5. 接続状態を再テストする：画面をロックして少なくとも30分待ち、通知、Webサイトへのアクセス、Wi-Fiとモバイル通信の切り替えが正常であることを確認してから、長時間の電池消費テストを行います。

適切な省電力設定には、同じ利用条件で端末全体の電池消費が減り、必要なネットワーク接続も正常に保たれるという2つの条件があります。サービスの停止やアプリのリクエスト失敗によって電池消費が改善したように見える場合は、まず接続を復旧してください。変更前後の設定を記録しておくと、省電力設定を一度に適用するより、影響のある項目を見つけやすくなります。ルールや上書き項目については設定リファレンスを、接続の問題についてはトラブル対処を参照し、順に確認してください。