VPNをオンにした後に現れるバッテリー消費は、たいてい別の名前をかぶった作業負荷の変化だ。待機したままのトンネル、夜間のバックアップ、数分おきに再接続するクライアントでは、消費する電力の量が大きく違う。ステータスバーのアイコンは、そのどれを見ているのかを教えてはくれない。

トンネルと、それが運ぶものを分けて考える

写真のバックアップやビデオ通話はデータを押し出し、VPNはそれを暗号化し、認証し、転送しなければならない。その電力コストの一部は通信を生み出したアプリのもので、トンネル自身のものは一部にすぎない。バッテリーのレポートをネットワークと画面の統計と並べて読むことが、両者を切り分ける方法だ。設定を一つ変える前に、そこから始めよう。

プラットフォームのレポートも独自のやり方で作業を割り当てる。VPNというラベルが付いた項目には、どのみち使われたはずの無線時間が含まれることがあり、暗号処理の追加コストだけを単独で切り出すことはほとんどない。割合は測定値ではなく出発点として扱おう。

adb shell dumpsys batterystats --charged com.example.vpn | head -60
adb shell dumpsys netstats detail | head -40

最初のコマンドは、直近の充電サイクルについて項目ごとの電力配分を表示する。二つ目は、どのインターフェースがどれだけのデータを動かしたかを示す。割合を作業負荷の記述に変えるのは、この文脈だ。トンネルについて結論を出す前に、両方を比べよう。

転送中に端末が熱くなるなら、同一の条件でクライアントやプロトコルの設定を比べよう。電力の数値を追いかけて暗号を弱めるのは、既知のコストを未知のコストと交換することにすぎない。

再接続は無線を起こしたままにする

画面が止まって見えても、ネットワークが止まっているわけではない。メッセージ、同期、更新確認は今もパケットを送っており、小さなやり取りのたびに、パケット自体の長さよりはるかに長く無線を起こすことがある。パケットの持続時間と無線がオンの時間との差に、待機中の消費は隠れている。待機中のトンネルが待機中の端末より高くつくことがある理由も、ここにある。

キープアライブには理由がある。NATの対応付けを開いたままにするか、消えた相手を検出するためだ。その間隔はプロトコルと使用中のネットワークによって決まる。無効にすると活動は減るかもしれないが、待機が続いた後にトンネルは使えなくなる。

grep -i keepalive /etc/wireguard/wg0.conf
wg show wg0 latest-handshakes

最初のものは、常時キープアライブが設定されているか、どの間隔かを示す。二つ目は最後のハンドシェイクがいつ起きたかを示し、静かなトンネルと絶えず作り直しているトンネルを区別できる。

接続の履歴が最も重要になるのは、ネットワークを移った後に消費が始まる場合だ。繰り返される復旧を直すことは、出口の場所を切り替えるよりたいてい価値がある。絶えず再接続するクライアントは、転送ではなく復旧に電力を費やしているからだ。

プラットフォームがトンネルを停止するとき

オペレーティングシステムはバックグラウンド実行を制限する。画面が消えるとトンネルが消えるのは、サーバーの故障ではなく、その方針の犠牲になっているのかもしれない。利用者から見ればどちらも同じに見えるからこそ、プラットフォームのログが重要になる。

すべてのアプリを電力管理から除外すると作業負荷が変わり、その後の比較は意味を失う。VPNクライアントと、それを必要とする一つのアプリだけを除外し、同じ基準でもう一度測ろう。

スリープ後にどうするかは別に決めよう。常時接続、VPNなしでのブロック、通常のバッテリー最適化はそれぞれ別の問いに答えるものであり、必要な保護範囲を黙って落として電力を節約する設定は、元の要件を満たしていない。

同じ条件どうしを比べてから決める

両方の計測で同じ作業、同じネットワーク、同じ時間を使い、転送量、再接続の回数、温度、電波強度を記録しよう。バッテリー残量の短期的な変化はばらつくので、同程度の使い方で繰り返し現れるパターンだけが、行動に移す価値のある証拠だ。一度きりの計測は逸話にすぎない。

予定が許すなら、任意の大きな転送は充電器と上限のないネットワークに移そう。そのうえで一日全体をもう一度見よう。何時間も待機するトンネルは、二十分だけ忙しいトンネルよりはるかに安くつく。

何を変えたのか、二回目の計測で何が分かったのかを書き留めよう。その記録がなければ、次の比較は別の基準から始まり、同じ議論がゼロからやり直しになる。

関連記事