Nginx Config Generator

Testing before reloading

Always test a config change before applying it — a syntax error in a blind restart takes the whole server down, whereas a failed test leaves the currently running config untouched:

sudo nginx -t && sudo systemctl reload nginx

nginx -t parses every config file and reports the first error with a file and line number; reload (not restart) re-reads the config and swaps it in with zero dropped connections, versus a full restart which briefly drops the listening socket.

Where the file goes

Nginx's convention on Debian/Ubuntu is to write the actual config into /etc/nginx/sites-available/<domain>, then symlink it into /etc/nginx/sites-enabled/ to activate it — keeping every config on disk (available) separate from which ones are actually live (enabled):

sudo nano /etc/nginx/sites-available/example.com
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Before this config does anything

The domain needs to actually resolve to this server first — point an A record at it via DNS before expecting HTTPS or Certbot to work, since Let's Encrypt validates ownership over HTTP. This server block runs on the instance itself, whether that's an EC2 box or a Lightsail instance — both need ports 80 and 443 open in their firewall/security group for Nginx to be reachable at all.

Adding a Content-Security-Policy header

A CSP header is just another add_header line inside the same server block — use the CSP Builder to generate the policy string itself, then paste it in alongside the lines this tool generates.

Password-protecting a location block

Basic auth on a specific path (staging environments, admin tools) is two directives inside a location block — auth_basic for the prompt text and auth_basic_user_file pointing at a credentials file generated by the Htpasswd Generator:

location /admin {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}