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.

Practice

1. Which type of location block does nginx check first when matching a request URL?

easy

A. Prefix match without any modifier

B. Exact match using = modifier

C. Regular expression match using ~ or ~*

D. Prefix match with ^~ modifier

Solution

1. Step 1: Understand nginx location matching order

   nginx first looks for an exact match location block marked with =.

2. Step 2: Confirm priority of exact match

   If an exact match is found, nginx immediately uses it without checking other blocks.

3. Final Answer:

   Exact match using = modifier -> Option B

4. Quick Check:

   Exact match = first checked [OK]

Hint: Exact match with = is always checked first [OK]

Common Mistakes:

• Thinking prefix matches are checked before exact matches
• Confusing ^~ modifier priority
• Assuming regex matches are checked first

2. Which of the following is the correct syntax for a location block that uses a case-insensitive regular expression match?

easy

A. location ~ "/images/" { }

B. location ^~ "/images/" { }

C. location = "/images/" { }

D. location ~* "/images/" { }

Solution

1. Step 1: Identify regex modifiers in nginx

   Modifier ~* means case-insensitive regex match.

2. Step 2: Match syntax to case-insensitive regex

   location ~* "/images/" { } uses ~* correctly for case-insensitive regex.

3. Final Answer:

   location ~* "/images/" { } -> Option D

4. Quick Check:

   ~* = case-insensitive regex [OK]

Hint: Use ~* for case-insensitive regex location [OK]

Common Mistakes:

• Using ~ instead of ~* for case-insensitive match
• Confusing ^~ with regex modifiers
• Using = for regex match

3. Given this nginx config snippet, which location block will handle the request for URL /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 prefix match'; }

medium

A. Exact match location = /images/logo.png

B. Prefix match location ^~ /images/

C. Regex match location ~* \.(png|jpg)$

D. Default prefix match location /

Solution

1. Step 1: Check for exact match

   Request URL is /images/logo.png, which exactly matches = /images/logo.png.

2. Step 2: Confirm nginx uses exact match first

   nginx uses exact match location immediately without checking others.

3. Final Answer:

   Exact match location = /images/logo.png -> Option A

4. Quick Check:

   Exact match wins over prefix and regex [OK]

Hint: Exact match location = always wins first [OK]

Common Mistakes:

• Choosing ^~ prefix match over exact match
• Assuming regex match has higher priority
• Ignoring exact match syntax

4. You have this nginx config:

location /images/ {
  return 200 'Prefix match';
}
location ^~ /images/ {
  return 200 'Prefix ^~ match';
}

But requests to /images/photo.jpg return 'Prefix match' instead of 'Prefix ^~ match'. What is the likely cause?

medium

A. Two prefix locations with same path cause nginx to pick first declared

B. ^~ modifier is ignored if regex location exists

C. Regex location always has higher priority than ^~

D. Syntax error in ^~ location block

Solution

1. Step 1: Understand prefix location conflicts

   Two prefix locations with identical paths cause nginx to use the first declared one.

2. Step 2: Check config order

   The location /images/ block appears before location ^~ /images/, so nginx picks the first.

3. Final Answer:

   Two prefix locations with same path cause nginx to pick first declared -> Option A

4. Quick Check:

   First prefix wins if paths identical [OK]

Hint: Avoid duplicate prefix locations; nginx picks first declared [OK]

Common Mistakes:

• Assuming ^~ always overrides prefix regardless of order
• Thinking regex always beats ^~
• Believing syntax error causes this behavior

5. You want nginx to serve static files under /static/ using a prefix match but avoid regex checks for these URLs for performance. Which configuration achieves this best?

hard

A. location /static/ { root /var/www/static; }

B. location ~* /static/ { root /var/www/static; }

C. location ^~ /static/ { root /var/www/static; }

D. location = /static/ { root /var/www/static; }

Solution

1. Step 1: Understand ^~ modifier effect

   Using ^~ tells nginx to stop searching regex locations if this prefix matches.

2. Step 2: Apply to static files

   Setting location ^~ /static/ ensures static files served quickly without regex overhead.

3. Final Answer:

   location ^~ /static/ { root /var/www/static; } -> Option C

4. Quick Check:

   ^~ prefix disables regex checks [OK]

Hint: Use ^~ prefix to skip regex for performance [OK]

Common Mistakes:

• Using plain prefix allows regex checks
• Using regex location unnecessarily
• Using exact match = for directory prefix