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

モバイル端末でClashまたはMihomo互換カーネルを採用したクライアントを有効にすると、通常はVPNの常時接続アイコンが表示されます。これは端末の通信がローカルVPNインターフェースを経由していることを示すだけで、プロキシクライアントだけがバッテリー低下の原因だとは断定できません。実際には、モバイル回線の再接続、特定アプリの継続的な通信、過剰なDNS問い合わせ、ノードへの不安定な接続、OSによるバックグラウンドサービスの強制終了と再起動などが電力を消費している可能性があります。

切り分けでは、まず「バッテリー使用量に占める割合が高い」ことと「実際の減り方が速い」ことを区別します。端末全体の消費量が少ない日は、期間内の消費内訳が表示されるため、アプリ一覧でClashの割合だけが高く見えることがあります。一方、画面を消していても端末が熱い、1時間ごとに目立って残量が減る、モバイルデータ通信が長時間止まらない場合は、対処が必要な異常に近い状態です。

VPN常時接続がバッテリー使用量に計上される理由

Android・iOS向けのClash系クライアントは、一般にOSのVPNインターフェースを利用して通信を処理します。端末から送信されたパケットをローカルの仮想ネットワークインターフェースで受け取り、設定に従ってDNS処理、ルール判定、プロキシ転送を行います。判定結果がDIRECTでも、通信が先にこのローカル処理経路を通ることがあります。そのため、OSはネットワーク処理、CPU使用時間、バックグラウンド動作時間の一部をVPNクライアントに計上します。

常時動作と高負荷は別の状態

画面が消えていてアクティブな接続がない場合、正常なローカルVPNサービスは低負荷で待機できます。キープアライブ、ヘルスチェック、OSによるネットワーク切り替えで一時的に起動することはありますが、CPUを長時間大きく消費する状態は正常ではありません。待機中の消費が目立つ場合は、単に「バックグラウンドで何時間動いたか」を見るのではなく、その間に大量の通信、頻繁なウェイクアップ、ノードへの再接続、過剰なログ出力がなかったか確認します。

安定したWi-Fiより、モバイル回線のほうが差を増幅しやすい傾向があります。電波が弱いと基地局との通信に必要な送信出力が上がり、Wi-Fiとモバイルデータを行き来するとプロキシ接続も再確立されることがあります。この場合、バッテリー画面では処理の一部がプロキシクライアントに計上されても、根本原因は通信環境と接続の再確立が重なったことにあります。

ルールモードにも処理コストがある

ルールモードでは、ドメイン名、IP、プロセス情報、ルールセットなどを基に接続先を決定します。一般的な設定での1回の照合コストは小さく、ルール数が多いだけで直ちにバッテリー消費が大幅に増えるとは限りません。ただし、極端に大きいルールセット、重複ルール、多数のリモートルールプロバイダー、頻繁な更新、常時有効なドメインスニッフィングは、メモリ使用量とバックグラウンド処理を増やします。多くの場合、原因は1件のDOMAIN-SUFFIXルールではなく、複数機能の組み合わせです。

クライアント・設定・他アプリのどこに原因があるかを切り分ける

効果的に切り分けるには、一度に変更する要素を1つに絞ります。TUNの無効化、ルール削除、ノード変更、省電力設定の変更を同時に行うと、一時的に消費が減っても、どの操作が効いたのか判断できません。現在正常に使える設定のコピーを保存し、次の順序で比較してください。

1. 集計期間を確認する。OSのバッテリー画面で対象期間を確認し、システム更新、アプリ更新、写真のバックアップ、大容量ファイルのダウンロード直後を除外します。
2. 実際の減少ペースを記録する。同じネットワークで画面を消し、30～60分待機します。開始時と終了時の残量、端末温度、継続的なアップロードやダウンロードの有無を記録してください。
3. 通信元を確認する。クライアントの接続画面で、特定のアプリが接続を繰り返し作成していないか調べます。ブラウザーのタブ、クラウドストレージ、写真の同期、メッセージアプリのバックアップ、メディアアプリなどはバックグラウンドで通信を続ける場合があります。
4. 安定したノードへ変更する。接続できることを確認済みのノードを選び、自動切り替えが頻発するポリシーグループを一時的に無効化して、再接続の回数が減るか確認します。
5. 最小構成と比較する。必要なDNS、少数のルール、1つのプロキシポリシーだけを残し、不要なデバッグ機能を無効にします。消費が正常に戻ったら、ルールセット、スニッフィング、ヘルスチェックを1項目ずつ戻します。
6. 最後にVPNを無効にして比較する。同じ環境でプロキシを無効にしたデータと比べて初めて、ローカルVPN経路による測定可能な差があるか判断できます。

ノードの遅延値より接続一覧を確認する

ノードの遅延テストで分かるのは、その時点で送ったテストリクエストの応答時間だけです。バックグラウンド通信がないことまでは示しません。同じドメインが数秒おきに接続一覧へ現れる場合は、まずどのアプリの通信かを特定し、プッシュ通知、広告リクエスト、テレメトリー、同期、失敗後の再試行のいずれかを確認します。ハンドシェイクを完了できないバックグラウンド処理は、1回の通信量が小さくても新しい接続を繰り返し作成し、ネットワークとCPUを頻繁に起動させることがあります。

画面を消した後も接続数が増え続ける場合は、最近インストールまたは更新したアプリを一時的に無効にして比較できます。DIRECTポリシーへ切り替えて確認する方法もあります。リクエストが続くなら端末上のアプリが通信元です。特定のプロキシノードでだけ繰り返されるなら、ノードの安定性、プロトコルの互換性、接続先への到達性を調べてください。

設定が原因となる高頻度のバッテリー消費

ヘルスチェック間隔が短すぎる

url-testやfallbackなどのポリシーグループは、テスト用URLへのアクセスでノードの状態を判定できます。ヘルスチェック自体は有用ですが、ノード数が多く間隔も短いと、クライアントは各候補ノードへ定期的にリクエストを送ります。数十個のノードを数分間隔でテストすると、単発の遅延テストではなく、ネットワークのウェイクアップが一日中繰り返されます。

モバイル端末では用途に合わせてチェック間隔を延ばし、実際には使わない候補ノードを減らしてください。クライアントがオンデマンドチェックや遅延チェックに対応していれば、必要なときだけポリシーグループを確認できます。ただし、具体的なフィールドは現在のカーネルとクライアントのドキュメントに従ってください。バージョンごとに対応フィールドが異なる場合があるため、出所不明の設定項目を別の設定断片からそのままコピーしないでください。

デバッグ用の詳細ログを常時有効にしている

詳細ログは、接続障害時にDNS処理、ルールの一致、プロキシのハンドシェイクを確認する用途に適していますが、日常的に常時使う設定ではありません。大量の接続ログは、整形やメモリ・ファイルへの書き込みに処理が必要で、診断画面も更新され続けます。問題を再現できたら、ログレベルをクライアント推奨の通常設定に戻し、容量が異常に大きい過去ログを削除します。

ログ画面を開いているときだけ消費と温度が明らかに上がる場合、原因はカーネルによる転送処理ではなく、画面が新しい記録を描画し続けていることかもしれません。ログ画面を閉じて画面を消し、再度テストすれば、画面更新とバックグラウンド通信処理を素早く切り分けられます。

DNSエラーと問い合わせループ

DNS設定に問題があると、Webページの表示が遅い、アプリが再試行を繰り返す、同じドメインへの問い合わせが頻発するといった症状が現れます。特にネットワーク切り替え時や、プライベートDNS、OSの暗号化DNS、クライアントDNSを併用している場合は、問い合わせ経路が互いに遮断されていないか確認してください。Mihomoのfake-ipモードは、ドメインを予約済みアドレスへ割り当て、カーネル側でドメインを復元してルールを適用します。予約済みアドレスが表示されること自体は異常ではありません。

DNSを調べる際は、まず現在のネットワークから接続できるリゾルバーを選び、一般的なドメインを安定して名前解決できることを確認してから、複雑なDNS振り分け設定を戻します。省電力だけを目的にIPv6を無効化したり、すべてのDNSサーバーを一度に変更したりしないでください。根本的なネットワーク障害が隠れるだけでなく、一部のアプリがタイムアウトまで待ってから別のプロトコルへフォールバックする可能性があります。

スニッフィング、プロセス照合、大規模ルールセット

ドメインスニッフィングは接続からドメイン情報を復元し、ドメイン情報を直接持たない通信のルール判定に役立ちます。プロセス照合には、クライアントとOSの対応も必要です。どちらも用途のある機能ですが、モバイル端末ですべての高度な機能を同時に有効化したまま、基本的な消費量を判断するべきではありません。まずドメインとIPのルールだけを残して安定性を確認し、その後スニッフィングとプロセスルールを追加できます。

リモートルールセットの更新頻度も確認が必要です。通常、ルールプロバイダーを短時間に何度も取得する必要はありません。サブスクリプションやルールのURLへ接続できないと、クライアントが内部仕様に従って再試行する場合があります。その場合は、失敗する処理をバックグラウンドに残さず、URL、通信経路、更新間隔を修正してください。

Androidのバックグラウンド制限と省電力設定

Android端末は、メーカーごとにバックグラウンドサービスの管理方法が大きく異なります。Clash系クライアントは通常、仮想ネットワークインターフェースを維持するためにフォアグラウンドVPNサービスを必要とし、通知欄の常駐通知もOSの仕組みの一部です。OSがクライアントを厳格な制限対象にすると、画面消灯後にサービスが終了することがあります。その後クライアントまたはOSがVPNを復旧しようとして、切断、再接続、初期化のやり直しが発生します。

確認したいシステム設定

• バッテリー使用設定：クライアントのバックグラウンド動作を許可するか、厳しい制限の対象外にします。メーカーによっては「制限なし」「バックグラウンドでの使用を許可」「バッテリー最適化の対象外」などの名称です。
• 自動起動と連携起動：個別の設定がある場合は、端末の再起動後やVPNサービスの終了後に、ユーザー設定どおりクライアントを復旧できるようにします。
• バックグラウンドデータ：クライアントによるバックグラウンド通信を許可します。フォアグラウンドでしか通信できない設定では、画面消灯後にプロキシのハンドシェイクやDNS問い合わせが失敗する可能性があります。
• 常時接続VPN：常に接続する必要がある場合だけ有効にします。有効にすると、OSは指定されたVPNを常時維持します。「VPNを使用していない接続をブロック」も選ぶと、クライアントが異常終了した際に他のアプリも通信できなくなります。
• 通知権限：一部のOSでは、フォアグラウンドサービスの通知がサービス管理と関連付けられています。必要なVPNステータス通知を残しておくと、サービスが終了したか判断しやすくなります。

クライアントを制限なしにしても、常に高負荷になるわけではありません。目的は、OSが不適切なタイミングでVPNを終了しないようにすることです。アイドル状態の接続を安定して維持するほうが、一定時間ごとにカーネル、仮想ネットワークインターフェース、プロキシ接続を破棄して再構築するより安定する場合があります。ただし、クライアント自体に継続的な通信があると、制限を外すことでその処理も長時間続きます。接続一覧と通信量を併せて確認してください。

TUNモードとシステムVPNの関係

AndroidのGUIクライアントで「TUNモード」と呼ばれる機能は、通常、OSのVPN APIを利用して幅広いIP通信を受け取ります。HTTPまたはSOCKSプロキシだけを設定する方式より対象範囲が広いため、より多くのアプリの接続がクライアントの統計に表示されます。対象範囲が広がれば総通信量やウェイクアップ回数も増える可能性はありますが、「TUNは必ず異常なバッテリー消費を引き起こす」とは断定できません。

システムプロキシに対応する少数のアプリだけでよければ、システムプロキシモードと比較できます。UDP、プロキシ設定を認識しないアプリ、完全なルーティングルールが必要ならTUNが適しています。選択基準は、どの通信まで対象にするかです。異常が起きた場合は、TUNを無効にすることだけを解決策にせず、具体的な接続、DNS、ノードへの再試行を先に確認します。

iOSのバックグラウンド動作と低電力モード

iOS向けのClash互換クライアントは、Network Extensionを使ってVPN機能を提供します。クライアント画面を閉じてもVPN拡張機能は通信を処理できるため、「アプリが前面にない」ことはプロキシの停止を意味しません。拡張機能の動作とリソースはOSが管理し、関連する処理はクライアントまたはネットワーク使用量としてバッテリー統計に計上される場合があります。

低電力モードは一部のバックグラウンド処理を抑えますが、使用中のVPNが自動的に切断されるとは限りません。他のアプリが通信を続ける限り、VPN拡張機能もその接続を処理する必要があります。写真の同期、クラウドストレージへのアップロード、ポッドキャストのダウンロード、アプリ更新が集中すると、プロキシクライアントの使用割合も上がる可能性があります。

オンデマンド接続とネットワーク切り替えを確認する

一部のクライアントは、モバイル回線、指定したWi-Fi、ネットワーク変更時などにVPNを自動接続するオンデマンドルールに対応しています。ルールが競合すると、接続状態が頻繁に切り替わることがあります。いったんオンデマンドルールを無効にし、安定したWi-Fi上で手動接続してしばらく確認してください。消費と切断が改善した場合は、ネットワーク条件を1項目ずつ戻します。

Wi-Fiからモバイル回線へ移動すると、既存のTCP、UDP、QUICベースの接続を再確立する必要があります。短時間の通信は正常ですが、端末を置いたままでも切り替えが続く場合は、Wi-Fiの電波状況、アクセスポイントへの自動接続設定、両方のネットワークからノードへ安定して接続できるかを確認します。

バックグラウンドアプリを何度も終了しない

マルチタスク画面でクライアントをスワイプして終了しても、VPN拡張機能が想定どおり停止するとは限りません。動作はクライアントの実装とOSの状態によって異なります。プロキシを無効にした比較テストが目的なら、クライアントまたはOSのVPN設定で明示的に切断してください。アプリの終了と再起動を繰り返すと、設定の読み込み、サブスクリプション状態の確認、接続の初期化が実行され、安定したテスト結果を得にくくなります。

iOSのバッテリー統計は、数時間から1日単位の傾向を見るのに適しており、数分間の割合だけで結論を出す用途には向きません。画面オフ中のアクティビティ、モバイルデータ使用量、端末温度も併せて確認してください。特定のネットワーク環境だけで異常が起きる場合は、すべての設定を削除する前に、そのネットワークへ接続し直すか、DNS、ルーター、ノードへの到達性を調べます。

症状別の切り分け手順

ケース1：待機中の減りが速いが通信量は少ない

1. クライアントのログ、接続モニター、リアルタイム速度テスト画面を閉じる。
2. 自動遅延テストと、間隔が短すぎるポリシーグループのヘルスチェックを停止する。
3. OSがVPNサービスを頻繁に終了・再起動していないか確認する。
4. 安定したノードへ変更し、ハンドシェイク失敗と再接続が減るか確認する。
5. 最小構成で1時間テストし、高度な機能を1項目ずつ戻す。

ケース2：待機中も通信量が多い

1. 接続一覧をドメイン、接続先アドレス、アプリなどの通信元で並べ替える。
2. クラウドストレージ、写真、メディアキャッシュ、システム更新を一時停止して比較する。
3. サブスクリプションとリモートルールが繰り返しダウンロードされていないか確認する。
4. DNSエラーによってアプリが再試行を続けていないか確認する。
5. DIRECTとプロキシの各ポリシーで、リクエストが引き続き発生するか確認する。

ケース3：モバイル回線でだけ発熱する

1. モバイル回線の電波強度を確認し、電波が安定する場所で再テストする。
2. 不要なバックグラウンド同期を無効にし、大容量ファイルのアップロードとダウンロードを減らす。
3. 利用中の通信事業者の回線から安定して接続できるノードを選ぶ。
4. ポリシーグループが複数のノード間で頻繁に自動切り替えしないようにする。
5. IPv4、IPv6、DNSの経路に長時間のタイムアウトがないか確認する。

ケース4：画面消灯後に切断され、ロック解除後に復旧する

1. Androidでは、バッテリー最適化、バックグラウンドデータ、自動起動、フォアグラウンドサービスの通知を確認する。
2. iOSでは、オンデマンド接続ルールと低電力モード時の実際の動作を確認する。
3. クライアントがフォアグラウンドでのみ接続を維持する設定になっていないか確認する。
4. ネットワーク切り替え後にOSがVPN権限を取り消していないか確認する。
5. 動作確認済みの最小構成を保存し、設定の読み込み失敗を切り分ける。

省電力設定で調整すべき範囲

モバイル端末の省電力対策は、すべてのバックグラウンド機能を止めることではありません。必要なルーティング機能を維持しながら、不要なウェイクアップを減らすことが目的です。普段使う設定では、実際に使うノードだけを残す、利用頻度に合ったヘルスチェック間隔にする、問題解決後はデバッグログを通常レベルへ戻す、リモートルールとサブスクリプションを適切な間隔で更新する、という4つの原則が役立ちます。

ノードのプロトコル、暗号化処理、ネットワーク実装も処理負荷に影響しますが、実際の利用環境では画面、モバイル回線の電波、通信量、アプリの挙動のほうが大きく影響することが一般的です。プロトコル名だけで消費量を判断したり、1回だけのテストで2つのノードを比較したりしないでください。同じネットワークと同程度の通信量で継続的に観察し、再接続回数と端末温度を記録します。

設定を変更した直後に異常が現れた場合は、以前の正常な設定へ戻し、新しく追加したルールプロバイダー、ポリシーグループ、DNS、スニッフィング設定を比較します。同じクライアントバージョンですべての設定に異常が出るなら、OS更新、クライアント更新、VPN権限を確認してください。特定のネットワーク環境だけで発生するなら、電波状況、ルーター、DNS、ノードへの到達性を重点的に調べます。

切り分け後は、テストしたネットワーク、クライアントのバージョン、カーネルの種類、設定変更、開始時と終了時の残量、観察時間を簡単に記録しておくことをおすすめします。クライアントやサブスクリプションの更新後に問題が再発しても、システム、ソフトウェア、設定のどこが変わったのかを素早く判断でき、最初から推測し直す必要がなくなります。