📉
咖啡厅 Wi-Fi 的常见故障
公共网络的 DHCP 续租失败、AP 重启、信号抖动都会造成隧道中断。若客户端回落明文，你以为在"断网"，实际却在继续以真实 IP 明文访问网页。
Kill Switch
终止开关：断线即断网，绝不回落到明文链路
多数客户端在隧道异常时会自动把流量改回系统默认网络——此时未加密的数据会直接从本地网卡发出。快连的终止开关改变这一行为：它接管系统路由与 DNS，在异常状态下保持"通路关闭"，直到加密隧道真正恢复。
Why It Matters
断线泄露：最容易被忽视的泄露窗口
用户通常只在"连接中"关注加密，却忽略了最危险的几秒钟——隧道失效到客户端察觉之间的时间差。
🔄
网络切换的静默窗口
从 Wi-Fi 切到蜂窝、从公司内网切到家庭网络时，旧隧道失效而客户端尚未察觉，操作系统可能直接把流量送到新网络。
🛡️
终止开关的定位
它不负责防止断线，只负责在断线期间不给出路。用户得到的是明确的"连不上"，而不是被静默改道的假象。
重要区别：终止开关与"自动重连"不是二选一。前者负责断线期间保持封锁，后者负责恢复后尽快建链。两者同时开启才是完整方案。
Triggers
五种触发条件
终止开关的状态机监听以下事件。任一事件发生即进入封锁状态，无需用户干预。
| 触发条件 | 判定依据 | 客户端响应 | 是否可恢复 |
|---|---|---|---|
| 用户主动断开或退出 | 本地控制指令 | 立即撤销路由与 DNS 权限 | 需手动连接 |
| 握手失败 | 握手超时或认证失败 | 保持封锁，按退避策略重试 | 自动 |
| 会话密钥失效 | 密钥过期或被服务端撤销 | 阻断并提示需重新连接 | 自动重建 |
| 网络切换 | 网卡状态变化、路由表变更 | 新网络下维持封锁直至隧道重建 | 自动 |
| 心跳超时 | 连续 N 次心跳未响应 | 判定链路失联并阻断 | 自动 |
| 休眠唤醒后未重建 | 唤醒后握手未完成 | 维持封锁，提示隧道不可用 | 自动 |
Cut Latency
切断时延：越短，泄露窗口越小
断线发生后，从"事件产生"到"路由彻底关闭"之间的时间，就是泄露窗口。快连把这一过程压缩到毫秒级。
| 阶段 | 处理动作 | 耗时 | 累计 |
|---|---|---|---|
| 事件捕获 | 状态机收到断线事件 | < 0.5 ms | 0.5 ms |
| 队列清理 | 清空待发送队列、释放缓冲明文 | 约 1 ms | 1.5 ms |
| 路由撤销 | 从系统路由表移除默认路由 | 约 2 ms | 3.5 ms |
| DNS 回收 | 撤销 DNS 解析权限、清除缓存 | 约 2 ms | 5.5 ms |
| 连接中断 | 向已建立连接发送 RST | 约 1.5 ms | 约 7 ms |
| 状态更新 | 刷新界面提示"已阻断流量" | 约 1 ms | 约 8 ms |
网络环境对时延的影响
| 网络环境 | 切断时延均值 | 说明 |
|---|---|---|
| 局域网 / 有线 | 约 8 ms | 路由操作本机完成，耗时最低 |
| Wi-Fi 5 / 6 | 约 9 ms | 网卡驱动注销连接带来少量增量 |
| 蜂窝网络 | 约 14 ms | 调制解调器状态切换需要额外时间 |
| 低功耗设备 | 约 22 ms | 算力受限导致路由批处理耗时增加 |
口径说明：上表为局域网与典型设备下的实测均值参考。真实时延取决于设备型号、系统版本与驱动实现；即使在低功耗设备上，也远小于人工察觉断线所需的时间（通常数秒以上）。
Protection Path
断线泄露防护：四步闭环路径
从断网瞬间到恢复放行，客户端按固定顺序处理。任何一步失败都不会退化为明文直连。
01
断网瞬间 · 触发拦截
心跳超时、握手失败、用户断开或网络切换事件写入终止开关状态机。客户端立即进入"封锁"模式：撤销默认路由、回收 DNS 解析权限、向已建立连接发送 RST，并锁定出口网卡状态。此阶段不等待重连结果。
02
回退判定 · 决定是否放行
客户端判定"是否存在可用的加密通路"：隧道会话是否有效、密钥是否过期、网络路径是否与配置匹配、落地节点是否可达。任一条件不满足即维持封锁状态，并按指数退避策略重试握手。此阶段明确禁止明文回退——这是与多数客户端的核心差异。
03
阻断 · 数据就地丢弃
待发送队列被清空，缓冲明文随会话销毁，TLS 会话票据与域名缓存同步清除。应用层收到明确的连接失败错误，由用户或应用自身决定重试时机——而不是被静默改道到明文链路。此阶段同时在界面上标注"已阻断流量"。
04
恢复放行 · 隧道重建后开闸
新会话完成双重加密握手且混淆模式就绪后，路由表与 DNS 权限一次性恢复，客户端在状态栏提示"已恢复加密连接"。全过程不存在明文过渡窗口，也不存在"先放行再加密"的中间状态。
Zero Residue
未加密数据零残留判定
"零残留"需要可验证的口径，而不是一句宣传语。下表列出断线瞬间需要清理的每一类数据及其判定方法。
| 数据类型 | 存放位置 | 终止开关处理 | 判定方法 |
|---|---|---|---|
| 待发送队列 | 客户端发送缓冲区 | 断线瞬间清空，不做明文重放 | 抓包应观察不到任何明文 TCP 数据 |
| 写缓冲 | 设备内存 | 随会话销毁释放，不做落盘 | 内存转储中不应出现明文残留 |
| DNS 缓存 | 系统与客户端解析缓存 | 同步清除，防止解析请求泄漏 | 断线后不应有 DNS 查询到达本地网关 |
| TLS 会话票据 | 客户端存储 | 删除，禁止下次会话复用 | 重连后不复用旧票据 |
| 域名访问记录 | 客户端缓存 | 清除，不保留访问痕迹 | 客户端本地不应存在访问历史文件 |
| 路由表条目 | 系统路由表 | 撤销默认路由，保持关闭态 | 断线期间所有出站请求均失败 |
判定口径：以"断线发生后，本机网卡发出明文字节数为 0"作为最终判定标准。任何形如"仅泄露域名""仅泄露 IP"的表述，都不满足零残留口径。
不同场景下的表现对比
| 场景 | 未开启终止开关 | 已开启终止开关 | 明文出网 |
|---|---|---|---|
| 手动断开 | 立即回落系统默认网络 | 路由保持关闭，需手动放行 | 0 字节 |
| Wi-Fi 切换蜂窝 | 数秒内走新网络明文直连 | 新网络下路由仍为关闭态 | 0 字节 |
| 握手超时 | 重试期间回落明文 | 仅在隧道建立后放行 | 0 字节 |
| 服务器维护重启 | 持续明文直连直到用户察觉 | 阻断并提示隧道不可用 | 0 字节 |
| 休眠唤醒 | 唤醒后短暂明文直连 | 隧道重建成功前不通路 | 0 字节 |
| 用户主动临时放行 | — | 明确提示已切换为无保护状态 | 风险由用户承担 |
Platform
各平台实现与权限差异
终止开关需要操作系统层面的流量接管权限，因此在四个平台上的实现机制并不相同。
🪟
Windows
- 通过 WFP（Windows Filtering Platform）过滤器接管出站流量。
- 支持按进程精细控制，可为指定应用单独设定策略。
- 需要管理员权限或以服务方式常驻运行。
- 首次开启需允许驱动加载，UAC 弹窗需手动确认。
- 系统休眠唤醒后由服务重新接管，阻断状态得以延续。
🍎
macOS
- 基于 Network Extension 实现隧道，通过 utun 接口切换通路。
- 需在「系统设置 → 网络」中允许网络扩展组件。
- 切换 VPN 配置时系统会短暂重建通道，期间保持阻断。
- 系统睡眠唤醒后扩展重新激活，路由恢复前不放开。
- 部分企业策略可能限制第三方 VPN 扩展安装。
🤖
Android
- 基于 VpnService 通道，终止开关与隧道共用同一接口。
- 权限模型最完整：断开连接时通道本身即被撤销。
- 系统不允许其他应用使用同一 VPN 通道，天然避免冲突。
- Android 9 及以上在后台与省电限制下表现更稳定。
- 部分厂商系统需额外允许后台运行与自启动。
📱
iOS
- 受系统 NEVPNProvider 机制约束，无法像桌面端那样完全静默接管。
- 切断时以通道断开 + 系统提示的方式告知用户。
- 首次使用需在系统设置中允许添加 VPN 配置。
- 低电量模式可能限制后台心跳，需在系统中放行。
- 切回主界面时系统可能回收通道，客户端会提示重连。
Enable & Test
开启与断线自测
开启终止开关后务必做一次自测。能看到提示不等于真的阻断——需要用可验证的方式确认。
授予权限
首次开启时系统会请求流量接管权限。Windows 需允许驱动加载，macOS 需在系统设置中允许网络扩展，Android 自动授予，iOS 需在系统设置中确认添加 VPN 配置。
在客户端中开启
进入「设置 → 安全」，将终止开关设置为"断开时阻断全部流量"。注意选择的是"阻断"模式而非"仅阻断隧道内流量"。
连接并确认状态
建立连接后，客户端状态栏应显示终止开关已激活。连接详情中可见当前策略。
强制断网测试
保持连接状态下关闭 Wi-Fi，或临时断开网络 30 秒。客户端应立即提示"已阻断流量"。
验证阻断生效
断网期间用浏览器访问任意页面——应当完全打不开。如果还能打开，说明终止开关未真正生效，需检查权限是否授予。
确认恢复放行
恢复网络后，客户端应自动重建隧道并提示"已恢复加密连接"，随后网页才能正常访问。恢复过程中不应出现任何一次明文成功访问。
自测失败怎么办：若断网后网页仍可访问，依次检查：① 系统权限是否真正授予；② 客户端是否为最新版本；③ 是否有其他 VPN 或代理软件同时运行（多客户端互相改写路由会导致策略失效）；④ 是否被第三方安全软件拦截了网络过滤驱动。
Trade-offs
局限与取舍
终止开关是一把双刃剑：它把"意外泄露"换成了"意外断网"。了解代价才能正确使用。
使用代价
- 可用性下降：隧道故障期间完全无法联网，这是设计目标而非缺陷。
- 重连耗时增加：示例值下重连约需 1.1–1.5 秒，期间应用需处理连接失败。
- 长时间断网无法工作：需要维持在线的系统（远程会议、监控回传）应提前规划。
- 多客户端冲突：同时运行多个 VPN/代理软件会互相改写路由，导致策略失效。
- iOS 提示较显眼：系统会弹出通道断开提示，无法完全静默。
典型适用场景
- 公共 Wi-Fi 下的日常上网与办公接入。
- 处理敏感业务：网银、邮箱、后台管理系统。
- 跨境办公，需避免 IP 暴露给服务商的场景。
- 笔记本经常在多个网络间切换的环境。
- 不希望应用在断线时被静默改道的场景。
不建议开启：需要 7×24 持续在线的服务器环境、移动热点作为唯一网络的场景。这类场景更适合保留"自动回落"策略。