Nginx Config Generator

Nginx(pronounced “engine-x”) is a high-performance web server and reverse proxy used to serve static content, route requests to application servers, terminate TLS connections, load balance traffic, and proxy HTTP and WebSocket connections. It is one of the most widely deployed web servers on the internet.

Developers and operators commonly use Nginx for:

• Reverse proxying to application servers
• Serving static websites and single-page apps
• APIs and API gateways
• Load balancing across multiple backends
• SSL / TLS termination
• WebSocket proxying
• Caching and compression

An Nginx configuration is a text file made of directives organized into contexts (blocks). The main file is usually /etc/nginx/nginx.conf, which contains an http context; inside it, one or more server blocks define virtual hosts, and location blocks match request paths. A directive like proxy_pass is only valid inside certain contexts — putting it in the wrong place produces an error, which is why this Nginx configuration generator keeps directives such as limit_req_zone and upstream in the http context automatically.

1. Pick a deployment preset — Basic Reverse Proxy, Next.js, ASP.NET Core, Node.js, React SPA, Static Website, Docker, WebSocket, API, or HTTPS Reverse Proxy.
2. Choose an output mode: a standalone server block for sites-available, or a full nginx.conf.
3. Enter your domain and one or more server names.
4. Set the upstream (host and port, a Unix socket, or an upstream group), or a document root for static sites.
5. Toggle features: HTTPS/SSL, WebSocket, security headers, gzip, caching, rate limiting, and more.
6. Copy the generated configuration or download nginx.conf, then validate it with nginx -t on your server.

A reverse proxy sits between the internet and your application:

Browser
   ↓
https://example.com
   ↓
Nginx  (public HTTP/HTTPS, TLS, headers)
   ↓
http://127.0.0.1:3000  (your app)

The core of an Nginx reverse proxy is a location block with proxy_pass and the forwarding headers that tell your application about the original request:

location / {
    proxy_pass http://127.0.0.1:3000;

    proxy_http_version 1.1;
    proxy_set_header Host              $host;
    proxy_set_header X-Real-IP         $remote_addr;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

• Host preserves the original hostname so your app generates correct links and routing.
• X-Real-IP and X-Forwarded-Forpass the client’s IP address, which Nginx would otherwise mask.
• X-Forwarded-Proto tells the app whether the original request was HTTP or HTTPS — important for redirects and secure cookies.
• proxy_http_version 1.1 enables keep-alive and is required for WebSocket upgrades.

A minimal Nginx reverse proxy server block — the default this generator produces:

server {
    listen 80;
    listen [::]:80;

    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;

        proxy_http_version 1.1;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

The typical self-hosted Next.js architecture:

Internet → Nginx → Next.js server → Port 3000

Nginx handles public HTTP/HTTPS traffic and forwards to the Next.js server, which runs internally and performs server-side rendering. Configure it as a reverse proxy — not as a static React SPA with an index.html fallback, which would break SSR and API routes. Deployment specifics vary depending on whether Next.js is self-hosted, containerized, or deployed on a managed platform. You can optionally enable WebSocket support and cache the /_next/static assets rather than blindly caching every route.

Internet → Nginx → Kestrel → ASP.NET Core

ASP.NET Core apps run behind the Kestrel server, commonly on port 5000. Nginx receives public traffic and reverse proxies to Kestrel, and HTTPS can terminate at Nginx. Configure the Forwarded Headers middleware in your app so it correctly detects the original scheme, host, and client IP:

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor
                     | ForwardedHeaders.XForwardedProto
});

Without this, features that depend on the request scheme (such as generating https:// URLs or issuing secure cookies) can misbehave behind the proxy.

Run your Node.js/Express app on a local port and let Nginx handle the public connection, TLS, and headers:

location / {
    proxy_pass http://127.0.0.1:3000;

    proxy_http_version 1.1;
    proxy_set_header Host              $host;
    proxy_set_header X-Real-IP         $remote_addr;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

If your app trusts proxy headers (for example app.set('trust proxy', 1) in Express), it will read the correct client IP and protocol from the forwarded headers.

Internet → Nginx → Docker network → Application container

When Nginx and your application run in separate containers, 127.0.0.1 inside the Nginx container refers to the Nginx container itself — not your app. Use the Docker Compose service name and container port as the upstream:

location / {
    proxy_pass http://web:3000;   # "web" = docker compose service name
    ...
}

Here webresolves via Docker’s internal DNS to the app container on the shared network. Only use 127.0.0.1 when Nginx runs on the host (or in the same network namespace) as the app.

WebSocket connections start as HTTP requests that are then upgraded. To proxy them, Nginx needs HTTP/1.1 and the upgrade headers:

proxy_http_version 1.1;
proxy_set_header Upgrade    $http_upgrade;
proxy_set_header Connection "upgrade";

Without these, the upgrade handshake fails and the connection falls back or drops. WebSocket proxying is used for real-time dashboards, chat applications, notifications, and live updates. Long-lived connections often need a higher proxy_read_timeout (for example 3600s) so idle sockets are not closed early.

Client (HTTPS) → Nginx (TLS termination) → App (HTTP)

With HTTPS enabled, Nginx listens on 443, presents your certificate, and forwards decrypted requests to your app. A typical SSL server block looks like this:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://127.0.0.1:3000;
        # ...forwarding headers
    }
}

Certificates can be obtained free from a certificate authority such as Let’s Encrypt. This tool references certificate paths but does not create or install certificates. Pair the HTTPS block with an HTTP→HTTPS redirect so plain-HTTP visitors are upgraded:

server {
    listen 80;
    listen [::]:80;

    server_name example.com;

    return 301 https://$host$request_uri;
}

Security headers harden responses against common attacks. This generator can add conservative defaults:

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options        "SAMEORIGIN" always;
add_header Referrer-Policy        "strict-origin-when-cross-origin" always;

A Content Security Policy is powerful but application-specific — a strict CSP can block inline scripts, styles, and third-party resources — so it is off by default and left for you to configure. If you enable HTTPS, you can also add an HSTS header, but only once HTTPS works reliably across your domain and subdomains.

Before applying any configuration, test its syntax against your installed Nginx:

sudo nginx -t

This checks the configuration against your Nginx version and enabled modules and reports the first error it finds. A browser-based generator cannot do this — it does not know your exact build — so nginx -t remains the source of truth.

Only after the test passes, reload Nginx to apply changes:

sudo systemctl reload nginx

reload gracefully applies the new configuration without dropping active connections, whereas nginx -t merely validates. The recommended workflow is:

Generate → Save config → nginx -t → Fix errors → Reload

Never reload a configuration you have not tested — a broken config can take your site offline.

On Ubuntu/Debian-style installs, site configs live in sites-available and are enabled via a symlink in sites-enabled:

sudo nano /etc/nginx/sites-available/example.com
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Directory layouts vary by distribution. Some systems use /etc/nginx/conf.d/*.conf instead of the sites-available/sites-enabled pattern, so check how your Nginx package is organized.

This generator offers two output modes. A Server Block contains just the server { ... } block(s) — ideal for dropping into /etc/nginx/sites-available/, which is already inside the http context. A Full nginx.conf is a complete standalone file with the events and http wrappers. Some directives — upstream, limit_req_zone, and proxy_cache_path — must live in the http context, so in server-block mode they are shown separately with a note explaining where they belong.

Yes. Your configuration is generated locally in your browser. No account or server-side processing is required, and nothing you type — domain names, upstream URLs, certificate paths — is uploaded, logged, stored, or placed in the URL. The download is produced on your device.

What is Nginx used for?

Nginx is a high-performance web server and reverse proxy. It serves static files, routes requests to application servers, terminates TLS/SSL, load balances traffic, proxies WebSocket connections, and caches responses — often sitting in front of Node.js, Next.js, ASP.NET Core, and other app servers.

What is an Nginx reverse proxy?

A reverse proxy accepts client requests on a public address and forwards them to a backend application running on an internal port. Nginx handles the public HTTP/HTTPS connection, TLS termination, and headers, then passes the request to your app via proxy_pass — for example http://127.0.0.1:3000.

How do I configure Nginx as a reverse proxy?

Add a server block that listens on port 80 (and 443 for HTTPS), set server_name to your domain, and add a location / block with proxy_pass pointing at your app, plus the standard forwarding headers (Host, X-Real-IP, X-Forwarded-For, X-Forwarded-Proto). This generator builds that block for you.

How do I proxy Nginx to Node.js?

Run your Node.js app on a local port (commonly 3000), then proxy_pass http://127.0.0.1:3000 from a location / block with proxy_http_version 1.1 and the forwarding headers. Pick the Node.js preset above to generate it.

How do I proxy Nginx to ASP.NET Core?

ASP.NET Core runs behind the Kestrel server, usually on port 5000. Reverse proxy to http://127.0.0.1:5000 and configure the Forwarded Headers middleware in your app so it detects the original scheme, host, and client IP. The ASP.NET Core preset sets sensible defaults.

How do I configure Nginx for Next.js?

For a self-hosted Next.js app, reverse proxy to the Next.js server (typically http://127.0.0.1:3000) — do not treat it as a static React SPA, because Next.js handles server-side rendering. Optionally enable WebSocket support and static-asset caching.

How do I configure Nginx with Docker?

If Nginx runs inside a container, 127.0.0.1 points at the Nginx container itself, not your app. Use the Docker Compose service name (for example http://web:3000) or the container's network address as the proxy target.

How do I enable WebSockets in Nginx?

Set proxy_http_version 1.1 and forward the upgrade headers: proxy_set_header Upgrade $http_upgrade; and proxy_set_header Connection "upgrade";. Enable the WebSocket option above to add them, and consider a higher proxy_read_timeout for long-lived connections.

How do I configure HTTPS in Nginx?

Listen on 443 ssl, set ssl_certificate and ssl_certificate_key to your certificate and key paths, and restrict ssl_protocols to TLSv1.2 and TLSv1.3. Enable HTTPS above to generate the SSL server block, plus an optional HTTP→HTTPS redirect.

How do I test an Nginx configuration?

Run sudo nginx -t. It checks the configuration against your installed Nginx version and enabled modules and reports the first syntax or context error. Only reload after it reports the test is successful.

How do I reload Nginx?

After nginx -t passes, run sudo systemctl reload nginx (or sudo nginx -s reload). Reload applies the new configuration gracefully without dropping active connections, unlike a full restart.

What causes a 502 Bad Gateway in Nginx?

A 502 usually means Nginx could not reach the upstream: the app is not running, the upstream host or port is wrong, a Docker container is on a different network, or a firewall is blocking the connection. Check that your app is listening on the address in proxy_pass.

How do I increase the Nginx upload limit?

Set client_max_body_size to a larger value, for example client_max_body_size 50m;. The default is small (1m), which causes 413 Request Entity Too Large errors on bigger uploads. Set it in the Advanced options above.

Does this tool validate Nginx configuration?

It performs structural input validation (domains, ports, upstreams, IPs, paths, sizes) so the output is well-formed, but it does not run Nginx. It cannot replace nginx -t, which validates against your specific Nginx build and modules. Always run nginx -t on your server before reloading.