镜像已推送，manifest inspect 却报 no such manifest

Buildx 日志已经显示镜像清单推送完成，同一个标签却在 docker manifest inspect 中报 no such manifest。先核对查询工具是否能读取仓库中的清单类型，再判断标签是否真的不存在。历史 Buildx 0.10.0 环境中，已有这类 OCI 清单与旧查询客户端不兼容的情况；不能据此认定当前所有 Docker 版本都会失败。

这篇针对仓库已有对象、查询却失败的分支。如果构建结果只留在构建器缓存，连推送都没有发生，应先检查Buildx 的输出方式。

先用另一种只读查询对照

把示例仓库、命名空间和标签换成实际值。私有仓库先确认当前终端使用了正确凭据，不要把访问令牌写进命令或日志：

docker version
docker buildx version
docker buildx imagetools inspect registry.example.com/team/app:release-check
docker buildx imagetools inspect --raw registry.example.com/team/app:release-check

imagetools inspect 直接查询仓库对象，--raw 输出原始清单 JSON。对照原推送日志中的仓库、标签和摘要，确认查的是同一个对象。如果不同终端使用了不同账号，或者发布的是另一个命名空间，查询结果没有可比性。

当 imagetools 能读到对象，旧 manifest inspect 仍失败时，再检查原始 JSON 的 mediaType。OCI index 使用 application/vnd.oci.image.index.v1+json；它可以包含镜像清单和证明材料。需要排查旧客户端时，可在已确认不会泄露凭据的环境查看调试输出：

docker --debug manifest inspect registry.example.com/team/app:release-check

若其中明确出现 OCI manifest found, but accept header does not support OCI manifests，证据指向客户端接受的媒体类型，而不是“推送成功是假象”。没有这类对照证据时，还应检查标签拼写、仓库权限及访问地址。

单个平台也可能对应一个索引

Buildx 0.10 开始默认加入最小 provenance 证明材料。即使只构建一个平台，推送结果也可能以索引组织实际镜像与 attestation。索引里的 unknown/unknown 条目可能是证明材料，不能当成一份可运行的 ARM64 或 AMD64 镜像，也不能据此认定镜像架构坏了。

查询索引得到的是索引结构，不一定包含每个子清单的完整层信息。原脚本如果依赖 docker manifest inspect --verbose 的字段或标志，换成 imagetools --raw 后要重新核对解析逻辑；不能只替换命令名就假定输出完全相同。非 HTTPS 仓库的连接配置也应按当前工具支持的方式单独处理，不随手取消证书校验。

优先修查询链，再决定是否改变构建产物

只需读取清单时，使用支持实际媒体类型的查询工具，通常不需要重新构建。先保留原标签与摘要，修正检查脚本，再验证它能找到实际运行平台对应的子清单。

如果下游确实不接受 attestation，而且升级下游暂时不可行，可以评估构建时使用 --provenance=false。这会取消该次构建的 provenance 生成，改变供应链元数据，并且需要重新构建、推送；它不只是改变查询显示。它也不保证解决所有清单、权限或多平台兼容问题。

试验应使用独立标签，并确认仓库写入权限。保留原正式摘要和部署配置，验证新对象及实际部署后再决定是否替换；回退仍指向原摘要。若 imagetools 同样找不到对象，则回到推送日志、认证与标签核对，不要先删镜像或退回旧版 Buildx。