为Docker私有镜像仓库配置CORS需在Registry服务或Nginx代理层设置响应头：指定Access-Control-Allow-Origin、Allow-Methods（含DELETE）、Allow-Headers（含Authorization）、Allow-Credentials为true、Expose-Headers（含Docker-Content-Digest），并正确处理OPTIONS预检。
在Docker中为私有镜像仓库（如 registry:2）配置CORS，核心目标是让Web管理界面（如 joxit/docker-registry-ui）能安全发起跨域请求——尤其是带认证的 DELETE、GET 和预检 OPTIONS 请求。关键不在UI端改代码，而在Registry服务本身或其前置代理层暴露正确的HTTP响应头。
直接配置Registry服务的headers（最推荐）
这是最干净、最符合容器化设计的方式。修改Registry的YAML配置文件，在http.headers下显式声明CORS策略：
-
Access-Control-Allow-Origin：填UI的实际访问地址，例如
http://localhost:8080或https://registry-ui.example.com；生产环境切勿用*（尤其开启凭据时） -
Access-Control-Allow-Methods：必须包含
HEAD、GET、DELETE、OPTIONS；删除镜像功能依赖DELETE -
Access-Control-Allow-Headers：至少包含
Authorization（用于Bearer Token或Basic Auth）和Accept -
Access-Control-Allow-Credentials：设为
true，否则带登录态的请求会被浏览器拦截 -
Access-Control-Expose-Headers：加上
Docker-Content-Digest，UI读取镜像摘要时需要
用Nginx反向代理统一出口（更灵活、更安全）
当Registry和UI部署在不同域名，或你希望集中管控认证、日志、限流时，用Nginx做反向代理是最优解。它把Registry“藏”在同源路径下，彻底规避浏览器CORS检查：
- 将Registry服务映射到Nginx的一个子路径，例如
/v2/，所有请求由Nginx转发 - 在Nginx
location /v2/块中添加标准CORS头，包括add_header Access-Control-Allow-Origin "https://your-ui-domain.com" - 对
OPTIONS请求单独返回204状态码并设置全部CORS头，避免预检失败 - UI前端直接调用
/v2/xxx，与自身同源，不再触发跨域限制
避免常见配置陷阱
CORS看似简单，但几个细节错一点就会导致UI白屏或删镜像失败：
- 如果UI启用了登录（如Basic Auth），
Access-Control-Allow-Credentials必须为true，且Access-Control-Allow-Origin不能是通配符* - Registry默认不处理
OPTIONS请求，若没配好预检响应，浏览器会直接拒绝后续请求 - Docker Registry v2协议要求某些头（如
Docker-Distribution-API-Version）必须存在，CORS头不能干扰它们的顺序或覆盖 - 使用Docker Compose部署时，确保Registry容器能被Nginx或UI容器通过服务名正确解析（如
http://registry:5000）
验证是否生效
启动后别急着打开UI，先用curl快速验证CORS头是否返回正确：
- 执行
curl -I -X OPTIONS http://your-registry:5000/v2/，检查响应中是否有Access-Control-Allow-Origin等头 - 再试一个带
Origin头的真实请求：curl -H "Origin: http://localhost:8080" -I http://your-registry:5000/v2/ - 打开浏览器开发者工具 → Network → 查看任意API请求的Response Headers，确认CORS相关字段齐全且值匹配
