Clashのスマホ版は電池を消耗する？Androidのバックグラウンド維持とiOSの接続設定

まず電池消費の原因を切り分ける：トンネル、通信、バックグラウンド処理

ステータスバーにVPNが常時表示されていても、プロキシのコアが常に高負荷で動いているとは限りません。Androidクライアントは通常、システムのVPNインターフェースで仮想ネットワークアダプターを作成し、通信をコアに渡して処理します。iOSの対応クライアントは、多くの場合Network Extensionのパケットトンネルを利用します。実際の電池消費は通信量や再接続の頻度、モバイル回線の電波状況にも左右されます。

この記事でいう「Clashのスマホ版」には、Clashまたはmihomoコアを使うAndroidクライアントと、対応するサブスクリプションやルール形式を利用できるiOSクライアントが含まれます。これらは同じアプリではありません。特にiOSでは、Androidクライアントの設定画面やTUNスイッチ、YAMLの項目をそのまま流用できません。

• トンネルの処理負荷：通信が仮想ネットワークアダプターを通り、ルール照合やプロトコルの暗号化・復号を行うため、処理負荷が増えます。動画視聴、ダウンロード、テザリングでは特に影響が出やすくなります。
• アプリの通信負荷：クラウド写真同期やメッセージ同期、ショート動画の先読みは、DIRECTに設定していてもトンネルを経由する場合があります。ルールをDIRECTにしても、システムのVPN層を迂回するとは限りません。
• 定期処理の負荷：ノードのヘルスチェック、サブスクリプションの更新、ルールセットのダウンロードや失敗時の再試行でネットワークが起動します。実行頻度が高いほど、待機中の節電効果が損なわれやすくなります。
• 無線通信の負荷：電波が弱い場合やWi-Fiとモバイル回線が切り替わる場合、接続を何度も確立し直す場合は、無線モジュールが長時間動作し続けることがあります。

2時間の待機テストで比較し、感覚だけで設定を変えない

まず短時間の条件比較を行い、バックグラウンド維持の設定を変更するか判断しましょう。Androidでは「設定」→「バッテリー」→「バッテリー使用量」、iOS 18では「設定」→「バッテリー」から残量の推移やアプリごとのアクティビティを確認できます。メーカーによってメニュー名が異なる場合は、設定画面で「バッテリー使用量」と検索してください。

1. テスト条件をそろえる：同じ場所、同じネットワーク、近い残量から始めます。たとえば毎回残量が80%前後の状態で開始し、システムアップデート、写真のバックアップ、大容量ファイルのダウンロードは一時停止します。
2. 基準値を記録する：プロキシが不要な時間帯にトンネルをオフにし、画面をロックして2時間待機します。開始時と終了時の残量、バックグラウンドでの動作、ネットワーク状態を記録してください。
3. 現在の設定を記録する：トンネルと元のルール設定を戻し、画面をロックして2時間テストします。ノード、速度測定の間隔、省電力設定を同時に変えないでください。
4. 一項目ずつ再テストする：自動速度測定の間隔を延ばすか、バックグラウンド制限を一つだけ調整します。他の条件は変えず、少なくとも2回繰り返してください。

たとえば、ある回はトンネルをオフにして80%→78%、オンにして80%→75%だったとします。この2回の差が3ポイントだったことは分かりますが、原因がTUNだとは断定できません。数値は記録方法の例であり、本サイトの実測値や一般的な正常値ではありません。2回目に電波が弱くなって再接続したり、写真が同期されたりすれば、比較の意味がなくなります。

毎回、最低限この6項目を記録する

• スマートフォンの機種、OSのバージョン、クライアントのバージョン、クライアントに表示されるコアのバージョン。
• テストの開始・終了時刻と電池残量。
• Wi-Fiまたはモバイル回線の別と、電波が安定しているかどうか。
• トンネルの状態、ルールモード、選択中のノード。
• 自動速度測定、サブスクリプション更新、ルールセット更新の各間隔。
• 画面ロック中の切断・再接続、通知の遅延、スマートフォンの発熱の有無。

Androidのバックグラウンド維持：切断の症状を見て電池最適化を設定

電池最適化の対象外にする設定は、「システムの制限でプロセスが動き続けられない」問題に対処するものであり、「プロキシ処理の電力を減らす」ものではありません。画面ロック後も通信が安定しているなら、最初からすべてのバックグラウンド制限を解除する必要はありません。ロック後10数分で通信が切れる場合に、クライアントのバックグラウンド権限を確認しましょう。

標準Android 14での確認手順

1. 「設定」→「アプリ」→「すべてのアプリを表示」→クライアントを選択→「アプリのバッテリー使用量」と進みます。機種によっては「バッテリー」と表示されます。まず、バックグラウンドでの使用が許可されているか確認してください。
2. 「制限あり」にした後、画面ロック中に切断される場合は、まず「最適化」に変更して再テストします。それでも接続が切れ、常時接続が必要な場合に限り、「制限なし」を試してください。選べる項目はOSのバージョンによって異なります。
3. クライアントのVPN常時接続通知を確認してください。Androidのフォアグラウンドサービスには通常、継続的な通知が必要です。通知をオフにすることを節電手順にしないでください。通知が非表示であることと、サービスが動作しているかどうかは別の問題です。
4. メーカー独自のシステムに「自動起動」「バックグラウンドで実行」「バックグラウンドタスクをロック」などの設定がある場合は、常時接続が必要なクライアントに限って必要に応じて有効にします。関係のないアプリまで一括で制限解除しないでください。

システムのVPN設定は、標準Androidなら「設定」→「ネットワークとインターネット」→「VPN」から該当するクライアントを選んで確認できます。「常時接続VPN」と「VPNを使わない接続をブロック」を有効にしている場合、クライアント停止後に端末全体がネットにつながらなくなるのは、ノード障害ではなく想定された保護動作の可能性があります。トラブルを調べる前に、これら2つの設定の状態を記録してください。

TUNとアプリ別プロキシの選び方

Androidの一般的なアプリは、デスクトップブラウザーのようにクライアントのHTTPプロキシポートを一律に利用するわけではありません。そのため、VPN/TUNだけをオフにしてローカルの待ち受けポートを残しても、端末全体の通信がルールどおりに行われるとは限りません。端末全体の通信をプロキシ経由にするならトンネルを維持します。一部のアプリだけで使うなら、Android VPNを利用したアプリ別の対象・除外リストにクライアントが対応しているか確認してください。

アプリ別の除外設定とYAMLの直接接続ルールは、適用される層が異なります。前者はクライアントとシステムが対応していれば、指定したアプリをVPNから除外できます。後者は通常、通信がコアに届いた後に直接接続の出口を選ぶ設定です。リストを変更したらクライアントの指示に従って接続を確立し直し、ブラウザー、メッセージ、決済アプリでそれぞれ動作を確認してください。

自動速度測定とルールセット更新による起動回数を減らす

「速度測定」には、少なくとも遅延の測定とダウンロード速度の測定があります。遅延測定はリクエストが小さいものの、ノード数が多く間隔が短ければ接続が大量に発生します。ダウンロード速度測定は実際にデータを転送するため、バックグラウンドで高頻度に実行するのはさらに不向きです。まずクライアントで設定した全ノードの定期測定をオフにし、サブスクリプション内のヘルスチェックや自動選択グループも確認してください。

まず間隔を60秒から600秒にして比較する

プロバイダーに100ノードあり、毎回すべてのノードを測定すると仮定します。60秒間隔なら1時間あたり約6,000回、600秒間隔なら約600回の測定です。これはノード数と間隔から算出したリクエスト数の例です。実際の回数は遅延実行、失敗時の再試行、クライアントのスケジュールにも左右されるため、電池の節約量にそのまま換算することはできません。

該当する項目に対応したmihomo設定では、既存のproxy-providers項目内にあるhealth-checkで、次の項目を調整できます。利用可能な既存の測定URLはそのまま使ってください。以下は設定の一部であり、単独で読み込める完全な設定ファイルではありません。

health-check:
  enable: true
  interval: 600
  lazy: true

intervalの単位は秒です。lazy: trueを設定すると、プロバイダーが使われていないときの定期ヘルスチェックを減らせますが、現在の接続による通信が停止するわけではありません。設定にurl-testやfallbackグループがある場合は、それぞれの測定設定も確認してください。プロバイダーのチェックとポリシーグループのチェックが並行して行われることがあり、片方だけ変更しても重複測定がなくならない場合があります。

3種類の更新タスクは別々に設定する

サブスクリプションを更新すると、ローカルの変更が上書きされる場合があります。クライアントの上書き・マージ機能を優先し、サブスクリプションを一度更新した後に最終的な設定を確認してください。同じルールのURLで数秒おきにダウンロード失敗がログに出る場合は、すべての更新間隔を延ばすのではなく、URLまたはネットワーク経路を修正しましょう。

iOSのオンデマンド接続：アプリ画面を閉じることとトンネル停止を区別する

iOSクライアントのメイン画面と、システムが管理するトンネル拡張機能は別のものです。メイン画面が前面に表示されていなくても、トンネルが停止したとは限りません。マルチタスク画面からアプリを何度もスワイプして終了しても、確実な節電にはなりません。クライアント内で接続状態を確認し、「設定」→「一般」→「VPNとデバイス管理」→「VPN」で現在の構成を確認してください。

オンデマンド接続は、ネットワークの条件を明確に指定できる場合に便利

オンデマンド接続では、クライアントがシステムにルールを設定し、条件に合ったネットワークでVPNを接続または切断します。単に「画面が消えたら切断する」機能ではありません。Wi-Fi名、ネットワークの種類、ドメイン名などを条件に設定できるかどうかはクライアントによります。「オンデマンド接続」のスイッチが表示されるだけで、適切な条件が設定済みだと思い込まないでください。

• 常にプロキシが必要：まず接続を維持し、速度測定の頻度を減らして、電波の安定した場所で待機中の状態を確認します。
• 一部のネットワークだけで使用：クライアントが対応していれば、特定のWi-Fiやネットワーク条件でオンデマンドルールを設定し、そのネットワークから離れた後の状態も確認します。
• たまに使う：使用前に手動で接続し、使い終わったらクライアント内で切断する方法が最も分かりやすい設定です。ただし、その後のバックグラウンドアプリは通常のネットワークを使うことになります。

手動で「切断」を押してもすぐ再接続する場合は、オンデマンドルールの条件がまだ満たされている可能性があります。ボタンが機能していないとは限りません。一時停止したい場合は、その構成のオンデマンド接続設定も確認してください。逆に、低電力モードやAppのバックグラウンド更新はVPNのオンデマンドルールの代わりにはなりません。トンネルを維持するために、すべてのアプリでバックグラウンド更新を有効にする必要はありません。

症状に合わせて設定を絞り、元に戻せるよう記録する

画面ロック後に通信が切れるが、待機中の電池消費は大きくない

まずAndroidのバックグラウンド制限と常時接続VPN、またはiOSのオンデマンドルールが実際に動作しているか確認します。接続が安定してから電池消費を比較してください。トンネルを何度も再起動しながら電池を評価しないでください。接続の復旧を繰り返すこと自体がネットワークの稼働を増やします。

画面ロック中も発熱し、ログが出続ける

速度測定の繰り返し、ルールのダウンロード失敗、ノードの再接続、DNSタイムアウトを優先して確認します。ログレベルをクライアントの通常設定に戻し、継続的なパケットキャプチャやデバッグログを無効にしてください。トラブル調査に必要な場合だけ、短時間のログを残します。DNSに問題がある場合は名前解決の経路を修正し、通信の取り込みを無効にして隠さないでください。

モバイル回線でのみ電池消費が目立つ

同じ場所で電波の強さを比べてから、安定したノードを一つ選んでテストします。TUNスタック、MTU、DNSモード、プロトコルを同時に変更しないでください。電池消費だけを根拠に特定のMTU値を設定するのも避けましょう。大容量ファイルの転送時だけ異常がある場合は、速度、発熱、再接続回数を記録してからネットワークの問題として調べてください。

設定変更後の確認リスト

1. 画面をロックして30分経過後も、必要なアプリで通信と通知を正常に受信できる。
2. Wi-Fiとモバイル回線を切り替えた後、想定どおりに接続が復旧または停止する。
3. サブスクリプションを一度更新した後も、速度測定の間隔とカスタムルールが有効になっている。
4. 同じ条件で2時間の待機テストを2回行い、1回だけの数値で判断しない。
5. 変更した設定を記録し、効果がはっきりしない場合は元に戻す。変更を重ね続けない。

長く使いやすいのは、接続が安定し、バックグラウンド処理を必要な範囲に抑え、挙動を説明できる設定です。Androidで電池最適化の対象外にするかは画面ロック中の切断状況で判断し、iOSでオンデマンド接続を使うかは利用シーンと切断後の通信要件に合わせて決めましょう。不要な処理を減らしてからバックグラウンド維持を調整するほうが、最初からすべての権限を有効にするより原因を特定しやすくなります。