Free. Modern Nginx 1.24+ syntax. TLS 1.3 ready.

Free Nginx Config Generator

Generate a complete server { } block for Nginx with modern TLS, security headers, rate limiting, caching, compression, reverse proxy, and sensitive-file blocking. For sysadmins, devops, and anyone running Nginx on a VPS or dedicated server. Built by Datastrive, a Chicago managed IT and infrastructure provider.

  • 8 configurable sections
  • Mozilla Modern TLS profile
  • Live preview & download

Define the basic server block: hostname, listen ports, document root, and default index files.

Space-separated list. Include both www and non-www if you want a single block to serve both. For wildcards, use *.example.com or ~^(.+)\.example\.com$ for regex matching.

Configure TLS / SSL. The defaults match Mozilla’s “Modern” SSL profile — TLS 1.3 only, modern ciphers, no legacy compat.

From Mozilla’s SSL config generator. Modern is right for any site that doesn’t need to support 10+-year-old browsers.

HTTP response headers that harden your site against common browser-based attacks.

HSTS commitment: once enabled, browsers refuse HTTP for the entire max-age duration (1 year). If your TLS breaks during that window, the site is unreachable until certs are restored. Enable only after HTTPS is rock-solid.

Limit how many requests an IP can make per second. Useful for preventing brute-force on login pages, API abuse, and basic DDoS mitigation.

Add long Cache-Control headers for static assets so browsers and CDNs cache them aggressively. Reduces server load and speeds up repeat visits.

Pipe-separated regex pattern. Default covers common static assets. Add or remove as needed.

Compress text-based responses on the fly. Saves bandwidth and speeds up page loads. Gzip is universally supported; Brotli compresses smaller but requires ngx_brotli.

Don’t compress images. JPEG, PNG, WebP, MP4, etc. are already compressed — running them through gzip/Brotli wastes CPU for zero size benefit. The output covers HTML, CSS, JS, JSON, XML, SVG, and similar text formats only.

Proxy requests to a backend application server (Node.js, Python, PHP-FPM via Unix socket, etc.). Common pattern for SaaS apps, APIs, and modern web apps.

Block direct access to sensitive files and dotfiles. Same protection set as the .htaccess generator, ported to Nginx location blocks.

Where this goes: save as /etc/nginx/sites-available/yourdomain.conf, then symlink to sites-enabled with ln -s /etc/nginx/sites-available/yourdomain.conf /etc/nginx/sites-enabled/. Test with nginx -t before reloading. Reload with systemctl reload nginx.
Generated nginx config

Working with Nginx config safely

Nginx config errors don’t take down a single page like a broken .htaccess does — they prevent Nginx from starting at all. The disciplines below keep you out of trouble.

  1. Always run nginx -t before reloading The test command parses your full config and reports syntax errors without touching the running service. If nginx -t fails, do not run systemctl reload nginx — the existing config keeps running, which is good. Fix the error first, retest, then reload.
  2. Use reload, not restart systemctl reload nginx performs a hot reload — existing connections finish on the old config, new connections use the new config, no downtime. restart kills all connections and re-launches. Always reload for config changes; only restart for module updates or upstream package upgrades.
  3. One config file per site, in sites-available/ The Debian/Ubuntu convention is /etc/nginx/sites-available/yourdomain.conf with a symlink in sites-enabled/. To disable a site, remove just the symlink — the file stays for future use. Some distros put files in conf.d/ instead; check your nginx.conf for the include path.
  4. Server blocks need a “default” or you’ll be confused later If a request comes in for a hostname Nginx doesn’t recognize, it serves whatever server block is listed first — usually unintentional. Add default_server to your main listen directive (listen 443 ssl default_server;) to make this explicit, or create a catch-all block that returns 444 (close connection) for unrecognized hosts.
  5. Watch for limit_req_zone placement Rate-limiting zones must be declared in the http { } context (/etc/nginx/nginx.conf or an include in conf.d/), not inside server { }. The actual limit_req usage goes in server or location. The generator outputs both and labels which goes where.
  6. Test rate limiting before going live It’s easy to set rate limits too aggressively and lock out real users. Hit your site with ab or siege from your own IP at the configured rate to verify legitimate traffic isn’t being throttled. Check Nginx error logs for limiting requests entries during normal traffic to spot false positives.
  7. Verify your TLS config with SSL Labs After deploying any TLS changes, run your domain through SSL Labs. The Mozilla Modern profile this generator outputs should score A+ out of the box. If you score lower, the report tells you exactly what’s wrong — usually a missing intermediate cert, an old protocol still enabled, or a weak cipher in the chain.

Frequently asked questions

Where do I put this config file?

Standard Debian/Ubuntu Nginx installations use /etc/nginx/sites-available/ for config files and /etc/nginx/sites-enabled/ for symlinks to active sites. Save the file as yourdomain.conf in sites-available, then create a symlink: sudo ln -s /etc/nginx/sites-available/yourdomain.conf /etc/nginx/sites-enabled/

RHEL/CentOS/Rocky/Alma installations typically use /etc/nginx/conf.d/ directly, with files ending in .conf auto-included. Save as /etc/nginx/conf.d/yourdomain.conf — no symlink needed. Check your /etc/nginx/nginx.conf to see which include pattern your install uses.

Does this work with Docker / Kubernetes / managed Nginx?

Mostly yes for Docker. The config syntax is identical — you’d mount the file into the container at /etc/nginx/conf.d/default.conf or similar. Adjust the root path to match your container’s filesystem.

For Nginx Ingress on Kubernetes, the syntax is similar but configuration is typically expressed as ConfigMaps and Ingress annotations rather than raw Nginx config. The directives this tool outputs are valid; they just need to be translated to Kubernetes resource format.

Managed services like Cloudflare, AWS CloudFront, or Vercel handle Nginx-equivalent config through their own dashboards. The concepts translate but the syntax doesn’t.

What’s the difference between Nginx and Apache?

Architecturally: Nginx is event-driven (one process handles thousands of concurrent connections), Apache is process-per-request by default (more memory per connection but simpler programming model). For most modern workloads, Nginx is faster and uses less memory.

Configuration-wise: Apache uses per-directory .htaccess files that are read on every request. Nginx uses centralized config files in /etc/nginx/ that are read once at startup. Nginx is faster for this reason but requires you to reload after every config change.

What this means in practice: Apache lets users customize behavior in their own directories without admin access. Nginx is faster but every config change requires shell access to the server.

Does enabling HTTP/3 break anything?

Generally no — HTTP/3 is opt-in via the Alt-Svc response header. Browsers that support HTTP/3 will switch to it on subsequent connections; everything else stays on HTTP/2 or HTTP/1.1.

Two requirements: Nginx 1.25+ (older versions don’t support QUIC), and UDP/443 must be open on your firewall. If you have a firewall in front of Nginx (like a hardware appliance or cloud security group), it likely needs an explicit rule for UDP/443 — many default to TCP/443 only.

Can I use this for WordPress?

Yes — switch the “Reverse Proxy” tab to PHP-FPM mode and point it at your local PHP-FPM socket (typically /var/run/php/php8.2-fpm.sock or similar depending on your PHP version). Add a try_files rewrite for WordPress permalinks.

Also enable the “Block wp-config.php” and “Block PHP in uploads” options for security. The generator output is a solid starting point for a WordPress-on-Nginx setup, though specific plugins (WP Rocket, NGINX Helper, etc.) may need additional config beyond what’s covered here.

How do I get SSL certificates?

For free certificates, use Let’s Encrypt via Certbot. The standard command (on Ubuntu/Debian): sudo apt install certbot python3-certbot-nginx, then sudo certbot --nginx -d example.com -d www.example.com. Certbot edits your Nginx config automatically and handles renewals via cron.

For wildcard certificates, you’ll need DNS-01 validation: sudo certbot certonly --manual --preferred-challenges dns -d *.example.com -d example.com. Set up DNS records as Certbot prompts. Renewal requires DNS API access for full automation.

The certificate paths in the generator (/etc/letsencrypt/live/example.com/...) match Certbot’s default layout. If you’re using paid certs from a different CA, adjust the paths accordingly.

Need someone to manage the server?

Datastrive runs and maintains Linux servers, web hosting, and Nginx infrastructure for businesses across the Chicago area. If hand-rolling Nginx config isn’t your idea of a productive Tuesday, that’s our job.

Talk to Datastrive →