iPhoneでClashのバッテリー消費が異常に多い？バックグラウンド動作の仕組みと省電力設定

まずは、ロック画面でもClashが動作し続ける理由を理解する

iPhoneのClash系クライアントは通常、iOSのNetwork Extensionを利用してローカルVPNを構築します。接続を有効にすると、Web閲覧、メッセージ、システムサービスの通信はまずパケットトンネルに入り、その後Clashのコアがルールに従って直接接続、プロキシ経由、拒否を判断します。メインアプリをバックグラウンドに移したり、システムによって最近使ったアプリから終了させられたりしても、トンネルを担当するネットワーク拡張は動作を続けられます。ロック後もプロキシ接続がすぐ切れず、「設定」のバッテリー画面に通信アクティビティが記録され続けるのはこのためです。

バックグラウンドで動作しているからといって、画面消灯後も常に高負荷とは限りません。通信要求がなければ、拡張機能は大半の時間を待機状態で過ごします。プッシュ通知、写真の同期、メールの更新、アプリからの要求を受けたときに、接続処理、DNS照会、ルール照合、データ転送を行います。実際の消費電力は、通信量、ウェイクアップ頻度、ノード品質、DNS設定、ログレベル、プロキシグループのチェックによって決まります。

ロック後にも発生する正常な通信アクティビティ

• メッセージアプリが接続を維持し、プッシュ通知を受信する。
• iCloudの写真、ファイル、デバイスのバックアップがアップロードを続ける。
• メールアカウントがバックグラウンドで取得を行い、システムサービスが時刻やアカウント情報を同期する。
• プロキシグループが設定した間隔でURLテストやノードのヘルスチェックを実行する。
• ルールプロバイダー、プロキシプロバイダー、サブスクリプションが更新時期を迎えるとリクエストを送信する。
• オンデマンド接続のルールがネットワークの変化を検知し、トンネルを再構築する。

そのため、「設定」→「バッテリー」の一覧にClashが表示されただけで、異常な消費とは判断できません。iOSが示すのは、選択した期間における各項目の相対的な割合です。他のアプリの使用量が少なければ、ネットワーク拡張の消費が少なくても高い割合で表示されることがあります。判断する際は、バッテリー残量の減り、バックグラウンド動作時間、モバイル通信の電波状況、実際の通信量も確認してください。

正常な消費と異常な消費を見分ける方法

最も有効なのは、一度きりの割合を注視することではなく、条件をそろえた比較テストを行うことです。開始前にバッテリーを80%以上まで充電し、ダウンロード中のコンテンツを停止、写真の同期を一時停止、画面を消灯します。2回とも同じWi-Fi、同じ場所、近い時間で実施してください。残量が20%未満の場合はシステムの制御が変わるため、比較には適しません。

30分間の比較テストを行う

1. 「設定」→「バッテリー」を開き、直近1時間に大容量ゲーム、動画の書き出し、システムアップデートがなかったことを確認します。
2. 安定したWi-Fiに接続し、インターネット共有をオフにして、Clashを普段使う構成とルールモードに切り替えます。
3. 画面をロックしたまま30分間放置し、開始時と終了時の残量を記録して、Clashのバックグラウンド動作も確認します。
4. ClashのVPN接続を切り、同じネットワークでさらに30分間放置します。
5. バッテリー残量の丸め表示による誤判定を避けるため、両方のテストをもう一度繰り返します。

30分テストにおける1ポイントという数値は、調査開始の目安であり、すべてのiPhoneに共通する基準ではありません。バッテリー容量、劣化状態、周囲の温度、残量表示の丸めによって結果は変わります。より信頼できる異常の兆候は、ロック後も発熱が続く、1時間に数ポイントずつ安定して減る、バックグラウンド通信量が明らかに増える、数秒おきに同じ接続エラーがログへ繰り返し出る、といった状態です。

バッテリー画面で確認する項目

「設定」→「バッテリー」で「アクティビティを表示」に切り替え、「画面オン」と「バックグラウンド」をそれぞれ確認します。Clashのバックグラウンド時間だけが長く、端末全体の消費がわずかなら、通常はネットワーク拡張が利用可能な状態を保っているだけです。バックグラウンド時間、消費割合、モバイルデータ通信が同時に増えている場合に、詳しい原因を調べます。モバイル通信量は「設定」→「モバイル通信」で確認できます。テスト前後の数値を記録すると、割合だけを見るより分かりやすくなります。

高頻度のヘルスチェックはよくある消費電力の原因

URLテストを行うプロキシグループは、検査用アドレスへ定期的にアクセスし、候補ノードの応答を比較します。プロキシプロバイダーにもヘルスチェックを設定できます。1回のリクエストは通常ごく少量ですが、40個のノードを30秒間隔でチェックする構成では、理論上1時間に約4,800回の探測が発生する可能性があります。通信状態が悪いとDNS、TCP、TLSの再試行も重なり、頻繁なウェイクアップにつながります。

モバイル端末でプロキシグループの更新を数秒間隔にする必要はありません。普段使いなら自動テストの間隔をまず600秒にし、回線の変化が少なければ900秒に設定できます。ノードを手動で調べるときだけ、テストを1回実行してください。Clash Meta（mihomo）互換の構成では、遅延チェックの遅延実行を有効にして、現在使っていないプロキシグループの自動テストを減らす方法もあります。

proxy-groups:
  - name: 自動選択
    type: url-test
    use:
      - mobile-provider
    url: http://www.gstatic.com/generate_204
    interval: 600
    tolerance: 100
    lazy: true

proxy-providers:
  mobile-provider:
    type: http
    url: https://example.com/subscription.yaml
    path: ./providers/mobile.yaml
    interval: 86400
    health-check:
      enable: true
      url: http://www.gstatic.com/generate_204
      interval: 600
      lazy: true

サンプルのサブスクリプションURLはフィールドの位置を示すだけなので、実際には現在利用できる有効なURLを使用してください。interval: 600は600秒ごとにチェックする設定で、tolerance: 100は候補間の遅延差が100ミリ秒未満の場合に頻繁な切り替えを抑える設定です。プロバイダーのinterval: 86400は設定ファイルを24時間ごとに更新する値で、ノードのヘルスチェック間隔とは別の設定です。

クライアント画面での調整手順

1. 「設定」→「パラメータ設定」を開き、遅延テスト、ヘルスチェック、プロキシグループのテスト間隔を探します。
2. 60秒未満の間隔はまず600秒に変更し、半日ほど様子を見ます。
3. 使っていないプロキシグループの自動テストをオフにし、メインの自動選択グループを1つだけ残します。
4. サブスクリプションを更新した後は手動テストを1回だけ行い、全ノードの速度テストを連続して実行しないでください。

クライアントによってフィールド名は多少異なります。画面に該当するスイッチがない場合は、自分で管理している構成であることを確認してからYAMLを編集してください。サブスクリプションサービスが自動生成する構成は、次回更新時にローカルの変更が上書きされる場合があります。クライアントのオーバーライド機能を使えば、間隔設定を保持できます。

ルール、DNS、ログの負荷を減らす

ルールは少なければ少ないほど速いとは限りません。ClashのコアはドメインルールやIPルールを適したデータ構造で処理するため、数千件程度の通常のルールだけで大きな消費電力が発生することは一般的ではありません。優先して見直したいのは、重複したルールセット、頻繁に更新されるリモートルール、過剰なスクリプト処理、すべての接続を複雑な処理チェーンへ送る構成です。モバイル端末では、明確で安定した通信振り分けに必要なものを優先して残しましょう。

ルール設定でまず確認する3つのポイント

• 無効なリモートルールセットを削除：到達できないアドレスへリクエストを続けると、タイムアウトと再試行が発生します。
• 重複するプロバイダーを減らす：同じドメイン分類を複数のソースから読み込む必要はありません。
• 更新間隔を延ばす：安定したルールセットは86400秒の更新間隔にでき、10分ごとに取得する必要はありません。

rule-providers:
  direct-sites:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/direct-sites.yaml
    url: https://example.com/direct-sites.yaml
    interval: 86400

ルールは上から下へ順番に照合されます。頻繁に使う明確なローカルドメインのルールは前方に置き、最後にMATCHをフォールバックとして残してください。省電力のために、LANへの直接接続、システムサービス、DNS関連のルールを安易に削除しないでください。接続失敗後の再試行によって、かえってウェイクアップが増える可能性があります。

DNS設定で過剰な並列処理を避ける

複数のnameserverとfallbackを設定しても、毎回すべてが順番に実行されるとは限りません。ただし、複雑なフォールバックやフィルタリングはリクエスト数を増やします。モバイル端末では通常、安定したプライマリDNSを2つ残せば十分です。暗号化DNSを使う場合は、現在のネットワークからサーバーへ到達できることも確認してください。サーバーが頻繁にタイムアウトすると、ドメイン解決のたびに待機と再試行が発生する可能性があります。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

IPv6を無効にするかどうかは、現在のネットワーク環境で判断します。キャリア回線や家庭のブロードバンドでIPv6が安定して使えるなら、そのまま有効にしておけます。ログにIPv6接続のタイムアウトが続き、実際に使うプロキシノードがIPv4にしか対応していない場合に限り、無効化を検討してください。バッテリー消費の感覚だけを頼りに、DNS、ノード、ルールを同時に変更してはいけません。どの設定が効果をもたらしたのか分からなくなります。

ログレベルはinfoまたはwarningに保つ

debugログは、ルールのマッチ、DNSリクエスト、接続失敗を短時間で調べるのに適していますが、終日有効にするものではありません。大量の通信があるとログが継続的に生成され、メモリやストレージへの操作も増えます。調査が終わったらログレベルをinfoに戻してください。構成が安定していてクライアントが対応している場合は、warningも使えます。問題が再現する前にログを消去せず、まず3〜5分間の繰り返し部分を保存するほうが有用です。

オンデマンド接続とTUNモードの設定方法

オンデマンド接続は、条件を満たしたときにVPNを自動的に有効化する機能です。たとえば自宅のWi-Fiから離れたら接続し、信頼できるネットワークに戻ったら切断できます。ルールが単純なら手動操作を減らせますが、条件が競合すると、Wi-Fiとモバイル通信の切り替え、ルーターの電波変動、端末のスリープ解除をきっかけにトンネルを何度も構築することがあります。

オンデマンド接続は条件を明確にする

• 既知のWi-FiのSSIDやネットワーク種別だけで判定し、適用範囲が重なるルールを複数作らないでください。
• 「すべてのWi-Fi接続」と「指定したWi-Fiから切断時」を同時に設定する場合は、ルールの順序にも注意してください。
• 数十秒おきに再接続する場合は、まずオンデマンド接続を30分間オフにして比較します。
• 地下鉄、エレベーター、地下駐車場などでネットワークが頻繁に切り替わる場合は、自動再接続を一時的にオフにして消費電力の変化を確認できます。

1日中ルールによる振り分けが必要なら、安定した接続を1回維持するほうが、頻繁に接続と切断を繰り返すよりリソースを消費しにくいことがあります。限られたアプリや特定のネットワークだけで使う場合は、明確なオンデマンド条件によってトンネルの稼働時間を短縮できます。省電力の目標はVPNを何度も再起動させることではなく、不要な処理と失敗時の再試行を減らすことです。

TUNモード自体が異常なバッテリー消費を意味するわけではない

iOSでシステム全体の通信を処理する機能は、通常、システムが提供するパケットトンネル機能に依存します。クライアント画面ではVPN、TUN、拡張モードなどと表示されることがあります。システム通信を処理するため、単一アプリにHTTPプロキシを設定するより対象範囲は広くなりますが、アイドル時に高負荷が続くはずではありません。実際に確認すべきなのは、UDPセッション数、接続ループ、DNSタイムアウト、ノードのパケットロスです。

構成でトラフィック嗅探も有効にしている場合は、ドメイン名を復元して判定する必要が本当にあるか確認してください。嗅探はルール判定を補助するために接続開始時の情報を読み取るため、通信量が多いと処理負荷が増えます。無効化する前に、構成が嗅探で取得したドメイン名に依存していないか確認してください。依存している場合、一部のルールがIP判定へフォールバックしたり、既定のポリシーに回ったりする可能性があります。

ノードとモバイル通信の電波状況も消費を増幅する

ノードのハンドシェイク失敗、パケットロス、長距離回線は、接続の再送を繰り返させます。表面上はClashのバッテリー消費に見えても、実際の原因はプロキシサーバーへ到達できないことや、現在のネットワーク品質である可能性があります。まず安定したノードを1つ選び、自動切り替えを停止します。そのうえでログにtimeout、connection reset、TLS handshake timeoutなどのエラーが繰り返し出ていないか確認してください。

具体的な数値でノードの状態を判断する

• 同じWi-Fiで5回連続してテストし、結果が80〜130ミリ秒の範囲で小さく変動するなら、1回60ミリ秒、次が900ミリ秒となる場合より通常は安定しています。
• パケットロスがある環境では、1回の遅延が短くても長時間接続に適しているとは限りません。音声通話やプッシュ通知が何度も切れる場合は、別の回線で検証してください。
• ノードが3回連続でタイムアウトしたら、いったん無効にしてください。自動プロキシグループに30秒ごとの再探測をさせないようにします。
• 電波の弱い場所でテストする場合は、5GとLTEの頻繁な切り替えが結果に影響しないよう、モバイル通信を一時的にLTEへ固定して比較します。

モバイル通信のモードは「設定」→「モバイル通信」→対象の回線番号→「音声通話とデータ」で確認できます。表示の有無や項目名は通信事業者によって異なります。LTE固定は調査時だけ行う手順です。問題がネットワーク切り替えと無関係だと確認できたら、元の自動設定に戻してください。

手順に沿って省電力の切り分けを行う

10個の項目を同時に変更すると、結果を比較できなくなります。以下では、よくある原因で元に戻しやすいものから順に確認します。各手順の後は少なくとも30分、待機中の消費電力を調べる場合は6〜8時間ほど観察してください。

1. バックグラウンド通信を確認：写真、クラウドストレージ、システムアップデートを一時停止し、実際の大容量通信を除外します。
2. 安定したノードを1つに固定：一時的に自動選択をやめ、発熱や急速なバッテリー消費が続くか確認します。
3. チェック間隔を延ばす：ヘルスチェックとURLテストを600秒に設定し、重複する速度テストグループを無効にします。
4. ログを確認：数秒おきに繰り返されるDNSタイムアウト、ハンドシェイク失敗、トンネル再構築を探します。
5. オンデマンド接続をオフにして比較：Wi-Fiとモバイル通信の切り替えが接続ループを引き起こしていないか確認します。
6. 通常のログレベルに戻す：debugからinfoまたはwarningへ戻します。
7. リモートリソースを確認：無効なルールプロバイダーを削除し、安定したリソースの更新間隔を86400秒に設定します。
8. VPN構成を再作成：前の手順で改善しない場合に限り、古いVPN構成を削除してクライアントに再作成させます。

VPN構成を削除する前に、現在のサブスクリプションURL、オーバーライドルール、プロキシグループの選択を保存してください。場所は「設定」→「一般」→「VPNとデバイス管理」→「VPN」です。対象の構成を開いて削除を実行します。クライアントを再度開き、VPN構成の追加を許可すれば復元できます。企業や仕事用アカウントで使用している他のVPNは削除しないでください。

クライアントやコアを更新すべきタイミング

異常が特定のクライアント更新後に始まった場合は、まずそのバージョンの変更履歴を確認してください。古いビルドを使っている場合も、ダウンロードページに掲載されている現在の安定版へ更新することをおすすめします。Clash Meta（mihomo）コアはプロトコル、DNS、ネットワークスタックの問題を継続的に修正していますが、構成の互換性が変わることもあります。更新前に構成をエクスポートし、更新後はまず元の構成でテストしてください。更新と大規模なルール変更を同時に行わないことが重要です。

バッテリーやシステム側の問題が疑われるケース

Clashを終了しても発熱が続く場合や、「設定」→「バッテリー」で複数のシステム項目に長時間のバックグラウンド動作が表示される場合、原因はプロキシ構成ではない可能性があります。「設定」→「バッテリー」→「バッテリーの状態と充電」で最大容量を確認してください。容量が大きく低下している、端末がシステムアップデートを終えたばかり、写真の再インデックス中である、といった状況では待機時の消費電力も変化します。端末を再起動してから同じ条件で比較するほうが、サブスクリプションを何度も削除するより効果的です。

よくある質問

iPhoneでClashのバッテリー消費を調べる際のポイントは、「ネットワーク拡張が接続を維持している状態」と「高負荷処理が続いている状態」を分けて考えることです。まず条件を固定して比較し、その後に高頻度のヘルスチェック、無効なリモートリソース、ノードの再接続、複雑なオンデマンドルールを確認します。設定は毎回1つだけ変更すると、バッテリー持続時間に本当に影響している項目を特定できます。