Clover Sandbox 上传 APK 一直转圈并报 404，如何排查？

结论

现有信息不足以确定故障原因，也无法确认 Clover 是否存在已知的 Dashboard 与数据库同步延迟。应先核对失败请求的 App ID、请求环境和账号上下文，再确认配置文件请求失败与上传操作之间是否有关联。

jarsigner 返回 jar verified，只能说明 APK 通过了该工具的签名验证，不能证明它满足 Clover 的全部上传要求，也不能证明 Dashboard 创建应用后，上传接口一定能访问该应用。

两种错误需要分别定位

应用请求返回：

{"details":"No app with ID YNTNZS0******","message":"Not Found"}

该请求没有找到对应应用，但仅凭响应无法确定原因。需要核对请求中的 App ID 是否正确、请求是否进入预期环境，以及当前账号是否处于正确的应用访问上下文。不能据此认定数据库没有保存应用。

另一个错误是：

<Error>
  <Code>NoSuchKey</Code>
  <Message>The specified key does not exist.</Message>
</Error>

它对应的地址包含：

cloverstatic.com/web/apps/developer-platform-web/_config/prod-na.json?...

这个错误指向该地址所请求的资源缺失，不能直接解释为 APK 文件不存在。仅凭文件名 prod-na.json，也无法判断 Clover 前端的配置组织方式，或证明 Sandbox 错用了生产环境。

先确认上传卡在哪一步

在浏览器开发者工具中打开 Network，启用 Preserve log，清空已有记录，再执行一次上传。保留完整请求链，检查以下内容：

1. 应用读取请求：重新打开应用详情页时，是否已经出现 No app with ID？如果上传前就失败，应优先排查应用访问和环境问题。
2. 上传相关请求：选择 APK 后，是否实际发送了携带文件内容的请求？如果没有，页面可能在上传前置步骤就已中断。
3. 失败顺序：配置文件错误和应用 404 哪一个先发生？查看请求的 Initiator，判断它们是否属于同一条调用链。
4. 请求内容：对照 Dashboard 当前应用，检查 URL、查询参数或请求体中的完整 App ID 是否一致，不要只比较脱敏后的前缀。

“App Releases”没有记录，只能说明发布记录尚未显示，不能据此判断文件是否已经传到服务器。

核对环境、区域和账号上下文

从 Sandbox 入口重新进入目标应用，对照应用创建、应用读取和上传相关请求，检查它们使用的主机、环境标识、区域标识及 App ID。

如果请求中存在开发者组织或账号范围标识，也要确认它们是否一致。先确定 Dashboard 实际发出了什么请求，避免通过手工替换请求地址中的 Sandbox、production 或区域字段来试错。

你已经尝试过多个浏览器，新建应用后问题仍然复现，因此可以降低单一浏览器缓存问题的排查优先级。继续重复新建应用带来的信息有限，保留一个可稳定复现的应用更便于对照请求。

APK 检查与上传兼容性

已有检查可以作为排障证据，例如：

jarsigner -verify -verbose myapp.apk

还应确认选择上传的是完成对齐、签名和最终验证的同一份文件，并且最终验证后没有再次修改 APK。

V1 签名、SHA256withRSA、SHA-256、META-INF/CERT.RSA 和 ZipAlign 检查，都不能替代对平台完整要求的核对。现有错误没有明确指向 Target SDK 或 build-tools;34.0.0，暂时没有依据通过反复更换这些参数来解决问题。

如何判断是否为同步延迟

保留同一个 App ID，记录创建时间和后续读取结果。如果账号、环境和请求参数均未改变，而应用稍后恢复可访问，这可以作为短暂延迟的线索，但仍不能据此推导官方同步机制或固定等待时长。

如果问题持续复现，可向 Clover 支持提供创建时间及其时区、App ID、完整失败路径、响应内容、请求顺序，以及响应中实际存在的请求追踪标识。HAR 文件可辅助分析，但共享前应移除 Cookie、Authorization、令牌及其他敏感信息。

当前需要确定应用是否在上传前就无法读取，以及 NoSuchKey 是否阻断了上传所需的配置加载。这两项结果能帮助判断后续应重点排查应用访问、前端配置，还是 APK 接收与校验环节。

备注：内容仅供参考。