Comprehensive Guide to Nginx Wildcard and Default Server Configuration

Nginx Server Name Matching Mechanism

When processing HTTP requests, Nginx first determines the listening port and IP address through the listen directive, then matches specific server blocks based on the server_name directive. When multiple server blocks listen on the same port, Nginx selects in the following priority order: exact match, wildcard match, regular expression match, and finally the default server.

Analysis of Wildcard Configuration Limitations

Many developers attempt to use the asterisk (*) as a wildcard to match all domains, such as configuring server_name *;. However, this syntax is not supported in Nginx and will cause configuration errors. While server_name *.*; might work in isolated testing, it often conflicts with other server blocks in real multi-site environments, failing to provide stable catch-all functionality.

Core Configuration Solution for Default Server

The most reliable solution is adding the default_server parameter to the listen directive. Specific configuration example:

server {
    listen 80 default_server;
    server_name _;
    # Other configuration directives
}

This configuration explicitly designates the server block as the default handler, automatically routing requests that cannot match any other server names to this block. server_name _; uses underscore as an invalid domain identifier, which is an industry convention ensuring no conflict with real domain names.

Request Processing Flow Optimization

To direct all undefined domain requests to a single entry point (such as index.php), combine with the try_files directive:

location / {
    try_files $uri $uri/ /index.php;
}

This configuration first attempts to access the requested file path, then tries directory indexing if not found, and finally forwards all unmatched requests to index.php, making it ideal for CMS-based dynamic website architectures.

Configuration Practices and Considerations

In actual deployment, it's recommended to place specific site server blocks at the top of the configuration file and the default server block at the end. For example:

# Specific admin console
server {
    listen 80;
    server_name admin.domain.com;
    # Dedicated configuration
}

# Status page
server {
    listen 80;
    server_name 192.168.1.100; # Server IP
    # Status monitoring configuration
}

# Default catch-all for other domains
server {
    listen 80 default_server;
    server_name _;
    root /var/www/default;
    index index.php;
    
    location / {
        try_files $uri $uri/ /index.php$is_args$args;
    }
    
    location ~ \.php$ {
        # PHP processor configuration
    }
}

This structure ensures specific domains are matched first, while all other requests are handled by the default server, guaranteeing both the stability of critical services and the convenience of large-scale domain management.

Comparison of Alternative Approaches

Besides the default_server solution, regular expression matching can also be used: server_name ~^(.+)$;. While this method theoretically matches any domain, it's inferior to the default_server approach in terms of performance and maintainability. Regular expression matching increases server parsing overhead and is prone to errors in complex configurations.

Error Troubleshooting and Validation

After configuration, use nginx -t to test configuration file syntax. Verify default server functionality by accessing domains not explicitly configured. Monitoring Nginx access logs can confirm whether request routing meets expectations.