推送镜像至自建Docker Registry时缺失content-length header的解决方法

问题描述 #

按照官方文档搭建自建Docker Registry后，推送镜像时出现以下错误：

missing content-length header for request: https://registry.filthyweebs.in/v2/test-image/blobs/sha256:b52eb23a552e2c2a580f2adc60e6b3d2c06e23c90323f3abfd4f9ffc3aa464f6

Registry日志中同时出现500错误：

time="2023-08-13T07:11:08.651744609Z" level=error msg="response completed with error" auth.user.name=admin err.code=unknown err.detail="invalid byte in chunk length" err.message="unknown error" go.version=go1.19.9 http.request.host=registry.filthyweebs.in http.request.id=14e4c98d-848b-4398-b0a7-b8d57ec794e0 http.request.method=PATCH http.request.remoteaddr=xxx.xxx.xxx.xxx http.request.uri="/v2/test-image/blobs/uploads/a0fa5af8-211d-445c-902b-5c5d7aadaac4?_state=zkuo-95XSKgz212Hf2nt3ZpOuX-qqzL2ROwU8hyCkVl7Ik5hbWUiOiJ0ZXN0LWltYWdlIiwiVVVJRCI6ImEwZmE1YWY4LTIxMWQtNDQ1Yy05MDJiLTVjNWQ3YWFkYWFjNCIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAyMy0wOC0xM1QwNzoxMTowOC4wODkzNzU4NjFaIn0%3D" http.request.useragent="docker/20.10.25+dfsg1 go/go1.20.7 git-commit/5df983c kernel/6.3.0-kali1-amd64 os/linux arch/amd64 UpstreamClient(Docker-Client/20.10.25+dfsg1 \(linux\))" http.response.contenttype="application/json; charset=utf-8" http.response.duration=15.292544ms http.response.status=500 http.response.written=98 vars.name=test-image vars.uuid=a0fa5af8-211d-445c-902b-5c5d7aadaac4

使用的docker-compose.yml配置如下：

version: '3'

services:
  registry:
    restart: always
    image: registry:2
    ports:
    - "7244:5000"
    environment:
      REGISTRY_AUTH: htpasswd
      REGISTRY_AUTH_HTPASSWD_REALM: Registry
      REGISTRY_AUTH_HTPASSWD_PATH: /auth/registry.password
      REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /data
      REGISTRY_VALIDATION_DISABLED: true
      REGISTRY_HTTP_TLS_CERTIFICATE: /certs/fullchain.pem
      REGISTRY_HTTP_TLS_KEY: /certs/privkey.pem
    volumes:
      - ./auth:/auth
      - ./data:/data
      - ./certs:/certs

服务器为Debian Bookworm，客户端是最新版本Kali Linux，两次搭建均出现相同问题。

可能的解决方案 #

1. 检查反向代理/中间件的Chunked编码处理 #

如果Registry前端部署了Nginx等反向代理，可能是代理配置修改了HTTP请求的Chunked编码，导致Registry解析失败：

• 确保代理配置中没有禁用Chunked传输，避免设置chunked_transfer_encoding off;
• 确认代理使用HTTP/1.1协议，添加proxy_http_version 1.1;
• 删除类似proxy_set_header Transfer-Encoding "";的手动清除头部配置

示例Nginx正确代理配置片段：

server {
    listen 443 ssl;
    server_name registry.filthyweebs.in;

    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

    location / {
        proxy_pass http://localhost:7244;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

2. 排查客户端代理设置 #

Docker客户端如果配置了HTTP/HTTPS代理，可能导致请求头部被篡改：

• 临时关闭客户端的代理：

  unset HTTP_PROXY HTTPS_PROXY NO_PROXY
  systemctl restart docker
  

• 尝试直接推送镜像，验证是否恢复正常

3. 临时禁用TLS测试 #

排除TLS协商问题导致的请求异常：

• 修改docker-compose.yml，注释掉TLS相关环境变量，改用HTTP端口：

  # REGISTRY_HTTP_TLS_CERTIFICATE: /certs/fullchain.pem
  # REGISTRY_HTTP_TLS_KEY: /certs/privkey.pem
  

• 在客户端的/etc/docker/daemon.json中添加Registry为不安全镜像仓库：

  {
    "insecure-registries": ["registry.filthyweebs.in:7244"]
  }
  

• 重启Docker客户端和Registry服务，尝试推送镜像

4. 开启Registry调试日志 #

添加调试环境变量，获取更详细的请求/响应信息：

• 在docker-compose.yml的environment中加入：

  REGISTRY_HTTP_DEBUG: true
  REGISTRY_LOG_LEVEL: debug
  

• 重启Registry后，查看日志中完整的请求头部，确认content-length是否确实缺失，或者Chunked编码格式是否正确

5. 检查服务器防火墙/安全设备 #

服务器上的WAF、防火墙或入侵检测系统可能修改了HTTP请求的Chunked编码部分，导致Registry解析失败：

• 临时关闭相关安全设备，测试推送是否正常
• 如果是云服务器，检查云服务商的安全组/WAF规则是否拦截或修改了请求

内容的提问来源于stack exchange，提问作者TheWhiteFang