nginx Reverse Proxy Wizard
Step through domain, upstream, TLS and extras to get a reverse proxy server block.
What domain points here?
Where should the traffic go?
How is TLS terminated?
Anything the app needs?
The wizard writes a reverse proxy server block: upstream pool, WebSocket map, TLS, headers and a dotfile guard. Check it with nginx -t before reloading.
Config
Learn
History for this tool
The most recent data you entered in this tool, stored only in this browser.
Save what you type here, in this browser? Your work would go into this browser's local storage, so a refresh or a trip to another tool does not wipe it. You also get a short list of previous entries under the form, each one restorable with a click. Nothing is ever uploaded, and there is no account.
Being straight about the trade-off: anything kept there can be read by anyone who can use this browser profile, and by any script that later runs on this site. A tool page can hold a private key, a password or a signed token. Saving is convenient; it is not private.
About this tool
A guided way to write a reverse proxy server block. Step through the domain, the upstream pool (one or more hosts, a balancing method and keepalive), TLS with a plain-HTTP redirect, and the extras an app usually needs — WebSocket upgrade, streaming, security headers and upload size. The config is built live beside the steps and can be copied or downloaded.Questions
- Why is there an upstream block instead of a plain proxy_pass?
- An upstream block lets nginx pool several backends, apply a balancing method, and reuse connections with keepalive. A bare proxy_pass to one host opens a new connection per request. The wizard always writes an upstream so the config can grow without being rewritten.
- Why does the WebSocket option add a map block?
- nginx cannot choose between the upgrade and close values inline, and the Connection header has to match the request. The map block turns $http_upgrade into $connection_upgrade once, and the location uses it. Without the map, the header would be wrong for either WebSockets or ordinary requests.
- Does the app see the real client IP?
- The location forwards X-Real-IP, X-Forwarded-For and X-Forwarded-Proto, so the app can read the original client and scheme. Make sure the app trusts those headers only from nginx, or a client could spoof them.
- Why skip keepalive when the target is https?
- Keepalive to an upstream needs HTTP/1.1 over a plain connection to reuse cleanly. An https target means a TLS handshake per connection, so the wizard leaves keepalive out and says so rather than pretending it helps.