APT 能下载软件包，但签名密钥不来

能让 Acquire::http::Proxy 正常工作，并不能说明签名密钥下载为何失败，除非你知道是哪个程序在获取密钥。

apt-key adv 这类旧做法走的是 GnuPG 的密钥服务器路径。其他安装方法用 curl 或浏览器下载密钥。这些程序并不都读取 APT 自己的代理配置。

对于 GnuPG 密钥服务器请求

GnuPG 使用 dirmngr 完成相关网络操作。其文档化的选项包括 honor-http-proxy 和显式的 http-proxy 设置；显式设置会覆盖环境变量。检查实际使用的 GnuPG 主目录和账户，尤其是带特权的命令。

也要检查密钥服务器的 URL。原生密钥服务器连接与针对同一密钥的 HTTPS 请求并不相同。通过 HTTP 代理的浏览器访问，并不能确立对密钥服务器端口的单独直连许可。

遵循发布方当前的安装方法

不要为了修复网络访问而复活已废弃的全局信任命令。发布方当前的说明应当指出密钥来源和预期的密钥环。若他们使用 HTTPS 下载，就配置发出该请求的 HTTP 客户端。在发布方可公开访问且允许公共中转的地方，HTTP 代理列表提供候选端点；指纹校验仍是单独的要求。

通过发布方的信息确认密钥完整的预期指纹。下载到的文件、相符的显示名称或搜索结果并不能确立身份。更换密钥时，使用当前有文档记载的替换流程。

APT 的 Signed-By 选项可以把该仓库关联到特定密钥环，而不是在来源之间授予通用信任。检查所需的密钥环格式与扩展名，然后确保获取账户能读取该文件并穿越其父目录。仅有管理员权限并不能确立该许可。

让错误指出下一项检查

• 超时涉及下载程序的路径或端点的可达性。
• 代理质询涉及它的账户和支持的方式。
• 指纹不匹配是交付后的信任失败。
• 之后的 APT 签名错误可能涉及密钥环路径或仓库关联。

在保留签名校验的前提下解决该环节。关闭它就会去掉签名密钥配置本应提供的检查。