Wildcard and regex server names in Nginx - Time & Space Complexity
When nginx receives a request, it matches the server name to find the right configuration. This matching can use wildcards or regular expressions.
We want to understand how the time to find the matching server grows as the number of server names increases.
Analyze the time complexity of the following nginx server name matching snippet.
server {
server_name example.com *.example.com ~^www\d+\.example\.com$;
# ... other config ...
}
server {
server_name api.example.com;
# ... other config ...
}
server {
server_name ~^blog\.(.+)\.example\.com$;
# ... other config ...
}
This snippet shows server blocks with exact names, wildcard names, and regex names nginx uses to match incoming requests.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: nginx checks each server block's server_name patterns one by one.
- How many times: It repeats this check for each server block until a match is found or all are checked.
As the number of server blocks grows, nginx must check more names to find a match.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | Up to 10 checks |
| 100 | Up to 100 checks |
| 1000 | Up to 1000 checks |
Pattern observation: The number of checks grows directly with the number of server names to test.
Time Complexity: O(n)
This means the time to find a matching server grows linearly as more server names are added.
[X] Wrong: "nginx matches server names instantly no matter how many there are."
[OK] Correct: nginx checks server names one by one, so more names mean more checks and longer matching time.
Understanding how nginx matches server names helps you reason about performance in real systems. This skill shows you can think about how configuration size affects response time.
What if nginx used a hash table for exact server names instead of checking each one? How would the time complexity change?
Practice
*.example.com match in nginx?Solution
Step 1: Understand wildcard usage in server names
A wildcard*before a domain matches any subdomain part, but not the root domain itself.Step 2: Apply to
This matches domains like*.example.comblog.example.comorshop.example.com, but notexample.comalone.Final Answer:
Any subdomain of example.com, like blog.example.com or shop.example.com -> Option CQuick Check:
Wildcard*matches subdomains only [OK]
- Thinking wildcard matches the root domain
- Confusing wildcard with regex syntax
- Assuming wildcard matches any domain ending
Solution
Step 1: Recall regex server name syntax in nginx
Regex server names start with a tilde~followed by the regex pattern.Step 2: Check each option
server_name ~^www\d+\.example\.com$; uses~^www\d+\.example\.com$which is correct regex syntax. Others either miss the tilde or use invalid delimiters.Final Answer:
server_name ~^www\d+\.example\.com$; -> Option DQuick Check:
Regex server names start with ~ [OK]
- Omitting the ~ before regex pattern
- Using * instead of ~ for regex
- Using slashes / / as regex delimiters
server {
server_name ~^www\d+\.example\.com$;
return 200 'Matched regex server name';
}What will be the response for a request to
www12.example.com?Solution
Step 1: Understand the regex pattern
The regex^www\d+\.example\.com$matches domains starting with 'www' followed by one or more digits, then '.example.com'.Step 2: Check if 'www12.example.com' matches
'www12.example.com' matches the pattern because '12' are digits after 'www'.Final Answer:
Matched regex server name -> Option AQuick Check:
Regex matches www12.example.com [OK]
- Assuming regex matches partial strings
- Ignoring start ^ and end $ anchors
- Confusing regex with wildcard matching
server {
server_name ~www\d+\.example\.com$;
return 200 'Hello';
}Why is this regex server_name directive incorrect?
Solution
Step 1: Check regex server_name syntax
Regex server names must start with~and the pattern should start with^to match from the beginning.Step 2: Identify missing ^ anchor
The patternwww\d+\.example\.com$lacks the^anchor, causing partial matches rather than full hostname matches.Final Answer:
Regex server name must start with ~ and pattern must start with ^ -> Option BQuick Check:
Regex patterns need ^ anchor at start [OK]
- Omitting ^ anchor in regex pattern
- Thinking delimiters like / / are needed
- Ignoring nginx error messages about regex
www.example.com. Which server_name config achieves this?Solution
Step 1: Understand the requirement
We want to match any subdomain except 'www.example.com'. This requires a regex with negative lookahead.Step 2: Analyze options
server_name ~^(?!www\.)[^.]+\.example\.com$; uses~^(?!www\.)[^.]+\.example\.com$which matches any subdomain not starting with 'www.'. Others either include 'www' or don't exclude it.Final Answer:
server_name ~^(?!www\.)[^.]+\.example\.com$; -> Option AQuick Check:
Negative lookahead excludes www subdomain [OK]
- Using wildcard that includes www.example.com
- Not using regex for exclusion
- Confusing wildcard and regex syntax
Ready to prove it?
Pass the test and this pattern moves unknown
