バッテリー消耗の原因調査の基本方針:まず分類し、そのうえで特定する
モバイル環境で報告される「バッテリー消耗が激しい」という問題は、単一の原因であることは少なく、設定側の問題とOS側の問題が重なって起きているケースが大半です。設定側とは、Clash本体やmihomoコアの動作パラメータのことで、具体的にはルールセットの更新頻度、ログ出力レベル、DNSクエリの方式などを指します。OS側とは、AndroidやiOSがバックグラウンドプロセスに対して課す省電力制限や、アプリが「非アクティブ」と判定された後に発動する省電力・スリープ処理を指します。調査の際は、以下の順序で範囲を段階的に絞り込んでいくことをおすすめします。
- まず、画面ロック中/バックグラウンド時に限って消耗が異常なのか、それとも前面で使用している時も高いのかを確認します。前者は主にOSのスケジューリングの問題、後者は主に設定内容やプロキシ経路の問題です。
- コアのログ出力量を確認し、頻繁な再接続、DNSタイムアウトによる再試行、ルールマッチ失敗によるループリクエストが発生していないかを判断します。
- サブスクリプションおよびルールセットの自動更新周期を確認し、ポーリング間隔が短すぎないかをチェックします。
- システムのバッテリー管理画面でクライアントが「制限あり」に指定され、頻繁に呼び起こされて再接続していないかを確認します。
以下の各章ではこの4つの観点に沿って、具体的な確認方法と調整すべきパラメータを解説します。
ルールセットとサブスクリプションのポーリング:更新周期の設定ミスはよくある原因
mihomoコアは設定ファイル内のrule-providersにそれぞれ独立したintervalフィールド(単位は秒)を設定できます。このフィールドは該当ルールセットの自動取得周期を制御するものです。一部のクライアントのGUIは設定ファイルに書かれた間隔をそのまま使用するため、サブスクリプション提供者が間隔を数分単位に設定していると、画面ロック中のスマホが定期的にネットワークモジュールを呼び起こしてHTTPリクエストを発行することになります。これはモバイル環境のバッテリー消耗調査で最も見落とされやすい項目です。
rule-providers:
reject-list:
type: http
behavior: domain
url: "https://example.com/rules/reject.yaml"
path: ./rules/reject.yaml
interval: 86400
頻繁に変化しないルールセット(広告ブロック、直接接続リストなど)については、intervalを43200秒(12時間)以上に調整することをおすすめします。分岐ルールが頻繁に変化するシナリオのみ、短い周期を維持してください。同様に、サブスクリプション自体の自動更新(プロファイル側のupdate-intervalやクライアントGUIの「サブスクリプション自動更新」オプション)についても1時間以内に設定するのは避けるべきです。そうしないとスマホはバックグラウンドで繰り返し呼び起こされ、ダウンロード、パース、設定の再読み込みという一連の処理を実行することになります。この処理自体はディスク書き込みやコアの再起動を伴うため、1回あたりの消耗コストは決して小さくありません。
ログレベルとDNS並列処理:設定ファイル内で見落とされがちな消耗要因
ログレベルをdebugやinfoに設定すると、コアは接続の確立、ルールマッチ、DNS解決のたびにログを書き込むため、継続的なディスクI/Oと文字列整形処理によって余分なCPU負荷が発生します。日常的なモバイル利用ではログレベルをwarningに調整し、接続性の問題を積極的に調査する際だけ一時的にdebugに切り替え、調査終了後は速やかに戻すことをおすすめします。
log-level: warning
DNS部分も確認する価値があります。enhanced-mode: fake-ipを有効にし、複数のnameserverに並列でクエリを送る構成はよく見られますが、上流DNS(特に海外サーバー)を過剰に設定し、適切なfallback-filterを設定していない場合、名前解決のたびに複数のリクエストを並列で送信し、タイムアウト判定で最適な結果を待つことになります。これはモバイル通信の電波状況が不安定な環境では、無線モジュールのアクティブ時間を大幅に増やす要因になります。
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 223.5.5.5
- 119.29.29.29
fallback:
- "tls://8.8.8.8:853"
fallback-filter:
geoip: true
geoip-code: CN
nameserverのリストを応答が安定した2〜3件に絞り、fallbackは海外ドメインだと明確に判定された場合のみ有効になるようにすると、不要な並列解決リクエストを減らせます。
設定でTUNモードを有効にしつつ、パケットごとのルーティングログやコネクショントラッキング機能も同時に有効にしている場合、通常のシステムプロキシモードよりもモバイル端末のCPU使用率が高くなります。必須でない限り、通常のネット利用ではシステムプロキシモードを優先し、透過プロキシで全トラフィックを扱う必要がある場合やUDP転送を処理する必要がある場合にのみTUNモードに切り替えることをおすすめします。
Android:バッテリー最適化ホワイトリストとバックグラウンド自動起動の権限
Android 6.0以降で導入されたDozeモードや、各メーカーのカスタムOS(独自の省電力管理フレームワークをベースにしたもの)は、長時間バックグラウンドに常駐し、画面が消灯した後もネットワーク接続を維持するアプリを制限します。具体的には、サービスがOSによって強制終了された後、VPNフレームワークが再接続を試みるため、その過程で短時間に何度もネットワークハードウェアが呼び起こされ、「消耗しているように見えるが実際は繰り返し再起動されているだけ」という状況が発生します。これを解決するには、クライアントをバッテリー最適化のホワイトリストに追加し、必要な自動起動権限を維持する必要があります。
-
システムのバッテリー管理設定を開く
「設定 → バッテリー → バッテリー最適化」またはメーカー独自OSの「省電力ポリシー」ページに進み、Clashクライアントアプリを見つけます。
-
アプリを「制限なし」に設定する
「最適化しない」または「バックグラウンド動作を許可」を選択し、画面ロック後にOSがこのプロセスのネットワーク接続を強制的に一時停止しないようにします。
-
自動起動および関連起動権限を確認する
アプリの権限管理画面で「自動起動」が有効になっていることを確認します。一部のOSでは「関連起動」の許可も追加で必要です。これがないと、OSに回収されたVPNサービスが自動で復旧できず、ユーザーが手動でアプリを再度開くしかなくなります。
-
常駐通知の権限が無効化されていないか確認する
VPNサービスはフォアグラウンド通知に依存してプロセスの優先度を維持しています。通知権限がOSやユーザーの操作によって無効化されると、サービスの存続時間が明らかに短くなり、再接続のループがより頻繁に発生する要因になります。
補足しておくと、ホワイトリストへの追加自体がバッテリー消耗を増やすわけではありません。これはあくまでOSがプロセスを頻繁に強制終了・再起動することを防ぐための対策です。本当の消耗要因は前の2章で触れたルールポーリング周期やDNS並列処理の設定にあり、ホワイトリストの調整で解決できるのは「接続の不安定さによる間接的な消耗」です。両方を同時に対処してはじめて明確な効果が見込めます。
iOS:オンデマンド接続とVPN構成プロファイルの省電力設定
iOSプラットフォームのネットワーク拡張フレームワーク(NetworkExtension)は、バックグラウンドのプロキシプロセスに対してより厳格な制限を課しており、OSはデバイスのバッテリー残量、ネットワークの種類、利用頻度に応じて拡張プロセスのスケジューリング優先度を動的に調整します。クライアントはiOS上では通常VPN構成の形でシステムに組み込まれ、構成プロファイル内の「オンデマンド接続」(On-Demand)ルールがVPNトンネルの確立タイミングを直接決定します。設定が不適切だと、不要な場面でトンネルが何度も確立・切断される原因になります。
- クライアント設定内のVPN構成管理ページを開き、「オンデマンド接続」または「On-Demand Rules」のオプションを見つけます。
- ルールが「常に接続」に設定されていないか確認し、ネットワークの種類によって区別されているかを確認します。例えば、モバイルデータ利用時、または指定したWi-Fi名以外のネットワーク利用時にのみトンネルを自動確立するようにします。
- 「特定のWi-Fiでは接続しない」を設定している場合、そのリストに自宅やオフィスなど長時間滞在する信頼できるネットワークが含まれているか確認し、そうした場面で無意味にVPNトンネルが確立された状態を保たないようにします。
- システム設定の「VPNとデバイス管理」で対応する構成プロファイルの状態が正常であることを確認します。異常な状態の場合、OSはより高頻度でトンネルの再交渉を試みるため、同様に消耗を増やします。
iOS上のネットワーク拡張プロセスがOSによってサスペンドされると、通常のアプリのようにバックグラウンドで活動を続けることはできません。拡張プロセスがスリープ中はルールセットやサブスクリプションの自動更新は実行されませんが、これは設計上の制限であり故障ではないため、追加の調査は不要です。本当に注目すべきはトンネルの確立頻度であり、拡張プロセスが「常に動いているかどうか」ではありません。
加えて、iOS上で有効にするログレベルも低めに保つことをおすすめします。理由はAndroidやデスクトップ環境と同じで、拡張プロセスが呼び起こされて高頻度のログ書き込みを実行すると、その呼び起こし時間が延び、OSがその拡張プロセスに与えるスケジューリング優先度の判定にも間接的に影響するためです。
長期的な監視:パネル機能で消耗傾向を継続的に観察する
上記の調整を終えたら、クライアント標準の接続パネルやトラフィック統計機能を使って一定期間の動作状態を観察し、主観的な印象だけで問題が解決したと判断しないことをおすすめします。特に注目すべき指標は3つあります。画面ロック後もアクティブな接続数が増え続けているか、DNSクエリの回数が通常のネット利用で必要な量を明らかに上回っていないか、ログ内でルールセットの再読み込みイベントがどの程度の頻度で発生しているかです。画面ロック後もアクティブな接続数が明確に減少しない場合は、通常バックグラウンドの他のアプリが継続的にネットワークリクエストを発行していることを示しており、この種の問題の根源はClash自体ではなくOS側の他のアプリにあることが多いです。アプリ別モードを一時的に有効にすることで、画面ロック後もどのアプリがアクティブな接続を維持しているかを特定できます。
バッテリー消耗の調査は本質的に段階的な消去法です。設定側のルールポーリング周期、ログレベル、DNS並列処理の設定はコア自体の基礎負荷を決定し、OS側のバッテリー最適化ホワイトリストとオンデマンド接続ルールはバックグラウンドでの存続方式が効率的かどうかを決定します。どちらか一方でも設定が不適切だと、その影響はバッテリー駆動時間に増幅されて現れます。本記事の順序に沿って一つずつ確認し、片方だけを調整して結論を出さないようにすることをおすすめします。