I'm trying to run Sonatype Nexus in a docker container behind Traefik. We use Nexus as a self-hosted repository of Docker images, and those tend to be fairly large, especially since we have some Windows images we need to store.
Unfortunately I'm getting a HTTP 499 error when I tried to upload a test image to Nexus. Docker just shows this as unknown: Client Closed Request. Traefik's access log shows:
10.150.1.34 - - [22/Aug/2024:15:50:59 +0000] "PATCH /v2/pushtest/blobs/uploads/f58b4909-39b8-453c-bddc-963cb8514f1a HTTP/1.1" 499 21 "-" "-" 54567 "docker@docker" "https://172.19.0.13:8082" 59998ms
...while the Nexus logs show Early EOF, Cause: Early EOF error:
2024-08-22 15:53:20,146+0000 WARN [qtp312332515-114] anonymous org.sonatype.nexus.repository.docker.internal.V2Handlers - Error: PATCH /v2/pushtest/blobs/uploads/91f3ef19-907c-41a7-9abe-c580039688a5
org.sonatype.nexus.blobstore.api.BlobStoreException: BlobId: path$nexus-repository-docker/91f3ef19-907c-41a7-9abe-c580039688a5/92c992e9-f187-4f84-a5ad-e722656aaad1, org.eclipse.jetty.io.EofException: Early EOF, Cause: Early EOF
I'm pretty sure Traefik's at fault here - exposing Nexus via another reverse proxy that we have (Apache-based) doesn't cause these issues.
I'm guessing this it related to some kind of limit and / or configuration parameter I can (hopefully) set. The curious part is the 59999ms time from the access log - this equates to 60s, but I couldn't find anything with this default timeout in the documentation, so I'm not sure which limits I need to check. Or if this even IS caused by a timeout in the first place...
Any idea what I'd need to change to get Traefik to work with our Docker image repository?
1 Like
Hi @mbender,
I'm pretty sure you run in a timeout. Here's the documentation to change it: Traefik EntryPoints Documentation - Traefik
From what I can tell it's impossible to set these timeouts on a per-service basis (they need to be set on the entire entrypoint). And I need the repository to use the default 443 port (otherwise Docker requires custom client-side configurations which I'd rather avoid), so I can't create a new dedicated "long-timeout" entrypoint either. This means I'd need to increase this timeout for all services using HTTPS.
I have a suspicion that, in the end, I won't be able to use Traefik for this. 
For the record - right now I'm testing a sample image push where one of the layers is 8GB in size. Windows images are hellish on Docker, but we still prefer them to the alternative...
Thats correct. But luckily there is a feature request that is currently being processed: Setting timeout per service/router · Issue #10962 · traefik/traefik · GitHub
2 Likes
I'm a wee bit concerned, because it seems this "one-timeout-for-all" has been a thing for a number of years now, and Traefik hasn't budged on the issue...
And it seems like a fairly important feature given the potential security implications.
But thanks for the link - I'll keep a close eye on that thread, perhaps something interesting will come of it. 
1 Like
@mbender, I have the same issue as you met.
reverse-proxy-1 | 2025-02-09T17:48:08Z DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:207 > Service selected by WRR: 7de75da966cac97b
reverse-proxy-1 | 2025-02-09T17:49:08Z DBG github.com/traefik/traefik/v3/pkg/proxy/httputil/proxy.go:117 > 504 Gateway Timeout error="read tcp 172.27.0.14:443->192.168.199.188:53102: i/o timeout"