Location matching priority order in Nginx - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding NGINX location matching priority

In NGINX, multiple location blocks can match a request URI. Which type of location block has the highest priority when matching a request?

A A location with the <code>^~</code> prefix (prefix match with no regex check)

B A location with the <code>~</code> prefix (case-sensitive regex)

C A location with the <code>=</code> prefix (exact match)

D A location without any prefix (standard prefix match)

💡 Hint

Exact matches are checked before regex or prefix matches.

NGINX first checks for exact matches (=), then ^~ prefix matches, then regex matches (~ or ~*), and finally standard prefix matches.

💻 Command Output

intermediate

Output of NGINX location matching with multiple blocks

Given this NGINX configuration snippet, what will be the response body when requesting /images/logo.png?

location = /images/logo.png {
  return 200 'Exact match';
}
location ^~ /images/ {
  return 200 'Prefix match';
}
location ~* \.(png|jpg)$ {
  return 200 'Regex match';
}
location / {
  return 200 'Default match';
}

A Default match

B Prefix match

C Regex match

D Exact match

💡 Hint

Check which location matches exactly the requested URI.

The = /images/logo.png location matches the URI exactly, so it is chosen before any prefix or regex matches.

🔀 Workflow

advanced

Order of NGINX location matching steps

Arrange the following NGINX location matching steps in the correct order of evaluation when a request arrives.

A 1,2,3,4

B 2,1,3,4

C 1,3,2,4

D 3,1,2,4

💡 Hint

Exact matches are checked first, then prefix with ^~, then regex, then standard prefix.

NGINX first tries exact matches, then prefix matches with ^~, then regex matches, and finally standard prefix matches.

❓ Troubleshoot

advanced

Why is my regex location not matching in NGINX?

You have these location blocks:

location ^~ /api/ {
  proxy_pass http://backend;
}
location ~ /api/v1/ {
  proxy_pass http://v1-backend;
}

Requests to /api/v1/users are always handled by http://backend. Why?

A Because regex locations always have higher priority than prefix locations

B Because <code>^~</code> prefix locations take priority over regex locations

C Because the regex location is invalid syntax

D Because <code>proxy_pass</code> is not allowed in regex locations

💡 Hint

Check the priority order of ^~ vs regex locations.

Locations with ^~ prefix are checked before regex locations. So the /api/ prefix location matches first and stops further regex checks.

✅ Best Practice

expert

Choosing location blocks for performance and clarity

You want to serve static files under /static/ and API requests under /api/. You also have some regex locations for specific API versions. Which configuration approach is best for performance and clarity?

A Use <code>location ^~ /static/</code> for static files, <code>location ^~ /api/</code> for API, and regex locations only for versioned API paths

B Use only regex locations for all paths to have consistent matching

C Use <code>location /</code> for everything and check paths inside application code

D Use <code>location = /static/</code> and <code>location = /api/</code> exact matches only

💡 Hint

Think about how NGINX prioritizes location blocks and how to avoid unnecessary regex checks.

Using ^~ prefix locations for static and API paths avoids regex evaluation for those prefixes, improving performance. Regex locations are reserved for specific cases.