Handling WebSocket connection dropouts in Nginx reverse proxy with scaled Docker Compose services

Docker Engine Compose
1

Hello Docker community,

We are currently re-architecting and containerizing the web platform and live kiosk services for our visitor management solution

The architecture uses Docker Compose to orchestrate an Nginx reverse proxy, a Node.js API backend with WebSockets for real-time badge scanning/access updates, and a Redis cache for active session state.

While HTTP REST endpoints route seamlessly, we are encountering intermittent WebSocket disconnects (1006 connection closed abnormally) during container health-check cycles when scaling backend replicas (docker compose up --scale backend=3).

A couple of questions regarding Docker internal networking & WebSocket upstreaming:

  1. Since Docker Compose internal DNS resolves service names across replicas via round-robin, does the initial HTTP 101 WebSocket upgrade handoff require IP-hash stickiness in Nginx to prevent dropped handshakes across container instances?
  2. Are there recommended proxy_read_timeout and TCP keepalive settings within Docker bridge networks to avoid idle socket drops between Nginx and the backend containers?

Here is a snippet of our compose definition:

services:
  reverse-proxy:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    depends_on:
      - backend
    networks:
      - access-network

  backend:
    build: .
    environment:
      - REDIS_HOST=redis
    networks:
      - access-network

Appreciate any advice from those running real-time WebSocket stacks on Docker Compose!

2

As far as I know will the WebSocket upgrade continue to use the same connection, so the same backend service.

Usually timeout 0 disables the timeout. And the application should recreate the connection if the WebSocket drops.