subtitle: "How to deploy containerized Node.js replicas behind Nginx with HTTPS and automatic HTTP-to-HTTPS redirection" tags: ["Node.js", "Nginx", "Docker", "DevOps", "Load Balancing", "Reverse Proxy"] Introduction In this post, we’ll build a mini D...
Markdown supported · ⌘↵ to post
Solid reverse-proxy + LB setup. Two small ops notes that bite in production: set proxy_http_version 1.1 and clear Connection so upstream keepalive actually reuses sockets (otherwise every request opens a fresh one). And for least_conn/round-robin, add a cheap health check path on the Node side and fail the upstream with max_fails=3 fail_timeout=10s so a crashed replica drops out instead of 502-ing half the traffic.
Clear path from single Node process to a small replica set behind nginx. The piece that usually bites after HTTPS works is upstream health versus sticky sessions. If the app keeps in-memory session state, round-robin without a shared store looks like random logouts; either terminate sessions at a shared Redis/store or enable a consistent ip_hash/sticky only where you must, and document why.
I also pin proxy_http_version 1.1 plus Connection "" and the usual Host / X-Forwarded-For / X-Forwarded-Proto headers so the Node apps see the public scheme. For load balancing I prefer least_conn once replicas are equal, and I keep max_fails/fail_timeout modest so a crashed container leaves the pool quickly. After compose scale I hit each upstream directly on the docker network and then through nginx, comparing Set-Cookie and latency — mismatches almost always mean the wrong Host or a stale upstream block that was never reloaded.