cert8.db 不是一次性缓存：请核实存储的所有者

一个陈旧的求助帖说，删掉名为 cert8.db 的文件，VPN 就恢复了。这种先后顺序多数时候只是巧合，而不是修复。该文件是证书数据库，删掉它会改变持久的安全状态，而一次成功的启动并不会显示这些变化。

登录卡死不是缓存问题

浏览器缓存保存的是资源副本；证书数据库保存的是信任决策、证书以及与之配套的密钥。删掉后者更接近于重置身份，而不像清理历史记录。如果客户端在登录时卡死，有用的证据是哪个进程打开了哪个配置文件、写了什么日志，而不是某个帖子删掉了哪个文件。复现卡死并读取客户端日志比删文件费时，但那是找到真正原因的唯一途径。

文件名本身也带着历史信息：NSS 把旧式的 cert8.db 和 key3.db 与 SQLite 格式的 cert9.db 和 key4.db 区分开来。把卡死前看到的那行日志记下来，因为它是你手上唯一持久的证据。

客户端实际打开的是哪个配置文件

先确定客户端、它的认证方式，以及它读取的存储。这里有三条登录路径：浏览器辅助、内置浏览器和原生客户端，它们不一定共用同一个配置文件。另一个目录里存在同名数据库，并不能证明卡死的进程打开的就是它。在 Linux 上，NSS 存储通常位于用户的 ~/.pki/nssdb 之下，或某个应用专属的配置目录中。两种布局可能同时存在于一台机器上，因此如果最近做过迁移，两处都要检查。

改动之前先列清存储里有什么：certutil -L -d sql:$HOME/.pki/nssdb 会打印证书，同一工具加上 -K 则显示是否存在密钥。

如果命令提示数据库无法打开，你找到的是该工具使用的配置文件，不一定是 VPN 用过的那一个。

任何修复之前先备份配置文件

关闭受影响的应用程序，然后用经过批准的备份方式复制整个配置目录。证书数据库和密钥数据库是相关但彼此独立的状态，只保存一个随意挑选的文件，不构成整套身份的恢复方案。妥善保护这份副本，因为配置文件里可能有私钥。记下备份了什么、放在哪里，这样修复失败时还有退路。

然后与维护者确认修复的确切范围。整体重置存储、删除一张已知过期证书、修复浏览器配置文件，是三种不同的改动，风险也各不相同。

修复之后登录并检查存储

在获得授权的修复之后，登录 VPN，确认服务器证书仍按预期通过验证。检查工作流所需的身份是否仍在，以及是否出现了意料之外的 信任锚。如果一次修复是靠比原先信任更多才让连接跑通，那不算修复。

把观察和指令分开：一次删除加上一次启动成功，并不等于通用解法。

如果卡死再次出现，先抓取客户端日志和正在使用的配置文件，再动别的。正是这份记录把猜测变成诊断。