Docker pull` / `docker compose build` consistently fails on large image layers with failed to copy: httpReadSeeker: failed open: failed to do request

Docker Desktop
1

Symptom: `:

failed to copy: httpReadSeeker: failed open: failed to do request:
Get "https://production.cloudfront.docker.com/.../data?...": EOF

The connection is severed mid-transfer (EOF) before the blob finishes.

Environment:

  • Docker Desktop engine 29.5.3, WSL2 backend (docker-desktop distro, WSL v2), Windows 11 Pro.
  • Daemon proxy (from docker info): HTTP/HTTPS Proxy: http.docker.internal:3128, No Proxy: hubproxy.docker.internal — this is Docker Desktop’s own internal proxy, not a corporate/system proxy.

Key behavior — it’s size-dependent, not transient:

  • Small images pull fine: alpine:3.20 (1st try), liquibase/liquibase:5.0.1 (2nd try).
  • Medium image eventually succeeds with retries: rabbitmq:4.2.0-management (7th try — layers accumulate across attempts).
  • Large layer never completes: postgres:17.5 failed 40/40 consecutive docker pull attempts; its big base layer gets cut every time and a single blob can’t resume, so retries make no progress.

Diagnostics proving it’s the Docker registry path, not the network:

  1. Path MTU is fine — ping -f -l 1472 8.8.8.8 (1500-byte packets, DF set) succeeds; all NIC MTUs are 1500.
  2. Host network is healthy — a 60 MB host download (Invoke-WebRequest) completed in 1.8s.
  3. No system proxy — Windows WinINET ProxyEnable = 0, nothing configured in Docker Desktop settings.
  4. CDN-independent — pulling the same image from the AWS ECR public mirror (public.ecr.aws/docker/library/postgres:17.5, a different CloudFront domain d2glxqk2uabbnd.cloudfront.net) fails identically with EOF. The only common factor is Docker Desktop’s http.docker.internal:3128 proxy.
  5. Restarting Docker Desktop / wsl --shutdown did not help.

Conclusion: Docker Desktop’s internal HTTP proxy (http.docker.internal:3128) appears to be terminating large/sustained registry blob transfers with EOF, regardless of registry or CDN. Small blobs succeed; large single blobs never complete.

Questions / asks for Docker:

  • Is there a known issue with the internal proxy and large blob transfers in engine 29.5.3?
  • Can the daemon be made to bypass http.docker.internal:3128, or is there a buffer/timeout/connection-limit on that proxy we can tune?
  • is there a problem with IPv6?
2

Not to protect Docker Desktop and its proxy, because it can definitely have bugs like this, but I have no problem with pulling the postgres image now. Can you recheck if you still exprience the error? According to downdetector, there were increasing number of reports about AWS yesterday, Hopefully it was a temporary problem. Otherwise I’m not sure what it is.

If you still have the same problem, do you have any other machine where you have only Docker CE, not Docker Desktop, where you could test pulling the same image? I’m curious if it depends on location or whether it is Docker Desktop or Docker CE. If there is nothng else, you could install Docker CE in a separate WSL2 distro to test this. Not in the same for which you enabled WSL2 integration. If you did that.

I’m not aware of current known problems with the internal proxy. I’m also not aware of ways to change the timeout, but you could try going to “Docker Desktop settings / Resources” and under “Docker Desktop proxy” set “no proxy”.

3

thanks for reply - I think my machine had an issue with IPv6 - when i disabled it on my network card it behaved a lot better…

4

I forgot to react to the IPv6-related question, but I would have probbaly just said that “it is possible”. Good that you fixed it.