Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
To route every subdomain to Nginx, configure two separate layers: a DNS wildcard such as *.example.com that sends otherwise-unanswered names to the Nginx server, and an Nginx wildcard server block such as server_name *.example.com. Make that listener the default_server when it must also receive unmatched Host headers. Keep exact server names for applications that need their own backend. The commonly seen server_name _ is only a conventional invalid name; it does not create a catch-all by itself.
What “catch-all subdomain” means
A catch-all arrangement answers names that you have not configured individually, for example customer-482.example.com or preview.example.com. Three decisions are involved:
Recommended Free Tools
- DNS destination: whether the hostname resolves to the machine running Nginx.
- HTTP routing: which Nginx
serverblock receives a request after it arrives. - TLS identity: whether the certificate presented for HTTPS covers the hostname the browser requested.
These layers are independent. A perfectly written Nginx block cannot handle a name that DNS never resolves, and a DNS wildcard cannot select the correct application when Nginx server-name rules send the request elsewhere. HTTPS adds a certificate requirement before the request reaches your application.
Plan the names and traffic before editing Nginx
Decide which names are truly dynamic and which need dedicated treatment. A common plan is:
#1 Best Overall
| Hostname category | DNS record | Nginx treatment | Typical purpose |
|---|---|---|---|
Apex, example.com |
Separate record if it should resolve | Exact name or the special .example.com form |
Main website |
Known application, such as app.example.com |
Exact record, or covered by the wildcard | Exact server_name app.example.com |
Dedicated backend or certificate |
| Any one-label subdomain | *.example.com |
server_name *.example.com |
Shared landing page, tenant router, or default application |
| Names outside the domain or malformed Host values | Usually no DNS record | A default_server on the relevant listen port |
Reject, redirect, or serve a safe default |
Use a separate exact block whenever an application needs a different upstream, access policy, root directory, or certificate. Nginx gives exact names precedence over wildcard names, so adding an exact block does not require removing the broad route.
Configure the DNS wildcard
1. Add the wildcard record
At the authoritative DNS provider, create a record for *.example.com pointing to the public address of the Nginx host. The record type can be an address record or an alias supported by your provider. Provider interfaces differ, so verify whether the host field should contain * or the complete wildcard name.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →DNS wildcard synthesis applies only when a more-specific record does not answer the query. Under the rules described by RFC 4592, an existing record such as api.example.com can therefore take precedence over the wildcard. A delegated child zone or another provider-specific record can also change the result.
2. Decide whether the apex should resolve
*.example.com normally handles subdomains, not the bare example.com. Add a separate apex record if visitors should reach the same Nginx host at the root domain. At the Nginx layer, the special name .example.com matches both the apex and subdomains; the DNS records still must resolve both names.
3. Check DNS before touching Nginx
Choose a name that has no explicit record, such as probe-482.example.com, and query it from a resolver outside your network. On a system with common DNS tools, run:
dig +short probe-482.example.com
For an address record, the result should be the Nginx host’s public address. If the result is empty, points elsewhere, or changes unexpectedly between resolvers, fix DNS first. Nginx cannot receive an HTTP request for a hostname that never reaches its address.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Build the HTTP catch-all in Nginx
Use a wildcard server name for subdomains
The leading-wildcard form is the clearest declaration for one-label subdomains:
server {
listen 80 default_server;
server_name *.example.com;
root /srv/www/default;
location / {
try_files $uri $uri/ =404;
}
}
This block serves files from /srv/www/default. Replace the root and location behavior with your application’s routing rules. The default_server parameter is important for requests whose Host header does not match any other block on that address and port; it is not a synonym for the wildcard in server_name.
Keep explicit applications separate
Put named sites in their own blocks on the same listener:
server {
listen 80;
server_name app.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
}
}
A request for app.example.com goes to this exact block, while another one-label name such as reports.example.com goes to the wildcard block. Nginx first considers exact names, then the longest matching wildcard, and only then the regular-expression names if any are present. A broad wildcard therefore does not override a more specific application block.
Understand the role of server_name _
Many examples use:
server_name _;
The underscore is simply a name that is unlikely to match a real Host header. Nginx documentation states that the catch-all and default server cannot be specified by server_name; they are properties of the listen directive. If a block must receive unmatched requests, use listen 80 default_server (and the equivalent address and port) rather than relying on the underscore. You may leave server_name _ in a default block as a visual convention, but it does not perform the routing.
Choose safe behavior for unknown hosts
The default block is exposed to traffic that does not belong to a known site. Serve only the intended default content, return a deliberate status, or route to a controlled application. Do not accidentally expose an administrative site by allowing an unrelated server block to become the first listener on the port.
Validate and reload the configuration
- Save the wildcard and exact-site blocks in the configuration location used by your Nginx installation.
- Run the syntax and file-reference check:
sudo nginx -t
Continue only when Nginx reports that the test is successful. A failed test leaves the running configuration unchanged, so correct missing semicolons, duplicate listen parameters, invalid paths, or unavailable certificate files before reloading.
- Reload without dropping existing connections:
sudo nginx -s reload
- Test one dedicated name and one previously undefined name:
curl -i http://app.example.com/
curl -i http://probe-482.example.com/
The first response should come from the application on port 3000. The second should show the default block’s content or status. If both responses look identical, inspect the Host values and the loaded configuration rather than assuming the wildcard is working.
Configure HTTPS for wildcard traffic
Match the certificate to the names you will serve
A certificate for *.example.com covers subdomains one label deep, such as tenant.example.com. It does not cover a.b.example.com, and it does not automatically cover the apex example.com. Deeper names require additional certificate names or separate certificates. List every required name in the certificate’s Subject Alternative Names (SANs), including the apex when it is part of the service.
This scope is independent of Nginx matching. Nginx can route a.b.example.com to a block, but a browser will still report a name mismatch if the presented certificate does not include that hostname.
Create the HTTPS default block
After obtaining a certificate and key, create an HTTPS listener for the shared route:
server {
listen 443 ssl default_server;
server_name *.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
root /srv/www/default;
location / {
try_files $uri $uri/ =404;
}
}
Use the actual certificate paths on your system. Keep explicit HTTPS blocks for applications that need another certificate or backend:
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallserver {
listen 443 ssl;
server_name app.example.com;
ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
location / {
proxy_pass http://127.0.0.1:3000;
}
}
Exact HTTPS names retain precedence over the wildcard, just as they do on port 80. Configure port 80 separately if it should redirect to HTTPS; do not assume that an HTTPS listener handles unencrypted requests.
Use DNS-01 to issue a wildcard certificate
Let’s Encrypt does not issue wildcard certificates through the HTTP-01 challenge. The DNS-01 challenge validates a TXT record at _acme-challenge.example.com (or the corresponding name for the requested domain) and supports wildcard issuance.
Best Value
- Request the exact wildcard names you need, such as
*.example.comandexample.comwhen both are required. - Have the certificate client publish the challenge TXT value at the provider’s DNS service.
- Wait until the TXT record is publicly visible to the validating resolvers.
- Complete validation and install the resulting certificate and key in the HTTPS server blocks.
- Automate DNS updates through the provider’s API when possible, and test renewal before the current certificate approaches expiration.
The DNS provider is part of the operational design: wildcard semantics, API access, propagation behavior, and renewal automation vary by provider. A provider that cannot safely update the DNS-01 record may require a manual renewal procedure.
End-to-end setup sequence
Use this order to avoid debugging one layer with assumptions from another:
- Inventory names. Mark the apex, dedicated applications, one-label dynamic subdomains, and any deeper names.
- Publish DNS. Add
*.example.comand an apex record if needed. Leave explicit records for services that must resolve elsewhere. - Verify resolution. Query an unknown test name and confirm that it reaches the intended Nginx address.
- Install HTTP blocks. Create the wildcard block with
listen 80 default_server, then add exact application blocks. - Validate and reload. Run
sudo nginx -t, correct errors, and reload withsudo nginx -s reload. - Test routing. Request one exact host and one undefined host, checking that they reach different expected handlers.
- Plan TLS coverage. Include every required wildcard level, the apex if applicable, and any deeper names that need explicit coverage.
- Issue certificates. Use DNS-01 for wildcard names and make the TXT update repeatable.
- Install HTTPS blocks. Add the 443 default server and exact HTTPS blocks, then validate and reload again.
- Inspect the result. Test both protocols and examine the certificate name presented for each HTTPS hostname.
Choosing an implementation pattern
| Pattern | DNS requirement | Certificate approach | Best fit | Main limitation |
|---|---|---|---|---|
| HTTP wildcard only | Wildcard DNS record | None for plain HTTP | Internal testing or sites that intentionally do not use TLS | Traffic is not encrypted and browsers may upgrade or warn |
| HTTPS wildcard with one shared backend | Wildcard DNS plus DNS-01 automation | One-level wildcard certificate | Many similar subdomains using the same application | Deeper labels and separate application identities need more certificate coverage |
| Exact HTTPS sites plus a wildcard fallback | Exact records where needed, wildcard for the remainder | Dedicated certificates for exact sites and a wildcard certificate for the fallback | Mixed hosting with a few special applications | More blocks, certificates, and renewal paths to maintain |
| Default listener for arbitrary Host headers | Only names that actually resolve reach it | Certificate must still match the requested name | Rejecting or safely handling unknown traffic | It cannot make an unresolvable name work, and TLS mismatches remain possible |
When selecting a DNS provider, evaluate wildcard-record behavior, support for API-driven TXT updates, propagation characteristics, and whether the service allows reliable renewal automation. Also confirm who operates Nginx: a self-managed host gives direct control of listeners and certificates, while a managed layer may impose its own routing and certificate rules.
Troubleshoot by locating the failing layer
The random subdomain does not resolve
- Query the exact name with an external resolver.
- Confirm that the wildcard record exists in the authoritative zone, not merely in a local hosts file.
- Look for a more-specific record, delegation, or provider rule that changes wildcard synthesis.
- Check that the returned address is the Nginx host, including IPv4 and IPv6 records if both are published.
No Nginx change can repair a DNS response that never points at the server.
The name resolves but reaches the wrong site
- Verify the request’s Host header with a verbose client request.
- Check that the exact block uses the intended spelling and is loaded by Nginx.
- Review all
listenaddresses and ports. A default server is selected per listening address and port, not globally. - Look for a longer or more-specific wildcard that wins before the broad wildcard.
- Run
sudo nginx -Tto inspect the complete active configuration, then test and reload after corrections.
HTTPS reports a name mismatch
- Inspect the certificate actually presented on port 443, rather than only the file you expected Nginx to use.
- Compare its SAN entries with the requested hostname.
- Check whether the request uses a deeper label or the apex, both of which require coverage beyond a one-level wildcard certificate.
- Confirm that the correct 443 server block is selected for the SNI name and that its certificate files are readable.
Wildcard issuance fails
- Do not switch to HTTP-01 for a wildcard request; use DNS-01.
- Check that the TXT value is published at the required
_acme-challengename. - Query the TXT record publicly and allow for DNS propagation before retrying validation.
- Review API credentials and permissions if an automated client cannot create or remove the TXT record.
Only some subdomains work
Compare the working and failing names one label at a time. A name such as one.example.com is within *.example.com; two.one.example.com is deeper and needs separate DNS and TLS planning. An explicit DNS record can also intentionally bypass the wildcard, so inspect the authoritative answers rather than inferring them from Nginx.
Operational checklist
- Wildcard DNS points to the intended Nginx address.
- Apex DNS is configured separately when the bare domain is required.
- Dedicated applications have exact
server_nameblocks. - The shared HTTP block uses
default_serveron the correct listen port. - The default response does not expose an unintended application.
nginx -tsucceeds before every reload.- HTTP tests cover both an exact name and an undefined name.
- HTTPS certificates list every required hostname and wildcard level.
- Wildcard certificates are issued with DNS-01, with publicly verifiable TXT records.
- Renewal can update DNS automatically or has a documented, tested manual procedure.
The resulting design has a clear boundary: DNS decides which names can reach the host, Nginx decides which server block handles each request, and TLS decides whether the browser can trust that hostname. Keeping those decisions separate makes a catch-all setup predictable while preserving dedicated behavior for explicit sites.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
