Nginx Config Linter & Syntax Checker

It statically analyzes your nginx.conf text for: unbalanced braces, missing semicolons, directives used in the wrong context (e.g. a server block inside a location), duplicate single-value directives, typos in directive names with correction suggestions, listen/server_name problems (such as port 443 without ssl), invalid location modifiers, the famous "if is evil" pattern, alias path-traversal bugs, proxy_pass pitfalls (missing resolver, URI in regex locations), add_header redefinition, version disclosure via server_tokens, and unsafe patterns like autoindex on or allow without deny all. Every finding carries a severity and the exact line number.

No — and any tool that claims to fully replace it is overselling. nginx -t parses with the real nginx binary, resolves every include file, and validates against the exact modules you compiled in. This linter is a heuristic pre-check: it cannot resolve include files, cannot know which third-party modules you have installed, and cannot evaluate variables at runtime. Use it to catch mistakes early (especially typos and nesting errors) before you deploy, then still run nginx -t on the server before reloading.

Because nginx's if is not a general-purpose conditional — it is part of the rewrite module and executes at an unexpected phase of request processing. Content handlers such as proxy_pass, try_files, or alias inside (or next to) an if can run in a surprising order, silently misrouting requests. The nginx wiki documents this under "IfIsEvil". The only reliably safe use of if is a block containing nothing but return, rewrite, or set directives — for anything more complex, use the map directive or separate location blocks. This linter flags every if inside a location and explains the safe subset.

No. All parsing and analysis run 100% locally in your browser with JavaScript — there are zero network requests, no file uploads, and no analytics payloads carrying your config. This matters because nginx configs often contain secrets: upstream credentials, internal hostnames, IP allowlists, and TLS details. Server-side checkers require you to upload all of that; here it never leaves your machine.

When a location ends with a slash but its alias does not (or vice versa), nginx concatenates paths in a way that escapes the intended directory. For example, location /static/ with alias /var/www/static (no trailing slash) maps a request for /static/../secret.txt outside /var/www/static — a classic path-traversal vulnerability. The fix is simple: end both the location and the alias with a slash, or neither. This linter flags the mismatch as an error.

$http_host is the raw Host header exactly as the client sent it, so trusting it lets attackers poison caches, password-reset links, and virtual-host routing (host-header attacks). $host is nginx's normalized, lowercased server name with the port stripped, and falls back to the matching server_name — it is almost always what you want to forward upstream. The linter suggests replacing $http_host with $host.

Treat it as a to-do, not a verdict. If you recognize the directive as belonging to a module you compiled in (e.g. headers-more, lua, brotli), you can safely ignore the warning. If you do not use any third-party modules, it is almost certainly a typo — check whether the linter suggested a similarly-spelled built-in directive, which would fail nginx -t with an "unknown directive" emergency error.

Three practical differences. First, privacy: those tools analyze your config on their servers (GetPageSpeed even offers piping nginx -T into their endpoint), while this linter runs entirely in your browser. Second, scope: Gixy is a security-focused static analyzer you install via pip; this tool additionally catches plain authoring mistakes — typos with suggestions, missing semicolons, illegal nesting, duplicate directives. Third, access: no signup, no install, works offline once loaded. For deep security auditing, Gixy remains the specialist; for fast pre-deploy sanity checks, this is the quicker loop.