Use wildcard and catch-all server names in Nginx

Use wildcard server_name entries for a domain family, a regex when you need a constrained capture, and default_server for names that match no configured virtual host. They solve different routing problems.

Match a domain family

server {
    listen 80;
    server_name example.com *.example.com;
    root /var/www/wildcard;
}

In Nginx, *.example.com matches both shop.example.com and a deeper name such as api.shop.example.com. It does not match the apex example.com, which is listed separately above. The special form .example.com covers the apex plus its wildcard names.

An asterisk is allowed only at a name boundary at the beginning or end. www.*.com is not a valid wildcard form. Use a carefully scoped regex when the required pattern cannot be expressed as a supported wildcard.

Capture a single tenant label

For a deliberately limited tenant naming scheme:

server {
    listen 80;
    server_name ~^(?<tenant>[a-z0-9]+)\.example\.com$;
    root /var/www/tenants/$tenant;
}

Here acme.example.com maps to /var/www/tenants/acme. The example intentionally accepts only lowercase letters and digits in one label. It does not accept hyphens or multi-label tenants. Expand the pattern only if the tenant provisioning rules require it, and ensure unknown tenants cannot expose unrelated content. Hostname routing alone does not provide tenant authorization.

Define the fallback explicitly

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

default_server makes this block the fallback for that listening address and port. _ has no wildcard power. Nginx-specific status 444 closes the connection without an HTTP response; choose an ordinary error response or a fixed-domain redirect if that better fits the service.

Configure IPv6 listeners separately when applicable. An HTTPS fallback also needs a deliberate TLS-handshake policy; an HTTP catch-all does not automatically handle port 443.

Understand name precedence

For names competing on the applicable listener, Nginx considers exact names first, then the longest leading-wildcard name, then the longest trailing-wildcard name, then regexes in configuration order. The default server handles unmatched names. Keep common exact names explicit when useful, and avoid turning every host into a regex unnecessarily.

Inspect configuration with nginx -T, verify the reload, and send requests with expected and unexpected Host values. Log both the requested host and configured server identifier if you want to compare routing through the Guance Nginx integration. An unfamiliar host alone is not evidence of malicious traffic.

FAQ

Does a wildcard TLS certificate match all those names too?

No. A typical *.example.com certificate covers one label such as shop.example.com, not api.shop.example.com or the apex. Provide certificates covering the actual HTTPS hosts. Let's Encrypt wildcard issuance uses DNS-01 validation.

Does underscore mean “match everything”?

No. It is a conventional placeholder. Default-server selection comes from listen, not a magic server_name value.

Can I mix names in one block?

Yes, for example server_name example.com www.example.com *.example.net;. Check certificate coverage and application behavior for each accepted hostname.

References: Nginx server names, Let's Encrypt challenge types.