実際の電池消費か、バッテリー使用量の計上かを見極める
まず画面オフ時の電池残量の変化を記録してから、接続維持の設定を調整します。バッテリー使用量の一覧でClashが上位でも、プロキシのコアに異常があるとは限りません。スマホのダウンロードや動画再生、バックグラウンド同期がVPNトンネルを通ると、ネットワーク処理の一部がVPNアプリの消費として計上されることがあります。電池残量の減り方、バックグラウンドでの動作時間、通信量、発熱を合わせて確認し、単一の割合だけで判断しないでください。
Androidアプリは通常、VpnServiceで通信を引き受けます。iOSアプリではNetwork ExtensionのPacket Tunnel拡張機能を使う場合があります。ClashやClash Meta（mihomo）は関連するコアやエコシステムを指すもので、すべてのモバイルアプリで同じ設定が使えるわけではありません。特にiOSでは、アプリと使用コアを確認してから対処してください。Androidのバッテリー最適化除外の手順をそのまま当てはめることはできません。
まずは調査内容を記録する
- スマホの機種、OSバージョン、アプリのバージョン、コアのバージョンを記録します。アプリのバージョンは通常「設定」→「アプリについて」で確認できます。コアのバージョンはログの起動時情報で確認が必要な場合があります。
- 開始時と終了時の電池残量、テスト時間、Wi-Fiまたはモバイルデータ通信、電波の強さ、画面を消したままだったかを記録します。
- 現在のプロキシモード、選択中のプロキシグループ、サブスクリプションのノード数、自動速度テスト・詳細ログ・自動再接続の設定状況を記録します。
- 現在の設定を保存します。サブスクリプションの上書きが関わる変更は、アプリが対応するオーバーライドまたはマージ設定に行い、次回の更新で変更が消えないようにしてください。
画面オフで2回テストして原因を絞る
電波が安定した場所で、各回60分を目安に観察します。2回とも同じネットワークを使い、開始時の電池残量も近づけて、大容量ファイルのダウンロード、システムアップデート、写真のバックアップは一時停止してください。充電直後やOS更新後のインデックス作成中、スマホが明らかに熱いときは、状態が落ち着いてからテストします。ここで示す60分は原因を調べるための時間であり、電池持ちを保証するものではありません。
- 1回目は基準値を測定：一時的にプロキシを停止し、システムのVPN接続が切れていることを確認してから、画面を消した状態で60分置きます。電池残量の減りとバックグラウンド通信量を記録してください。常時接続が必要な作業がある場合は、使っていない時間帯にテストします。
- 2回目は設定を変えずに測定：プロキシを起動し、普段使っているルールモードとノードのまま、同じ条件でさらに60分観察します。切断や再接続が起きたか、発熱が続いたかを記録してください。
- 変更するのは一度に1項目だけ：2回目で電池消費が明らかに増えた場合は、次のテストで定期速度テストだけをオフにするか、安定したノード1つにだけ変更します。DNS、ルーティング、省電力設定、接続維持を同時に変えると、原因を特定できません。
- 一度で結論を出さず再テスト：電池残量は整数単位で表示されるため、短時間では誤差が大きくなります。差がはっきりしない場合は2～3時間に延ばし、別の日にも繰り返してください。
プロキシを停止しても電池が急速に減る場合は、まず電波の弱さ、ほかのアプリのバックグラウンド動作、システム同期を確認します。プロキシを使ったときだけ異常が起きるなら、トンネルの通信量、プローブ処理、再接続を調べてください。プロキシ経由でしかアクセスできないアプリは、1回目のテスト中に接続を繰り返し試みることがあります。その場合は両方のテストで、該当アプリのバックグラウンド処理を停止してください。
Androidの省電力設定：常時接続が必要なアプリだけを除外する
省電力設定からアプリを除外すると、バックグラウンド処理がシステムに制限されにくくなりますが、コア自体の処理量が減るわけではありません。画面を消してすぐは正常なのに、しばらくすると接続が切れ、画面を点けると復旧する場合は、まずバックグラウンド制限を確認します。スマホが発熱し続け、通信量も増え続けているなら、アプリを「制限なし」にするだけで異常な処理が長時間続くおそれがあります。
OSごとにバックグラウンド権限を確認する
- 標準に近いAndroid 14：「設定」→「アプリ」→「すべてのアプリを表示」→対象のアプリ→「アプリのバッテリー使用量」からバックグラウンド使用の設定を確認できます。メーカー独自の画面では「電池」や「バッテリー使用量」と表示され、「制限なし」「最適化」「制限」などを選べる場合があります。
- メーカー独自のOS：アプリ情報にある「自動起動」「バックグラウンド動作」「省電力設定」も確認してください。自動起動が許可されていても、バックグラウンド通信に個別の制限がないか、引き続き確認が必要です。
- 最近使ったアプリのロック：最近使ったアプリの画面でアプリをロックできるOSもありますが、通常はアプリの終了を防ぐだけです。バッテリー設定やバックグラウンド権限の代わりにはなりません。
まずはシステム標準の最適化設定を使います。画面オフ後に制限されることを確認した場合に限り、プロキシアプリだけを除外してください。ネットワークを使うすべてのアプリを対象にする必要はありません。設定後は画面を消して30～60分様子を見て、Wi-Fiからモバイルデータ通信に切り替えたあと接続が復旧するかも試してください。一度画面を点けて通信できても、バックグラウンド接続がずっと正常だったとは限りません。
常駐通知とVPNの常時接続は別の設定
Androidのフォアグラウンドサービスでは、通常、通知を常時表示します。サービスが動作中であることをシステムやユーザーに知らせるもので、通知そのものが主な電池消費源になることは通常ありません。通知を非表示にしてもプロキシは停止しませんし、通知が表示されていてもノードへの接続が正常とは限りません。
Android 13以降では、通知権限とフォアグラウンドサービスの要件を分けて考える必要があります。通知を許可しなくても、フォアグラウンドサービスがシステムによる管理の対象外になるわけではありません。通知を隠して節電するより、サービスの通知を表示したまま接続状態を確認するほうが有効です。
システムの「設定」→「ネットワークとインターネット」→「VPN」には、「VPNを常時接続」や「VPN以外の接続をブロック」が表示される端末があります。前者は選択したVPNの接続を維持し、後者はトンネルが使えないときにほかの通信を制限します。後者を有効にすると、切断時にすべてのアプリがネットワークへ接続できなくなる場合があるため、節電設定として使わないでください。メニュー名や対応状況はOSとアプリによって異なります。
ヘルスチェックと自動速度テスト：まず頻度を下げ、対象を絞る
ノードのヘルスチェックでは、定期的にリクエストを送信します。1回あたりの通信量は少なくても、ネットワークの頻繁な起動、接続タイムアウト、暗号化ハンドシェイクがバックグラウンド処理の負荷を高めることがあります。モバイル通信では、電池消費がデータ量に単純比例するわけではありません。多数のノードを含むサブスクリプションでは、プロキシプロバイダー、プロキシグループ、クライアントそれぞれの定期チェックを確認してください。
| 確認項目 | 設定の内容 | 確認・調整の方法 |
|---|---|---|
health-check.interval |
この設定に対応するプロキシプロバイダーのヘルスチェック間隔（秒） | 元の値が300なら900に変更し、ノード切り替えの速さに問題がないか確認する |
プロキシグループのinterval |
url-testやfallbackなどのグループで行う定期プローブの間隔 |
プロバイダーのチェックとは別に確認し、複数箇所をすべて60秒にしない |
lazy |
対応するヘルスチェックまたはプロキシグループで、未使用時のプローブを遅らせるかどうかを設定 | コアのドキュメントで対応状況を確認してから、trueの使用を検討 |
| クライアントの自動速度テスト | アプリの画面から追加で実行される遅延測定やダウンロードテスト | まず定期実行をオフにし、必要なときだけ手動でテストする |
| サブスクリプションの更新間隔 | ノードと設定を再取得する処理であり、ノードの速度測定とは別 | 頻繁な更新が不要なら、12時間または24時間に設定 |
ノード80個、60秒ごとに1回の例で、毎回すべてのノードをチェックすると、1時間で約4,800回のプローブが発生します。900秒ごとに変更すれば約320回です。これはスケジュール回数の例で、実測した電池消費ではありません。再試行、遅延チェック、ほかのプロキシグループによる処理も含みません。特定の速度テストで何KB消費したかだけでなく、頻度と対象範囲を先に確認しましょう。
ノードを1つ手動で選ぶと比較には使えますが、プロバイダーのバックグラウンドヘルスチェックまで停止するとは限りません。画面上では手動選択になっていてもログに一括プローブが定期的に記録される場合は、プロバイダー側とクライアント側の定期処理を確認してください。
再接続・DNS・TUN：機能をむやみに無効にせず、繰り返し処理を調べる
スマホでVPNが通信を処理していても、画面に「TUNモード」と表示されるとは限らず、デスクトップ版と同じ設定項目があるとも限りません。確認すべきなのは、ネットワーク切り替え後に再接続を繰り返す、DNSリクエストがタイムアウトし続ける、特定のバックグラウンドアプリが接続に何度も失敗するといった異常な処理です。通常の通信処理やルール判定にも負荷はかかりますが、TUNを有効にしているだけで異常の原因と判断することはできません。
- まずノードの問題を切り分ける：利用可能と確認済みのノードを1つ選び、30分間様子を見ます。再接続が明らかに減る場合は、元のノードの安定性と自動切り替えの条件を確認してください。
- 次にDNSのタイムアウトを確認する：ログに名前解決のタイムアウト、接続失敗、同じドメインへの大量の再試行が繰り返し記録されていないか、一時的に確認します。DNSのタイムアウトを受けてアプリ側が再試行を続けると、通信と処理の負荷が増えることがあります。
- ネットワーク側の設定を確認する：Androidの「プライベートDNS」や別のDNSアプリを手動設定している場合は、まず現在の値を記録し、アプリのドキュメントを確認して設定が干渉していないか調べてください。複数のDNS設定を一度に変更しないでください。
- バックグラウンド通信の発生元を調べる：アプリの接続画面で通信量や接続数を確認し、クラウドストレージへのアップロード、写真のバックアップ、動画の先読みなどが動作していないか調べます。プロキシは通信経路にすぎず、負荷の原因はこうしたアプリにある場合があります。
ルールモードは普段の通信の振り分けに適していますが、「DIRECT」でもデータが端末のVPN処理を完全に迂回するとは限りません。通信がすでにトンネルに取り込まれていれば、コアが判定や転送を行う場合があります。一方、グローバルモードにしても、バックグラウンド処理がすべて自動で減るわけではありません。モードを何度も切り替えて節電しようとせず、実際の通信とルールの適用状況を調べてください。
ログの採取は短時間にとどめます。ログレベルを一時的にdebugへ変更し、2～5分間再現したらinfoまたはクライアントの標準レベルに戻してください。詳細ログを長時間有効にする、接続画面を常時開いて頻繁に更新するといった操作も負荷を増やします。ログを共有する前に、サブスクリプションURL、トークン、ノードの認証情報などの機密情報を削除してください。
iOSのバックグラウンド接続維持：アプリ画面とトンネル拡張を分けて考える
iOSには、Androidの「制限なし」に完全に相当する共通のバッテリー最適化除外設定はありません。Packet Tunnelに対応するアプリでは、トンネルを拡張機能が処理するため、アプリ画面をバックグラウンドにしてもトンネルが停止するとは限りません。「Appのバックグラウンド更新」を有効にしても、VPN拡張機能の接続が無制限に維持されるわけではありません。接続が続いているかは、システムのVPN状態とアプリの接続履歴で確認してください。
次の3か所を確認する
- バッテリー使用状況：iOS 18の場合、「設定」→「バッテリー」を開き、「過去24時間」または「過去10日間」を選んで、該当する時間帯のアクティビティを確認します。ほかのOSバージョンでは、集計期間や画面の場所が異なる場合があります。
- VPN構成：「設定」→「一般」→「VPNとデバイス管理」→「VPN」を開き、現在使用中の構成を確認します。別のアプリの接続を、対象のクライアントのものと取り違えないようにしてください。
- オンデマンド接続：アプリに「オンデマンド接続」や自動接続ルールがある場合は、Wi-Fiとモバイルデータ通信の切り替え時に接続が繰り返し開始されていないか確認します。一時的にオフにして比較テストを行い、設定を戻すか判断してください。
低電力モードでは一部のバックグラウンド動作が調整されますが、VPNが必ず切断される、または必ず節電できるとは限りません。接続を維持する必要がある場合は、低電力モードをオンにして画面オフ時とネットワーク切り替え時の両方をテストしてください。アプリを頻繁に強制終了しても、一般的な接続維持の方法にはなりません。影響はアプリとOSの実装によって異なります。
アプリにプローブ間隔、ログレベル、アプリごとの設定がない場合、ほかのプラットフォーム向けのYAML設定を無理に適用しないでください。まずアプリが実際に対応している設定を確認し、利用できる範囲で、ノードの固定、定期速度テストの削減、オンデマンド接続の確認を行って比較してください。
利用状況に合わせて接続維持の設定を決める
| 利用シーン | 設定の目安 | 考慮すべき点 |
|---|---|---|
| たまにWebページを見る | 必要なときだけ接続し、まずはシステム標準のバッテリー最適化を維持 | 利用前に手動接続が必要な場合がある |
| 終日メッセージ受信・同期 | 必要なアプリだけAndroidのバックグラウンド制限から除外し、ヘルスチェックは適度な頻度にする | 接続を維持するための基本的な負荷がかかるため、画面オフ時の安定性を確認する |
| 通勤中にネットワークを頻繁に切り替える | 安定したノードを優先し、自動再接続とオンデマンド接続のルールを確認する | 電波が弱い場所では再試行やネットワーク切り替えで電池消費が増える場合がある |
| 特定のネットワークでのみ使う | クライアントが対応するネットワーク条件のルールを使う | ネットワーク条件の変化によりトンネルが再接続される場合がある |
最後に記録するのは3点で十分です。同じ条件での画面オフ時の電池消費、画面オフ中に切断したか、ネットワーク切り替え後に復旧したかを確認してください。まず重複するプローブや接続失敗後の再試行を減らし、必要に応じてバックグラウンド権限を緩和します。接続が安定しているなら、バッテリー使用量の順位を理由にDNSを何度も変えたり、ルールを書き直したりする必要はありません。
原因を特定できない場合は、スマホの機種、OSとクライアントのバージョン、コアのバージョン、テストした時間帯、ネットワークの種類、個人情報を削除した短時間のログを添えて報告してください。「画面オフから40分後に接続が止まり、画面を点けるとすぐ復旧する」のように具体的に説明すると、バックグラウンド制限、ノード障害、トンネルの異常を切り分けやすくなります。