Reverse Proxy & Load Balancing with Nginx

# compose.yaml
services:
  app1:
    image: hashicorp/http-echo:1.0
    command: ["-listen=:5678", "-text=backend one"]
  app2:
    image: hashicorp/http-echo:1.0
    command: ["-listen=:5678", "-text=backend two"]
  proxy:
    image: nginx:1.27-alpine
    ports: ["8080:80"]
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
    depends_on: [app1, app2]

# nginx.conf
upstream backend {
    server app1:5678 max_fails=2 fail_timeout=10s;
    server app2:5678 max_fails=2 fail_timeout=10s;
}
 
server {
    listen 80;
 
    location / {
        proxy_pass http://backend;
 
        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;
 
        proxy_connect_timeout 2s;
        proxy_read_timeout    5s;
    }
}

docker compose up -d
for i in $(seq 1 6); do curl -s localhost:8080; echo; done

You should see both backends. Nginx round-robins by default.

Once a proxy is in front, the application no longer sees the client — it sees the proxy. Without these headers:

• Every log line records the proxy's IP, so rate limiting and audit trails are useless.
• Redirects are built against the proxy's hostname.
• The application thinks the request was HTTP, and redirect loops to HTTPS.

X-Forwarded-For appends rather than replaces, so a chain of proxies is preserved. Your application must be configured to trust it — accepting it from anywhere lets a client forge their own IP.

docker compose stop app1
for i in $(seq 1 6); do curl -s localhost:8080; echo; done

Every response now comes from app2. max_fails=2 fail_timeout=10s marks a backend unavailable after two failures and retries it ten seconds later — a passive health check, driven by real traffic rather than a separate probe.

docker compose start app1

docker compose stop app1 app2
curl -s -o /dev/null -w '%{http_code}\n' localhost:8080     # 502

502 — the proxy could not get a usable response. Nothing was listening, or the connection was refused. The fault is behind the proxy.

For a 504, make a backend slow: with proxy_read_timeout 5s, a backend that takes ten seconds produces a gateway timeout. The backend is alive and simply too slow — a completely different investigation.

That distinction is exactly the one you will need for a Kubernetes Ingress, which is the same pattern with the proxy managed for you.

docker compose logs proxy | tail -5

The proxy's own log names the upstream it tried and why it failed. It is the first place to look, and the last place people look.