Why location matching controls request routing in Nginx - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a location block that matches requests to the root URL.

Nginx

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

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

A/

B~

Croot

Ddefault

Attempts:

3 left

💡 Hint

Common Mistakes

Using '~' which is for regex matching, not root path.

Using 'root' which is not a valid location path.

The / location matches the root URL path, routing requests to the backend.

2fill in blank

medium

Complete the code to match requests starting with /images/ using a prefix location.

Nginx

location [1] {
    root /var/www/images;
}

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

A/images/

B~ /images/

C^~ /images/

D/img/

Attempts:

3 left

💡 Hint

Common Mistakes

Using regex (~) when prefix match is intended.

Using a different path like '/img/' which won't match '/images/' requests.

The prefix /images/ matches all requests starting with that path.

3fill in blank

hard

Fix the error in the regex location that matches .php files.

Nginx

location [1] {
    fastcgi_pass unix:/var/run/php.sock;
}

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

A^~ \.php$

B/\.php$/

C~* \.php$

D~ \.php$

Attempts:

3 left

💡 Hint

Common Mistakes

Using ~* which is case-insensitive and may not be desired.

Using slashes around regex which nginx does not require.

The ~ prefix defines a case-sensitive regex match for .php files.

4fill in blank

hard

Fill both blanks to create a location block that matches requests starting with /api/ and disables regex matching.

Nginx

location [1] [2] {
    proxy_pass http://api_backend;
}

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

A^~

B/api/

C~

D~*

Attempts:

3 left

💡 Hint

Common Mistakes

Using regex (~ or ~*) which allows regex matching.

Using just /api/ without ^~ which allows regex to override.

The ^~ prefix tells nginx to match the prefix /api/ and skip regex checks.

5fill in blank

hard

Fill the two blanks to define a location block that matches exactly /status and returns 200 with a message.

Nginx

location [1] /status {
    return [2] 'OK';
}

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

A=

B^~

C200

D~

Attempts:

3 left

💡 Hint

Common Mistakes

Using regex (~) instead of exact match (=).

Omitting the return code or using wrong code.

The = prefix matches the exact URI /status, which has the highest priority and skips regex locations. return 200 'OK'; sends a success response.

Practice

1. What does the location directive in nginx control?

easy

A. How nginx routes incoming requests based on URL patterns

B. The server's IP address configuration

C. The database connection settings

D. The logging format for errors

Solution

1. Step 1: Understand the role of location in nginx

   The location directive defines how nginx matches URLs to decide where to send requests.

2. Step 2: Identify what location controls

   It controls routing of requests, not server IP, database, or logging.

3. Final Answer:

   How nginx routes incoming requests based on URL patterns -> Option A

4. Quick Check:

   Location controls routing = B [OK]

Hint: Location matches URLs to route requests [OK]

Common Mistakes:

• Confusing location with server IP settings
• Thinking location controls database connections
• Assuming location affects logging formats

2. Which of the following is the correct syntax to define a prefix location block in nginx?

easy

A. location ~ /example { }

B. location = /example { }

C. location /example { }

D. location ! /example { }

Solution

1. Step 1: Review nginx location syntax

   Prefix locations use location /path { } without modifiers.

2. Step 2: Identify correct prefix syntax

   location /example { } is correct for prefix matching.

3. Final Answer:

   location /example { } -> Option C

4. Quick Check:

   Prefix location syntax = A [OK]

Hint: Prefix location has no modifier, just path [OK]

Common Mistakes:

• Using '=' which means exact match, not prefix
• Using '~' which means regex match
• Using '!' which is invalid syntax

3. Given this nginx config snippet:

location /images/ {
  root /data;
}
location /images/thumbnails/ {
  root /thumbs;
}

Which root directory will nginx use for the request /images/thumbnails/pic.jpg?

medium

A. Default root directory

B. /data

C. Both /data and /thumbs

D. /thumbs

Solution

1. Step 1: Understand location matching order

   nginx chooses the most specific matching location block for the URL.

2. Step 2: Compare matching locations for /images/thumbnails/pic.jpg

   Both /images/ and /images/thumbnails/ match, but /images/thumbnails/ is more specific.

3. Final Answer:

   /thumbs -> Option D

4. Quick Check:

   Most specific location wins = A [OK]

Hint: Longest matching prefix location is chosen [OK]

Common Mistakes:

• Choosing the first matching location instead of the most specific
• Assuming both roots apply simultaneously
• Ignoring location specificity

4. You have these location blocks:

location /app/ {
  proxy_pass http://backend1;
}
location ~ /app/ {
  proxy_pass http://backend2;
}

Requests to /app/test always go to backend1. Why?

medium

A. Requests to /app/test do not match either location

B. Prefix locations have higher priority than regex locations

C. The config has a syntax error

D. Regex locations always override prefix locations

Solution

1. Step 1: Recall nginx location matching priority

   nginx first matches prefix locations, then regex locations only if no prefix matches.

2. Step 2: Analyze given config

   Since /app/ prefix matches /app/test, nginx uses that before regex ~ /app/.

3. Final Answer:

   Prefix locations have higher priority than regex locations -> Option B

4. Quick Check:

   Prefix beats regex if prefix matches = D [OK]

Hint: Prefix location matches first, regex only if no prefix match [OK]

Common Mistakes:

• Thinking regex always overrides prefix
• Assuming syntax error causes this
• Believing request doesn't match any location

5. You want requests to /api/v1/ to go to backend_v1 and requests to /api/ to go to backend_default. Which config correctly routes requests?

hard

A. location /api/v1/ { proxy_pass http://backend_v1; } location /api/ { proxy_pass http://backend_default; }

B. location ~ /api/ { proxy_pass http://backend_v1; } location /api/ { proxy_pass http://backend_default; }

C. location /api/ { proxy_pass http://backend_default; } location ~ /api/v1/ { proxy_pass http://backend_v1; }

D. location = /api/v1/ { proxy_pass http://backend_v1; } location /api/ { proxy_pass http://backend_default; }

Solution

1. Step 1: Understand location matching order

   nginx chooses the most specific prefix location for a request.

2. Step 2: Use more specific prefix /api/v1/

   Since /api/v1/ is longer/more specific than /api/, nginx selects it for matching requests.

3. Step 3: Check options

   location /api/v1/ { proxy_pass http://backend_v1; } location /api/ { proxy_pass http://backend_default; } uses prefix locations where the longer one wins, correctly routing requests.

4. Final Answer:

   location /api/v1/ { proxy_pass http://backend_v1; } location /api/ { proxy_pass http://backend_default; } -> Option A

5. Quick Check:

   Specific location before general = C [OK]

Hint: Place more specific location before general prefix [OK]

Common Mistakes:

• Placing general location before specific causing wrong routing
• Using regex unnecessarily for simple prefix matching
• Using exact match which only matches exact URL