Preferential prefix match (^~) in Nginx - Cheat Sheet & Quick Revision

Recall & Review

beginner

What does the ^~ prefix mean in an nginx location block?

It tells nginx to do a preferential prefix match. If this prefix matches, nginx stops searching further and uses this location block.

intermediate

How does ^~ differ from a normal prefix match in nginx?

Normal prefix matches are checked before regex matches, but regex can override them. ^~ stops regex checks if matched, giving it higher priority.

intermediate

Which location block will nginx choose if both ^~ /images/ and ~* \.jpg$ match a request for /images/pic.jpg?

nginx will choose the ^~ /images/ block because ^~ stops regex checks when matched.

beginner

Write a simple nginx location block using ^~ to serve all requests starting with /static/ from a specific folder.

location ^~ /static/ { root /var/www/static_files; }

intermediate

Why would you use ^~ instead of a regex location in nginx?

Because ^~ is faster and simpler for prefix matching, and it avoids regex overhead when you want to prioritize a path prefix.

What happens when nginx finds a ^~ prefix match?

A It ignores the prefix and uses the default location.

B It stops searching and uses that location block.

C It continues to check regex locations.

D It returns a 404 error.

The ^~ prefix tells nginx to stop searching further and use this location if matched.

Which location block has higher priority in nginx?

A location ^~ /images/

B location /images/

C location ~* \.jpg$

D location = /images/

^~ prefix has higher priority than normal prefix or regex matches.

If no ^~ prefix matches, what does nginx do next?

A Stops processing.

B Returns 404 error.

C Checks regex locations.

D Uses the default location.

nginx checks regex locations if no ^~ or exact prefix matches are found.

Which is true about location ^~ /api/?

A It ignores requests starting with /api/.

B It only matches exact /api/ requests.

C It matches regex patterns inside /api/.

D It matches any request starting with /api/ and stops regex checks.

^~ matches prefix and stops further regex location checks.

Why is ^~ preferred over regex for simple prefix matching?

A It is faster and simpler.

B It supports complex patterns.

C It always returns 404.

D It disables caching.

^~ is optimized for prefix matching and avoids regex overhead.

Explain how nginx processes location blocks when a request URL matches multiple patterns including a ^~ prefix.

Think about the order nginx uses to find the best location.

Describe a scenario where using ^~ in nginx location blocks improves performance or behavior.

Consider static file serving or common URL prefixes.

Practice

1. What does the ^~ prefix in an nginx location block do?

easy

A. It tells nginx to prefer this prefix match and skip regex checks.

B. It makes nginx perform a case-insensitive match.

C. It enables regex matching for the location.

D. It disables all other location matches.

Solution

1. Step 1: Understand nginx location matching

   nginx checks location blocks in order: exact, prefix, regex. The ^~ prefix tells nginx to prefer this prefix match and stop searching further.

2. Step 2: Effect of ^~ prefix

   This means nginx will not check regex locations if this prefix matches, improving performance for static or specific URL prefixes.

3. Final Answer:

   It tells nginx to prefer this prefix match and skip regex checks. -> Option A

4. Quick Check:

   ^~ means prefer prefix and skip regex [OK]

Hint: Remember ^~ means prefer prefix, skip regex checks [OK]

Common Mistakes:

• Confusing ^~ with regex (~ or ~*)
• Thinking ^~ makes match case-insensitive
• Assuming ^~ disables all other matches

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

easy

A. location ~ /images/ { }

B. location ^~ /images/ { }

C. location ^ /images/ { }

D. location ~^ /images/ { }

Solution

1. Step 1: Identify correct prefix syntax

   The preferential prefix match uses ^~ immediately after the word location.

2. Step 2: Check each option

   location ^~ /images/ { } uses location ^~ /images/ { } which is correct. location ~^ /images/ { } mixes regex and prefix incorrectly. location ^ /images/ { } uses invalid ^ alone. location ~ /images/ { } uses regex ~ which is not preferential prefix.

3. Final Answer:

   location ^~ /images/ { } -> Option B

4. Quick Check:

   Correct syntax for preferential prefix = location ^~ [OK]

Hint: Look for 'location ^~' to define preferential prefix [OK]

Common Mistakes:

• Using ~ or ~* instead of ^~ for prefix match
• Placing ^~ after the path instead of after location
• Omitting the space between ^~ and path

3. Given this nginx config snippet, which location block will handle the request for URL /static/css/style.css?

location /static/ {
  root /var/www/html;
}
location ^~ /static/css/ {
  root /var/www/css_files;
}
location ~* \.css$ {
  root /var/www/css_regex;
}

medium

A. The block with location /static/

B. The block with location ~* \.css$

C. No block matches; default server root is used

D. The block with location ^~ /static/css/

Solution

1. Step 1: Identify matching locations for URL

   The URL /static/css/style.css matches all three locations: prefix /static/, preferential prefix ^~ /static/css/, and regex ~* \.css$.

2. Step 2: Apply nginx matching order with ^~

   nginx prefers exact match first, then ^~ prefix matches, then regex. Since ^~ /static/css/ matches, nginx stops searching and uses this block.

3. Final Answer:

   The block with location ^~ /static/css/ -> Option D

4. Quick Check:

   ^~ prefix match stops regex checks [OK]

Hint: ^~ prefix match beats regex for matching URLs [OK]

Common Mistakes:

• Choosing regex block because of file extension
• Ignoring ^~ priority over regex
• Assuming longest prefix always wins without ^~

4. You have this nginx config:

location ^~ /app/ {
  proxy_pass http://backend;
}
location ~ /app/secure/ {
  proxy_pass http://secure_backend;
}

But requests to /app/secure/login are handled by http://backend. What is the problem?

medium

A. The regex location syntax is incorrect and ignored.

B. The proxy_pass directive is missing a trailing slash.

C. The ^~ prefix match prevents regex location from being used.

D. nginx does not support mixing ^~ and regex locations.

Solution

1. Step 1: Understand nginx location matching with ^~

   The ^~ prefix tells nginx to prefer this prefix match and skip regex checks if matched.

2. Step 2: Analyze why regex location is ignored

   Since /app/secure/login matches ^~ /app/, nginx stops searching and uses that block, ignoring the regex location.

3. Final Answer:

   The ^~ prefix match prevents regex location from being used. -> Option C

4. Quick Check:

   ^~ stops regex location checks [OK]

Hint: ^~ disables regex locations if prefix matches [OK]

Common Mistakes:

• Thinking regex overrides ^~ prefix
• Believing proxy_pass syntax causes this issue
• Assuming nginx can't mix ^~ and regex locations

5. You want nginx to serve static files from /var/www/static for URLs starting with /static/, and use regex locations for other patterns. Which config correctly uses ^~ to optimize performance?

hard

A. location ^~ /static/ {
root /var/www/static;
}
location ~ \.php$ {
fastcgi_pass unix:/run/php.sock;
}

B. location /static/ {
root /var/www/static;
}
location ^~ ~ \.php$ {
fastcgi_pass unix:/run/php.sock;
}

C. location ~ ^/static/ {
root /var/www/static;
}
location ~ \.php$ {
fastcgi_pass unix:/run/php.sock;
}

D. location ~* /static/ {
root /var/www/static;
}
location ^~ \.php$ {
fastcgi_pass unix:/run/php.sock;
}

Solution

1. Step 1: Use ^~ for static file prefix

   To prioritize static files under /static/ and skip regex checks, use location ^~ /static/ { root /var/www/static; }.

2. Step 2: Define regex location for PHP files

   Regex location for PHP files is defined with location ~ \.php$ { ... }. This will be checked only if ^~ prefix does not match.

3. Step 3: Validate options

   location ^~ /static/ { root /var/www/static; } location ~ \.php$ { fastcgi_pass unix:/run/php.sock; } correctly uses ^~ prefix for static and regex for PHP. Other options misuse syntax or combine prefixes incorrectly.

4. Final Answer:

   location ^~ /static/ { root /var/www/static; } with regex location for PHP -> Option A

5. Quick Check:

   Use ^~ for static prefix, regex for others [OK]

Hint: Use ^~ for static prefixes, regex for patterns [OK]

Common Mistakes:

• Mixing ^~ with regex in one location
• Using regex (~) for static prefix
• Incorrect syntax combining ^~ and regex