Nginx Server Block Configuration: Understanding Default Server and Domain Name Matching Mechanisms

In Nginx configuration, server blocks are the core structures for defining virtual hosts and handling requests for specific domain names. When a user accesses a domain via a browser, Nginx matches the Host header field in the request with the server_name directive in the configuration to determine which server block processes the request. However, if misconfigured, Nginx may respond to all domain requests, even those not explicitly specified in server_name. This phenomenon often stems from the behavior of the default server.

How the Default Server Works

Nginx follows this logic when selecting a server block: first, it attempts to match server_name with the request's Host header. If an exact match is found, that server block is used. If no match exists, or if the request lacks a Host header, Nginx routes the request to the default server for that port. In the configuration file, the first defined server block is typically treated as the default, unless another block is explicitly designated using the default_server directive. For example, in this configuration:

server {
    listen 80;
    server_name FAKE.COM;
    # Other configurations...
}

Even though server_name is set to FAKE.COM, if this is the only server block in the file, it acts as the default server for port 80, responding to all requests on that port, including those with non-matching domain names. This explains why users might observe Nginx responding to any domain.

Configuring a Default Server to Restrict Domain Access

To prevent Nginx from responding to unconfigured domains, you can explicitly define a default server block to handle unmatched requests. A common approach is to return an HTTP 404 status code, indicating that the resource is not found. For instance:

server {
    listen 80 default_server;
    server_name _;
    return 404;
}

Here, listen 80 default_server specifies this block as the default server for port 80, server_name _ uses an invalid server name (underscore) to ensure it doesn't match any actual domain, and return 404 directly returns a 404 response. Thus, all requests not matching other server blocks are caught and return 404.

Optimizing Default Server with Status Code 444

Beyond returning 404, Nginx supports returning status code 444, a Nginx-specific HTTP response that closes the connection without sending any content. This saves bandwidth and avoids leaking server information to clients. Example configuration:

server {
    listen 80 default_server;
    server_name _;
    return 444;
}

This method is suitable for scenarios where you want to completely block access from unconfigured domains, but note that clients may see a connection drop rather than a standard error page.

Best Practices for Organizing Configuration Files

In complex multi-domain environments, it is recommended to place the default server block in the main configuration file and use the include directive to load other domain-specific configuration files. For example, in nginx.conf:

http {
    # Default server block
    server {
        listen 80 default_server;
        server_name _;
        return 404;
    }
    
    # Include other server configurations
    include /etc/nginx/conf.d/*.conf;
}

In the /etc/nginx/conf.d/ directory, you can place files like domain_1.conf, domain_2.conf, each defining server blocks for specific domains. Since the default server block is defined first in the main configuration, it will handle unmatched requests, while other blocks are loaded in filename order without affecting default behavior. This structure enhances maintainability and flexibility.

Handling Default Server for SSL/TLS Connections

For websites using HTTPS, default server configuration requires additional consideration of SSL certificates. If no certificate is provided, Nginx may fail to establish a secure connection. Here is an example for an SSL default server:

server {
    listen 443 ssl default_server;
    server_name _;
    ssl_certificate /path/to/self-signed.crt;
    ssl_certificate_key /path/to/self-signed.key;
    return 404;
}

This uses a self-signed certificate to ensure SSL handshake success, then returns 404. It prevents SSL connection errors while restricting access from unconfigured domains.

Practical Application Cases

In real-world deployments, default servers can also be used for redirecting or proxying requests on specific ports. For example, if Apache runs on port 8080 to handle internal requests, but applications generate links containing :8080, you can configure a default server to redirect these requests to the standard port:

server {
    listen 192.168.1.100:8080;
    return 301 http://$host$request_uri;
}

This ensures that external users accessing port 8080 are redirected to port 80, improving user experience and security.

In summary, by understanding Nginx's default server mechanism and configuring it properly, you can effectively control domain access and avoid responding to unauthorized requests. Combining the default_server directive, appropriate HTTP status codes, and modular configuration file organization, developers can build robust multi-domain Nginx environments.