定義と狙い
Kill Switch 2は、VPNなどの安全な通信経路が意図どおりに成立していないときに、通常の通信を抑止することで“通信の取りこぼし”を減らすための考え方・機能として捉えると分かりやすいです。狙いは、接続断・再接続中・アプリ切替などのタイミングで、意図しない経路（端末の通常回線など）に通信が逃げることを抑える点にあります。
ただし、こうした機能は「すべての状況で100%防げる」という形で保証されるとは限りません。最適化とは、保護対象を明確にし、例外や前提を理解したうえで、実際に自分の環境で期待した挙動になっているかを確かめること、と考えてください。
仕組み（簡単なモデル）
仕組みを抽象化すると、次の流れで働くとイメージできます。
- VPN経路が“有効”かどうかを監視する
- 有効でない状態になったら、通信を制御して意図しない経路への接続を抑える
- 状態が“復帰”したら、必要な通信を再開する
ポイントは、監視と制御のタイミングです。接続断が起きた瞬間、再接続に入るまでの短い時間帯、あるいは特定の通信だけが別ルートで動くケースでは、抑止が完全に追いつかない可能性があります。そのため、最適化は「どの状態をどう判断して、何を抑止するのか」を押さえる作業になります。
また、“抑止する通信”の範囲も重要です。ウェブ閲覧だけではなく、DNS（名前解決）や、バックグラウンド通信、アプリ固有の通信、ローカルネットワーク宛の通信などが含まれるかで、体感や結果が変わります。ここが設計思想の違いとして現れやすい領域です。
できること／難しいこと（制限と例外）
Kill Switch 2で最適化を考えるとき、必ず意識したい制限があります。
- 保護対象が万能ではない：抑止の範囲は機能ごとに異なり得ます。想定していた通信が抑止されない例外があるかもしれません。
- タイミングのギャップ：接続断から検知・制御が始まるまでの短時間で、何らかの通信が成立してしまう可能性があります。
- 再接続やアプリ挙動の違い：アプリが再試行する、バックグラウンドで通信する、通信の種類が複数あるなど、挙動によって結果が変わります。
- ローカルや内部通信：インターネット宛て以外（ローカル宛）をどう扱うかで、期待とズレることがあります。
ここで重要なのは、機能の有無だけで結論を出さず、「自分の使い方で、どの通信がどう扱われるか」を確かめることです。最適化は、設定項目を“入れる/切る”ではなく、“前提と到達範囲”を理解することに寄っていきます。
実践的な確認方法（自分の環境で点検）
最適化のための確認は、「再現性」と「観察対象の明確化」を重視すると失敗しにくいです。以下は一般的な観察手順の例です（詳細な操作名や項目は、利用している環境やクライアントにより異なります）。
1) 接続断の“前後”を観察する
VPNの状態が切り替わる瞬間に注目します。