Server Blocks Explained

Analogy categoryAnalogies

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.

nginx

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 -t before reloading, and nginx -T to 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?

Locations and Matching Rules