TUNモードを使わない方がよいケース
TUNモードは唯一の選択肢ではありません。端末の発熱や消費が日常利用に明らかに影響している場合は、システムプロキシモード(プロキシが必要なアプリやブラウザ側で個別にプロキシアドレスを設定する方式)への切り替えを検討し、カバー範囲の一部を犠牲にしてシステムレイヤーのオーバーヘッドを下げるという判断もできます。システムプロキシモードでは、プロキシを明示的に設定したアプリのみが転送対象となり、それ以外のアプリは一切影響を受けないため、マッチングと転送の総量がかなり小さくなります。
このトレードオフは、ブラウザや少数のアプリでのみプロキシが必要な場合、端末の性能が低めで発熱に敏感な場合、あるいは一時的な利用でグローバルなカバー範囲を求めていない場合に適しています。逆に、端末上のすべてのアプリをカバーする必要がある場合(例えば、一部のアプリにハードコードされたドメイン検出があり、グローバルプロキシを回避すると機能に異常が出るケースなど)は、TUNモードの方が依然として確実な選択です。この場合、消費増加は受け入れるべきコストであり、力を入れるべきは前述のルール簡略化とホワイトリスト設定であって、TUNを使うかどうかで悩むことではありません。
一通りの調査フローの提案
- システムのバッテリー使用状況を開き、消費割合が本当に異常かどうかを確認する(本稿冒頭の判断基準を参照)。
- TUNモードがオンになっているか確認し、1日試験的にシステムプロキシモードに切り替えて消費量の差を観察する。
- 現在読み込まれているルールセットの数と更新間隔を点検し、長期間使わないカテゴリを削除し、更新周期を延ばす。
- 策略グループ内の自動速度測定の探査頻度を確認し、不要な定期探査タスクを減らす。
- メーカーの省電力ポリシー設定が適切かどうかを確認する:長時間の常時起動が必要ならホワイトリストに追加し、時々の利用ならシステム標準の制限を維持する。
- 調整後1〜2日のバッテリー曲線を観察し、消費が適正な範囲まで下がったかを確認してから、さらに調整するかどうかを判断する。
この順序で一つずつ調査すれば、消費異常の原因をおおむね特定の箇所に絞り込むことができ、「プロキシソフトが電力を消費する」と大まかに結論付けずに済みます。多くの場合、消費問題の根本原因はルールセットの肥大化やバックグラウンドのウェイクアップ過多であり、この2点を調整する方がTUNモードを使うかどうかで悩むよりも効果的です。