Nginx Location Block Priority Tester & Match Simulator

Nginx Location Block Priority Tester & Match Simulator

Interactive C-Core Simulator

Test and simulate Nginx location block matching order (= exact, ^~ preferential prefix, ~ regex, ~* case-insensitive, / prefix) with request URIs.

Presets:
Live Request URI Simulator
MATCH:location ^~ /static/(0.34ms)
GET
Fast Tests:
#1
log_not_found off; ...Exact match bypasses all other rules instantly
#2
WINNER
alias /var/www/spa/static/; ...Preferential prefix: Skips all regex tests for static build assets
#3
expires 7d; ...Regex for root-level and un-prefixed media assets
#4
proxy_pass http://backend_upstream; ...Preferential prefix: Directs all /api/ endpoints to backend
#5
root /var/www/spa/dist; ...Catch-all fallback prefix for client-side HTML5 history routing
Locations: 5Exact (=): 1Pref (^~): 2Regex (~): 1Prefix (/): 1
Lines: 55 · Bytes: 1842B
MATCH RESOLVED IN 0.34msHTTP 200 PROCESSED
location ^~ /static/
Phase 2: Preferential Prefix (^~)

Longest matching prefix rule has "^~" modifier. Regular expression evaluation was completely bypassed.

Purpose: Preferential prefix: Skips all regex tests for static build assets

Active Directives Executed:
alias /var/www/spa/static/;
expires 365d;
add_header Cache-Control "public, immutable";

Step-by-Step Evaluation Trace (6 Steps)

Evaluated in strictly RFC-ordered phases
URI Normalization & Extractionnormalization

Decoded percent-encodings, collapsed redundant slashes, and stripped query string.

Request URI: "/static/css/bundle.css"
Normalized:  "/static/css/bundle.css"
Query:       ""
Tier 1: Exact (= /favicon.ico)exact

URI "/static/css/bundle.css" != "/favicon.ico".

Standard Prefix: ^~ /static/ [8]prefix scan

URI begins with prefix "/static/" (length 8).

Standard Prefix: ^~ /api/prefix scan

URI "/static/css/bundle.css" does not start with "/api/".

Standard Prefix: (standard) / [1]prefix scan

URI begins with prefix "/" (length 1).

Tier 2: No-Regex Prefix (^~ /static/)preferential check

Longest matching prefix rule has "^~" modifier. Regular expression evaluation was completely bypassed.

location ^~ /static/ {
  alias /var/www/spa/static/;
  expires 365d;
  add_header Cache-Control "public, immutable";
}
Result: ^~ /static/|Latency: 0.34ms
Regex Checked: 0Prefix Checked: 3

RFC & Nginx Core Algorithm Fidelity

Simulates exact Nginx C-core matching mechanics: = exact match, ^~ preferential prefix, regex order of appearance, and longest standard prefix fallback.

Zero Server Leaks & Zero Latency

All URI normalization, regular expression parsing, and priority sorting execute 100% client-side in browser memory with zero network overhead.

Production Config Generation

Instantly export clean, validated Nginx server configuration blocks with matching documentation comments and diagnostic curl verification commands.

Technical Reference & Architecture Guide

Nginx Location Match Tester — Reference Guide

Developer utility for nginx-location-match-tester.

Key Parameters & Controls

uristring

Target request URI path (excluding protocol and domain) evaluated against configured location blocks.

Default: "/"
modifier'=' | '^~' | '~' | '~*' | ''

Nginx location modifier controlling evaluation priority, regular expression bypass, and early termination.

Default: ""
pathstring

URI prefix pattern or PCRE-compatible regular expression tested against the normalized request URI.

Default: "/"
outputTab'trace' | 'batch' | 'ladder' | 'conf'

Active inspection panel displaying step-by-step match traces, batch test assertions, priority ladders, or raw nginx.conf syntax.

Default: "trace"
inputMode'visual' | 'raw'

Configuration editing mode toggling between interactive location block cards and direct raw nginx.conf text parsing.

Default: "visual"

Pro Tips & Best Practices

Prefer ^~ for Static Assets

Using location ^~ /static/ prevents expensive regular expression scans from executing when serving static files, bypassing all subsequent regex directives like ~* \.(jpg|png|css)$.

Order Regex by Traffic Volume

Because Nginx halts regex evaluation at the first matching ~ or ~* block in physical file order, place high-traffic endpoints before rarely accessed regex rules.

Use Exact Match for Root Hit

Applying location = / short-circuits the evaluation cycle for homepage requests in high-throughput reverse proxies, avoiding full prefix tree traversals.

Encode URIs Before Testing

Nginx decodes percent-encoded characters like %20 and collapses consecutive slashes into a single slash before matching. Always test both raw and encoded variants.

Common Gotchas & Troubleshooting

Regex location unexpectedly overrides a longer prefix block

Prefix locations without ^~ only act as fallbacks if no regular expression matches. Add the ^~ modifier to the prefix block to stop regex evaluation, or reorder the regex rules.

Query string parameters in tested URI fail to match location path

Nginx matches location directives strictly against the normalized $uri, stripping query parameters ($args). Move query string assertions to map directives or rewrite rules instead of location paths.

Case-sensitive regex ~ fails on mixed-case file uploads

Replace the case-sensitive ~ modifier with case-insensitive ~* when handling client uploads or file extensions across case-insensitive file systems.

Frequently Asked Questions

What is the exact execution priority order among Nginx location modifiers?▼

Nginx evaluates location directives in five distinct phases: 1) Exact match (=) terminates immediately if matched; 2) Prefix match search identifies the longest matching prefix; 3) If the longest prefix uses ^~, regex evaluation is skipped and it wins; 4) Regular expressions (~ and ~*) are evaluated sequentially from top to bottom, and the first match wins; 5) If no regex matches, the longest prefix match from step 2 is selected.

How does Nginx normalize request URIs before matching location blocks?▼

Prior to location matching, Nginx decodes percent-encoded characters (e.g., %20 to space, %2F to /), resolves relative path segments . and .., and collapses multiple consecutive slashes (//) into a single slash. Query strings following ? are stripped and stored separately in $query_string.

Why doesn't location matching support query string parameters or fragment identifiers?▼

RFC 3986 distinguishes between URI path and query/fragment components. Nginx adheres to this separation by matching location blocks solely against the request path. To branch routing logic on query arguments, inspect $args or $arg_<name> within rewrite rules or map directives.

Does the physical order of prefix location blocks in nginx.conf affect routing?▼

No. Unlike regular expression locations (~ and ~*), standard prefix blocks ("") and ^~ are sorted internally into a tree by Nginx and evaluated to find the longest matching prefix regardless of their order in the configuration file.

Are parsed configuration files and test cases stored on external servers?▼

No. All URI normalization, location matching algorithms, batch test executions, and configuration generation run strictly client-side within the browser's JavaScript engine. No configuration snippets or URI paths are transmitted to external servers.

Related Tools & Utilities

All Tools →
Cloudflare Pages & Workers _headers & _redirects GeneratorDeveloper

Generate Cloudflare Pages _headers and _redirects configuration files with HSTS, CSP, X-Frame-Options, caching rules, and 301/302 URL redirects.

Open tool→
Vercel Configuration (vercel.json) Interactive BuilderDeveloper

Build vercel.json configuration files with custom routing rewrites, redirects, headers, cleanUrls, trailingSlash, and cron job declarations.

Open tool→
ESLint Flat Config (eslint.config.mjs) Interactive BuilderDeveloper

Generate modern ESLint 9+ flat configuration files (eslint.config.mjs / .js) with TypeScript, React, Next.js, Vue, Prettier, and custom plugin rules.

Open tool→
SemVer Range & Version Satisfaction CalculatorDeveloper

Test semantic versioning (SemVer) ranges (caret ^, tilde ~, hyphens, x-ranges, pre-releases) and evaluate package version satisfaction in real-time.

Open tool→
Cron Expression Parser & Schedule ExplainerDeveloper

Translate cryptic 5-part and 6-part cron expressions into plain English explanations and predict the next 10 upcoming run dates.

Open tool→
Interactive JavaScript Regular Expression (RegEx) Tester & MatcherDeveloper

Test, debug, and benchmark regular expressions in real-time with capture group extraction, replacement previews, regex flag toggles, and syntax explanations.

Open tool→