为什么 VPN 断开几秒钟也可能产生隐私问题？
VPN 正常工作时，设备会通过 VPN 建立的加密隧道访问互联网，对外网站通常看到的是 VPN 节点的公网 IP，而不是用户原始网络的公网 IP。
问题在于 VPN 连接并不可能永远保持在线。
Wi-Fi 与移动网络切换、路由器重新拨号、电脑休眠后恢复、VPN 节点维护、网络瞬时抖动以及客户端异常，都可能导致 VPN 隧道暂时中断。有些中断只有几秒钟，用户甚至不会察觉，但操作系统通常不会因为 VPN 断开而自动停止联网。
如果没有额外保护，系统可能立即恢复原来的网络路径，浏览器、下载工具、即时通信软件以及其他后台程序也会继续发送数据。
此时网站看到的公网 IP可能从 VPN 节点重新变成用户真实网络的公网 IP，DNS 请求也可能重新交给本地运营商或当前网络处理。
Kill Switch 就是针对这个问题设计的。
Kill Switch 是什么？
Kill Switch 通常翻译为“网络终止开关”或“断网保护”。
它的核心逻辑并不复杂：当 VPN 隧道无法提供预期保护时，阻止受保护的网络流量通过普通网络继续访问互联网。
例如用户正在通过 VPN 浏览网页，此时 VPN 节点突然失去连接。如果没有 Kill Switch，操作系统可能直接恢复普通网络连接，网页仍然可以继续加载，但网站看到的公网 IP 已经发生变化。
开启 Kill Switch 后，VPN 客户端可以在检测到隧道失效时限制相关网络流量，等待 VPN 恢复以后再重新允许联网。
因此 Kill Switch 真正保护的是 VPN 连接发生变化的短暂窗口。
对于普通用户来说，这个窗口可能只有几秒钟；对于持续运行的下载程序、即时通信软件、同步程序和后台服务来说，几秒钟已经足以建立新的网络连接并发送数据。
App Guard 又是什么？
App Guard 并不是一个像 TCP、WireGuard 或 IPsec 那样具有统一技术标准的名称，不同 VPN 厂商可能使用 App Guard、App Kill Switch、Application Kill Switch、Per-App Kill Switch 等不同名称。
它们通常描述的是一种“应用级断网保护”。
与面向整个系统的 Kill Switch 相比，App Guard 会让用户指定需要保护的应用，然后只对这些程序实施 VPN 连接状态限制。
例如用户指定浏览器和下载工具受到 App Guard 保护。当 VPN 正常连接时，这些程序可以正常访问互联网；如果 VPN 隧道中断，受保护应用的网络连接会被限制，而其他没有加入 App Guard 的程序仍然可以继续使用普通网络。
因此，两者最核心的差异其实在于保护范围。
Kill Switch 更接近系统级网络保护，而 App Guard 更强调针对特定应用进行控制。
Kill Switch 与 App Guard 的主要区别
| 对比项目 | Kill Switch | App Guard |
|---|---|---|
| 主要保护范围 | 整个设备或 VPN 所覆盖的系统流量 | 用户指定的应用 |
| VPN 断开后的行为 | 通常限制整个受保护网络的互联网访问 | 只限制指定 App |
| 其他应用能否继续联网 | 通常不能或受到较大限制 | 通常可以 |
| 保护强度 | 范围更广 | 范围更精细 |
| 使用灵活性 | 相对简单 | 更灵活 |
| 适合场景 | 公共 Wi-Fi、长期 VPN、隐私敏感环境 | 浏览器、下载工具、特定业务软件 |
| 对日常网络影响 | VPN 故障时可能导致整机断网 | 对其他程序影响较小 |
| 配置复杂度 | 通常开启即可 | 需要选择需要保护的应用 |
如果用户最关心的是“只要 VPN 断开，我就不希望设备继续通过原始网络访问互联网”，Kill Switch 更符合这个需求。
如果用户只要求几个特定程序必须经过 VPN，同时希望其他程序始终保持正常联网，App Guard 会更加灵活。
Kill Switch 为什么通常保护得更彻底？
系统级 Kill Switch 的优势来自它更大的控制范围。
现代操作系统中同时存在大量网络活动。除了浏览器，还有系统更新、云同步、邮件客户端、即时通信、后台服务和其他用户看不到的进程。
如果只保护一个浏览器，那么浏览器之外的程序仍然可能通过普通网络访问互联网。
系统级 Kill Switch 可以减少这种遗漏。
因此，当 VPN 被用于公共 Wi-Fi、防止原始 IP 意外暴露或者要求设备网络始终经过 VPN 的场景时，系统级 Kill Switch 通常具有更完整的保护范围。
但它也存在相应代价。
一旦 VPN 节点暂时不可用，整个设备可能表现为“没有网络”。
用户需要等待 VPN 自动重连、手动更换节点或者主动关闭保护后才能恢复普通网络。
这种行为有时会让用户误以为 VPN 导致了网络故障，实际上恰恰可能是 Kill Switch 正在按照设计工作。
App Guard 为什么更加灵活？
并不是所有用户都希望 VPN 断开以后整台电脑立即失去网络。
假设用户只有浏览器需要通过 VPN，而游戏、局域网设备管理、公司内部工具或者其他程序可以继续使用普通网络，那么系统级 Kill Switch 就可能带来不必要的影响。
App Guard 可以缩小保护范围。
用户只需要把真正要求 VPN 连接的程序加入保护列表。当 VPN 中断以后，这些程序无法继续通过原始网络通信，而没有受到保护的应用仍然可以按照原来的网络路径运行。
这使 App Guard 特别适合需要同时使用 VPN 网络和普通网络的桌面环境。
但灵活性也意味着用户需要自己正确配置保护范围。
如果某个程序没有加入 App Guard，那么它通常不会自动获得相同保护；如果应用还会调用其他独立进程或后台服务进行通信，也需要考虑这些进程是否处于保护范围内。
App Guard 与分流功能有什么关系？
App Guard 很容易和 Split Tunneling，也就是 VPN 分流功能混淆，因为两者都可能以“选择应用”的方式进行设置。
实际上，它们处理的是两个不同阶段的问题。
Split Tunneling 决定的是VPN 正常运行时，哪些流量经过 VPN；App Guard 处理的是VPN 无法提供预期连接时，指定应用是否还能继续联网。
例如用户通过分流规则让浏览器经过 VPN，而游戏直接连接互联网。在 VPN 正常工作时，浏览器使用 VPN 网络，游戏使用普通网络。
如果 VPN 突然断开，App Guard 可以进一步限制浏览器通过原始网络继续访问互联网，而游戏仍然保持自己的普通连接。
因此，分流负责“怎么走”，App Guard 更关注“VPN 失效以后还能不能走”。
在同时需要跨境访问、本地服务和低延迟应用的环境中，两种机制配合使用可以实现更加精细的网络控制。
Kill Switch 通常是怎样实现的？
Kill Switch 看起来只是一个开关，但真正可靠的实现通常需要深入操作系统的网络层。
VPN 客户端可以通过系统防火墙、网络过滤框架、路由策略或者操作系统提供的 VPN 接口限制流量。
关键并不是简单检测到 VPN 断开以后再执行一个“关闭网络”的动作，而是尽量避免出现保护规则尚未生效、普通网络已经恢复的时间窗口。
这也是为什么不同 VPN 客户端虽然都提供一个叫 Kill Switch 的按钮，实际实现效果仍然可能存在差异。
一个完善的 Kill Switch 还需要处理休眠唤醒、Wi-Fi 切换、移动热点切换、VPN 客户端崩溃、节点重连以及操作系统网络接口变化等情况。
因此，Kill Switch 本质上属于 VPN 客户端网络控制能力的一部分，而不是单纯的界面功能。
Kill Switch 能防止哪些泄露？
Kill Switch 最主要的作用是降低 VPN 意外中断以后原始网络信息暴露的风险，其中最直观的是公网 IP。
如果应用在 VPN 中断后立即通过普通网络重新建立连接，远程服务器可能看到用户原始公网 IP。
DNS 同样需要关注。
VPN 正常连接时，客户端可能使用指定 DNS；隧道失效后，如果系统恢复本地 DNS，新的域名查询可能重新通过当前运营商或局域网发送。
因此，Kill Switch 与 DNS 防泄露经常同时出现在 VPN 客户端中。
但 Kill Switch 并不能解决所有隐私问题。
已经登录的网站账号、浏览器 Cookie、设备指纹、GPS 定位、应用权限和用户主动提交的信息，都不会因为开启 Kill Switch 自动消失。
它解决的是 VPN 网络路径失效时的流量保护，而不是让设备获得完全匿名的身份。
哪些场景更适合使用 Kill Switch？
如果经常在机场、酒店、咖啡店等公共 Wi-Fi 环境中使用 VPN，希望整个设备在 VPN 异常时停止外网通信，系统级 Kill Switch 是比较合适的选择。
需要长期保持固定 VPN 网络出口的用户同样适合开启。
例如某些工作环境要求设备始终通过特定网络出口访问远程系统，如果 VPN 断开以后设备直接恢复普通网络，可能造成网络环境突然变化。Kill Switch 可以在 VPN 恢复以前阻止这种自动切换。
对于普通用户，如果 VPN 只是偶尔用于访问某个网站，而设备上的其他程序仍然需要持续联网，则可以根据实际需求选择更加灵活的应用级保护。
哪些场景更适合 App Guard？
App Guard 更适合对网络路径有明确要求的特定应用。
例如浏览器必须使用 VPN，但在线游戏希望保持本地直连；某个下载程序需要通过 VPN，而视频会议软件需要使用原始网络获得更低延迟；或者只有某个业务应用要求始终通过指定 VPN 环境运行。
此时没有必要因为 VPN 节点发生短暂故障，让整台设备上的所有程序同时失去网络。
应用级保护可以把影响限制在真正需要 VPN 的程序上。
这种模式尤其适合桌面系统，因为 Windows、macOS 等平台通常会同时运行大量不同用途的软件，用户对网络路径的控制需求也更加复杂。
Kill Switch 与 App Guard 应该选哪个？
对于大多数用户来说，如果最重要的目标是避免 VPN 意外断开后原始 IP 和网络流量直接暴露，优先开启系统级 Kill Switch 会比较简单。
如果日常工作同时依赖 VPN 网络和本地网络，而且只有几个程序必须保持 VPN 连接，则应用级保护更容易兼顾安全性和可用性。
两者并不一定需要互相替代。
部分 VPN 产品可以把系统级网络控制、应用分流和应用级保护组合起来，让用户根据场景决定保护范围。
真正需要考虑的不是哪个功能名称听起来更加高级，而是 VPN 失效以后，哪些程序允许继续联网，哪些程序必须立即停止通信。
把这个问题确定下来以后，Kill Switch 与 App Guard 的选择通常就会非常明确。
365VPN 为什么提供 Kill Switch？
365VPN 提供 Kill Switch 的核心目的，是减少 VPN 连接异常时出现意外网络暴露的窗口。
日常网络环境并不稳定，用户从 Wi-Fi 切换到其他网络、电脑从休眠状态恢复、路由器重新连接或者 VPN 节点发生短暂异常，都可能造成隧道重新建立。
如果设备在这个过程中自动恢复普通互联网连接，用户可能完全没有察觉网络出口已经发生变化。
开启 365VPN Kill Switch 后，当 VPN 无法维持预期保护时，可以限制受保护流量直接通过原始网络发送，并在 VPN 重新建立连接后恢复正常通信。
配合 DNS 防泄露、智能分流以及稳定节点使用，可以进一步减少网络切换过程中不必要的信息暴露。
对于需要稳定网络出口的用户，365VPN 还支持独立 IP 以及导入用户自己购买的 IP 或代理，从而根据不同场景构建更加可控的网络环境。
Kill Switch 开着以后突然“没网”，先别急着关闭
这是实际使用 VPN 时非常常见的情况。
如果 VPN 节点发生异常，同时 Kill Switch 正在工作，设备可能表现为网页打不开、应用无法联网，但 Wi-Fi 图标仍然显示已经连接。
这种情况下可以先检查 VPN 客户端连接状态。
如果 VPN 已经断开，可以尝试重新连接或者切换其他节点。连接恢复以后，受保护的网络流量通常也会恢复。
如果直接关闭 Kill Switch，普通网络可能立即重新可用，但原始公网 IP 和网络路径也会随之恢复。
因此，对于确实需要持续 VPN 保护的用户，更合理的处理顺序通常是先恢复 VPN，而不是把 Kill Switch 长期关闭。
写在最后
Kill Switch 与 App Guard 都围绕一个非常实际的问题设计：VPN 并不会永远保持连接，因此客户端必须决定隧道失效以后怎样处理正在运行的网络流量。
Kill Switch 通常从整个设备或 VPN 所覆盖的网络范围进行保护，当 VPN 连接异常时限制流量直接回到普通网络；App Guard 则进一步把这种控制细化到应用级，只阻止指定程序在 VPN 不可用时继续联网。
系统级 Kill Switch 的保护范围更完整，App Guard 的网络控制更加精细，而 Split Tunneling 则负责决定 VPN 正常工作时不同应用应该选择哪条网络路径。
对于大多数重视网络隐私的用户，Kill Switch 是一项值得长期开启的基础功能；如果同时存在本地直连和 VPN 应用，可以再通过分流和应用级保护进行更加细致的配置。
VPN 的安全性不仅取决于连接成功以后使用了什么加密协议，也取决于连接失败的那一刻，客户端如何处理原本受到保护的网络流量。Kill Switch 的价值，恰恰体现在这个最容易被忽略的短暂窗口。