Android VPN 重置的边界：每一层究竟清掉了什么
缓存、应用存储、网络重置和恢复出厂设置清除的 Android 状态各不相同。删除配置文件之前，先确认你怀疑的状态落在哪一层。
Android 上有四种常被笼统称为 VPN 重置的操作，它们清掉的东西并不相同。清除应用缓存只删除临时文件；清除应用存储则会删掉配置本身。网络重置会重建连接栈，恢复出厂设置则替换用户数据分区。请按你怀疑的状态来选择操作，而不是按习惯。一旦判断错，需要的配置文件或注册路径会在你开始诊断之前就消失。
我在每一单里用的规则是：说清状态，说清它的归属，然后只删那个归属的那份。本页余下的部分讲的是哪个 Android 组件持有哪一段字节。
Android VPN 配置究竟存放在哪里
非受管手机上，第三方客户端把配置放在自己的应用数据目录里，形式可能是偏好设置文件、JSON 块或一个小型 SQLite 数据库。设置里的“清除存储”删掉的就是这个目录。配置并不在系统的 VPN 列表里：那张列表保存的是客户端通过 VpnService 注册的连接记录，包含连接名称、所属包名以及用户设置过的常开标志。
VpnService 是管道，不是存储。客户端只申请一次授权，自建 tun 接口并自行搬运数据包，因此平台从不需要理解配置格式。这就是为什么从另一部手机拷来的配置文件经常被导入成空配置，或者在校验时失败。
凭据走的是另一条路。通过系统 KeyChain 取得的密钥或证书留在系统管理的存储区里，所以清除应用数据可能让凭据仍然可用，只删掉客户端对它的别名。
受管设备会多出一个归属方。EMM 创建的工作配置会在自己的策略下运行客户端的一份副本，而常开 VPN 可能被设备策略锁定，用户无法断开。这类设备上的配置通常在注册时下发，而不是手工输入。此时恢复属于重新注册的决策，而不是重新导入。
缓存、存储、网络重置、恢复出厂设置
这四种操作对应上述边界。点任何东西之前，先读一遍你怀疑的那一行。
| Operation | What it removes | What survives |
|---|---|---|
| Clear cache | Temporary files, including any diagnostic bundle the client wrote there | Profile, credentials, enrollment |
| Clear storage | The app's preferences, databases and saved profile | KeyChain entries, other apps, device policy |
| Network reset | Wi-Fi, mobile and Bluetooth registrations, and on most builds the saved VPN entries | App data, KeyChain, work profile |
| Factory reset | The user data partition, accounts and device-bound keys | Nothing on the device |
清除缓存最安全，也最没用。它删掉临时文件，而那里可能正是客户端存放支持人员刚刚向你要的那份日志的地方。Android 的应用问题排查指南把缓存和存储当成两种不同的删除，你也应该这样区分。
清除存储才是真正意义上的单应用重置。它会删掉配置、保存的网关，以及客户端为特定网络保留的信任标记。它不会吊销 KeyChain 条目，不会删除属于其他应用的系统 VPN 记录，在受管配置上也不会删除当初下发该配置的策略。
设置里的网络重置针对整台设备，确切范围随厂商和 Android 版本变化。你自己这台机器上的确认对话框，才是关于它会忘记什么唯一可靠的说明。
先把回来的路记下来
做任何破坏性操作之前，先写下五件事：客户端版本、配置名称、网关地址、服务归属方，以及连接失败的确切阶段。
正是这五项事实把客户端故障与策略或服务器故障区分开。超时、证书被拒和立即拒绝是三种不同的失败，各自指向不同的归属方。先清存储，你就丢掉了本可区分它们的那份客户端侧证据。趁日志还在，留一份脱敏副本。
然后确认连接将如何重建。如果配置依赖客户端证书、受管配置或绑定在这台设备上的 MFA 注册，光有显示名称和主机名是不够的。
没人规划的引导锁定
有一种失效模式值得单开一节。如果下载配置的唯一入口是一个只能通过你要删除的那条隧道访问的内部门户，那么清除存储就会造成一个应用内无路可走的死角。
常开 VPN 配合“无 VPN 时阻止连接”，会把它变成彻底断网：手机没有可用的路径到达门户，客户端也没有配置可以把隧道拉起来。两种状态互相把对方钉死。
出路是流程上的，而不是技术上的。趁隧道还能用，先导出或拍下配置，确认门户有一条不依赖 VPN 的路由，然后才去清任何东西。在受管设备上，动配置之前先问管理员有哪些恢复路径。
验证重建后的隧道
配置回来后，按顺序测试：名称解析、到已知内网主机的 TCP 连接，以及你真正依赖的失败阻断行为。顺序重要，因为隧道起来之后仍可能泄漏 DNS。
状态栏里的钥匙图标只能证明接口存在，仅此而已。
如果定向重置之后连接仍然失败，不要再加大操作规模。保留前后证据，记下你清的是哪一层，并带着前面那五项事实把案子交给组件归属方。恢复出厂设置是成本高得多的另一个决策，它不是 VPN 排查清单里的下一步。