Clashのスマホのバッテリー消費が速いときの対処法：バックグラウンド動作と省電力設定

消費電力がプロキシ由来か、画面操作由来かを確認する

スマートフォンでClashクライアントの電池消費が多く表示されても、プロキシコアが常にCPUを大量に使っているとは限りません。AndroidではVPNインターフェースの転送、バックグラウンドサービス、一部の通信活動がクライアントの消費として計上されます。iOSではPacket Tunnelネットワーク拡張の活動が該当アプリにまとめられる場合があります。画面の点灯、ログ画面の頻繁な表示、連続した速度測定、サブスクリプションの繰り返し更新は、短時間の集計値を大きく押し上げます。

判断する前に、比較可能なアイドルテストを1回行います。バッテリーを80%以上まで充電し、画面を消したままネットワーク環境を変えず、プロキシを有効にした場合と無効にした場合の2時間後の電池残量をそれぞれ記録します。テスト中は大容量ファイルのダウンロード、動画再生、Wi-Fiとモバイルデータの切り替えを避けてください。システム画面の消費割合だけを見ると誤判断しやすくなります。割合はその測定期間の総消費に占める比率であり、単独で測定したmAhではないためです。

ヘルスチェックがネットワークを繰り返し起こす理由

ノードが多いほどチェック要求が集中する

プロキシプロバイダーのヘルスチェックは、各ノードからテスト用アドレスへ定期的にアクセスし、応答結果に基づいて利用可否を判定します。サブスクリプションに80ノードが含まれ、チェック間隔が300秒の場合、クライアントは5分ごとに数十回の接続を確立する可能性があります。1回の通信量は少なくても、接続ハンドシェイク、TLSネゴシエーション、無線通信のウェイクアップ、失敗時の再試行によって余分な電力を消費します。

スマートフォンでは、通常300秒ごとの全ノードチェックは必要ありません。普段のブラウジングでは間隔を900〜1800秒に変更し、遅延チェックを有効にできます。`lazy: true` はプロバイダーが実際に使用されていないときの能動的なテストを減らす設定ですが、具体的な発動条件はクライアントが採用するmihomoのバージョンや画面設定によって異なります。少数のノードを固定して使う構成なら、900秒程度が障害検知の速さと待機時の消費電力を両立しやすい設定です。

proxy-providers:
  mobile-subscription:
    type: http
    url: "サブスクリプションURL"
    path: ./providers/mobile.yaml
    interval: 86400
    health-check:
      enable: true
      lazy: true
      url: https://www.gstatic.com/generate_204
      interval: 900
      timeout: 5000

ここでの `interval: 86400` はサブスクリプションの更新周期で、単位は秒です。一方、ヘルスチェックの `interval: 900` はノードの検査周期を示します。用途は異なります。サブスクリプションの更新を24時間ごとにしても、ノードが15分ごとにチェックされることは止まりません。クライアントの画面に「自動更新」と「自動速度測定」が別々に用意されている場合は、それぞれのスイッチを確認してください。

自動速度測定は可用性チェックより電池を消費する

可用性チェックはテスト用アドレスから応答が返ることを確認するだけです。遅延順の並べ替えでは複数ノードの応答時間を測定し、帯域幅テストではさらに大きなデータを送受信します。スマートフォンで数分おきに全ノードの速度を自動測定するのは適していません。可用性チェックは残し、完全な速度測定は手動に変更しましょう。ノード一覧が変わったときや、現在の回線が明らかに遅くなったときだけ実行するのが効果的です。

• ノードが20個未満：ヘルスチェックは900秒に設定できます。
• ノードが20〜100個：1800秒に設定し、遅延チェックを有効にするのがおすすめです。
• ノードが100個超：まずサブスクリプションのグループを整理し、そのうえで3600秒まで延長することを検討します。
• 携帯回線の電波が弱いとき：一括速度測定を停止し、失敗した接続の大量再試行を避けます。

DNSクエリとルールマッチングが与える実際の影響

ClashのFake-IPモードでは、アプリからのDNSクエリを受け取り、ドメインとマッピング先アドレスの関係を保持したうえで、ドメインに基づいてルールを適用します。この処理自体が主な消費電力になることは通常ありません。注意すべきなのは、クエリ失敗後の再要求、多すぎるリモートDNS上流、ネットワーク切り替え後の接続再確立、そしてバックグラウンドでアプリが継続的に送るテレメトリや同期リクエストです。

不要な上流とタイムアウト再試行を減らす

スマートフォンの設定に大量のDNSサーバーを同時に登録する必要はありません。各グループには安定した上流を2つ残せば十分です。応答が遅い、または現在のネットワークから到達できない暗号化DNSを複数設定すると、タイムアウトまで待った後に別の上流を試すことになります。1回の失敗は大きな問題ではありませんが、バックグラウンドアプリが繰り返し問い合わせると、タイムアウトの連続によって無線モジュールの稼働時間が長くなります。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  ipv6: false
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.12.12.12/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"

`ipv6: false` は、現在のプロキシノード、ルール、ネットワーク環境のいずれもIPv6に依存していない場合に限って適しています。家庭のブロードバンドやモバイルネットワークでIPv6リソースへのアクセスが必要なら、省電力だけを理由に無効化すべきではありません。まずログにAAAAクエリの連続失敗、到達不能なルート、接続のフォールバックがないかを確認し、そのうえで変更を判断してください。

Fake-IPのフィルターリストも無制限に増やすべきではありません。項目が多すぎても直接的に大きな消費電力を生むわけではありませんが、一部アプリが想定したドメインマッピングを迂回し、追加の名前解決や接続試行を発生させることがあります。LAN機器名、時刻同期用ドメイン、実アドレスを明示的に必要とするアプリのドメインは追加して構いません。それ以外は最小限に保ちます。

TUNモードとシステムVPNの消費電力の境界

AndroidとiOSのClash系クライアントは、通常システムのVPNインターフェースを通じて通信を引き受けます。TUNを有効にすると、アプリの通信が仮想ネットワークインターフェースに入り、コアがDNS処理、ルールマッチング、プロキシ転送を行います。単一アプリにHTTPプロキシだけを設定する場合と比べ、TUNはより広範囲の通信を処理するため、バックグラウンド接続も多く扱います。

TUNだから必ず電池を多く消費するわけではありません。設定が正常でノードが安定していれば、追加負荷は通常限定的です。異常な消費は、ノードが繰り返し切断・再接続する、ルールによって接続ループが発生する、弱い電波で大量の長時間接続を維持する、または省電力機能がVPNサービスを終了と再起動を繰り返す場合に起こりやすくなります。トンネルを頻繁に再構築するほうが、安定して維持するより多くの電力を消費しがちです。

Android：必要なバックグラウンド動作を許可する

標準のAndroid 14およびAndroid 15を例にすると、「設定」→「アプリ」→「Clashクライアント」→「アプリのバッテリー使用量」から「バックグラウンド使用を許可」を有効にできます。メーカー独自のシステムでは「無制限」「バックグラウンドアクティビティを許可」「最適化しない」などと表示される場合があります。名称は異なりますが目的は同じで、画面ロック後にシステムがVPNサービスを終了しないようにします。

プロキシを常時維持する必要がある場合は、「設定」→「ネットワークとインターネット」→「VPN」→対象クライアント右側の設定ボタンから、「常時接続VPN」を有効にできます。「VPN未接続時の接続をブロック」は、必要な通信がすべて正常に通ることを確認してから検討してください。ノードや設定に問題があると、この項目によって端末全体がインターネットに接続できなくなります。

バックグラウンド権限は多ければよいわけではありません。通知、起動時の自動開始、VPNのバックグラウンド動作は接続維持に必要な場合があります。一方、フローティングウィンドウ、位置情報への継続的なアクセス、付近のデバイス検索は、クライアントの機能上必要かどうかで判断してください。システムのバッテリー設定では、「バックグラウンド動作を許可」と、サードパーティ製の管理アプリによる「画面ロック時のクリーンアップ」が競合しないようにします。

iOS：低電力モードとネットワーク拡張

iOSクライアントはNetwork Extensionを通じてプロキシトンネルを動作させます。「設定」→「一般」→「VPNとデバイス管理」→「VPN」で構成状態を確認できます。消費電力の記録は「設定」→「バッテリー」にあります。「過去24時間」と「過去10日間」を見るときは、「バックグラウンドアクティビティ」と画面点灯中の前景利用時間を区別してください。

低電力モードは一部アプリのバックグラウンド更新を制限しますが、確立済みのVPNトンネルはシステムが管理するため、維持するためにクライアントを何度も開く必要はありません。画面ロック後に頻繁に切断される場合は、まずクライアントのオンデマンド接続ルール、ノードの安定性、システムログを確認してください。VPNを手動で繰り返しオフ・オンするのは避けます。切り替えるたびにインターフェース、DNS状態、プロキシ接続を再構築する必要があるためです。

そのまま使える3つの省電力設定

設定1：常時オンライン

1. サブスクリプションの自動更新を24時間ごとに設定します。
2. ヘルスチェックの間隔を900秒または1800秒に設定し、遅延チェックを有効にします。
3. 遅延が安定したノードを選び、自動選択のたびにグループ全体の速度測定を行う方式は避けます。
4. TUNまたはシステムVPNを維持し、クライアントに必要なバックグラウンド動作を許可します。
5. リアルタイムログ画面と接続一覧を閉じ、異常があるときだけ一時的に開きます。

設定2：必要なときだけ接続

1. システムの常時接続VPNを無効にします。
2. クライアントのショートカットスイッチをAndroidのクイック設定、またはiOSのコントロールセンターに追加します。
3. 使用後は画面を閉じるだけでなく、クライアントの停止ボタンでVPNを終了します。
4. 次回起動時はまずサブスクリプションの更新日時を確認し、手動更新が必要か判断します。

設定3：弱い電波では電池持ちを優先

1. 地下鉄、エレベーター、電波の境界エリアではノードの速度測定を行わないでください。
2. ヘルスチェックの間隔を1800〜3600秒に延長します。
3. 最近安定しているノードを1つ固定し、自動切り替えを減らします。
4. 不要なクラウドストレージ同期、写真バックアップ、バックグラウンド動画再生を停止します。
5. ネットワークが安定してから、サブスクリプション更新とノードの可用性チェックを実行します。

再現可能なデータで最適化効果を確認する

参考テストでは、Pixel 8、Android 15、Wi-Fi信号約-48 dBm、正常なバッテリー状態、画面消灯2時間という条件を使用できます。76ノードを含む構成で、300秒間隔の全量ヘルスチェックを行うと、2時間で電池残量が3%減少しました。1800秒に変更して遅延チェックを有効にすると、減少は1%でした。同じ端末でVPNを無効にした対照では1%減少しました。これらの数値はテスト方法を示すためのもので、すべてのスマートフォンで同じ結果になるとは限りません。

iPhone 15、iOS 18.6で行った4時間のアイドルテストでは、安定したノードとオンデマンド接続ルールを使った場合、電池残量は2%減少しました。頻繁な自動速度測定を有効にし、Wi-Fiとモバイルネットワークを何度も切り替えた場合は5%減少しました。iOSのバッテリー表示は整数パーセントで記録されるため、2時間未満のテストは誤差が大きくなります。4時間または一晩の結果を比較するほうが適しています。

各テストでは、一度に1つの変数だけを変更します。たとえば、最初はヘルスチェック間隔だけを調整し、次の回でDNSを変更し、最後にTUNのオン・オフを比較します。5つの設定を同時に変更すると、消費電力が下がっても、どの項目が有効だったのか判断できません。テスト時には室温、電波の種類、ノード、ダウンロード状況、画面使用時間も記録してください。

消費電力が異常なままのときの確認手順

手順1：自動タスクを停止する

自動速度測定を無効にし、ヘルスチェックを一時的に3600秒へ変更して、サブスクリプションの自動更新も停止します。画面をロックして2時間テストしてください。消費電力が明らかに下がった場合は、機能を1つずつ戻します。変化がなければ、原因はノード接続、別のバックグラウンドアプリ、またはシステムのネットワーク環境にある可能性があります。

手順2：繰り返し発生するエラーを確認する

実行ログを開き、3〜5分間観察します。`timeout`、`network is unreachable`、`connection reset`、DNSの連続失敗を重点的に確認してください。同じ対象で数秒おきにエラーが繰り返されるなら、接続が再試行を続けている可能性があります。まず安定したノードに変更し、DNSとIPv6の設定を確認します。

手順3：Wi-Fiとモバイルネットワークを比較する

安定したWi-Fiで1回テストした後、4Gまたは5Gで同じ時間のテストを行います。モバイルネットワークだけで異常が出る場合は、まず電波強度と通信方式の切り替えを確認してください。スマートフォンが5G、4G、圏外の間を頻繁に切り替えると、プロキシを無効にしていても大きく電池を消費することがあります。

手順4：設定の規模を確認する

大きすぎるルールセットは、起動時の解析時間とメモリ使用量を増やします。ただし、安定稼働後の主な負荷は通常、実際のネットワーク活動によるものです。一時的に簡素化した設定を使い、プロキシグループ1つ、少数のルール、DNS構成1つだけを残して確認できます。簡素化した設定で正常に戻ったら、ルールプロバイダーとプロキシプロバイダーを段階的に追加します。

手順5：クライアントとコアを更新する

クライアントが保守されているバージョンを使用していることを確認し、コアのバージョンと更新履歴も確認します。mihomoでは、バージョンによってモバイルネットワークの切り替え、DNSキャッシュ、TUN接続に関する問題が修正されている場合があります。アップグレード前に現在の設定をエクスポートし、更新後はまず元の設定で再測定してください。大量のパラメーターを同時に変更しないことが重要です。

省電力設定のまとめ

Clashのスマートフォン版で重要なのは、バックグラウンド機能をすべて無効にすることではなく、意味のないウェイクアップと再接続を減らすことです。ヘルスチェックを900〜1800秒に保ち、遅延チェックを有効にし、高頻度の全ノード速度測定を停止し、安定したDNSとノードを使うほうが、クライアントを何度も終了するより効果的です。

Androidでは、システムのバッテリー最適化とVPNバックグラウンドサービスの競合に対処する必要があります。iOSでは、オンデマンド接続、ネットワーク拡張の状態、低電力モード中の動作を確認します。TUNモードは長時間有効にできますが、信頼できるノード、接続ループのないルール、安定したネットワーク環境が前提です。変更後は2〜4時間のアイドル比較テストで結果を確認してから、さらに調整するか判断してください。