Part 1 · 1 chapters · ~8 min

Reverse Proxies and Web Servers

Why a proxy sits in front of almost every app, Nginx, Caddy, HAProxy, Envoy and Traefik compared, buffering slow clients for worker-based servers, TLS termination, and the cloud load balancer plus in-cluster ingress pattern.

Nginx, Caddy, HAProxy, Envoy

code

# nginx in front of a worker-based app server (Gunicorn, Puma)
upstream app { server 127.0.0.1:8000; keepalive 32; }
server {
  listen 443 ssl http2;
  ssl_certificate /etc/ssl/bank.pem; ssl_certificate_key /etc/ssl/bank.key;
  client_max_body_size 10m;
  location /static/ { root /srv; expires 1y; add_header Cache-Control "public, immutable"; }
  location / {
    proxy_pass http://app;
    proxy_http_version 1.1; proxy_set_header Connection "";
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme;
    proxy_read_timeout 30s;
    proxy_request_buffering on;          # read slow uploads fully before tying up a worker
  }
}

Behind a proxy, the app must trust forwarding headers only from the proxy (Express trust proxy, Django SECURE_PROXY_SSL_HEADER, Rails config.action_dispatch.trusted_proxies), or clients can spoof their IP and scheme.

REVERSE PROXIES

what sits in front of the app process, and why

swipe the figure sideways, or tap expand for full screen

1/6

why a proxy at all

A proxy in front of the app terminates TLS, buffers slow clients so app workers are not tied up reading slowly uploaded bodies, serves static files, enforces limits and balances across instances.

TLS, slow clients, static files, limits, balancingprotects scarce app workers