The nginx misconfigurations that fail silently

Most nginx misconfigurations announce themselves. You typo a directive, nginx -t fails, you fix it. That feedback loop is fast and it works. The dangerous ones are different. The config is valid. nginx -t passes. The server starts, serves traffic, logs nothing unusual. And the thing you configured is quietly not happening. I maintain gixy-ng , a static analyzer for nginx configs. A growing share of its checks exist for exactly this category, because it turns out static analysis is the only practical way to catch a failure that produces no signal at runtime. Here are four worth knowing about. 1. OCSP stapling that staples nothing server { listen 443 ssl ; server_name example.com ; ssl_certificate /etc/ssl/example.com.pem ; ssl_certificate_key /etc/ssl/example.com.key ; ssl_stapling on ; ssl_stapling_verify on ; } Looks right. It does nothing. OCSP stapling means nginx fetches the certificate's revocation status from the CA itself and attaches it to the handshake, so the client does not have to. To do that, nginx has to make an outbound request to a hostname. nginx does not use the system resolver for runtime lookups. It has its own, and it only exists if you configure it. No resolver in scope means the hostname never resolves, the fetch never happens, and stapling is silently skipped. Your config test passes. Your clients go do their own OCSP lookups, which is the exact thing you turned stapling on to avoid. resolver 127.0 .0.1 valid=300s ipv6=off ; resolver_timeout 5s ; Use a local resolver or your cloud provider's internal DNS. Pointing this at 8.8.8.8 sends every internal lookup off your network in cleartext, which is its own problem. Check it with: echo | openssl s_client -connect example.com:443 \ -servername example.com -status 2>/dev/null \ | grep -A 17 'OCSP response' Working stapling prints OCSP Response Status: successful . Broken stapling prints no response sent . Run it twice, since the first handshake after a reload usually goes out unstapled while the f