VPS执行apt update出现NO_PUBKEY、EXPKEYSIG、The following signatures were invalid或“仓库没有Release签名”，说明APT无法按当前信任配置验证仓库元数据。它不是普通下载超时，也不应通过关闭签名检查来“修好”。
先找到具体失败的软件源和密钥标识，再检查系统时间、仓库状态与密钥配置。只有确认仓库身份和官方更新方式后，才替换密钥或修改Signed-By。随意从搜索结果导入公钥，可能把错误密钥加入系统信任。
先读懂几类常见报错
| 提示 | 通常说明什么 | 优先检查 |
|---|---|---|
| NO_PUBKEY | 缺少验证当前签名所需的公钥，或软件源没有引用正确keyring | 仓库URL、密钥指纹、Signed-By路径 |
| EXPKEYSIG | 签名或用于签名的密钥有效性出现问题 | 系统时间、仓库公告、新密钥与新Release |
| Release file is not valid yet | 本机时间可能落后，或镜像元数据时间异常 | 时区、NTP和当前UTC时间 |
| repository is not signed | 仓库缺少APT可验证的签名信息 | URL是否正确、发行版代号、仓库是否已停用 |
| does not have a Release file | 路径、发行版版本或仓库结构不匹配 | sources配置和仓库支持列表 |
一条apt update可能同时访问系统官方仓库、Docker、数据库、监控工具和其他第三方源。只要其中一个失败，就应针对那一个源处理，不要删除全部密钥或重写所有源。
第一步：保存完整错误并定位软件源
sudo apt-get update记录报错中的仓库域名、发行版代号、密钥指纹或ID以及错误类型。再检查当前软件源：
grep -R --line-number -E '^(deb |deb-src |Types:|URIs:|Suites:|Signed-By:)'
/etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/nullDebian传统单行源通常使用.list，deb822格式通常使用.sources。不要看到同一域名出现多次就立即删除；先判断是否分别提供二进制包、源码包或不同组件。
第二步：检查VPS时间是否可信
date -u
timedatectl status时间偏差会影响签名和Release文件有效期判断。若时间明显错误，先核对云平台时钟、NTP或chrony状态，再重新运行更新。只为了通过签名检查手工把时间调到任意日期，会让TLS、日志和定时任务出现新的问题。
如果VPS既无法解析仓库域名又报连接错误，应先按VPS DNS解析链与53端口排查恢复名称解析，再判断剩余签名错误。
第三步：确认仓库仍支持当前系统版本
- 检查系统发行版和代号是否与软件源一致；
- 查看仓库官方文档是否更换域名、组件或安装方式；
- 确认旧版本系统是否已经停止提供该仓库；
- 检查代理、缓存镜像或企业内网镜像是否仍同步最新Release；
- 不要把另一个Ubuntu或Debian版本的源直接套到当前系统。
若只有第三方仓库失败，可以先在维护窗口暂时禁用该源并重新更新系统官方仓库，但这不等于问题已经修复。依赖该仓库的软件将暂时无法获得更新，应记录并安排后续处理。
第四步：按官方渠道更新专用keyring
apt-key已经弃用。对第三方仓库，更清晰的做法是将经过核对的仓库公钥保存在专用keyring中，并让该软件源通过Signed-By只信任这一组密钥。
sudo install -m 0755 -d /etc/apt/keyrings
ls -l /etc/apt/keyrings /usr/share/keyrings具体密钥下载地址、文件格式和指纹必须以仓库当前官方文档为准。获取密钥时使用可信通信渠道，核对域名、TLS和官方公布的指纹。不要把文章中的示例域名、论坛附件或陌生代码仓库当作密钥来源。
传统.list源通常类似：
deb [signed-by=/etc/apt/keyrings/vendor.gpg] 仓库官方HTTPS地址 stable maindeb822格式通常把路径放在独立字段：
Types: deb
URIs: 仓库官方HTTPS地址
Suites: stable
Components: main
Signed-By: /etc/apt/keyrings/vendor.gpg以上只说明结构，不是可直接使用的软件源。Signed-By的价值是限制某个仓库使用指定密钥验证，避免把所有第三方密钥放进全局信任范围。
不要用这些方式掩盖问题
- 为互联网仓库添加
trusted=yes； - 设置
allow-insecure=yes或全局允许不安全仓库； - 长期使用
--allow-unauthenticated安装软件包； - 从未知钥匙服务器按短ID盲目导入密钥；
- 把第三方密钥加入全局trusted.gpg而不限制仓库；
- 删除全部keyring后反复尝试更新。
APT的Release签名用于确认仓库元数据没有被不持有签名密钥的人修改。绕过认证可能让更新“继续运行”，却失去判断包索引是否可信的基础。
修复后怎样验收
- 重新运行
sudo apt-get update并保存完整输出； - 确认原仓库不再出现NO_PUBKEY、EXPKEYSIG或未签名警告；
- 检查没有因编辑错误而忽略其他
.list或.sources文件； - 确认keyring文件可被
_apt读取，Signed-By路径正确； - 使用
apt-cache policy核对候选包来自预期仓库； - 保留旧配置备份和变更记录，出现异常时可回滚。
如果问题实际是下载超时、代理或连接速度，而签名验证已经正常，应转到npm、pip与APT网络代理配置处理连接路径，不要继续修改密钥。
结论
VPS的APT签名错误应按“失败仓库、系统时间、版本支持、官方密钥、Signed-By、更新复验”处理。NO_PUBKEY不是让用户关闭验证的提示，EXPKEYSIG也不能只靠重新导入任意密钥解决。确认仓库身份并缩小信任范围，才是比绕过签名更安全、可维护的修复。
