Nginx Config Generator

WHAT IT DOES

Including the lines that do not go in the server block.

Choose a preset, name the domain, and point it at an upstream or a directory. The output is a complete server block, plus the directives that have to live in the http block instead — the WebSocket connection map and the rate-limit zone, both of which stop nginx from starting if they are pasted in the wrong place. Three presets set the toggles; changing any of them makes the configuration yours, and the preset stops claiming otherwise.

Why use it?

Common Nginx setups need related directives in the correct contexts. A starting configuration helps assemble those pieces, while leaving host-specific review and validation to you.

How to use this tool

Choose the configuration preset and enter the actual domain, paths, and upstream settings it requires.
Generate the configuration and read its comments, including any separately labelled http-context sections.
Place the sections in the appropriate configuration files on a test host and run nginx -t before reloading. Check backend availability separately.

Details and limitations

Directives that only exist in the http context are written into their own labelled section above the server blocks, with a comment saying where they go.
WebSocket support writes proxy_http_version 1.1 and the Upgrade and Connection headers together with the map that defines $connection_upgrade, because the headers alone reference a variable that does not exist.
Security headers stay at server level. An add_header inside a location replaces every header inherited from the server rather than adding to them, which is how headers disappear from exactly the responses that needed them.
Redirecting HTTP keeps serving /.well-known/acme-challenge over plain HTTP, since redirecting the challenge is how certificate renewal quietly stops working.
HSTS without TLS is refused rather than written, and when it is written the note says it lasts a year: a browser that has seen it will not fall back to plain HTTP for that long.
Every generated file is checked by tests for balanced braces and terminated directives, and each preset is generated with every option turned on to prove it still parses.

Verify the assembled configuration

Choose a reverse proxy preset, use example.com as the domain, and point it at your own test upstream. If WebSocket support is enabled, place the generated map in the http context.

Expected result

The generated server uses the chosen upstream. Run nginx -t on the assembled configuration before reloading; syntax validity does not establish backend availability.

Nginx Config questions

Why are some lines in a separate section at the top?

Because nginx will not accept them anywhere else. map and limit_req_zone are only valid in the http context, so they go in nginx.conf inside http { }, or in a file included from there. Pasted inside a server block they produce a startup error rather than a warning.

Is this configuration ready to deploy?

It is a starting point that parses, not a deployment. The certificate paths assume certbot's layout, the upstream is whatever you typed, and only you know what your application needs. Run nginx -t before reloading: a configuration that fails the test leaves the running one alone, and one that passes and is wrong does not.

Why does it write http2 on rather than listen 443 ssl http2?

Because that is the current directive. nginx 1.25.1 replaced the http2 parameter on listen with its own http2 directive, and the old form is deprecated. On an older nginx, move http2 back onto the listen line.