Skip to main content

Exact Match

Exact matching tells NGINX:

“Match this location only if the request URI is exactly the same—no more, no less.”

If the URI differs even by one character, the match fails.

location = /path {
...
}
  • = means exact match only
  • No regex
  • Case-sensitive
  • Highest priority in location matching

How Exact Matching Works

location = /login {
return 403;
}
Request URIMatch?Why
/loginYesExact
/login/NoExtra /
/login?user=1YesQuery string ignored
/LoginNoCase-sensitive

Query strings are ignored during location matching.

Priority: Exact Match Always Wins

NGINX location matching order:

  1. Exact match (=) ← highest priority
  2. Longest prefix match
  3. Regex match
  4. location / fallback

Once an exact match is found, NGINX stops searching immediately.

Protect a Sensitive URL

server {
listen 80;
server_name example.com;

location = /admin {
deny all;
}

location /admin/ {
auth_basic "Admin Area";
auth_basic_user_file /etc/nginx/.htpasswd;
}
}
RequestResult
/admin❌ Access denied
/admin/🔐 Auth required
/admin/settings🔐 Auth required

Exact match allows fine-grained control.

Exact Match vs Prefix Match

location = /about {
return 200 "Exact About";
}

location /about {
return 200 "Prefix About";
}
RequestMatched Location
/about= /about
/about//about
/about/team/about

Common Use Cases for Exact Matching

  1. Redirect a single URL
location = /old-page {
return 301 /new-page;
}
  1. Block a specific endpoint
location = /xmlrpc.php {
deny all;
}
  1. Optimize performance for hot URLs
location = /health {
access_log off;
return 200 "OK";
}
  1. Override application routes
location = /favicon.ico {
access_log off;
log_not_found off;
}

Exact Match with try_files

location = / {
try_files /index.html =404;
}
  • Applies only to /
  • Does not affect /anything-else

Common Mistakes

  • Expecting /path/ to match /path
  • Forgetting query strings don’t affect matching
  • Overusing exact matches where prefix is better
  • Thinking exact matches apply to subpaths