画面オフでVPNが切れる：どのライフサイクル？

画面が暗くなった瞬間に転送は止まり、数秒後にバッジが続く。この光景を作る原因は三つある：クライアントプロセスが制限される、経路がアイドルになってマッピングを失う、アプリがトンネルの気づかないうちにセッションを失う。それぞれ証拠が異なり、対処も別の層に属する。以下の順序は、設定を総当たりする代わりに一つの統制されたテストで切り分ける。

同じに見える三つの障害

制限されたバックグラウンドプロセスはキープアライブの送信をやめ、相手側はやがてトンネルを死んだと宣言する。経路上のアイドルなマッピングはデバイスが眠っている間に失効し、まだ完全に生きているクライアントに戻りトラフィックが届かなくなる。アプリはトンネルが上がったまま自分の接続を失い、背後に健全なVPNバッジがあるエラーダイアログが出る。ユーザーの目には、三つとも画面オフでVPNが切れたように映る。

区別が重要になるのは、実際には対処法が互いに矛盾するからだ。クライアントを電力制限から除外すれば第一のケースは直るが、失効したマッピングには何の効果もない。キープアライブを延ばせば第二は直るが、第三では、そもそもネットワーク側に問題がなかったのにバッテリーを浪費する。

統制下でアクティブとアイドルを比較する

すべてを一定に保つ：同じデバイス、同じネットワーク、同じエンドポイント、同じアプリ。画面を短い固定時間ロックし、三つの観察を記録する：クライアントが切断を報告するか、ロック解除時に新しい要求が通るか、既存の転送が再開したか。次にキープアライブか定期要求を動かした状態で繰り返し、二回の実行を比較する。二回の実行間で変えた一つの変数は、一週間の体験談より価値がある。

タイミングは記録に含める。九十秒後の切断はマッピングかキープアライブ間隔を思わせ、ロックした瞬間の切断はプロセス停止を示す。トリガーと間隔の両方を書き留めるのは、次の試行に比較対象が必要だからだ。

プラットフォームのバックグラウンドポリシーを読む

AndroidではVPNサービスのライフサイクルがプラットフォームの一部であり、always-onとblock-without-VPNは別々のスイッチで効果も別だ。always-onでないクライアントは、システムがリソースを回収すると停止されうるし、アプリ内の設定では変わらない。iOSはトンネルプロバイダーに独自のバックグラウンド制限を課し、文書化された挙動は動き続けるデスクトップのデーモンとは異なる。一般的なバッテリー最適化ガイドではなく、該当コンポーネントのプラットフォーム文書を読むこと。

管理されたデバイスはさらに層を増やす。ポリシーが個人設定を上書きすることがあり、機能しているように見えた変更が次のポリシー更新で戻る。要件が本当なら組織の承認済み例外手続きを使い、なぜ例外が必要かを書き留める。

ウェイク後にデバイスがすること

自動再接続は、空白時間中の通信を遮断することと同じではない。両方を確認する：トンネルが戻るか、空白時間中に送信しようとしたアプリが無防備のまま外に出たか。二秒で再接続しても最初の一秒でDNSクエリを漏らすクライアントは、業務デバイスとして誤った障害ポリシーだ。無害な要求と自分で管理する宛先で試す。

アプリの復旧が第三の問いだ。トンネルが戻ってもタイムアウトしたSSHセッションは直らず、ユーザーはそのセッション喪失をVPN障害として報告しがちだ。トリガー、クライアントのビルド、正確な時刻を報告書にまとめておくのは、その組み合わせが、予測可能な画面オフのライフサイクルと、デバイスと無関係に失敗するサーバーを分けるからだ。