Traefik v3.6: How to handle large streaming uploads over HTTPS/HTTP2

[mahdinazmi]

Traefik v3.6: Large streaming uploads over HTTPS/HTTP2 return 408 after ~5 minutes unless request buffering middleware is enabled

Environment

• Host: Hetzner Cloud VM (no extra load balancer in front)
• Reverse proxy: Traefik v3.6 (Coolify “coolify-proxy”)
• App: Node.js backend (Express) with:
  • Streaming file uploads using Busboy
  • Chunked upload to Backblaze B2
  • Upload progress via Socket.IO (WebSocket)
• Protocol: HTTPS / HTTP/2
• Domain: https://api.devbranch.dev

Goal

Support large file uploads (60MB+) that can take 5–6+ minutes over slow connections, while:

• Keeping true streaming end-to-end:
  • Browser → Traefik → Node (Busboy reads the request stream)
• Emitting real-time upload progress from Node via Socket.IO, based on bytes read from the request stream.
• Avoiding buffering the entire request body in Traefik.

Traefik (coolify-proxy) Configuration

coolify-proxy service (simplified):

services:
  traefik:
    image: traefik:v3.6
    command:
      - '--ping=true'
      - '--ping.entrypoint=http'
      - '--api.dashboard=true'
      - '--entrypoints.http.address=:80'
      - '--entrypoints.https.address=:443'
      - '--entrypoints.http.http.encodequerysemicolons=true'
      - '--entryPoints.http.http2.maxConcurrentStreams=250'
      - '--entrypoints.https.http.encodequerysemicolons=true'
      - '--entryPoints.https.http2.maxConcurrentStreams=250'
      - '--entrypoints.https.http3'
      - '--providers.file.directory=/traefik/dynamic/'
      - '--providers.file.watch=true'
      - '--certificatesresolvers.letsencrypt.acme.httpchallenge=true'
      - '--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=http'
      - '--certificatesresolvers.letsencrypt.acme.storage=/traefik/acme.json'
      - '--api.insecure=false'
      - '--providers.docker=true'
      - '--providers.docker.exposedbydefault=false'
      # I also tried these but they did not affect the ~5 minute behavior:
      # - '--entrypoints.http.transport.respondingTimeouts.readTimeout=1200s'
      # - '--entrypoints.http.transport.respondingTimeouts.writeTimeout=1200s'
      # - '--entrypoints.http.transport.respondingTimeouts.idleTimeout=1200s'
      # - '--entrypoints.https.transport.respondingTimeouts.readTimeout=1200s'
      # - '--entrypoints.https.transport.respondingTimeouts.writeTimeout=1200s'
      # - '--entrypoints.https.transport.respondingTimeouts.idleTimeout=1200s'

Application-Level Traefik Labels

traefik.enable=true

# --- Middlewares ---
traefik.http.middlewares.gzip.compress=true
traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https

# Upload streaming middleware (buffering)
traefik.http.middlewares.upload-stream.buffering.maxRequestBodyBytes=0
traefik.http.middlewares.upload-stream.buffering.memRequestBodyBytes=0
traefik.http.middlewares.upload-stream.buffering.memResponseBodyBytes=0
traefik.http.middlewares.upload-stream.buffering.retryExpression=IsNetworkError() && Attempts() < 5

# Socket.IO middleware (no buffering)
traefik.http.middlewares.socketio-no-buffer.buffering.maxRequestBodyBytes=0
traefik.http.middlewares.socketio-no-buffer.buffering.memRequestBodyBytes=0
traefik.http.middlewares.socketio-no-buffer.buffering.memResponseBodyBytes=0

# --- HTTP Router (redirect to HTTPS) ---
traefik.http.routers.http-0.entryPoints=http
traefik.http.routers.http-0.middlewares=redirect-to-https
traefik.http.routers.http-0.rule=Host(`api.devbranch.dev`) && PathPrefix(`/`)
traefik.http.routers.http-0.service=api-service

# --- HTTPS Router for Socket.IO (NO upload-stream middleware) ---
traefik.http.routers.socketio-https.entryPoints=https
traefik.http.routers.socketio-https.middlewares=gzip,socketio-no-buffer
traefik.http.routers.socketio-https.rule=Host(`api.devbranch.dev`) && PathPrefix(`/socket.io/`)
traefik.http.routers.socketio-https.service=api-service
traefik.http.routers.socketio-https.priority=10
traefik.http.routers.socketio-https.tls.certresolver=letsencrypt
traefik.http.routers.socketio-https.tls=true

# --- HTTPS Router for Upload Routes (can be with or without upload-stream) ---
traefik.http.routers.upload-https.entryPoints=https
# For true streaming I use ONLY gzip:
traefik.http.routers.upload-https.middlewares=gzip
# If I add upload-stream here, timeout disappears but streaming breaks:
# traefik.http.routers.upload-https.middlewares=gzip,upload-stream
traefik.http.routers.upload-https.rule=Host(`api.devbranch.dev`) && PathPrefix(`/api/v1/admin/`) && PathRegexp(`/uploads/`)
traefik.http.routers.upload-https.service=api-service
traefik.http.routers.upload-https.priority=10
traefik.http.routers.upload-https.tls.certresolver=letsencrypt
traefik.http.routers.upload-https.tls=true

# --- HTTPS Router for All Other Routes (default) ---
traefik.http.routers.https-0.entryPoints=https
traefik.http.routers.https-0.middlewares=gzip
traefik.http.routers.https-0.rule=Host(`api.devbranch.dev`) && PathPrefix(`/`)
traefik.http.routers.https-0.service=api-service
traefik.http.routers.https-0.tls.certresolver=letsencrypt
traefik.http.routers.https-0.tls=true

# --- Service ---
traefik.http.services.api-service.loadbalancer.server.port=3000
traefik.http.services.api-service.loadbalancer.responseforwarding.flushinterval=1ms### Behavior 1 – True Streaming (no `upload-stream` middleware)

When upload-stream is NOT applied to the upload router:

• Uploads are streamed end-to-end.

• Node (Busboy) sees bytes gradually and emits Socket.IO upload-progress events correctly.

• For large uploads (~135MB) over a slow connection, after ~5.1–5.3 minutes the browser sees:

  408 Request Timeout
  net::ERR_FAILED 408 (Request Timeout)
  Access to XMLHttpRequest at 'https://api.devbranch.dev/api/v1/admin/.../uploads/videos'
  from origin 'https://backoffice.devbranch.dev' has been blocked by CORS policy:
  No 'Access-Control-Allow-Origin' header is present on the requested resource.

  • Traefik access log for such a failed request:

  {
    "ClientAddr":"146.70.62.93:35197",
    "DownstreamContentSize":0,
    "DownstreamStatus":408,
    "Duration":306442633433,
    "OriginContentSize":0,
    "OriginStatus":0,
    "OriginDuration":306442525634,
    "RequestMethod":"POST",
    "RequestPath":"/api/v1/admin/courses/69804f524855ffb6014732b7/uploads/videos",
    "RequestContentSize":134880875,
    "RequestHost":"api.devbranch.dev",
    "RequestProtocol":"HTTP/2.0",
    "RouterName":"https-0-xk8osscwck4o84kskgok4ws0@docker",
    "ServiceAddr":"172.18.0.11:3000",
    "ServiceName":"api-service@docker",
    "ServiceURL":"http://172.18.0.11:3000",
    "StartUTC":"2026-02-12T08:06:34.853439035Z",
    "entryPointName":"https"
  }

Interpretation:

• DownstreamStatus: 408 and Duration ≈ 306s → Traefik itself is returning the 408 after ~5.1 minutes.
• OriginStatus: 0 → Traefik never got a response from the backend (the client was still uploading).
• So this is a client body read timeout on the HTTPS entrypoint, not a backend timeout.

Behavior 2 – With upload-stream buffering middleware

When I attach the upload-stream buffering middleware to the upload router:

traefik.http.routers.upload-https.middlewares=gzip,upload-stream Then:

• The 408 timeout disappears: large uploads complete without HTTP errors.
• However, Traefik now buffers the entire request body before sending it to the backend:
  • Browser → Traefik: slow (5+ minutes)
  • Traefik → Node: fast (a few seconds)
• From Node’s perspective, it receives the entire body quickly, so:
  • My Busboy/B2 logic sees a short “upload” and emits all Socket.IO upload-progress events 0 → 100% in a burst at the end.
  • On the frontend, there is no visible progress during the real upload; all progress logs arrive after the upload completes.

So:

• Without upload-stream:

  • ✅ True streaming + real-time progress
  • ❌ 408 timeout after ~5 minutes from Traefik

• With upload-stream:

  • ✅ No 408 timeout
  • ❌ Progress only updates at the end (because backend only sees the body after buffering)

What I Tried

• Increasing respondingTimeouts.* on both http and https entrypoints to 1200s did not change the ~5 minute behavior when streaming a large request body.
• Attempting --entrypoints.https.transport.readTimeout=1200s / writeTimeout=1200s etc. caused Traefik to fail startup (invalid flags for v3.6).
• Verified that there is no additional reverse proxy or LB in front (DNS points directly to the Hetzner VM running coolify-proxy).

Question

In Traefik v3.6:

• Is there a specific setting that controls how long an entrypoint will spend reading a large request body from the client (HTTP/2 POST) before returning 408 Request Timeout?
• How can I increase this limit to allow uploads that take 6–10 minutes, without enabling buffering middleware (i.e., while preserving true streaming behavior to the backend)?
• Or is using the buffering middleware (like my upload-stream config) currently the only supported way to avoid this client body read timeout for large uploads?

[djsisson]

im not sure of the solution, but afaik traefik does not have a 5 minute timeout

it has a 60 second read timeout
https://doc.traefik.io/traefik/reference/install-configuration/configuration-options/#opt-entrypoints-name-transport-respondingtimeouts-readtimeout
this is usually needed when uploading, but the default is 60second not 5 minute

there is no forwarding timeout to the backend that would close after 5 minutes

if the upload to traefik takes the same time but only fails when streaming to the backend, then the issue is not client->traefik but traefik->backend, since the request to traefik takes the same amount of time.

my suspicion is

if the backend closes the connection after 5 minutes, this cancels the context in traefik, so it would then respond with a 408, the origin status is not set as it didn't respond but closed the connection.

as a test, can you bypass the proxy, and directly map your backend to a port, and try and upload directly to your backend, if it works, then the issue is somewhere in either traefik or go net/http (i think there might be a difference in http 1.1 vs http 2), if it still fails then you know the timeout is in node/backend