Clashモバイル版のバッテリー消費が異常に多いときの対策：バックグラウンド動作・バッテリー最適化・接続設定

1. まず比較可能な消費電力の基準値を作る

「過去24時間」のバッテリー使用量ランキングをそのまま見ると、画面使用時間、動画再生、モバイル回線の電波状況、システム更新の影響を受けやすくなります。夜間の2時間待機や普段の作業1時間など、使い方が近い時間帯を選び、プロキシを停止した状態、システムプロキシのみを有効にした状態、TUNまたはVPNで通信を引き受けた状態をそれぞれ比較しましょう。テスト中は、できるだけ同じネットワーク、同じノード、同じアプリの利用状況を保ちます。

4つの重要情報を記録する

1. 電池残量の変化：開始時と終了時の残量を記録し、システム統計におけるクライアントの割合ランキングだけを見ないでください。ランキングは相対値なので、他のアプリの使用量が少ないと、プロキシクライアントの消費が大きくなくても上位になることがあります。
2. 端末温度：画面消灯後も温かい状態が続く場合、再接続の繰り返し、大量のログ出力、高頻度の速度測定、異常なネットワーク要求が発生している可能性があります。
3. サービスの継続性：VPNアイコンが何度も消えるか、画面ロック解除後にプロキシが復旧するか、クライアントログに短時間で起動記録が繰り返し出ていないかを確認します。
4. ネットワーク条件：Wi-Fi、モバイル回線、電波の弱い場所、ネットワーク切り替え時を分けて確認します。モバイル回線の電波が弱いと基地局との通信自体で消費電力が増えるため、すべてをClashの原因にすることはできません。

プロキシを有効にした後の電池減少が基準値より少し大きいだけで、発熱やサービス再起動がないなら、すべての機能を無理に削る必要はありません。バックグラウンド動作を過度に制限すると、システムがVPNサービスを停止し、クライアントやシステムが再起動して「停止—起動—再接続」のループに陥ることがあります。結果として、安定して動作させるより多くの電力を消費する場合があります。

2. バックグラウンド動作とシステムのバッテリー最適化を確認

Androidメーカーの端末では、システム全体のバッテリー最適化、アプリのバックグラウンド動作制限、自動起動管理、省電力モードが同時に用意されていることが一般的です。複数の設定が重なって適用される場合があります。クライアントのバックグラウンド動作を許可していても、画面消灯後に強力な省電力機能がネットワークを制限することがあります。また、自動起動を許可していても、アプリが「制限あり」のバッテリーモードに入っているとVPNサービスが停止することがあります。

Androidでの確認手順

1. システムのアプリ情報を開き、現在使用しているClashまたはmihomoのGUIクライアントを探します。
2. バッテリーまたは電池使用量の管理を開き、アプリを「制限あり」からバックグラウンド動作を許可するモードに変更します。システムによって「制限なし」「バックグラウンドでの使用を許可」など、表示は異なります。
3. 自動起動、関連付け起動、バックグラウンドでのポップアップ表示など、メーカー独自の拡張項目を確認します。サービスが回収された後にシステムの通常の仕組みで復旧できる状態にすれば十分で、プロキシと無関係な権限まで同時に有効にする必要はありません。
4. 省電力モードがVPNを停止したり、バックグラウンド通信を制限したり、定期タスクを遅延させたりしないか確認します。テスト時はまず極端な省電力モードを終了してください。
5. 最近使ったアプリの画面でアプリをロックする方法は、補助的な対策にすぎません。一部のシステムはバッテリー設定に基づいてサービスを回収するため、アプリのバッテリー設定の代わりにはなりません。

「画面ロックから十数分後に通信が切れ、画面を点灯してクライアントを開くと復旧する」場合は、バックグラウンド通信またはVPNサービスが制限されている可能性を優先して確認します。「プロキシは使えるが、クライアントのバックグラウンド時間が長い」場合は、バックグラウンド権限をすぐに無効にするのではなく、ヘルスチェック、サブスクリプション更新、ログレベル、ノード再接続を確認してください。

頻繁な再起動は常駐より電池を消費しやすい

プロキシサービスの起動時には、設定の読み込み、ルールセットのロード、DNSの初期化、仮想ネットワークインターフェースの作成、ノードへの接続が必要です。システムが一定間隔でサービスを回収すると、クライアントはこれらの処理を繰り返すことになります。ログに設定の読み込み、VPNの確立、インターフェース作成、ノード接続が連続して記録されているなら、重視すべきはバックグラウンド設定やクライアントの安定性であり、単に常駐時間を短くすることではありません。

3. 接続方式、ノードの安定性、再接続動作を比較

モバイルクライアントは通常、システムのVPNインターフェースを使って通信を引き受けます。これはClashの設定におけるTUNモードに近い動作ですが、具体的な実装はクライアントとOSによって異なります。一部のアプリだけがシステムプロキシ設定を利用する場合と比べ、VPNやTUNによる処理範囲は広く、多くの接続、DNSリクエスト、ルーティング判断を処理するため、固定的な消費電力が高くなる可能性があります。モバイルアプリでモードを切り替えられるかどうかは、実際のクライアントの項目を基準にしてください。

TUNまたはVPNモードで消費電力が増えることがある理由

• 仮想インターフェースを通るすべての接続は、コアが読み取り、ルールに従って照合する必要があります。一部のシステムサービスやバックグラウンドアプリの通信も対象になります。
• UDP、リアルタイム通信、長時間接続ではセッション状態の維持が必要になる場合があり、ネットワーク切り替え後に再確立されることもあります。
• DNSハイジャック、Fake IP、拡張DNSモードではローカルでの問い合わせ処理が増えます。ただし、それだけで異常な電池消費になるとは限りません。重要なのは、問い合わせループ、タイムアウトによる再試行、設定の競合が発生していないかです。
• モバイル回線とWi-Fiを切り替えると、古い接続が無効になり、新しい接続では出口を選び直す必要があります。ノードのハンドシェイクが遅いと、この段階の消費電力が大きくなります。

クライアントが指定アプリのみのプロキシやLAN通信のバイパスに対応している場合は、実際の用途に応じて処理範囲を狭められます。たとえば、プロキシが不要なローカル画面ミラーリング、プリンター、LANストレージへのアクセスは直接接続にできます。節電目的でプロキシが必要なシステムコンポーネントまで無計画に除外すると、一部アプリが通信できない、DNS経路が一致しない、接続が誤った出口へ漏れるといった問題が起きるため注意してください。

ノードの不安定さは見落としやすい原因

ノードの遅延が高いからといって、必ずしも消費電力が高いとは限りません。しかし、頻繁なタイムアウトや切断は再試行、プロキシグループの再選択、アプリ側接続の再構築を引き起こします。まず安定性を確認したノードを一つ固定し、頻繁に切り替わる自動プロキシグループは一時的に使わず、しばらく様子を見ます。温度とバックグラウンド動作が明らかに改善したら、プロキシグループのテストURL、テスト間隔、切り替えしきい値を確認します。

url-testは設定した間隔で候補ノードをテストし、条件に合う結果を選択します。fallbackは利用可能性を確認し、現在のノードが使えなくなったときに切り替えます。load-balanceはポリシーに従って接続を振り分けます。ノード数が多く、テスト間隔が短いと、定期的な探索によって追加のネットワーク起動が発生します。モバイル端末で数十個のノードを高頻度テストグループに入れる必要はありません。まずは普段使う地域と安定した品質のノードに絞りましょう。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - ノード-A
      - ノード-B
      - ノード-C
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 100

上記は候補数とテスト頻度を調整する考え方を示す例であり、すべてのサブスクリプションに同じ数値を適用するものではありません。テストURLは期待する結果を安定して返せる必要があります。利用中のネットワークからそのURLへ確実にアクセスできないと、クライアントは失敗を繰り返し、再テストやノード切り替えを続けることがあります。

4. ルール、DNS、定期タスクの切り分け範囲を絞る

ルール数が多いからといって、必ずしも異常な電池消費になるわけではありません。mihomoはルールの種類に応じた照合方式を使うため、適切に管理された大規模なルールセットでも、通常はネットワーク再試行による影響より安定しています。確認すべきなのは、ルールプロバイダーの頻繁な更新、設定の重複読み込み、複雑なスクリプト処理、DNS問い合わせループ、ログの継続的な書き込みです。

ルールプロバイダーの更新間隔を確認

リモートルールセットやサブスクリプションは、定期的にファイルを取得して再読み込みします。複数のルールプロバイダーに短い更新間隔を設定すると、モバイル端末でネットワークが頻繁に起動します。変化の少ないドメインやIPのルールセットを数分おきに更新する必要は通常ありません。まず設定内のrule-providers、サブスクリプションの自動更新、クライアントの定期更新項目を確認し、重複タスクがないか調べます。

rule-providers:
  direct-list:
    type: http
    behavior: domain
    url: https://example.invalid/rules/direct.yaml
    path: ./ruleset/direct.yaml
    interval: 86400

例にあるURLはフィールド構成を示すだけのものです。実際の設定では、サブスクリプションまたはルールの管理元が提供する有効なURLを使用してください。更新間隔を変更したら設定を再読み込みし、ログでルールのダウンロードと設定更新が短時間に繰り返されていないか確認します。

DNSの再試行と名前解決ループを見つける

DNS設定に問題があると、Webページの初回表示が遅い、ログで同じドメインが何度も検索される、ノードのドメインを解決できない、ネットワーク切り替え後も長時間接続されないといった症状が現れます。暗号化DNSサーバーへのアクセスにプロキシが必要で、そのプロキシノードのドメイン名も同じ名前解決経路に依存している場合、起動時の依存関係が循環することがあります。ノードの名前解決用に利用可能な基礎DNS経路を確保し、クライアントとコアのドキュメントに従ってdefault-nameserver、nameserver、プロキシサーバーのドメイン解決を設定してください。

Fake IPモードはドメインに仮想アドレスを割り当て、コアがドメインと接続の対応関係を保持します。ルール照合や透過プロキシとの互換性を改善できる一方、LANサービス、特殊なアプリ、特定の検知用ドメインでは除外リストへの追加が必要になることがあります。除外範囲が広すぎるとモードの効果が下がり、狭すぎると非対応アプリが再試行を繰り返します。切り分けでは、ログで繰り返し失敗している具体的なドメインを対象にし、過度に大きな除外リストをそのままコピーしないでください。

デバッグログによる継続的な書き込みを減らす

詳細ログは短時間の障害特定には向いていますが、長期間有効にするものではありません。ログレベルをdebugにすると、多数の接続、DNS、ルール照合の情報がストレージに書き込まれ続け、画面更新の負荷も増えます。診断が終わったらinfo、warning、またはクライアントが推奨する通常レベルに戻してください。過去のログを削除しても空き容量が増えるだけで、その後の動作に影響するのはログレベルと記録頻度です。

5. AndroidとiOSのバックグラウンド動作の違い

Android：VPNサービスが回収されていないか重点的に確認

Androidクライアントは通常、VpnServiceを使ってローカルVPNを構築します。システム通知バーに表示される常駐通知は、前景サービスと関係していることが多く、ネットワークサービスが継続動作していることをシステムに知らせます。通知権限を手動で無効にしたり、バックグラウンド動作を制限したり、メーカー独自の深いスリープを有効にしたりすると、サービスの安定性に影響する可能性があります。具体的な動作はOSのバージョンとクライアントの実装によって異なるため、システムのバッテリー記録とクライアントログを合わせて判断してください。

Androidでは、アプリのクラッシュ、応答なし、起動回数などのシステム情報も確認できます。クライアント自体が頻繁に終了する場合は、まず現在のシステムバージョンに対応した安定版へ更新し、同じ設定を正常に読み込めるか確認します。設定ファイルが大きすぎる、構文エラーがある、メモリに余裕がないといった要因でも起動に失敗します。「プロキシが切断された」という事実だけでコアのクラッシュと判断しないでください。

iOS：アプリ画面とネットワーク拡張を分けて考える

iOSの互換クライアントは通常、Network Extensionを通じてプロキシまたはVPN機能を提供します。アプリ画面がバックグラウンドに移行しても、ネットワーク拡張はシステムによって管理され続けるため、マルチタスク画面からアプリを削除しても、クライアント内の停止ボタンでトンネルを終了したことと同じとは限りません。バッテリー統計でも、一部のネットワーク活動がクライアント、システムのネットワークサービス、またはデータを転送中のアプリに分けて計上されることがあります。

iOSの電池消費を切り分ける際は、低電力モード、モバイル回線の品質、オンデマンド接続ルール、クライアント内のノードテスト計画を確認します。オンデマンド接続を設定していると、ネットワーク環境の変化によってルール評価が実行されます。さらに高頻度のヘルスチェックを設定していると、Wi-Fiとモバイル回線の切り替え時に接続の再構築が目立ちやすくなります。テスト中はネットワークを固定し、不要なノードテストを一時停止してから電池曲線を比較してください。

どちらのプラットフォームでも、別のOSのバックグラウンド設定名をそのまま当てはめるのは避けてください。確認すべき事実は3つです。プロキシトンネルが継続しているか、システムがサービスを繰り返し終了していないか、設定がネットワークタスクを継続的に発生させていないか。設定画面は異なっても、診断の考え方は同じです。

6. 段階的にモバイル端末の電池消費を切り分ける

段階1：プロキシと直接関係があるか確認

1. 同じネットワーク環境で、プロキシを停止した状態の待機時電池残量を一定時間記録します。
2. プロキシを有効にし、安定したノードを一つ固定します。ダウンロード、動画再生、大規模な同期は行いません。
3. 電池の減り、温度、バックグラウンド動作を比較します。差が小さい場合は、短時間の割合変動だけで結論を出さず、より長い期間を観察してください。

段階2：システムによる繰り返しのサービス回収を除外

1. クライアントの通常のバックグラウンド動作を許可し、システムの極端な省電力モードを終了します。
2. 画面ロック後にプロキシが中断するか、ロック解除後に新たな起動ログが出るかを確認します。
3. サービスが頻繁に復旧する場合は、バッテリー最適化、自動起動、バックグラウンド通信、VPN権限を確認します。

段階3：定期的なネットワークタスクを減らす

1. サブスクリプションの自動更新と、リモートルールセットの高頻度更新を一時停止します。
2. 自動プロキシグループの候補ノードを減らし、ヘルスチェックの間隔を延ばします。
3. ログレベルをデバッグから通常レベルに戻します。
4. 安定したノードを一つ固定し、ノードのタイムアウトとプロキシグループの頻繁な切り替えを除外します。

段階4：DNSと通信の引き受け範囲を確認

1. ログに連続したDNSタイムアウト、同じドメインへの繰り返し問い合わせ、ノードドメインの名前解決失敗がないか確認します。
2. プロキシがまだ確立していない段階でも、基礎DNSが必要な名前解決を完了できることを確認します。
3. 必要に応じてアプリのバイパス、LANへの直接接続、TUNの処理範囲を調整し、変更するたびに再テストします。

段階5：機能を戻して検証

電池消費を明らかに改善した要因が見つかっても、すぐにテストを終えないでください。サブスクリプション更新、プロキシグループ、元のルールを一つずつ戻し、各項目を戻すたびにしばらく観察します。ある項目を戻した後に異常が再発すれば、原因範囲をさらに絞れます。たとえば特定の自動プロキシグループを有効にしたときだけ発熱するなら、設定全体を削除するのではなく、そのグループのノード数、テストURL、間隔を確認します。

結論：バックグラウンドを過度に制限せず、安定動作を優先する

Clashモバイル版の異常な電池消費は、単一のスイッチだけで起きるとは限りません。システムのバッテリー制限、VPNサービスの再起動、不安定なノードへの再接続、高頻度のヘルスチェック、サブスクリプション更新、DNSタイムアウトが重なって発生することがあります。最も有効なのは、プロキシ停止時と安定動作時の基準値を比較し、サービスが継続しているかを確認したうえで、定期タスクを減らし、DNSとノードの品質を検証することです。

一日中プロキシを維持する必要がある端末では、サービスを何度も終了・復旧させるより、安定して常駐させるほうが省電力になることが多いです。特定の場面だけプロキシを使う端末では、クライアント内からサービスを停止できます。設定後は少なくとも普段の利用サイクルを一通り観察し、Wi-Fiとモバイル回線の動作を分けて記録して、信頼できる結論を出してください。