What Are Server Blocks?
An Nginx server block is the equivalent of an Apache virtual host: a self-contained server {} directive that tells Nginx which requests it should handle and how. A single Nginx instance can define dozens of server blocks, each bound to a combination of listening address, port, and hostname, letting one machine serve blog.example.com, shop.example.com, and api.example.com from entirely separate configuration stanzas without running separate processes.
Cricket analogy: Just as a single stadium can host separate IPL franchises like Mumbai Indians and Chennai Super Kings on different match days without building a new ground each time, one Nginx process hosts many sites via separate server blocks.
The Listen Directive and the Default Server
Every server block needs a listen directive specifying the IP address and port Nginx should bind to, such as listen 80; or listen 443 ssl;. When multiple server blocks share the same listen value, Nginx must pick one to answer requests that don't match any server_name — this is the 'default server,' marked explicitly with the default_server parameter, for example listen 80 default_server;. Without an explicit default, Nginx silently falls back to whichever server block appears first in the parsed configuration, which is a common source of confusing bugs when a new site block is added above an existing one.
Cricket analogy: It's like a tournament committee designating a reserve umpire who steps in for any match without an assigned official; without an explicit designation, the umpire who happened to arrive first at the ground takes over by default.
Matching Requests by server_name
Once Nginx has selected a listening socket, it uses the Host header from the HTTP request to pick the matching server block via server_name. Nginx checks exact names first (server_name shop.example.com;), then wildcards starting with an asterisk (*.example.com), then wildcards ending with one (www.example.*), and finally regular expressions prefixed with a tilde (~^(?<subdomain>.+)\.example\.com$). This priority order matters: an exact match always wins over a wildcard even if the wildcard appears earlier in the file, so debugging 'wrong site served' issues almost always starts by checking which server_name pattern actually took precedence.
Cricket analogy: It's like DRS review priority: a clear on-field decision (exact match) is only overturned by conclusive ball-tracking evidence, and vague evidence (a wildcard-like hint) never outranks a precise, confirmed edge detection on Snicko.
Organizing Server Blocks in Practice
In production, server blocks are rarely all crammed into one file. The common Debian/Ubuntu convention splits each site into its own file under /etc/nginx/sites-available/, then activates it by creating a symlink in /etc/nginx/sites-enabled/, which the main nginx.conf includes via include /etc/nginx/sites-enabled/*;. This makes enabling or disabling a whole site a single ln -s or rm operation, and keeps configuration diffs in version control scoped to one site at a time instead of one sprawling file.
Cricket analogy: It's like a franchise keeping each player's individual playing contract in a separate folder rather than one giant binder, so releasing or signing Virat Kohli means swapping one folder, not editing the whole binder.
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
return 444;
}
server {
listen 80;
listen [::]:80;
server_name shop.example.com www.shop.example.com;
root /var/www/shop.example.com/html;
index index.html;
access_log /var/log/nginx/shop.access.log;
error_log /var/log/nginx/shop.error.log;
location / {
try_files $uri $uri/ =404;
}
}Use nginx -T to dump the fully merged configuration, including every included server block, exactly as Nginx parsed it. This is the fastest way to confirm which server_name pattern actually won a match, especially when multiple included files define overlapping blocks.
Forgetting default_server on any listening socket doesn't cause an error — Nginx just silently picks the first server block it parsed as the fallback. If that happens to be a staging site or a placeholder block, unmatched Host headers (including raw IP requests and bots) will be served content you never intended to expose.
- A server block is Nginx's unit of virtual hosting, matched by listen socket plus server_name.
- listen defines the IP:port; default_server marks the fallback for unmatched Host headers on that socket.
- server_name matching priority: exact name > leading wildcard > trailing wildcard > regex, regardless of file order.
- sites-available/sites-enabled with symlinks is the standard convention for toggling sites on and off cleanly.
- Always run
nginx -tbefore reloading, andnginx -Tto inspect the fully merged configuration. - Omitting default_server does not error; it silently falls back to the first-parsed block on that socket.
Practice what you learned
1. Which directive explicitly marks a server block as the fallback for a given listening socket?
2. If two server blocks both listen on port 80, one with `server_name shop.example.com;` and another with `server_name *.example.com;`, which wins for a request to shop.example.com?
3. What happens if no server block on a listening socket is marked default_server?
4. In the standard Debian/Ubuntu layout, how is a site actually activated after its config is written to sites-available?
5. Which command shows the fully merged Nginx configuration exactly as parsed, across all included files?
Was this page helpful?
You May Also Like
Locations and Matching Rules
How Nginx's location block matching algorithm actually works — prefix, exact, and regex modifiers, and the precedence order that trips up most misconfigurations.
Nginx Variables
How Nginx's dollar-sign variables are lazily computed per request, the difference between commonly confused ones like $uri and $request_uri, and how map builds custom derived variables cleanly.
Logging in Nginx
How access logs and error logs work in Nginx, the difference between request_time and upstream_response_time for diagnosing latency, and how to control log volume in production.
Related Reading
Related Study Notes in DevOps
Browse all study notesAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics