Location matching priority order in Nginx - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define an exact match location in nginx.

Nginx

location [1] /exact {
    proxy_pass http://backend;
}

Drag options to blanks, or click blank then click option'

A~

B^~

C=

D~*

Attempts:

3 left

💡 Hint

Common Mistakes

Using ~ or ~* instead of = for exact match

Using ^~ which is for prefix match, not exact

The = modifier defines an exact match location in nginx.

2fill in blank

medium

Complete the code to define a case-insensitive regular expression location.

Nginx

location [1] \.jpg$ {
    root /images;
}

Drag options to blanks, or click blank then click option'

A~

B~*

C=

D^~

Attempts:

3 left

💡 Hint

Common Mistakes

Using ~ instead of ~* for case-insensitive matching

Using = or ^~ which are not regex modifiers

The ~* modifier defines a case-insensitive regex location in nginx.

3fill in blank

hard

Fix the error in the location block to make it a prefix match with higher priority.

Nginx

location [1] /images/ {
    root /data;
}

Drag options to blanks, or click blank then click option'

A=

B~

C~*

D^~

Attempts:

3 left

💡 Hint

Common Mistakes

Using = which is exact match, not prefix

Using ~ or ~* which are regex modifiers

The ^~ modifier defines a prefix match with higher priority than regex.

4fill in blank

hard

Fill both blanks to create a regex location that matches .png files case-sensitively.

Nginx

location [1] \.png$ {
    root [2];
}

Drag options to blanks, or click blank then click option'

A~

B/var/www/images

C/usr/share/nginx/html

D~*

Attempts:

3 left

💡 Hint

Common Mistakes

Using ~* for case-insensitive instead of ~

Choosing wrong root directory

The ~ modifier is for case-sensitive regex. The root path is set to /var/www/images.

5fill in blank

hard

Fill all three blanks to create a location block that matches exactly /api, proxies to backend, and sets a header.

Nginx

location [1] /api {
    proxy_pass [2];
    proxy_set_header [3] $host;
}

Drag options to blanks, or click blank then click option'

A=

Bhttp://backend_server

CHost

D~

Attempts:

3 left

💡 Hint

Common Mistakes

Using ~ instead of = for exact match

Wrong proxy_pass URL

Incorrect header name

The = modifier is for exact match. proxy_pass points to backend URL. proxy_set_header Host $host; sets the Host header.

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