Nginx Config Validator
Paste an nginx.conf and catch syntax errors, misplaced directives, and common security mistakes — before you reload nginx.
Drop a .conf file here, or paste config text above.
Everything runs in your browser — your config is never uploaded to any server.
Paste an nginx config above (or load the sample) and the checks will appear here.
Uses JavaScript's regex engine, not nginx's real PCRE engine — close, but not identical (e.g. no possessive quantifiers/atomic groups).
Catching nginx config mistakes before they reach production
A broken nginx.conf usually announces itself in one of two unpleasant ways: `nginx -t` refusing to reload with a cryptic line-number error, or — worse — a `reload` silently keeping the old (working) config in memory while the new one sits broken on disk, so nothing seems wrong until the next full restart. Both are avoidable by catching the same class of mistakes earlier, while you're still editing.
The most common real-world nginx.conf mistake isn't exotic — it's a forgotten semicolon. Because nginx's grammar only cares about `;`, `{`, and `}` (not line breaks), a missing `;` doesn't produce a clean "line 12: expected ;" error the way most modern parsers do; instead, the next directive's name and arguments silently get absorbed as extra arguments of the previous directive, sometimes with no error at all until something downstream behaves strangely. This tool's line-break heuristic specifically watches for that pattern — a known directive name appearing mid-argument-list on a new source line — and flags it before it becomes a support ticket.
Directive placement is the second common trap: `proxy_pass` only makes sense inside a `location` (or `if`) block, `listen`/`server_name` only inside `server`, and so on — but nginx's own parser doesn't reject a directive just because it's in an unusual place if the directive name is one it recognizes at all in a broader sense, and error messages are pointed at nginx's own internal directive registry rather than at "you nested this wrong." This validator checks the directive-to-context table directly, so a `proxy_pass` accidentally left at the `http` level (outside any `server`/`location`) gets flagged with the exact line, not just "the config failed to load."
Beyond syntax, a handful of small config choices have outsized security consequences: leaving `server_tokens` at its default (`on`) hands out your exact nginx version in every response header and default error page, which is free reconnaissance for anyone probing for a version-specific CVE; using the URL-decoded `$uri` variable inside a `return`/`rewrite`/`add_header` (instead of the raw `$request_uri`) can let an attacker inject characters into a redirect target under some configurations. Neither of these breaks anything visibly during normal testing, which is exactly why they're worth a dedicated pass rather than relying on noticing them by eye in a 200-line config.
Frequently asked questions
Does this replace `nginx -t`?
No. `nginx -t` is the only tool that checks your config against the exact nginx build and modules actually installed on your server, and it's the final word before a reload. This validator catches the same class of mistakes (syntax errors, wrong directive placement, a handful of security smells) before you even get to a server with nginx installed — useful while editing locally, in a CI step, or when you don't have shell access to the target machine yet.
Is the security checklist exhaustive?
No — it covers a small, deliberately chosen set of checks (missing `server_tokens off;`, `autoindex on;`, and `$uri` used where `$request_uri` is safer) loosely inspired by Gixy, the open-source nginx config auditor. It is not a replacement for Gixy or a full security audit.
Why does the regex tester behave slightly differently from real nginx?
nginx's `location ~` and `location ~*` matching uses PCRE (via the bundled PCRE library in the nginx binary). This tool runs entirely in your browser, so it uses JavaScript's built-in RegExp engine instead — the two are very close for common patterns, but PCRE-only features like possessive quantifiers or atomic groups won't behave the same way here.
Does my config ever leave my browser?
No. Parsing, validation, and both simulators run with plain JavaScript in this tab. Nothing is uploaded, logged, or sent anywhere — you can even disconnect from the internet after the page loads and it keeps working.