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
History tool ini
Data terakhir yang pernah kamu isi di tool ini, tersimpan hanya di device/browser ini.
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.