Nginx Config Analyzer

What this Nginx config check looks for

An Nginx configuration can pass nginx -t and still be insecure or subtly broken: nginx -t only proves the syntax is valid, not that TLS 1.0 is off, that security headers reach every page, or that an alias cannot be walked out of. This analyzer parses the configuration the way Nginx does and reports those problems with a line number, a reason and the directive to write.

It reads directives, blocks, quoted strings, comments and variables. include lines are listed but not followed, so paste an included file separately to check it.

What it checks

It also notes things that are not wrong in themselves: gzip on HTTPS pages (BREACH), uploads over the 1 MB default client_max_body_size, HTTP/2 not enabled, proxy_http_version 1.1 without WebSocket headers, and what server_name _ and default_server really do.

The add_header trap

add_header is inherited from the server block only by locations that have no add_header of their own. Add a single Cache-Control header to one location and every security header set on the server disappears from that location's responses:

server {
    add_header X-Frame-Options "SAMEORIGIN" always;
    location /assets/ {
        add_header Cache-Control "public, max-age=31536000";   # X-Frame-Options is gone here
    }
}

Repeat the server's headers inside the location, or keep them in a snippet and include it in both places. proxy_set_header follows the same rule.

The alias off-by-slash

With location /static { alias /var/www/app/static/; }, a request for /static../.env maps to /var/www/app/static/../.env, the file one level up. The location and the alias should both end in a slash, or neither should be an alias at all: root /var/www/app; with location /static/ is simpler.

Header injection through $uri

$uri holds the decoded path, so %0d%0a in a request becomes a real line break. return 301 https://$host$uri; then lets anyone add a header, such as Set-Cookie, to your redirect. $request_uri is the raw, still-encoded path and is safe there.

Test and reload

sudo nginx -t                  # syntax and file checks for every included file
sudo systemctl reload nginx    # apply without dropping connections

If nginx -t fails, the old configuration keeps running after a reload; a restart or a reboot would not start at all. Check the result from outside with curl -I https://example.com and look for the headers you added.

Let Shipown write and test it

The Nginx config generator writes a server block with the HTTPS redirect, security headers and proxy headers already in. Shipown writes the virtual host for each app it deploys, tests it with nginx -t before reloading, asks Certbot for the certificate, and puts the previous configuration back if Nginx rejects the new one. See deploying with Shipown.