Paste a configuration to lint it, then test a request path against the location rules. The matcher applies the order Nginx uses, exact match first, then the longest prefix, then the regular expressions, and it normalises the path the same way.
Runs locally in your browserNginx chooses the location that answers a request in a fixed order: an exact match with = first, then the longest matching prefix, then the regular expressions in the order they are written. This matcher follows that order and normalises the path the way Nginx does, so the answer it shows is the rule Nginx would use.
The report stays a review aid. It reads the pasted text only, and nginx -t on the machine that serves the site remains the authority on whether the file loads.
An exact match such as location = /health wins immediately. Otherwise the longest matching prefix is remembered; when that prefix is written with ^~, the regular expressions are skipped and the prefix serves the request.
Without ^~ the regular expressions are tried in the order they appear and the first match wins; when none matches, the remembered prefix serves the request. Locations nested inside a matched prefix are searched the same way, which is why a nested ^~ or a nested regular expression can beat a rule written further down the file.
The report flags unbalanced braces or quotes, a missing server block, a missing server_name, a port 80 listener without an obvious return 30x redirect, proxy_pass without proxy_set_header Host, and proxy_pass without X-Forwarded-For or X-Forwarded-Proto. Port 80 is recognised as 80, *:80, 0.0.0.0:80 and [::]:80.
It also reports location patterns that use braces without quotes: Nginx refuses to load a file such as location ~ ^/p/[0-9]{3}$ { } with unknown directive, and the warning names the fix. When every check passes, the report says so instead of inventing a finding.
Quote a regular expression when it contains braces: location ~ "^/p/[0-9]{3}$" { } loads, the bare form does not. The preview decodes percent-escapes, merges repeated slashes and resolves . and .., so /a//b, /a/./b and /a/x/../b all reach location = /a/b.
Matching is case-sensitive unless the rule uses ~*. Named locations (location @name) are listed but never chosen from a request path, and directives such as rewrite, try_files and error_page are not followed, so read the result as the routing step Nginx performs first.