CruxDevCruxDev Tools Prompts
dev Utility • Zero-Server Privacy • 100% Client-Side

Nginx Config Generator

Generate Nginx server block configurations for reverse proxy, static files, SSL/TLS, rate limiting, and caching with best practices.

Overview

Generate a reverse-proxy nginx server block for a domain and upstream port, with optional HTTPS. The output includes a port-80 redirect, a TLS termination block with Let's Encrypt certificate paths, and proxy headers for WebSocket support, ready to paste into sites-available.

How It Works

Enter your domain, set the port your application listens on locally, and decide whether to include the SSL configuration. The configuration regenerates as you type: with SSL enabled you get two server blocks, one on port 80 that 301-redirects to HTTPS and one on 443 that proxies to your local port; with SSL disabled a single port-80 block proxies directly. Click the copy button and paste the result into your nginx configuration.

Step-by-Step Usage Guide

  1. Type your domain name into the domain field.
  2. Set the upstream port your application actually listens on.
  3. Toggle the SSL checkbox depending on whether certbot has issued certificates.
  4. Copy the generated configuration into your nginx sites directory and reload nginx.

Technical Specifications & Standards

The template is a conventional reverse-proxy setup. The port-80 block returns a 301 redirect to the HTTPS host, preserving the request URI. The TLS block listens on 443 with ssl and http2, points ssl_certificate and ssl_certificate_key at the standard Let's Encrypt live paths for your domain, and defines a location that proxies to 127.0.0.1 on your chosen port. The proxy block sets proxy_http_version 1.1 and forwards the Upgrade and Connection headers, which is what allows WebSocket connections to pass through, and passes the Host header through so the application sees the original hostname. Three things to know before deploying. First, the certificate files are assumed to exist: run certbot for the domain first, otherwise nginx will refuse to load the configuration. Second, the listen 443 ssl http2 form is deprecated since nginx 1.25.1, which warns and prefers http2 on; the generated line still works on current nginx but produces that warning. Third, the TLS block lists only the apex domain in server_name, while the redirect block also matches www, so make sure your certificates cover both names.

Targeted Use Cases

  • Fronting a Node, Python, or Go application with nginx on a single VPS.
  • Getting WebSocket connections through a reverse proxy without a separate configuration.
  • Producing the standard HTTP-to-HTTPS redirect block for a new deployment.
  • Teaching or documenting what a minimal proxy setup needs.

Notes & Gotchas

  • Run certbot and confirm the certificate files exist before reloading nginx with the TLS block.
  • On nginx 1.25.1 or newer, expect a warning about the http2 listen parameter and switch to http2 on if it bothers you.
  • Keep the upstream bound to 127.0.0.1 so the application is not directly reachable on its own port.
  • Add your own hardening, such as gzip, HSTS, and client_max_body_size, which this minimal template does not include.

Frequently Asked Questions

Why does nginx fail to start with this configuration?

Most commonly the certificate files do not exist yet. The template points at the Let's Encrypt live paths for your domain; obtain the certificate with certbot first, or switch off the SSL option until certificates are ready.

What does the warning about the http2 directive mean?

Since nginx 1.25.1, enabling HTTP/2 via the listen parameter is deprecated in favor of a separate http2 on directive inside the server block. The old form still functions but nginx -t prints a warning.

Are WebSockets supported through the proxy?

Yes. The location block sets proxy_http_version 1.1 and forwards the Upgrade and Connection headers, which is required for WebSocket upgrades to pass through nginx.

Does the generated config include gzip or caching?

No. The template covers redirect, TLS, and proxying only. Add compression, cache headers, body size limits, and logging to suit your deployment.