Exact match (=) in Nginx - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
We want to understand how the time it takes for nginx to find an exact match in its configuration grows as the number of rules increases.
Specifically, how does nginx check for an exact match when processing requests?
Analyze the time complexity of the following nginx exact match configuration snippet.
location = /about {
return 200 "About page";
}
location = /contact {
return 200 "Contact page";
}
location / {
return 404;
}
This snippet defines exact match locations for "/about" and "/contact" URLs, and a default catch-all location.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: nginx checks each exact match location one by one to find a matching URL.
- How many times: It compares the request URI against each exact match rule until it finds a match or exhausts all.
As the number of exact match locations grows, nginx must check more rules one after another.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | Up to 10 string comparisons |
| 100 | Up to 100 string comparisons |
| 1000 | Up to 1000 string comparisons |
Pattern observation: The number of checks grows directly with the number of exact match rules.
Time Complexity: O(n)
This means the time to find an exact match grows linearly as you add more exact match locations.
[X] Wrong: "nginx finds exact matches instantly no matter how many rules there are."
[OK] Correct: nginx checks exact matches one by one, so more rules mean more checks and longer time.
Understanding how nginx processes exact matches helps you reason about request handling speed and configuration design in real projects.
"What if nginx used a hash table for exact matches? How would the time complexity change?"
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
