No. Every config block is generated by plain JavaScript in your browser. Domains, backend IPs and certificate names never leave your machine — a full proxy config is a map of your infrastructure.
Free Server Tool — 100% In-Browser
nginx Reverse-Proxy Builder
Generate production-ready nginx configs: load balancing across your app servers, TLS with security headers, page caching and 1-second microcaching, Memcached and Redis object caching, gzip and static asset tuning — plus a watchdog script that watches upstreams, cache hit ratio and certificate expiry. Built entirely in your browser.
The Proxy Config Everyone Copies, Then Gets Wrong
nginx reverse-proxy configs fail in specific, repeatable ways: no
Connection header reset so upstream keepalive never
engages, caching that serves logged-in users someone else's page,
rate limiting missing on exactly the endpoint bots hammer, real
client IPs lost behind the proxy so your logs and fail2ban see
127.0.0.1 forever. This builder emits the config with those decisions
already made, and every block is annotated with where it belongs —
http block, server block or location.
Every byte is produced by JavaScript in your browser. Domains, backend IPs and certificate names are never uploaded.
How It Works
1. Name the Site
Domain, upstream pool name, and your backend servers with optional weights and a backup.
2. Pick the Layers
TLS + headers, load-balancing method, page caching, Memcached or Redis object caching.
3. Tune It
gzip, static assets, keepalive, buffering and timeouts from the Performance tab.
4. Deploy & Watch
nginx -t, reload, then cron the watchdog script to watch upstreams, cache ratio and cert expiry.
nginx Reverse-Proxy Builder
Basics (apply to every block)
Upstream & load-balancing options
TLS & hardening options
Page caching options
The output puts proxy_cache_path in the http block and the cache directives in your proxy location — the comments show exactly which is which. Purging a single URL needs the proxy_cache_purge module; without it, the output shows the supported alternatives.
Memcached / Redis object caching
Rule of thumb the output explains: Memcached is the classic page-cache offload — your app writes rendered pages to it, nginx serves them without ever touching the app. Redis is usually better owned by the app itself (sessions, objects, queues); the redis2 module route is for when you want nginx to talk to Redis directly.
Performance tuning
Ops & monitor
Generates three things: the deploy/reload command sequence, a log_format that records upstream response times and cache status (the two numbers you need for tuning), and a zero-dependency watchdog script — nginx -t, upstream reachability, cache hit ratio from the last 1000 log lines, certificate expiry, and connection counts — cron it every 5 minutes.
Everything above runs in JavaScript in your browser. Domains, backend IPs and certificate names you enter are never uploaded — a full proxy config is a map of your infrastructure, and it stays on your machine.
Proxy Defaults, Explained
| Decision | Default in the output | Why |
|---|---|---|
| Upstream keepalive | keepalive 32 + Connection header cleared | Without the empty Connection header nginx opens a fresh TCP connection per request and the keepalive pool is dead weight. |
| Load balancing | least_conn | Round-robin punishes fast+slow backend mixes; fewest-connections keeps slow uploads from piling onto one server. |
| Health checks | Passive: max_fails 2, fail_timeout 10s | Open-source nginx has no active checks — passive marking is built in, and the watchdog script adds the alerting layer. |
| Caching for dynamic apps | 1-second microcache | A 1s window absorbs stampedes and stays effectively fresh — even logged-out WordPress or forums can survive front-page Reddit traffic. |
| Cache bypass | Cookies, Authorization, POST never cached | Serving one user another user's page is the classic cache catastrophe — the generated map refuses to cache them. |
| Stale serving | proxy_cache_use_stale error timeout updating | A dead backend returns the last good page instead of a 502 during deploys and restarts. |
| Rate limiting | 10 r/s, burst 20, nodelay | Kills brute-force and scrapers without queueing legitimate users. |
| Real IPs | X-Real-IP + X-Forwarded-For set, real_ip optional | Your app, logs and fail2ban need the actual client, not 127.0.0.1. |
| Body size | 16m | The nginx 1m default rejects modern uploads with a confusing 413. |
| Memcached vs Redis | Memcached for page offload, Redis at app level | memcached_pass serves stored pages without touching the app; Redis shines for sessions, objects and queues owned by app code. |
nginx Reverse-Proxy Builder — FAQ
Are my domains or backend IPs uploaded anywhere?
Why least_conn instead of round-robin?
Round-robin spreads requests evenly, but requests are not equal: one slow upload can occupy a backend for a minute. least_conn sends each new request to the server with the fewest active connections, so slow requests stop stacking on one box. The dropdown keeps round-robin for identical backends, ip_hash for session stickiness, and a cookie hash when you control the app.
Why does upstream keepalive need the empty Connection header?
By default nginx sends Connection: close to the upstream, which forces the backend to close the connection after every single request — the keepalive pool then does nothing. The generated location sets proxy_http_version 1.1 and proxy_set_header Connection "", which is the only combination that actually reuses backend connections.
What is 1-second microcaching?
Caching dynamic pages feels risky because content goes stale — so cache them for exactly one second. A traffic spike of 500 requests in one second collapses to a single backend request; to any individual user the page is at most one second old. It is the highest-value, lowest-risk caching there is for WordPress, forums, dashboards and APIs with anonymous traffic. The bypass rules still keep cookies, auth and POST uncached.
Memcached or Redis — which do I pick?
They answer different questions. Memcached is a slab of memory for whole pages: your app writes a rendered page under a key, and nginx serves it with memcached_pass without ever asking the app — thousands of requests per second from one core. Redis is a data structure server your app should own: sessions, counters, queues, invalidation logic. If you are running WordPress, the object-cache plugin with Redis (or Memcached) is the app-level win; the page-cache offload on top is the nginx-level win. The Object Cache tab generates both paths so you can layer them.
Can I purge a single cached URL?
Open-source nginx has no built-in purge. The generated config comments where the proxy_cache_purge module (ngx_cache_purge) hooks in if you install it; the supported alternatives without extra modules are the microcache approach (wait out the 1s), short TTLs, or purging by key path — delete the cache directory entry and let proxy_cache_lock refill it once.
How do I know the cache is actually working?
Two ways, both in the output. The X-Cache-Status response header shows HIT, MISS, BYPASS or EXPIRED per request — curl it once to see. And the watchdog script greps the last 1000 access-log lines for the header value, computes your hit ratio, and alerts when it drops: a falling ratio usually means your bypass map is matching too much, or an app is sending no-cache headers you forgot about.
What does the watchdog script check?
A single bash file with zero dependencies beyond nginx itself and curl: config validity (nginx -t), each upstream answering, cache hit ratio from the log, certificate expiry under 14 days (openssl), and worker connection saturation. It prints a plain report and exits non-zero when something needs attention — cron it every 5 minutes and pipe it to your alerting. It is the safety net that works before you have Prometheus.