VPN 应用启动之前，kill switch 会拦截流量吗？

Kill switch 是否覆盖其应用启动前的那段时间，取决于操作系统的策略，而不是客户端的营销页面。自动启动复选框只证明有东西被安排启动，并不证明网络起来的那一刻拦截规则已经存在。这是两件事，而只有一件事真正保护了流量。

请按顺序走完清单，因为每一步都在收窄你实际测试的内容。

拦截究竟来自哪里

实现分为两大类：要么由平台安装拦截，因为它在任何应用运行之前就知道隧道；要么 由客户端在启动之后自行安装拦截。前一类的拦截可以早于登录存在；后一类不可能早于它自身的进程存在，无论该进程被安排得多早。测试之前，先弄清你依赖的是哪一类。

在 Android 上，「始终开启的 VPN」配合「无 VPN 时阻止连接」设置属于平台策略，要在系统设置里配置，而不是只存在于客户端内部。受管理的设备可能已经替你设好。仅仅在开机时启动的客户端，并不是同一个机制。

把这段时间与服务分开

这段时间关闭，并不证明强制执行已经停止；这段时间开启，也不证明隧道已经就绪。许多客户端把界面、守护进程和托盘程序拆开。托盘是你看到的部分，守护进程才持有规则。

要测组件，而不是图标。

安全地测试启动这段时间

要测的区间从重启或登录开始，到隧道完成认证为止。后台应用会在这段时间联网，更新检查是常见的肇事者。请使用无害活动，并遵循供应商记录的流程，而不是先把自己的访问切断。随后再在一次正常重连之后重复一遍，因为重连路径和冷启动路径执行的是不同的代码。

在隧道已经建好之后做测试，对启动阶段什么也证明不了。

如果要求的是持久性，就去读重启时的行为。某项设置可以留在配置里，而它的强制执行要到更晚才开始；两件事都重要：保存下来的策略，以及它生效的那一刻。

逐个平台读策略

Android 把「始终开启」和「拦截」作为两个独立开关公开，两者都打开才有启动前的保护。Windows 有一个通过策略配置的「始终开启的设备隧道」概念，这与一个提前启动的用户态客户端并不是一回事。OpenVPN Connect 会按平台记录它自己的 kill switch 行为，你测的就是它记录在案的范围。不要把某个系统的设置名称搬到另一个系统上，还假定语义也一起搬了过去。

需要交互式密码的配置文件，其启动依赖与机器隧道不同。

记录什么

写下当前生效的是哪种机制、它在哪个阶段生效，以及在该阶段之前尝试过哪些流量。记录平台版本，因为这一行为会随版本变化，也会在受管理与个人配置之间不同。注明策略归客户端还是归系统所有，因为这决定了谁能修补缺口。之后在任何客户端或系统更新后重新测试。

如果这个缺口要紧，长久的解法是平台策略，而不是把启动延迟调短。

这就是对最初那个问题的回答，以条件的形式说出：只有当安装拦截的东西先于应用存在时，kill switch 才能在应用启动之前保护流量。