UtilitiesHub

Nginx Config Generator

Generate a ready-to-edit Nginx server block for static sites or reverse proxy apps. Configure your domain, root path, upstream app, HTTPS redirect, gzip, and cache settings, then copy or download the generated config.

Generated Nginx config


Explore More

Go straight to the formatter, validator, encoder, generator, or developer utility you need.

Coding Tools

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, serving 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 — the Nginx equivalent of Apache's virtual hosts — where you define precisely how incoming requests for a domain, port, and URL path are handled. Nginx configuration is powerful, but it's also specific: the order of directives matters, location block matching has 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 the parameters you provide: domain, document root, server type (static site, PHP-FPM, Node.js reverse proxy, or Python/other), SSL configuration, gzip compression, security headers, and browser cache headers. The output is a readable starting template you can understand and confidently adapt — not an opaque snippet copy-pasted from a forum that you're not sure what it does.

Static Site, PHP, and Reverse Proxy — Key Differences in Config

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

Static sites and SPAs: Nginx reads files directly from a directory on disk. The config sets a root directive pointing to the build output directory and uses try_files $uri $uri/ /index.html to serve the file matching the URL path, fall back to a directory index, or fall back to index.html for single-page applications where client-side routing handles paths. No application server is involved — Nginx handles all requests itself, making this the fastest serving mode.

PHP with PHP-FPM: Nginx does not execute PHP itself. For PHP applications (Laravel, WordPress, Symfony), requests for .php files are 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 the standard FastCGI parameters (SCRIPT_FILENAME, PATH_INFO, etc.). Static assets (images, CSS, JS) are served directly by Nginx without involving PHP-FPM.

Reverse proxy (Node.js, Python, others): Nginx sits in front of an application server running on a local port — a Node.js Express app on port 3000, a Python Gunicorn server on port 8000, a Go HTTP server, or any other process listening on TCP. Nginx forwards requests with proxy_pass http://localhost:PORT and passes essential headers: Host, X-Real-IP, X-Forwarded-For, and X-Forwarded-Proto. These headers let the application see the original client IP and protocol, which is critical for logging, rate limiting, and HTTPS detection.

SSL Configuration and the HTTP-to-HTTPS Redirect

For any public-facing website, HTTPS is a baseline requirement. The generated SSL config includes two server blocks: one on port 80 that permanently redirects all HTTP traffic to HTTPS (with a 301 redirect using return 301 https://$host$request_uri), and one on port 443 that handles HTTPS with the SSL certificate and key paths.

The certificate paths default to the standard Let's Encrypt / Certbot output locations (/etc/letsencrypt/live/yourdomain.com/fullchain.pem and privkey.pem). Certbot can provision free certificates from Let's Encrypt and — with the --nginx flag — will automatically modify your Nginx config with the correct SSL settings and set up automatic renewal. The config also includes ssl_protocols TLSv1.2 TLSv1.3 to disable older, insecure TLS versions.

Performance: Gzip Compression and Browser Cache Headers

Gzip compression: Enabling gzip in Nginx compresses text-based responses — HTML, CSS, JavaScript, JSON, XML, SVG — before sending them to the browser. Compression typically reduces response size by 60–80% for these content types. The browser decompresses transparently, and the speed improvement — especially on slower connections — is significant. The config enables gzip for the most useful content types and sets an appropriate compression level that balances CPU cost against size reduction.

Browser cache headers: Static assets like images, CSS files, JavaScript bundles, and fonts rarely change between requests. Adding a long Cache-Control: max-age header (commonly 1 year for fingerprinted assets) tells browsers to cache the file locally and not request it again until it expires. This dramatically reduces repeat-visit bandwidth and page load time. For assets with versioned filenames or content hashes in the filename, long cache times are safe because the filename changes whenever the content changes.

Security Headers — Why They Belong in Your Nginx Config

HTTP security headers are browser instructions that add baseline protection against common web vulnerabilities. Adding them to your Nginx config means they apply to every response from your server, regardless of what your application layer does or doesn't set:

X-Frame-Options: SAMEORIGIN prevents your pages from being embedded in iframes on other sites, protecting against clickjacking attacks. X-Content-Type-Options: nosniff prevents browsers from MIME-type sniffing responses that could cause a JavaScript file served as a different content type to execute. Referrer-Policy: strict-origin-when-cross-origin controls how much referrer information is sent in cross-origin requests. Strict-Transport-Security (HSTS) tells browsers to always use HTTPS for future requests to your domain, even before the server has a chance to redirect. These headers have no functional impact on legitimate users but meaningfully narrow the attack surface for certain vulnerability classes.

Frequently Asked Questions About Nginx Configuration

It's a solid starting template, but production deployments need additional review. Depending on your setup you may need to tune worker_processes, keepalive_timeout, upstream connection pooling, rate limiting, more granular cache rules, stricter TLS cipher settings, and OCSP stapling. Always run sudo nginx -t to validate the config before reloading, and test in a staging environment before going live.
On most Linux distributions, Nginx site configs go in /etc/nginx/sites-available/. Create a file there (e.g. /etc/nginx/sites-available/example.com), paste your config, then create a symlink to enable it: sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/. Finally, test with sudo nginx -t and reload with sudo systemctl reload nginx. On some setups (e.g. custom installs), configs go directly in /etc/nginx/conf.d/ as .conf files — both locations are included by the default nginx.conf.
Apache uses per-directory .htaccess files that are read on every request, which adds overhead but allows per-directory config without restarting the server. Nginx does not support .htaccess — all config must be in server-level files, which requires a reload after changes but is significantly faster at runtime. Nginx also uses an event-driven, non-blocking architecture that handles high concurrency with lower memory usage than Apache's process/thread-per-request model.
The easiest way is Certbot with the Let's Encrypt CA, which is free. Install Certbot, run sudo certbot --nginx -d yourdomain.com, and it will automatically provision a certificate and update your Nginx config with the correct SSL paths and settings. Certificates auto-renew via a cron job or systemd timer that Certbot sets up. The paths the generator uses (/etc/letsencrypt/live/yourdomain.com/fullchain.pem etc.) match the standard Certbot output paths.
At minimum: proxy_set_header Host $host (passes the original hostname to the app), proxy_set_header X-Real-IP $remote_addr (passes the client's IP), proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for (maintains the IP chain through multiple proxies), and proxy_set_header X-Forwarded-Proto $scheme (tells the app whether the original request was HTTP or HTTPS). Without these, your application sees Nginx's local IP as the client address and may incorrectly determine the request protocol.