Nginx Location Match Tester
Paste an nginx config and a request URI to see which location block wins and why. Follows the documented nginx match order — exact, ^~, regex in file order, longest prefix — with a full decision trace. Runs entirely in your browser.
Loading tool...
What is Nginx Location Match Tester?
The Nginx Location Match Tester is a static analyzer for one specific question: given this request URI, which location block will nginx select, and why. Paste the location blocks from your config together with a URI, and the tool normalizes the URI the way nginx does — percent-decoding, collapsing duplicate slashes and resolving dot segments — then replays the documented decision order: an exact match wins outright, otherwise the longest matching prefix is remembered and wins immediately if it carries ^~, otherwise regex locations are tried in order of appearance and the first match wins, otherwise the remembered prefix is used. Every stage is shown as a numbered trace, and every location block gets a verdict explaining why it won or lost.
Key Benefits
- Turns a confusing routing bug into an explicit, ordered explanation instead of a guess about which block should win.
- Surfaces the normalization step, so percent-escapes, duplicate slashes and dot segments stop being invisible reasons for a surprising match.
- Makes ^~ visible as a deliberate short circuit rather than a mysterious reason your regexes stopped running.
- Exposes regex ordering problems, because the first match in file order wins rather than the most specific pattern.
- States its own limits as warnings — nested and named locations, if blocks and PCRE-only regex syntax — instead of returning a confident wrong answer.
Common Use Cases
- •Debugging a request that lands in a catch-all or the wrong location block after a config change.
- •Reviewing a config before deploy to confirm which block a sensitive path such as /admin/ or /api/ actually reaches.
- •Teaching or learning the nginx match order with a real config and immediate, step-by-step feedback.
- •Checking whether a ^~ prefix has silently disabled a regex location that a teammate expected to run.
- •Understanding why a percent-encoded or dot-segment URI bypasses a path-based rule.
How to Test Which nginx location Block Wins
- Paste your location blocks: Copy the location part of your nginx config. The server block wrapper is optional; comments and quoted strings are handled. Or load one of the built-in examples to start.
- Enter the request URI: Type the path you want to test, for example /api/v2/users?id=7. Query strings, percent-escapes, duplicate slashes and dot segments are normalized first, exactly as nginx does before matching.
- Read the winning block and the trace: The result panel names the selected location with its modifier and line number. The decision trace below it lists every stage, including the stages that were skipped and the reason they were skipped.
- Check the candidate table and the warnings: Every location block is listed with the reason it won or lost, so you can see which rule pre-empted the one you expected. Warnings call out nested locations, named locations, if blocks and PCRE-only regex syntax that this analyzer does not model.
Key Features
- Replays the documented nginx order: exact match first, then ^~ against the regex pass, then regexes in file order, then the longest prefix.
- Normalizes the request URI the way nginx does — percent-decoding, collapsing duplicate slashes and resolving dot segments — before comparing anything.
- Shows a numbered decision trace with every stage that ran, was skipped or was short-circuited, so the outcome is explained rather than asserted.
- Lists every location block with its verdict: matched and won, matched and lost to a more specific rule, or never matched at all.
- Reports its own limits as warnings — nested locations, named locations, if blocks and PCRE-only regex syntax — instead of guessing an answer.
- Flags the cases that bite in production: a missing catch-all, an unanchored regex, or a ^~ prefix that silently disables your regexes.