答案是修改nginx的client_max_body_size参数：在http块中设为1024m并重载配置，同时调高gitlab后台的maximum attachment size至1024mb，确保前后端限制协同且后端≥nginx值。
这个问题本质是 Nginx 在反向代理 GitLab 时，对单次 HTTP 请求体大小做了过严限制，而 CI 流水线并发上传多个大体积制品（如容器镜像、二进制包、模型文件等）时，每个上传请求都可能突破默认阈值，触发 413 Request Entity Too Large 错误。
确认 Nginx 是瓶颈源头
不是 GitLab 应用或 Runner 配置的问题，而是前端 Nginx 拒绝接收大请求体。验证方法很简单：
- 用
curl -v -X POST模拟一个 200MB 的空文件上传到/api/v4/projects/:id/packages接口，观察响应头是否明确返回Server: nginx和状态码413 - 检查 Nginx 日志（如
/var/log/nginx/error.log），搜索client intended to send too large body关键字 - 运行
grep -r "client_max_body_size" /etc/nginx/，确认当前生效值（常见默认为1m或未显式设置）
精准调整 Nginx client_max_body_size
这个参数必须覆盖到 GitLab Package Registry 的实际请求路径。推荐在 http 块中全局设置，避免遗漏：
- 编辑主配置文件（如
/etc/nginx/nginx.conf或/etc/nginx/conf.d/gitlab.conf） - 在
http { ... }区块内添加：
client_max_body_size 1024m;（建议设为 1GB，足够应对多数制品包） - 若使用 GitLab Omnibus 安装，也可在
/etc/gitlab/gitlab.rb中添加：
nginx['client_max_body_size'] = '1024m'，然后执行gitlab-ctl reconfigure - 保存后重载配置：
sudo nginx -s reload或sudo systemctl reload nginx
同步检查 GitLab Package Registry 自身限制
Nginx 放行后，还需确保 GitLab 后端服务不拦截：
- 登录 GitLab 管理后台 → Admin Area → Settings → Network → 找到 Maximum attachment size，建议调高至
1024（单位 MB） - 检查
/etc/gitlab/gitlab.rb是否有显式限制：
gitlab_rails['max_attachment_size'] = 1024 * 1024 * 1024 - Package Registry 默认不限制单个包大小，但若启用了
packages_enabled且搭配了对象存储（如 S3），需确认对象存储的预签名 URL 有效期与分块上传策略兼容
规避并发上传冲突的 CI 实践建议
即使 Nginx 和 GitLab 都已放宽限制，高并发上传仍可能因连接竞争或超时引发不稳定：
- 在
.gitlab-ci.yml中为 package job 添加resource_group: package-upload，强制串行化上传任务 - 对超大制品（如 >500MB），改用
gitlab-runner exec docker或脚本调用curl -T直传至对象存储，绕过 GitLab API 层 - 启用 GitLab 的
direct_upload功能（需 GitLab ≥ 15.6），让 Runner 直接上传到后端存储，不经过 Nginx+Rails 链路
