Build production-ready Nginx server block configurations visually — configure SSL, reverse proxy, security headers, caching, and more with instant preview.
server {
listen 80;
listen [::]:80;
server_name example.com;
root /var/www/html;
index index.html index.htm;
# Security headers
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "no-referrer-when-downgrade" always;
# Logging
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log warn;
}A server block is Nginx's equivalent of an Apache virtual host: it defines how Nginx answers requests for one domain on one port. Each block sets the server_name, the listen port, a document root or proxy target, and location rules that match incoming URIs. A single Nginx instance can host dozens of server blocks, one per site, which is why most distros split them into /etc/nginx/sites-available with symlinks in sites-enabled.
Pick a preset — Static Site, Reverse Proxy, PHP-FPM, Node.js App, WordPress, or Redirect Only — then refine it through the tabbed sections: basics, SSL/TLS, reverse proxy, security headers, logging, redirects, caching, and custom location blocks. The config preview updates as you type. Everything runs entirely in your browser, so server names, certificate paths, and internal upstream addresses never leave your machine. Copy the result into sites-available and reload Nginx.
try_files serves content from disk: try_files $uri $uri/ =404 checks for a matching file, then a directory, then returns 404 — the standard pattern for static sites, with a /index.html fallback for single-page apps. proxy_pass forwards the request to another process instead, such as proxy_pass http://127.0.0.1:3000 for a Node.js app. Use try_files when Nginx owns the files, proxy_pass when an application backend generates the response.
A 502 means Nginx reached the client but could not get a valid response from your upstream. The usual suspects: the backend process is not running or listening on a different port than proxy_pass points to, SELinux blocking outbound connections (try setsebool -P httpd_can_network_connect 1), a Unix socket path mismatch with PHP-FPM, or upstream timeouts on slow requests. Check the Nginx error log first — it names the exact upstream failure.
Always run nginx -t before reloading — it parses every config file and reports the exact file and line of any syntax error without touching the running server. If the test passes, apply changes with systemctl reload nginx (or nginx -s reload), which gracefully re-reads configuration without dropping active connections. Never use restart for a config change in production; reload is zero-downtime, and a bad config will simply be rejected.
Enable SSL in the SSL/TLS section and point ssl_certificate and ssl_certificate_key at your certificate files — with Let's Encrypt these live under /etc/letsencrypt/live/yourdomain/ as fullchain.pem and privkey.pem. The generator can also emit an HTTP-to-HTTPS redirect block and an HSTS header. Stick to TLS 1.2 and 1.3; older protocols are deprecated and fail compliance scans. Run certbot renew --dry-run to confirm automatic renewal works.
Almost always yes. The caching section enables gzip compression for text-based responses — HTML, CSS, JavaScript, JSON — which typically cuts transfer size by 70 percent or more, and adds expires headers so browsers cache static assets like images and fonts instead of re-downloading them. Do not gzip already-compressed formats such as JPEG or WOFF2; it wastes CPU for no gain. For fingerprinted asset filenames, long expires values like 30d are safe because the URL changes on every deploy.
The security section can add the headers most audits expect: X-Frame-Options to block clickjacking, X-Content-Type-Options: nosniff to stop MIME sniffing, Referrer-Policy, a Content-Security-Policy you define, and HSTS for HTTPS sites. It can also hide the Nginx version with server_tokens off and add basic rate limiting (for example 10r/s per client) to blunt brute-force attempts. Test your deployed site against securityheaders.com to verify the result.