在 Android 系统的安全体系中，VPN 流量泄漏是一个高危问题 —— 它直接威胁用户的 IP 隐匿性，使匿名通信形同虚设。2026 年 4 月底，安全研究员 lowlevel/Yusuf 披露了一个影响 Android 16 的 VPN 绕过漏洞：攻击者仅凭普通应用权限，即可通过 Android 新引入的 QUIC 连接拆除机制，让拥有特权地位的 system_server 进程直接通过物理网卡发送 UDP 数据包，从而绕过 always-on VPN 和 “阻止无 VPN 连接” 两项保护。Google 安全团队将该漏洞标记为 "Won't Fix (Infeasible)" 和 "NSBC"（Not Security Bulletin Class），拒绝将其纳入官方修复流程。GrapheneOS 项目在不到一周内发布了对应补丁，通过禁用底层优化彻底封堵攻击向量。本文从技术机制、修复策略和工程化参数三个维度展开分析。
QUIC 优化如何成为 VPN 泄漏的入口
要理解这个漏洞，需要回溯 Android 在网络栈层面的两个设计决策。首先，Android 从很早起就在应用层实现了 VPN 路由强制 —— 通过 iptables 规则将所有非白名单流量重定向到 tun0 或类似的虚拟接口。系统服务进程（如 system_server）理论上也应该遵守这一路由策略，否则 always-on VPN 就失去了意义。其次，Android 在 QUIC 协议支持上持续投入，QUIC 作为 UDP 之上的传输层协议，已被 Chrome 和 Android 网络库广泛用于 HTTP/3 连接。
问题出在 Android 16 新引入的 registerQuicConnectionClosePayload API。这是一个性能优化：当应用主动关闭某个 UDP socket 时，如果应用同时注册了一个 QUIC CONNECTION_CLOSE 帧的 payload，system_server 会在后台代替应用完成 QUIC 连接的优雅关闭。这避免了应用进程突然退出时连接残留的问题。这个优化本身逻辑合理，然而实现细节却存在致命缺陷：system_server 接受任意应用提交的 UDP payload，而不验证该 payload 是否为合法的 QUIC CONNECTION_CLOSE 帧，也不检查原应用是否被配置为仅允许通过 VPN 发送流量。
关键点在于：system_server 进程在 Android 中拥有 elevated networking privileges，它发出的网络请求不受普通应用的 VPN 路由规则约束。这本来是为了让系统服务能够执行网络诊断、时间同步等管理功能，但 QUIC 优化将这个特权滥用通道直接开放给了任意普通应用。攻击流程因此形成：恶意应用只需声明 INTERNET 和 ACCESS_NETWORK_STATE 两个默认权限，就可以通过 registerQuicConnectionClosePayload 向 system_server 注册一个携带真实 IP 地址信息的 UDP 包；当应用关闭自己的 UDP socket 时，system_server 会通过物理网卡直接发送这个包，用户原本配置的 VPN 隧道被完全绕过。lowlevel/Yusuf 在 Pixel 8 + Android 16 + Proton VPN 的测试环境中验证了这一点，成功将设备的真实公网 IP 地址泄露至远程服务器。
Google 的 "不可修复" 判决与 GrapheneOS 的响应逻辑
Google 安全团队将这个漏洞分类为 "Won't Fix (Infeasible)" 并标注为 NSBC，意味着他们认为在现有架构下修复的成本过高，且该漏洞不属于安全公告的收录范围。这一判断的核心依据是：system_server 的网络特权是架构层面的设计，而非普通的安全缺陷；修改这一行为可能破坏 Android 系统服务的正常运行。这是一个典型的架构耦合问题 ——VPN 路由强制机制与系统服务的网络特权在底层共享同一套权限模型，解耦需要大规模重构。
GrapheneOS 作为 de-googled ROM 项目，选择了完全不同的应对路径。GrapheneOS 的核心哲学是：如果一个优化存在安全风险且无法在合理时间内彻底修复，那么最安全的做法就是禁用它。在 release 2026050400 中，GrapheneOS 明确指出修复方式是 "disabled registerQuicConnectionClosePayload optimization"，即直接在系统层面禁用这项 QUIC 优化。这个决策背后的逻辑是：QUIC 连接优雅关闭是一个锦上添花的特性，而 VPN 流量泄漏是隐私安全的根本威胁。两者权衡，禁用优化是唯一负责任的选择。
GrapheneOS 能够快速响应并推送修复，得益于 de-googled ROM 在代码控制权上的优势。标准 Android 系统依赖于 Google 的月度安全更新流程，而 GrapheneOS 直接对 AOSP 代码拥有完整的维护权，可以根据安全研究随时发布针对性补丁。这种响应速度在官方渠道中几乎不可能实现 —— 即便是被承认的安全漏洞，Google 通常也需要等待下一个安全公告周期才能推送修复。
always-on VPN 在 GrapheneOS 中的强制路由机制
理解 GrapheneOS 的修复，还需要了解 always-on VPN 在该 ROM 中的实现方式。Android 原生的 always-on VPN 功能依赖 VpnService API 和 iptables 规则：在用户启用该功能后，系统会在网络栈层面插入 iptables 规则，强制所有应用的网络请求经过 VPN 接口。GrapheneOS 在此基础上进行了两项强化。
第一项强化是更严格的路由策略。标准 Android 的 VPN 路由规则遵循一个逻辑：默认情况下所有流量走 VPN，但系统服务白名单中的进程可以绕过这一限制。GrapheneOS 缩小了这个白名单的范围，将更多系统服务纳入 VPN 路由强制范围，从而减少利用特权服务绕过的攻击面。第二项强化是额外的流量监控层。GrapheneOS 在内核层面引入了网络流量审计机制，能够检测到异常的网络流量模式 —— 例如，一个被配置为仅允许 VPN 流量的应用突然尝试直接访问物理网卡。
这次 QUIC 漏洞的修复进一步强化了这些机制。禁用 registerQuicConnectionClosePayload 优化之后，系统服务不再具备通过 system_server 直接发送任意 UDP 包的能力，所有网络通信都必须经过 VPN 路由层处理。从 iptables 的角度，这相当于在 filter 表的 OUTPUT 链中增加了一条更严格的规则，确保即使拥有特权地位的 system_server 也无法绕过 VPN 接口。
临时缓解方案与工程化参数
对于运行标准 Android 的用户，lowlevel/Yusuf 在技术报告中提供了一个临时缓解方案：通过 ADB 执行以下命令修改 DeviceConfig 标志：
adb shell device_config put netd_features close_quic_connection false
这个命令将 close_quic_connection 特性标志设置为 false，从而禁用 QUIC 连接关闭优化的后端逻辑。该操作不需要 root 权限，普通用户可以在开发者选项中启用 ADB 后执行。然而，这个方案有两个显著局限：首先，它需要用户具备 ADB 操作能力，普通消费者的门槛较高；其次，DeviceConfig 标志的持久性不受保证 ——Google 在未来的 Android 版本中可能直接移除这个标志，使得临时缓解失效。
如果用户无法安装 GrapheneOS 但希望获得接近的保护效果，建议采取以下分层策略。第一层是始终启用 always-on VPN 并开启 “阻止无 VPN 连接” 选项，但需要认识到这些选项在面对类似 QUIC 漏洞时可能失效。第二层是使用应用级别的防火墙工具（如 AFWall+）配合 iptables 规则，将更多应用的出站流量限制在 VPN 接口上。第三层是监控网络活动 —— 通过 GrapheneOS 内置的网络流量审计或第三方工具，检测是否有应用尝试直接访问物理网卡而非 VPN 接口。
de-googled ROM 生态的补丁策略启示
这个案例揭示了 de-googled ROM 生态在安全响应上的独特价值。GrapheneOS 能够在一周内完成从漏洞披露到补丁发布的全流程，而 Google 需要数周甚至数月才能将相同修复纳入官方更新。这种速度优势来自三个方面：代码库的直接控制权使得修复可以绕过 Google 的代码审查流程；用户群体相对小众且安全意识强，使得漏洞更容易被社区研究者发现和报告；项目团队专注于安全强化而非功能迭代，能够将资源集中于高优先级漏洞。
然而，这个案例也暴露了标准 Android 安全模型的结构性问题。system_server 作为一个拥有网络特权的系统服务，其权限边界本应通过严格的设计来限制，但在实际实现中却通过 QUIC 优化无意中打开了一个滥用通道。Google 将其标记为不可修复，实际上反映了一个更深层的矛盾：Android 的安全模型建立在 "系统服务可信" 的前提上，但这个前提在复杂系统服务的交互中越来越难以维持。
对于安全从业者和隐私倡导者而言，这个案例提供了一个重要的工程参考：当一个架构层面的设计决策引入安全风险且无法快速修复时，禁用相关优化是最保险的做法。GrapheneOS 用行动证明了这一点 —— 它没有试图在 system_server 的权限模型上打补丁，而是直接移除了有问题的优化。这种断舍离的思路在安全工程中具有普遍意义：安全性和功能性常常存在冲突，在冲突无法调和的情况下，安全性应当始终优先。
资料来源
- CyberInsider: GrapheneOS fixes Android VPN leak Google refused to patch（2026-05-06）
- lowlevel.fun: Tiny UDP Cannon: Android VPN Bypass（技术分析报告）
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。