Nginx Config Generator

The Performance Tradeoffs Behind Each Toggle

Most of the toggles in this generator exist because they change measurable request-time behavior, not just correctness. Enabling gzip trades a small amount of CPU time compressing responses for a large reduction in bytes transferred — a meaningful win for text-heavy JSON APIs and JS bundles, but wasted (and sometimes counterproductive) on already-compressed assets like images, so the generated config scopes gzip_types to text-based MIME types rather than compressing everything. Enabling SSL with HTTP/2 lets the browser multiplex many requests over a single TCP connection instead of opening several, which matters most on pages with dozens of small assets and comparatively less on an API that returns one JSON payload per request.

Rate limiting has the opposite performance profile: it protects your upstream from being overwhelmed, but a limit_req zone sized too small will start rejecting legitimate traffic during ordinary spikes — a deploy that triggers a burst of health checks, or a marketing push that doubles normal traffic for an hour. The generator's default burst multiplier gives some headroom above the steady-state rate, but at real production scale you should load-test the generated limits against your actual traffic shape before relying on them, since a rate limit that's fine in isolation can still be the first thing that breaks under a legitimate spike.

What This Tool Actually Generates

This is a client-side Nginx server-block generator: you describe your setup — a domain, an upstream backend address, and which capabilities you need — and it assembles a complete, ready-to-deploy configuration file rather than a fragment you have to stitch together yourself. It exists because Nginx is the reverse proxy sitting in front of most non-trivial deployments: Node.js, Python, Ruby, Go, and Java applications behind it, Kubernetes ingress controllers built on it, and countless VPS deployments using it as the first thing that terminates a client connection. Getting that first layer wrong is disproportionately costly, since it's the layer where SSL is terminated, security headers are set, and the first line of abuse protection lives.

How the Generator Assembles a Valid Config

Internally, the tool doesn't fill in one big template — it composes the config from independent blocks keyed to each toggle, then places them according to Nginx's context rules. The domain field sets server_name; the upstream field sets proxy_pass and the associated proxy_set_header lines for forwarding the real client IP and host. Each toggle you enable — SSL, gzip, rate limiting, security headers, WebSocket support, www redirect — injects its block only where Nginx's context hierarchy allows it: limit_req_zone is emitted at the http-level scope rather than inside the server block because Nginx rejects it anywhere else, while compression and security-header directives are placed before the location block so they apply to every route. This ordering is why the output passes nginx -t unmodified instead of requiring manual rearrangement.

Why a Plain proxy_pass Block Breaks WebSocket Connections

WebSocket connections start life as an ordinary HTTP request and then ask the server to switch protocols mid-connection, using the Upgrade and Connection headers to signal that intent. A default Nginx reverse-proxy block has no reason to forward those two headers — most proxied traffic is plain HTTP with no protocol upgrade in play — so a config copied from a generic REST-API example silently drops them. The practical effect is that ordinary HTTP routes through such a config work perfectly, since nothing about them depends on the missing headers, while any WebSocket-based feature — a chat widget, a live dashboard, a build-log streamer — fails to establish a connection at all, and the client library typically reports a vague, generic connection error rather than anything pointing at the proxy layer. Because the symptom shows up entirely on the client side and the failure produces no distinctive server-side log line, it's easy to burn time checking application code, load balancer health checks, or firewall rules before the actual one-line cause — an Nginx location block missing proxy_set_header Upgrade $http_upgrade; and proxy_set_header Connection "upgrade"; — gets checked. Toggling WebSocket proxy support in this generator adds exactly those two header directives up front, closing off a failure mode that's easy to omit and disproportionately time-consuming to diagnose after the fact.

Frequently Asked Questions