What if your website could instantly know the exact page a visitor wants, no guesswork needed?
Why Exact match (=) in Nginx? - Purpose & Use Cases
Start learning this pattern below
Jump into concepts and practice - no test required
Imagine you want your web server to respond only when the URL is exactly /home, not /home/ or /homepage. Without exact matching, your server might serve the wrong page or confuse users.
Manually checking every possible URL variation is slow and error-prone. You might accidentally allow unwanted URLs or block valid ones, causing broken pages or security issues.
Using the exact match = in nginx lets you tell the server to respond only when the URL matches exactly what you specify. This keeps your routing clean and precise without extra work.
location /home {
# matches /home, /home/, /homepage
}location = /home {
# matches only /home exactly
}This lets your server deliver the right content exactly when you want, improving user experience and security.
For example, an online store wants the URL /checkout to trigger the payment page only when typed exactly, avoiding confusion with /checkout/summary or /checkout-old.
Manual URL checks are slow and risky.
Exact match = in nginx ensures precise URL handling.
It improves site reliability and user trust.
Practice
= sign mean in an nginx location block?Solution
Step 1: Understand nginx location matching
The=sign in nginx location means the URL must match exactly the specified path.Step 2: Compare with other matching types
Other types like prefix matching uselocation /pathwithout=, which matches URLs starting with that path.Final Answer:
It matches the exact URL path only. -> Option BQuick Check:
Exact match = exact URL [OK]
- Thinking = matches URL prefixes
- Confusing = with regex matching
- Assuming = matches URLs containing the path
/about in nginx?Solution
Step 1: Recall nginx exact match syntax
Exact match useslocation = /path { }syntax, where=comes immediately afterlocation.Step 2: Check other options
location /about = { } places=after path, which is invalid. location ~ /about { } uses regex (~), not exact match. location /about { } is prefix match.Final Answer:
location = /about { } -> Option DQuick Check:
Exact match syntax = location = /path [OK]
- Placing = after the path
- Using regex (~) instead of = for exact match
- Omitting = for exact match
location = /test {
return 200 'Exact match';
}
location /test {
return 200 'Prefix match';
}What will be the response body when accessing URL
/test?Solution
Step 1: Identify matching location for /test
The URL/testmatches exactly thelocation = /testblock because of the exact match sign=.Step 2: Understand nginx location priority
Exact match locations have higher priority than prefix matches, so the first block is used and returns 'Exact match'.Final Answer:
Exact match -> Option AQuick Check:
Exact match location wins for exact URL [OK]
- Choosing prefix match response for exact URL
- Assuming 404 if exact match exists
- Confusing order of location blocks
location = /home {
proxy_pass http://backend;
}
location /home {
proxy_pass http://frontend;
}But requests to
/home are always sent to http://frontend. What is the likely problem?Solution
Step 1: Check syntax of exact match location
The exact match locationlocation = /home { ... }may have a syntax error like missing semicolon after proxy_pass, causing nginx to ignore it.Step 2: Consider nginx matching rules
Exact match locations have highest priority and should be matched first. If requests go to frontend, likely the exact match block is ignored due to a syntax error or config reload issue.Step 3: Identify common mistake
Often, missing semicolons or incorrect proxy_pass URL cause nginx to ignore the block silently.Final Answer:
The exact match location block is not matched because of a syntax error. -> Option AQuick Check:
Syntax errors cause nginx to ignore blocks [OK]
- Assuming order affects exact match priority
- Missing semicolon after proxy_pass
- Confusing trailing slash importance
/special. Which nginx config snippet correctly achieves this without affecting other URLs starting with /special?Solution
Step 1: Understand exact match requirement
To serve only the exact URL/special, uselocation = /specialwhich matches exactly that path.Step 2: Analyze other options
location /special { root /var/www/special; } matches any URL starting with/special. location ~ /special { root /var/www/special; } uses regex to match URLs containing /special anywhere. location ^~ /special { root /var/www/special; } uses prefix match with ^~, which matches prefixes but not exact only.Final Answer:
location = /special { root /var/www/special; } -> Option CQuick Check:
Exact match = location = /path [OK]
- Using prefix match for exact URL
- Overcomplicating with regex
- Confusing ^~ with exact match
