Clashのスマホ版で電池がすぐ減るときの対処法｜Android・iOSのバックグラウンド接続と省電力設定

実際の電池消費とアプリ別の使用量を切り分ける

まず同じ条件で比較してから設定を変更しましょう。ステータスバーにVPNアイコンが表示され続けていても、システムトンネルが接続中というだけで、CPUが常に高負荷で動作しているわけではありません。確認すべきなのは、画面ロック中も本体が明らかに熱くなる、待機中の電池消費が増える、ログに接続失敗や再接続が繰り返し記録される、といった症状です。

Clashはカーネルや設定を取り巻くエコシステムの名称であり、AndroidとiOSで同一のアプリを指すものではありません。Clash Metaは後にmihomoという名称になりました。クライアントによって、採用するカーネルやトンネルの実装、設定画面は異なります。特にiOSでは、一部のClash形式の設定を読み込めても、mihomoの全項目に対応しているとは限りません。以下のOS設定の確認方法は共通して使えますが、設定項目については各クライアントのドキュメントを確認してください。

30分ずつ2回測定して基準を作る

1. 充電しておらず、電波が安定している時間帯を選びます。画面の明るさ、ネットワークの種類、接続先ノードを固定し、システムアップデートや大量の写真同期は同時に行わないでください。
2. まずクライアントの接続を停止し、画面をロックして30分間待機します。開始時と終了時の電池残量、ネットワークの種類、本体の発熱の有無を記録してください。
3. 次にクライアントを起動し、同じ条件で画面をロックして30分間待機します。測定中に速度テストを繰り返したり、リアルタイムログを開いたりしないでください。
4. 2回の測定結果の差が1ポイント程度なら、さらに長時間の比較を行います。電池残量の表示には丸めがあるため、短時間の測定だけでは原因を特定できません。

たとえば、80%から79%への変化と79%から75%への変化に差があれば、さらに調べる価値があります。ただし、これは記録方法の例であり、特定のクライアントで測定した結果ではありません。電波の弱さ、バックグラウンドのバックアップ、バッテリーの劣化でも差が出るため、電池使用量のランキング画面だけで判断しないでください。

TUNの常時接続：通信の制御を保ち、トンネルの重複を避ける

Androidクライアントは通常、システムのVPNサービスを使って通信を制御します。クライアントによっては、関連する設定をVPNまたはTUNと呼びます。iOSクライアントは通常、システムが提供するNetwork Extensionのトンネル機能を使用します。スマホではシステムプロキシの設定だけで、すべてのアプリの通信を制御できるとは限らないため、どちらのOSでもデスクトップ版の「TUNを無効にしてシステムプロキシだけを使う」という手順をそのまま適用しないでください。

複数の通信制御機能が競合していないか確認する

• 別のVPN、ファイアウォール、ローカルVPN方式のフィルタリングアプリを一時停止してから、対象のクライアントを起動します。同じシステムユーザーや構成の範囲では、こうしたアプリがそれぞれ独立したVPNトンネルを同時に維持できないことがほとんどです。
• クライアントの状態が「接続済み」から「接続中」に何度も切り替わっていないか確認します。数十秒ごとに再接続する場合は、バックグラウンド維持の設定を増やす前に、再接続の原因を解消してください。
• まずWi-Fiに接続した状態でテストし、次にモバイル通信で確認します。電波が弱いときやネットワークを切り替えたときだけ発熱するなら、TUNの実装を疑う前にネットワークや接続先ノードを確認しましょう。

ルールモードが決めるのは、すでに制御対象になっている通信の出先です。DIRECTに一致する接続もクライアントを経由する場合があり、トンネルを完全に迂回するわけではありません。Androidクライアントに「アプリごとのプロキシ」機能がある場合は、VPNで制御する必要のないアプリを迂回させることで、不要な処理を減らせます。ただし、対象の設定が「選択したアプリのみプロキシ経由」なのか「選択したアプリを除外」なのかを確認してください。設定の向きが逆です。

一般向けのiOSクライアントでは、Androidのように任意のアプリごとに通信を振り分けられるとは限りません。同じ名前の設定を探して、システム構成を何度も変更しないでください。組織の管理下にある端末では、アプリごとのVPNが管理ポリシーによって制限される場合もあります。

Androidのバックグラウンド維持：制限されているクライアントだけを対象にする

画面ロック後に通信が切れ、電池消費が増える場合、同じ悪循環が原因になっていることがあります。システムがクライアントを停止し、アプリの接続が失敗して、ロック解除後に再接続が集中するという流れです。すべてのアプリを「制限なし」にするのではなく、まずクライアントが本当にシステムに制限されているか確認しましょう。

OSの設定画面から順に確認する

• Pixelなど、標準Androidに近いシステム：「設定」→「アプリ」→「すべてのアプリを表示」→対象のクライアント→「アプリのバッテリー使用量」と進み、「バックグラウンドでの使用を許可」などの項目を確認します。Androidのバージョンによっては、「最適化」や「制限なし」を選べます。
• Samsung One UI：「設定」→「バッテリー」→「バックグラウンドでの使用制限」と進み、クライアントが「スリープ中のアプリ」や「ディープスリープ中のアプリ」に登録されていないか確認します。旧バージョンでは「バッテリーとデバイスケア」→「バッテリー」に項目がある場合があります。
• その他の独自OS：アプリ情報で「バッテリー」「バックグラウンド」「自動起動」などを検索します。プロセスが終了する、再起動後に接続が復元しないといった症状がある場合に限り、必要な権限を許可してください。

設定を1つ変更したら、画面をロックして15～30分待ち、ロック解除後にクライアントの接続時間とログを確認します。トンネルが維持され、通信にも問題がなければ、バックグラウンド維持の権限をすべて追加する必要はありません。AndroidのVPNクライアントは、フォアグラウンドサービスで動作を維持することが一般的です。通知が表示され続けること自体は、電池消費に異常がある証拠ではありません。

iOSのバックグラウンド接続：オンデマンドルールを確認し、アプリを何度も終了しない

iOSでは、プロキシトンネルの拡張機能とクライアントの画面は別のライフサイクルで動作します。アプリの画面を閉じた後もトンネルが動作し続ける場合があります。また、「Appのバックグラウンド更新」は、すべてのVPNトンネルの動作を決める一括スイッチではありません。そのため、日常的な省電力対策としてクライアントを何度も上スワイプして終了するのはおすすめしません。

1. 「設定」→「バッテリー」を開き、クライアント接続の前後でアプリのアクティビティと端末全体の電池残量の推移を比較します。iOSのバージョンによって「過去24時間」や日別の使用状況が表示されるため、現在の画面で確認できる範囲を見てください。
2. 「設定」→「一般」→「VPNとデバイス管理」→「VPN」と進み、現在有効な構成を確認します。「オンデマンド接続」の設定場所は構成の詳細画面の場合もあれば、クライアント側で管理されている場合もあります。
3. 手動で切断してもすぐ再接続する場合は、オンデマンド接続が有効になっていないか確認します。特定のWi-Fiに接続したときだけ切り替えを繰り返す場合は、そのネットワークに適用されるオンデマンドルールを確認してください。
4. まず1つのネットワークに接続した状態で30分観察し、その後Wi-Fiとモバイル通信を切り替えてテストします。オンデマンドルール、DNS、ノードを同時に変更すると、どの設定が効果をもたらしたのか判断しにくくなります。

低電力モードは一部のバックグラウンド動作を制限しますが、使えないノード、誤ったDNS、頻繁に発動する接続ルールを自動で修正するものではありません。低電力モードでも発熱が続く場合は、さらに強い省電力設定を探すのではなく、接続ログと通信元を確認しましょう。

DNS問い合わせと失敗時の再試行：同じエラーの繰り返しを確認する

通常、DNS問い合わせにはキャッシュが使われるため、ドメイン解決のログが表示されただけで電池消費の異常と判断する必要はありません。注目すべきなのは、同じドメインへの問い合わせが短時間に何度も失敗する、上流DNSに到達できない、名前解決の経路が循環している、アプリが接続失敗を繰り返している、といった状況です。

ログを有効にするのは一時的にして、2～5分間確認する

1. クライアントのログ画面でtimeout、DNS、failedなどを検索し、同じエラーが繰り返し発生していないか確認します。
2. エラーが起きた時刻、ドメイン、上流アドレスを記録します。1回のタイムアウトは一時的な通信不安定の可能性があります。同じエラーが連続する場合に、優先して対処してください。
3. Androidでは「設定」→「ネットワークとインターネット」→「プライベートDNS」を開き、現在の設定を記録します。カスタムのホスト名を入力している場合は、条件を管理したテストとして一時的に「自動」に変更し、クライアントのDNS経路との相互作用を確認できます。テスト後は必要に応じて元に戻してください。
4. iOSでは、追加のDNSプロファイルがインストールされていないか、別のDNSアプリが有効になっていないか確認します。まず同時に動作する要素を減らしてから、クライアントの説明に従って必要な設定を戻してください。

暗号化DNSの失敗を解決するために、証明書の検証を安易に無効化しないでください。まずシステムの日付、ネットワークへの接続、上流DNSの設定を確認します。fake-ipは「有効にすると必ず電池を消費し、無効にすれば必ず節電できる」という設定ではありません。アプリの互換性に影響することがあるため、ログや再現手順から名前解決の問題が疑われる場合に限り、比較テストを行いましょう。

mihomoの上流DNSへの接続にプロキシが必要な場合は、ブートストラップ用の名前解決とノードのドメイン名解決の両方で接続経路を確保してください。名前解決にプロキシが必要で、そのプロキシの接続にも同じ名前解決が必要になる状態を避けます。出所の異なる複数の設定を継ぎ足すより、サブスクリプションで提供される基本のDNS設定を使うほうが、問題を特定しやすくなります。各設定項目の詳しい説明は設定リファレンスをご覧ください。

速度テスト、ルールセット、サブスクリプションの更新：バックグラウンドタスクの間隔を調整する

電池消費の原因は、実際のブラウジングとは限りません。複数のプロキシグループで頻繁に速度テストを行ったり、複数のルールプロバイダーが何度もダウンロードしたりすると、バックグラウンド通信が発生します。特にモバイル通信の電波が弱い環境では、小さな通信が頻発するだけでも無線モジュールが繰り返し動作することがあります。

上の表は比較テストを始める際の目安であり、すべての端末に最適な値ではありません。mihomoでは、url-testプロキシグループのintervalとルールプロバイダーの更新間隔は、通常秒単位です。一方、クライアントのサブスクリプション更新画面では単位が異なる場合があります。600秒は10分、86400秒は24時間です。設定前に単位を確認してください。

個々の間隔だけでなく、速度テストの重複も確認する

設定に自動テストグループが4つあり、それぞれ20個のノードを列挙して60秒ごとにテストする場合、単純計算では1回のテストで80項目が対象になります。実際の通信量は遅延テストの仕組み、グループの使用状況、カーネルのスケジューリングなどに左右されるため、一定のリクエスト数になるとは限りません。それでも、テストの重複を確認するきっかけになります。使っていないテストグループを削除するか、クライアントが対応していればオンデマンドテストを有効にしてください。

変更前に設定をコピーしてください。リモートサブスクリプションからダウンロードしたYAMLを直接編集すると、次回の更新で変更が上書きされることがあります。オーバーライドやマージに対応するクライアントでは、変更を保持できる専用の設定画面を使いましょう。iOSクライアントがこれらのmihomo項目に対応していない場合は、クライアントの「自動テスト」「更新間隔」などの設定を変更し、互換性のない設定を無理に貼り付けないでください。

症状に合わせて調整する：接続安定性と電池持ちを両立する設定

日常利用では、ルールモード、安定した接続先ノード1つ、頻繁すぎない自動テスト、適切な間隔でのサブスクリプション更新、デフォルトまたはinfoのログレベルから試せます。Androidでは、システムによってクライアントが実際に停止される場合に限り、バックグラウンド制限を解除します。iOSでは実際のネットワーク要件に合わせてオンデマンド接続を設定し、トンネルを何度も手動で切り替えないようにしてください。

一度に変更する設定は1つにし、同じ条件で比較できる時間を少なくとも1回確保してください。問題が続く場合は、スマホの機種、OSのバージョン、クライアントのバージョン、カーネルのバージョン、ネットワークの種類、開始時と終了時の電池残量、エラーが発生した時刻を整理し、症状に応じてヘルプセンターで確認してください。ログを共有する前に、サブスクリプションURL、トークン、ノードアドレス、個人のアクセス履歴を隠してください。サブスクリプションファイル全体をそのまま公開アップロードするのは避けましょう。