Nginx Config Generator

Nginx Config Generator — Generate Server Block Configs for Any Setup

Nginx is one of the most widely deployed web servers and reverse proxies in the world — it powers everything from static file hosting and single-page applications to high-traffic API gateways and load balancers. Its configuration language is built around server blocks (Nginx's equivalent of Apache virtual hosts), where you define precisely how incoming requests for a domain, port, and URL path are handled. Nginx configuration is powerful but specific: the order of directives matters, location block matching follows a defined precedence, and mistakes can silently serve incorrect content, break SSL, or introduce performance regressions.

This generator produces a clean, correctly structured Nginx server block based on your parameters: domain, document root, server type, SSL configuration, gzip, security headers, and cache settings. The output is a readable template you can understand and adapt — not an opaque snippet from a forum that you're guessing at.

Static Sites, PHP, and Reverse Proxy — How the Config Differs

The server block structure changes meaningfully depending on what you're serving:

Static sites and SPAs: Nginx reads files directly from disk. The root directive points to the build output directory. For SPAs with client-side routing (React Router, Vue Router), the critical directive is try_files $uri $uri/ /index.html — it serves the matching static file, or falls back to index.html for any path that doesn't match a file, letting the client-side router handle it. Without this, refreshing a page on a deep route like /dashboard/settings returns a 404 because Nginx can't find a file at that path.

PHP with PHP-FPM: Nginx doesn't execute PHP itself. Requests for .php files get passed to a PHP-FPM process pool via FastCGI. The config includes a location ~ \.php$ block with fastcgi_pass pointing to the FPM socket or TCP address, plus standard FastCGI parameters (SCRIPT_FILENAME, PATH_INFO). A common mistake is missing the SCRIPT_FILENAME parameter — without it, FPM receives the request but doesn't know which file to execute, returning a blank page or 502 error.

Reverse proxy (Node.js, Python, Go): Nginx forwards requests to an application server on a local port. The essential block: proxy_pass http://localhost:3000; with headers Host, X-Real-IP, X-Forwarded-For, and X-Forwarded-Proto. These headers let the application see the original client IP and protocol — critical for logging, rate limiting, and HTTPS detection. Without them, every request appears to come from 127.0.0.1 over HTTP, regardless of the actual client.

SSL Configuration and the HTTP-to-HTTPS Redirect

HTTPS is a baseline requirement for any public-facing site. The standard Nginx SSL setup uses two server blocks: port 80 redirects all HTTP traffic to HTTPS with return 301 https://$host$request_uri, and port 443 handles HTTPS with the certificate and key.

The certificate paths default to standard Let's Encrypt / Certbot locations (/etc/letsencrypt/live/yourdomain.com/fullchain.pem and privkey.pem). Certbot provisions free certificates and — with the --nginx flag — automatically modifies your Nginx config with correct SSL settings. The config includes ssl_protocols TLSv1.2 TLSv1.3 to disable older, insecure TLS versions.

Important: If your site is behind a CDN (Cloudflare, AWS CloudFront) or load balancer that terminates SSL, Nginx sees plain HTTP from the proxy. In this case, the HTTP-to-HTTPS redirect shouldn't live in Nginx — the CDN handles it. Configure Nginx to listen on port 80 and trust the proxy's forwarded headers instead.

Performance Tuning: Compression and Caching

Gzip compression: Compresses text-based responses (HTML, CSS, JavaScript, JSON, XML, SVG) before sending them to the browser — typically 60–80% size reduction. The browser decompresses transparently. For a page with 200KB of HTML and 300KB of JavaScript, gzip reduces the transfer to under 100KB. This directly impacts Largest Contentful Paint and Google's page experience ranking signals.

Browser cache headers: Static assets rarely change between deployments. A long Cache-Control: max-age header (1 year for fingerprinted assets with content hashes in filenames) tells browsers to cache files locally. For non-fingerprinted assets, shorter durations (1 hour to 1 week) balance freshness against bandwidth savings. The key rule: if the filename changes when content changes, you can cache aggressively. If the filename stays the same (like style.css), use shorter cache times or no-cache with ETag validation.

Security Headers — Applied at the Server Level

HTTP security headers protect against common web vulnerabilities. Adding them in the Nginx config means they apply to every response, regardless of what the application layer sets:

X-Frame-Options: SAMEORIGIN prevents clickjacking by blocking iframe embedding on other sites. X-Content-Type-Options: nosniff prevents MIME-type sniffing that could cause a script served as a different content type to execute. Strict-Transport-Security (HSTS) forces browsers to always use HTTPS, even before the first redirect completes. Referrer-Policy: strict-origin-when-cross-origin controls referrer information leakage. These headers have zero impact on legitimate users and meaningfully reduce the attack surface.

Frequently Asked Questions About Nginx Configuration