See which nginx location block wins — and why every other block lost. Free location match tester for =, ^~, ~ and ~*, running entirely in your browser.
~* \.(gif|jpg|jpeg)$ First regex in configuration order that matched. Length is irrelevant.
/documents/1.jpg/documents/1.jpg—Matching runs against the normalised path only. The query string is split off first and never participates.
| Line | location | Stage | Outcome | Reason |
|---|---|---|---|---|
| 2 | = / | Exact | No match | An = location needs the whole URI to be equal, not to start with it. |
| 3 | / | Prefix | Matched but shorter | It matches, but another prefix matched more characters. |
| 4 | /documents/ | Prefix | Matched but shorter | It matches, but another prefix matched more characters. |
| 5 | ^~ /images/ | Prefix | No match | The URI does not start with this prefix. |
| 6 | ~* \.(gif|jpg|jpeg)$ | Regex | Selected | First regex in configuration order that matched. Length is irrelevant. |
| Modifier | Syntax | Matches by | Order | Stops regex | Typical use |
|---|---|---|---|---|---|
| = | location = /path | Equality | 1 | Yes | Hot paths such as / — the fastest possible match. |
| ^~ | location ^~ /path | Starts with | 2 | Yes | Directories that must never be handed to a regex, such as uploads. |
| ~ | location ~ regex | PCRE regex | 3 | No | Extension routing where case matters. |
| ~* | location ~* regex | PCRE regex | 3 | No | Extension routing where case does not matter. |
| (none) | location /path | Starts with | 4 | No | General routing by path. |
| @ | location @name | Internal only | — | No | error_page and try_files fallbacks. |
The order column is not a simple ranking. A prefix location only stops regex evaluation when it carries ^~ and is itself the longest match — which is exactly why a ^~ block sometimes appears to do nothing.
| # | Stage | Ends the search | What happens |
|---|---|---|---|
| 1 | Normalise | No | Percent-decoding, . and .. resolution, repeated slashes collapsed. The query string is split off here and never takes part in matching. |
| 2 | Exact | Yes | location = /path, compared for equality. A hit ends the search immediately. |
| 3 | Auto-redirect | Yes | A proxying location whose name is the URI plus a slash. nginx answers 301 and never reaches the regexes. |
| 4 | Prefix | No | Every matching prefix is compared and the longest is remembered. Configuration order is ignored. |
| 5 | Nested | No | The winning prefix is descended into. A nested regex is tried before the parent level. |
| 6 | Regex | Yes | Regexes are tried in configuration order and the first match wins. A longer or more specific regex written later never runs. |
| 7 | Fallback | Yes | No regex matched, so the prefix remembered earlier is used. |
The selection rules on this page were verified against a running nginx 1.27.5 rather than taken from secondary write-ups, and the engine is covered by unit tests derived from those runs.
No — prefix locations are checked first, but a matching regex still wins. nginx checks all prefix locations first and remembers the longest match, then evaluates regex locations in the order they appear in the file. The first matching regex wins. If no regex matches, the remembered prefix location is used. The one exception is ^~: when the longest matching prefix carries it, the regex phase is skipped entirely.
Only for regex locations. Prefix locations — including = and ^~ — are selected by longest match, so their order in the file is irrelevant. Regex locations are tested top to bottom and the first match wins, so moving a regex block changes which one runs. A more specific regex placed below a broader one never executes.
It stops nginx after the prefix match instead of raising priority. If the longest matching prefix location carries ^~, nginx skips the regex phase and uses that block. It does not make the prefix match longer or rank it above other prefixes — it only suppresses regex evaluation. That is why a ^~ block appears to do nothing when a longer plain prefix also matches: the longer one is remembered instead, and it does not suppress anything.
No — /static also matches /staticfoo. Prefix matching is a plain string comparison, not a path-segment boundary, so location /static serves /staticfiles and /static-backup as well. Separately, when /static/ is used with proxy_pass, a request to /static without the trailing slash gets a 301 redirect to /static/ before any regex is considered.
Yes — matching runs against the normalised URI, not the raw request. nginx decodes %XX, resolves . and .. and compresses repeated slashes before selecting a location. A decoded %2F becomes a real separator and takes part in that resolution, so /a/b%2F..%2Fzz is matched as /a/zz. The query string is split off first and never participates in matching at all.
A location block tells nginx what to do with a request whose URI matches a pattern. A server block usually holds several, and the interesting part is not what each one does but which one nginx picks — because the selection rules are not the ones most people assume.
There are five forms. location = /path matches only when the whole URI is equal. location /path matches any URI starting with those characters. location ^~ /path is the same prefix comparison with one extra effect. location ~ regex and location ~* regex apply a PCRE pattern, case-sensitively and case-insensitively. location @name never takes part in URI matching at all and exists only as a target for try_files and error_page.
Selection runs in stages. First the URI is normalised: percent-decoded, . and .. resolved, repeated slashes collapsed, query string split off. Then an = location equal to the URI ends the search immediately. Then every matching prefix is compared and the longest is remembered — configuration order plays no part here at all. If that remembered prefix carries ^~, nginx stops and uses it. Otherwise the regex locations are tried in the order they appear in the file, and the first match wins, however specific a later one might be. If none matches, the remembered prefix is used.
Two of those rules pull in opposite directions, and that is where the confusion lives: prefixes are chosen by length regardless of order, regexes by order regardless of length. A config that reads correctly from top to bottom can still route a request somewhere you did not intend, and no amount of re-reading reveals it. This page replays the whole sequence against your own config and shows where each block dropped out.
# From the nginx documentation. Which block serves each request?
server {
location = / { } # A
location / { } # B
location /documents/ { } # C
location ^~ /images/ { } # D
location ~* \.(gif|jpg|jpeg)$ { } # E
}
# / -> A exact match, search ends here
# /index.html -> B no regex matched, longest prefix used
# /documents/document.html -> C longer prefix than B
# /images/1.gif -> D ^~ won the prefix stage, regex skipped
# /documents/1.jpg -> E regex beats the longer prefix C
# The last two lines are the whole lesson: identical-looking prefixes
# behave differently because only one of them carries ^~. Each location you wrote gets a row: matched but shorter, skipped because a ^~ prefix won, unreachable because an earlier regex matched, or simply no match. Knowing why the others lost is usually what actually resolves the question.
Normalisation, exact match, longest-prefix memory, the ^~ short-circuit, regex in file order and the fallback are shown as discrete steps against your own configuration rather than described in the abstract.
When a ^~ prefix suppresses the regex phase, every skipped regex is labelled as skipped rather than quietly vanishing — and when the ^~ fails to apply because a longer plain prefix won, that is shown too.
nginx descends into the winning prefix and searches its children, so a nested regex runs before the parent level's. Nested blocks keep their indentation in the table so the structure stays readable.
Browsers run ECMAScript regexes, not PCRE. Atomic groups, possessive quantifiers, POSIX classes and escapes such as \A and \K are flagged instead of silently mis-evaluated, so a confident wrong answer is never presented as fact.
Server configs carry upstream hostnames, internal ports and auth rules. Parsing is plain string work with no dependencies and no network calls, verified by an automated contract test on every build.
Dumps the fully resolved configuration, which is invaluable for finding what is actually loaded. It will not tell you which location a given URI selects — that is the gap this page fills.
The most authoritative answer available: the "using configuration" line names the block nginx really chose. It needs root, a reload, and a server you can reach — so it answers after deployment, not before.
Strong at whole-file linting and security rules. They generally run server-side, which means uploading a configuration that contains internal hostnames and certificate paths.
The nginx documentation states the algorithm precisely and is worth reading once. Applying it by hand to eight blocks and a URI is where the errors creep in, because two of the rules point in opposite directions.
location /documents/ · location ~* \.(gif|jpg|jpeg)$ · GET /documents/1.jpg
~* \.(gif|jpg|jpeg)$ wins
The prefix /documents/ matches and is the longest prefix in the file, so nginx remembers it — then evaluates the regexes anyway and hands the request to the first one that matches. Length loses to the regex phase. Had that prefix been written ^~ /documents/, the regex would never have run at all. This is the example from the nginx documentation, and it is the single most useful one to internalise.
location /uploads/ · location ~ \.php$ { fastcgi_pass ... } · GET /uploads/evil.php ~ \.php$ wins — the upload lands in the interpreter
The prefix /uploads/ matches, but a plain prefix does not stop the regex phase, so a file someone uploaded is handed straight to PHP-FPM. Writing location ^~ /uploads/ short-circuits the regex phase and closes it. This is not a hypothetical: it is the shape behind a long line of upload-to-RCE reports, and the difference between vulnerable and safe is two characters.
location ^~ /a/ · location /a/b/ · location ~ \.php$ · GET /a/b/x.php
~ \.php$ wins — the ^~ never applied
^~ only suppresses the regex phase when it is itself the longest matching prefix. Here /a/b/ is longer, so it is the one nginx remembers, and its plain modifier lets the regex phase run. The ^~ block is still in the file, still looks protective, and has no effect on this request. Reading a config top to bottom will not reveal that; comparing prefix lengths will.
location /static · location /static/ · GET /staticfoo
/static wins
Prefix matching compares characters, not path segments. /staticfoo starts with /static, so it matches, and /static/ does not match at all because the URI has no slash in that position. Anything reachable under a path that merely starts with the same letters is served by that block — which is how a /static rule ends up serving /static-backup.
location ~ ^/a · location ~ ^/a/b/c$ · GET /a/b/c
~ ^/a wins; ~ ^/a/b/c$ is unreachable
Regexes are evaluated in the order they appear in the file and the first match ends the search. The second block is more specific and matches this URI exactly, and it will never run — for any request. Prefix locations are chosen by length regardless of order; regex locations are chosen by order regardless of specificity. Mixing those two rules up is the usual reason a rule "stops working" after someone tidies the file.
location /a/ · location /b/ · GET /a/b%2F..%2Fzz
$uri becomes /a/zz, so /a/ wins
nginx percent-decodes, resolves . and .. and collapses repeated slashes before any location is consulted. %2F decodes to a real separator and then participates in that resolution, so this target does not stay inside /a/b/ — it lands on /a/zz. Matching against the target you typed rather than the normalised $uri gives the wrong answer here.
Drop in a whole server block, or just the location blocks you are reasoning about. Nested locations are understood, and the original line numbers are kept so the table matches your file.
Type the path as it arrives on the wire, including any percent-encoding and query string. The three rows above the table show how it is normalised before matching.
The verdict card names the selected block and the one-line reason. The decision table underneath explains every other block: which stage it was eliminated at and why.
Unanchored regexes, prefixes missing a trailing slash, a ^~ carrying a regex pattern, unreachable duplicates and upload directories reachable by a PHP regex are all reported.
Copy link encodes the config and URI in the URL fragment so a colleague opens precisely what you are looking at. Fragments are never transmitted to a server.
^~ is only consulted on the prefix that already won on length. A longer plain prefix wins first, and the regex phase then runs as though the ^~ were not there.
location ^~ /a/ { }
location /a/b/ { }
location ~ \.php$ { }
# /a/b/x.php -> ~ \.php$ location ^~ /a/ { }
location ^~ /a/b/ { }
location ~ \.php$ { }
# /a/b/x.php -> ^~ /a/b/ Prefix matching compares characters rather than path segments, so the block also serves every sibling path that starts with the same letters.
location /static { root /var/www; }
# also serves /staticfoo and /static-backup location /static/ { root /var/www; }
location = /static { return 301 /static/; } Regexes are tried in file order and the first match ends the search, so the more precise block never executes for any request.
location ~ ^/api { }
location ~ ^/api/v2/users$ { }
# the second is unreachable location ~ ^/api/v2/users$ { }
location ~ ^/api { } ^~ takes a literal prefix. nginx loads the file without complaint and the block simply never matches anything, which makes it hard to spot in review.
location ^~ "\.php$" { deny all; } location ~ \.php$ { deny all; } The query string is split off during normalisation, so a location can never match on it. Read $arg_name inside the block instead.
location /search?q= { }
# never matches anything location /search {
if ($arg_q = "") { return 400; }
} . and .. segments are resolved and repeated slashes are collapsed, and only then is a location chosen. A decoded %2F becomes a real separator and participates in that resolution, so /a/b%2F..%2Fzz is matched as /a/zz. Three decoded characters are exceptions and stay literal: %25, %23 and %3F — which is why /a%3Fx=1 has a question mark in its path and an empty query string. A + is not a space here; only %20 is. Traversal above the root and an invalid escape are both rejected with 400 before matching starts./static matches /staticfoo. The winner is remembered rather than used immediately, because the regex phase may still override it.^~ block has no effect on the request at all. Placing ^~ on a nested location does not protect against a regex declared at the outer level, and it never suppresses regexes nested inside its own block.^ anchors to the start of the URI only. One difference has security weight: PCRE's $ also matches just before a trailing newline, so a URI ending in %0A still satisfies \.php$ even though a JavaScript engine would refuse it. That behaviour is emulated here and reported, because it is a known way to slip past rules keyed on a file extension.location ^~ /uploads/ so the regex phase cannot hand a stored file to an interpreter. A plain prefix looks equivalent and is not.location /static/ rather than location /static unless you deliberately want /staticfoo and /static-backup served by the same block. Add a separate location = /static when the bare path also needs handling.location ~ /admin searches anywhere in the URI and matches /public/admin/x. Write ~ ^/admin when you mean the start. Anchoring only at the end is normal and correct for extension routing.error_log /var/log/nginx/debug.log debug; and look for the "using configuration" line, which names the selected location. The two approaches answer different questions: the log tells you what a live server did, and this page tells you what a config you have not deployed yet would do. ^~, which skips the regex phase completely. Or the regex is fine but the URI is not what you think: matching runs against the normalised path, after percent-decoding and .. resolution, with the query string removed. = location requires the whole URI to be equal, not to start with the pattern. location = /a/ does not match /a, and location = /a does not match /a/b. Trailing slashes are ordinary characters here, so the two forms are different strings. When an exact location does match, the search stops immediately and nothing else is even compared. location = /a matches a request for /a?x=/b. If you need to branch on a parameter you have to read $arg_name or $args inside the block. One subtlety worth knowing: %3F decodes to a literal question mark that stays in the path, so /a%3Fx=1 has an empty query string and a path containing ?. (?i), POSIX classes such as [[:alpha:]], and escapes like \A and \K that JavaScript quietly reads as ordinary letters. When a location is flagged, the remaining candidates are still evaluated in nginx's order, but that block's verdict needs checking on a real server. If you are writing the pattern itself, the regex tester covers ECMAScript syntax in depth. location /Static/ does not match /static/x. On case-insensitive filesystems such as macOS and Cygwin, nginx compares prefixes case-insensitively and additionally forces every regex location to behave like ~*. This page models the Linux behaviour, which is what production servers almost always run. If you develop on a Mac and deploy to Linux, that difference can hide a broken rule until it ships. try_files runs afterwards, inside whichever block already won. If a request never reaches the block containing your try_files, the directive is irrelevant — the usual cause is a ~ \.php$ regex taking the request before the prefix block with the fallback ever gets to act. An internal redirect issued later does restart matching, so a rewritten URI is resolved against the location list again from the top. / carries proxy_pass or another *_pass directive, a request for the same path without the slash is answered with a 301 during location selection — before any regex is evaluated. Separately, the static file module issues a 301 when the path resolves to a real directory on disk. The first is visible here; the second depends on your filesystem. Adding location = /path suppresses the first. ^~ on the outer block does not shield it from its own nested regexes, and nesting can make a globally longer prefix unreachable when a sibling at the outer level wins first. Nested blocks are modelled here with the same indentation you wrote them in. Web & API
Build curl commands in your browser — set method, headers, auth, and body, get a copy-ready command instantly. Presets for Bearer, POST JSON, file upload. Free, private, no signup.
Web & API
Generate htpasswd entries with bcrypt, Apache MD5 (apr1), SHA-1 & more. Get ready-to-paste Apache, nginx & Docker config. 100% in your browser — no upload.
Web & API
Generate Open Graph, Twitter Card & SEO meta tags with a live Google, Facebook & X preview. 100% free, in-browser, no signup — copy & paste the code.
Web & API
Stop counting hex digits. Free online traceparent decoder — runs in your browser, nothing uploaded. Trace ID, span ID, all 8 trace-flags bits, tracestate check, Datadog/X-Ray/B3 conversion.
Security Tools
Decrypt AES online — GCM/CBC/CTR, passphrase or raw key, auto-detects OpenSSL & CryptoJS "U2FsdGVkX1" format. 100% in-browser, keys never leave the page.
Security Tools
Free online AES encryption — AES-128/192/256, GCM/CBC/CTR, passphrase (PBKDF2) or raw key. Runs 100% in your browser; nothing is uploaded.