Nginx Snippet Generator

About this tool

Nginx configuration is compact but unforgiving: a missing semicolon stops the reload, and directives only work in the right context. The Nginx Snippet Generator gives you six common blocks, all ticked by default: HTTPS redirect (a port-80 server that returns 301 to https://$host), www to non-www redirect (a 443 server for www.<domain> that returns 301 to the apex), gzip compression, a static asset cache location (30 days, Cache-Control immutable, access_log off), security headers (X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and a basic Content-Security-Policy) and a rate limit sample for /api/. Enter your primary domain for the redirect blocks, untick what you do not need, and copy the merged output, where each block starts with a # label. The blocks are snippets, not a finished server block: place each in the right context, add your own ssl_certificate lines and run nginx -t before reloading.

Why use it

• Common Blocks in One Place: HTTPS redirect, www to non-www redirect, gzip, static caching, security headers and rate limiting are all available as tick boxes.

• Domain Filled In: The redirect blocks use the domain you type, with a leading www. handled for the apex redirect.

• Sensible Gzip Defaults: Compression level 5, a 1024-byte minimum, gzip_vary on and a MIME list covering text, CSS, JSON, JavaScript, XML and SVG.

• Long-Lived Asset Caching: The cache location gives CSS, JavaScript, images and fonts a 30-day expiry with Cache-Control immutable and turns off their access logging.

• Security Headers With always: Each header uses the always flag so it is also sent on error responses.

• Live Size Counter: Line and byte counts update as you change the selection or domain.

How to use

1. Enter your primary domain; the HTTPS and www redirect blocks use it, and http://, https:// or a trailing path is stripped automatically.
2. Untick any block you do not need — all six start ticked. Clear selection unticks everything and Select all options ticks it again.
3. Review the merged output, where each block starts with a # label comment, and check the line and byte counts.
4. Click Copy output and move each block into the right context: redirect blocks are separate server blocks, gzip and add_header lines go in http or server, the cache location goes inside a server, and limit_req_zone belongs in http.
5. Add ssl_certificate and ssl_certificate_key to the www redirect server and change the /api/ proxy_pass target to your own backend.
6. Run nginx -t and reload Nginx only when the test passes.

When it helps

• When you need a quick reference for the syntax of a common Nginx block before editing an existing config
• When you need to redirect an old domain or HTTP traffic to a canonical HTTPS URL
• When adding gzip compression or browser caching headers to an existing Nginx config that lacks them
• When hardening a server by adding X-Frame-Options, X-Content-Type-Options, Referrer-Policy and a starter Content-Security-Policy
• When adding basic per-IP rate limiting to an API location

Examples

Domain: https://Example.com/path, only HTTPS redirect ticked

# HTTPS redirect
server {
  listen 80;
  listen [::]:80;
  server_name example.com;
  return 301 https://$host$request_uri;
}

Domain: www.example.com, only www to non-www redirect ticked

# www to non-www redirect
server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  server_name www.example.com;
  return 301 https://example.com$request_uri;
}

Only Security headers ticked

# Security headers
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=()" always;
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'" always;

Tips

• Always run nginx -t after editing and before running nginx -s reload — a config error will prevent the reload from succeeding and Nginx will continue serving the old configuration without any visible error to users
• Use the include directive to split large server blocks into smaller files such as a separate ssl-params.conf for TLS settings, which makes the main server block easier to read and reuse across virtual hosts
• Set worker_processes auto in the main nginx.conf to automatically match the number of available CPU cores, and set worker_connections to 1024 or higher for servers handling more than a handful of concurrent connections
• For reverse proxy configurations, add proxy_read_timeout 90 to prevent Nginx from timing out long-running API requests before your application server has finished processing them
• Test your security headers using securityheaders.com after deployment — it grades your header configuration and flags missing or misconfigured headers with clear remediation instructions

Frequently Asked Questions

Glossary

server block

The top-level configuration unit in Nginx that handles requests for a specific IP address, port, and server_name combination. Equivalent to a VirtualHost in Apache. Multiple server blocks can coexist in a single Nginx instance.

location block

A nested directive within a server block that matches request URIs and defines how to handle them. Supports exact matching with =, prefix matching, and regex matching with ~ (case-sensitive) or ~* (case-insensitive).

proxy_pass

An Nginx directive that forwards the incoming HTTP request to an upstream server and returns the response to the client. Requires companion directives for setting forwarded headers like X-Forwarded-For.

upstream block

A named group of backend servers defined with the upstream directive that enables load balancing across multiple application server instances. Referenced by proxy_pass using the upstream name.

try_files

An Nginx directive that attempts to serve a list of files or paths in order and falls back to a final argument (typically a named location or status code) if none are found. Essential for SPA routing and static site serving.

HSTS (HTTP Strict Transport Security)

A response header that instructs browsers to only access the domain over HTTPS for a specified max-age duration, preventing SSL stripping attacks. Set using add_header Strict-Transport-Security in the HTTPS server block.