If NGINX serves its welcome page, the wrong virtual host, or the wrong HTTPS certificate, it usually selected a different server block before your intended block could handle the request. NGINX chooses a listener (address and port) first, then compares the request’s Host name with server_name. A missing or non-matching name falls through to the block marked default_server for that listener. Check those two decisions, confirm the block is included, validate the merged configuration, and reload only after a clean test.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
How NGINX chooses a server block
NGINX does not scan every server block and pick the one whose contents look most appropriate. It makes two separate routing decisions:
As an Amazon Associate I earn from qualifying purchases.
- Listener selection: it finds the address and port that received the connection, such as
0.0.0.0:80or[::]:443. - Name selection: for that listener, it compares the HTTP
Hostheader with theserver_namevalues in the eligible blocks.
If no name matches, or the request has no Host header, NGINX uses the default server for that address-and-port pair. This is why a perfectly valid block can appear to be ignored: the request may be arriving on another port, using another hostname, or never reaching the file that defines the block.
| Decision | What NGINX examines | Typical mistake |
|---|---|---|
| Listener | listen address, IP family and port |
The site is configured on port 8080 while the browser connects to port 80. |
| Hostname | The request’s exact Host value, wildcard rules and regular expressions |
www.example.com is requested but only example.com is listed. |
| Fallback | The block with default_server on that listener |
An old or unintended block remains the default. |
The conventional server_name _; line does not create catch-all behavior. The fallback is a property of default_server on the listen directive. The underscore is simply a commonly used name that is unlikely to match a real request.
#1 Best Overall
Work through this diagnostic sequence
1. Confirm the actual destination
Look at the URL and the client command, not just the configuration file. Plain HTTP normally reaches port 80; HTTPS normally reaches port 443. A request to http://example.com:8080/ cannot be handled by a block listening only on port 80. A reverse proxy, load balancer, container port mapping or firewall may also change the port that reaches NGINX.
Record the address family as well. A block listening on an IPv4 address may not receive a connection that arrives through an IPv6 address unless an appropriate IPv6 listen is configured. Similarly, a block bound to one local address is not automatically selected for traffic sent to another address on the same host.
Free tools Windows power users keep installed
One-click scans. No signup required.
2. Inspect the effective configuration
NGINX runs the configuration assembled from the main file and its include directives. A file sitting in a directory is inert until an included pattern references it. As an administrator, print the complete merged configuration:
sudo nginx -TSearch that output for every listen, server_name, default_server and include. Confirm that the block you edited appears in the output exactly as expected. If it does not, fix the include path or the enabled-site link before investigating hostname matching.
Read the output as the running instance sees it, rather than assuming a familiar distribution layout. The active master configuration may be different from the file you opened in an editor, and an included glob can load several similarly named files. The order shown by nginx -T is also useful when diagnosing regular-expression names or a fallback that was never explicitly marked.
3. Validate syntax before changing the running service
Run:
sudo nginx -tThe test checks syntax and attempts to open referenced files. Correct every reported error before reloading, including an invalid include path, a duplicate default for the same address and port, or a missing TLS certificate and key. A successful test means the configuration can be loaded; it does not prove that the desired hostname will win the name-selection step, so continue with the request tests below.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Do not treat a warning as confirmation that the intended block is active. A clean test and a visible block in nginx -T are separate requirements: the first proves loadability, while the second proves that the file is part of the assembled configuration.
4. Test name matching without relying on DNS
Send the server’s address with an explicit Host header:
curl -i http://203.0.113.10/ -H 'Host: example.com'Replace the address and name with your own values. This isolates NGINX matching from DNS. Test each intended name separately, including the www form:
curl -i http://203.0.113.10/ -H 'Host: www.example.com'Opening the IP address in a browser sends the IP itself as the host value. It is therefore a deliberate test of the IP-name configuration, not a test of the domain block. If the explicit-header request reaches the correct site but the domain does not, investigate DNS, proxying or a CDN rather than changing server_name blindly.
Rank #2
Use response headers, status codes and a distinctive test file to tell blocks apart. A default block that returns an error or a short marker makes the result unambiguous, whereas two sites with similar HTML can make a successful match look like a fallback.
5. Check which name wins
For a given listener, NGINX evaluates names in this priority:
- Exact names.
- The longest matching wildcard beginning with an asterisk, such as
*.example.com. - The longest matching wildcard ending with an asterisk, such as
mail.*. - Regular expressions, in the order they appear in the configuration.
An exact name takes precedence over a wildcard. Among wildcards, the most specific (longest) match wins. Regular expressions are order-sensitive, so an earlier expression can prevent a later one from being considered. When the set of public names is known, listing them explicitly is easier to audit than depending on broad expressions.
Remember that a hostname is matched as received. The bare name and its www variant are different values, as are an IP literal and a DNS name. Add every intended hostname explicitly when practical, then reserve wildcards for names that are genuinely managed by the same block.
6. Reload and repeat both tests
After nginx -t succeeds, reload the service:
sudo nginx -s reloadOn systems managed by systemd, sudo systemctl reload nginx is the equivalent service action. A reload applies the new configuration while existing request processing continues; it is not a substitute for fixing a failed syntax test. Repeat the explicit-Host curl request, then test through the real DNS name and protocol.
Perform the checks in that order after every change: merged configuration, syntax test, reload, direct host test, then DNS test. This prevents a stale worker process, a typo in an include, and a DNS issue from being confused with one another.
Known-good HTTP configurations
An explicit site block
server {
listen 80;
server_name example.com www.example.com;
root /var/www/example;
}Both names are declared because NGINX matches the complete host value. If you want one name to redirect to the other, give the redirect its own block or handle it intentionally; do not assume that a request for www will match the bare domain.
An intentional fallback
server {
listen 80 default_server;
server_name _;
return 444;
}This block rejects unknown HTTP names with NGINX’s nonstandard connection-close status. You can instead serve a generic landing page or return a redirect, but make that policy explicit. Only one block can be the default for a particular address-and-port combination. If two blocks claim default_server on the same listener, configuration testing fails rather than choosing one arbitrarily.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsBinding a specific address
server {
listen 192.0.2.20:80;
server_name example.com;
root /var/www/example;
}A block bound to one local address will not receive traffic arriving on another address. If the machine has several addresses, compare the address in listen with the address returned by DNS and with the address exposed by any front-end proxy.
Separate IPv4 and IPv6 listeners
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
return 444;
}When both address families are exposed, configure the intended policy for each listener. A request resolving to IPv6 can otherwise land on a different first-loaded or default block than the equivalent IPv4 request. Check both sockets in nginx -T and test both DNS paths when your clients use them.
Why the underscore pattern is often misunderstood
server_name _; is frequently used in a default block because the underscore is not normally a public hostname. It is not a special NGINX token and does not match every host. Removing default_server from the listen line removes the block’s explicit fallback status; changing the underscore to another unlikely string does not create or remove fallback behavior.
If no block is marked default_server, NGINX uses the first server block loaded for that address and port as the default. Relying on file order makes behavior fragile when package updates or include ordering changes. Mark the intended fallback explicitly and ensure there is only one for each listener.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11The scope is the complete address-and-port pair. A default on port 80 does not conflict with a default on port 443, and a default on one local IP does not replace a default on another. Duplicate claims matter only when they refer to the same listener, but they still prevent a clean configuration test.
HTTPS: a wrong certificate is a different stage of the same problem
HTTPS adds TLS negotiation before the HTTP request is available. During the handshake, the client sends the requested hostname through SNI. NGINX uses the 443 listener and SNI information to choose a certificate; only after TLS succeeds does it process the HTTP request and its Host header.
Consequently, a wrong certificate can indicate a 443 listener or SNI/default-server issue even if a later HTTP name match would select the correct content. Configure the intended certificate on the appropriate 443 block and test with the real hostname. A request made only to an IP address may not send the SNI name you expect.
server {
listen 443 ssl;
server_name example.com www.example.com;
ssl_certificate /etc/ssl/example/fullchain.pem;
ssl_certificate_key /etc/ssl/example/privkey.pem;
root /var/www/example;
}Also provide an intentional HTTPS fallback when unknown names must be rejected or sent elsewhere. Make sure the certificate and key paths shown in the effective configuration exist and are readable by the NGINX master process. Validate with nginx -t before reloading.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Test certificate selection with the hostname clients are expected to use, not only with the numeric address. Check the bare name and www name separately when they use different certificates or blocks. If the certificate is wrong but HTTP content later appears correct, keep the investigation on the 443 listener and SNI side; changing a port-80 block cannot alter a certificate already sent during the handshake.
DNS, proxies and front-end layers
An explicit Host request goes directly to the address you specify, while a browser request can pass through DNS, a CDN, a load balancer or another reverse proxy first. Each layer may select a destination port and may preserve, replace or omit the original host value. Confirm which layer terminates TLS and which one actually connects to NGINX before editing the origin configuration.
If the direct address test selects the expected block but the public name does not, the origin’s server_name may already be correct. Compare the public DNS answer with the listener addresses, check whether the proxy forwards the intended hostname, and verify that the proxy’s HTTPS certificate is not being mistaken for NGINX’s certificate. A default page at the origin and a default page at the proxy are different faults.
Common symptoms and the precise fix
The browser shows the packaged welcome page
- Run
nginx -Tand locate the block serving that page. It is often the current default for port 80. - Check that your site file is included and that its
server_nameexactly covers the browser’s host, includingwww. - Use an explicit-
Hostcurl request to determine whether the fault is NGINX matching or DNS.
The site works on port 8080 but not on port 80
The request is reaching a different listener. Add or correct the port-80 block, or deliberately redirect port 80 to the service on 8080. A block on 8080 cannot intercept a connection that arrived on 80.
Recommended Free Tools
The IP shows one site while the domain shows another
This can be correct. The IP request carries an IP host value, while the domain request carries the domain. Add the IP as a server_name only if serving it is an intentional policy; otherwise use a default block for unknown names.
The bare domain works but www does not
Declare both names or create a separate redirect block. NGINX does not infer one hostname from the other.
Changing a configuration file has no effect
The file may not be included, the edited file may not be the one used by the running instance, or the service may not have been reloaded. Confirm its presence in nginx -T, run nginx -t, reload, and repeat the direct host test.
Reload fails with a duplicate default error
Search the complete output for every default_server on the affected address and port. Remove the flag from all but the intended fallback. A default on port 80 does not conflict with a default on port 443; the address-and-port pair is the scope.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →The content is correct but HTTPS reports the wrong certificate
Inspect all 443 listeners, SNI names and certificate paths. The certificate is selected before HTTP routing, so changing only the port-80 or application block cannot fix a 443 handshake problem.
A request without a hostname reaches an unexpected site
Requests with no matching or missing Host value are expected to use the listener’s default. Decide whether that fallback should serve content, redirect, or reject the request, then mark that policy explicitly with default_server.
Choose a fallback policy deliberately
| Policy | Configuration behavior | When it fits |
|---|---|---|
| Serve a default site | The default block returns normal content. | You operate a landing page for unknown hostnames. |
| Redirect | The default block sends an intentional redirect. | You control the destination and accept that unknown hosts disclose the redirect target. |
| Reject | The default block closes or returns an error. | You want unrecognized hostnames to fail rather than expose a site. |
Apply the policy separately to HTTP and HTTPS. An HTTP fallback cannot determine which certificate an HTTPS client sees, and a certificate problem cannot be repaired by changing an HTTP server_name.
Make the fallback observable during testing. A short response, a distinctive status or an explicit connection-close behavior helps identify accidental traffic without changing the intended content blocks. Document which block is the fallback for every exposed listener so a future site addition does not silently change the result.
Operational requirements and pitfalls
- Privileges: reading the complete active configuration and reloading the service commonly requires administrator privileges, so run the diagnostic commands with the permissions used by your deployment.
- File readability: certificate, key, root and include paths must exist and be accessible to the NGINX process. A path in an unused file does not matter until that file is included, but a referenced missing path can stop a reload.
- One source of truth: avoid editing a template or disabled-site file while the running instance loads a different generated file. The output of
nginx -Tidentifies what is actually active. - Reload timing: a reload changes configuration for new processing while existing request handling continues. Always verify the post-reload behavior; a successful signal alone does not prove the intended block won.
- Address consistency: compare DNS answers, proxy destinations and every
listenaddress. A correct name on the wrong socket is still unreachable.
The NGINX Cookbook preview also emphasizes nginx -t and the default_server pattern as practical operating techniques. Treat such references as supplementary documentation; the authoritative check for your installation remains the merged configuration printed by your own NGINX process.
Final verification checklist
- The request’s protocol, destination address and port match an intended
listendirective. - The effective output from
nginx -Tcontains the site block and all expected includes. nginx -tcompletes successfully with no syntax, path, certificate or duplicate-default errors.- Every required host value, including
wwwor an intentional IP name, appears inserver_nameor is covered by a consciously chosen wildcard. - Only the desired fallback has
default_serverfor each address-and-port pair. - An explicit-
Hostrequest reaches the expected block before DNS is used as a variable. - HTTPS has the correct 443 listener, SNI names and certificate files.
- The service has been reloaded after the successful test, and both direct and real DNS requests now return the expected result.
What the fallback tells you
Seeing the default site is evidence that NGINX did receive the connection but selected another block at the listener or hostname stage. Start with the actual port, inspect the merged configuration, test the host header directly, and then fix the name or fallback policy. Treat HTTPS certificate selection as an earlier TLS decision, and the apparent mystery usually reduces to one missing listener, one unmatched name, or one configuration file that was never included.
Frequently Asked Questions
Why does opening the server IP show the NGINX default page?
The IP address is sent as the HTTP host value, so it may not match your domain’s server_name. NGINX then uses the default server for that address and port. Test the domain explicitly with a Host header, and add the IP as a server_name only if serving it is intentional.
Does server_name _; match every hostname?
No. The underscore is only a conventional unlikely name. Fallback behavior comes from default_server on the listen directive. Without an explicit default, NGINX uses the first loaded block for that listener.
Free tools Windows power users keep installed
One-click scans. No signup required.
Why does the bare domain work but www does not?
example.com and www.example.com are different host values. List both names in server_name or create a deliberate redirect block for one of them.
Can a server block on port 8080 handle a request sent to port 80?
No. NGINX selects the listener by address and port before it evaluates hostnames. Configure the port-80 listener or intentionally redirect it to the service on 8080.
What should I check when nginx -t reports a duplicate default?
Search nginx -T for every default_server on the affected address-and-port pair. Remove the flag from all but the intended fallback. Defaults on different ports, such as 80 and 443, do not conflict.
Why is HTTPS showing the wrong certificate while the page content is correct?
Certificate selection occurs during TLS negotiation, using the 443 listener and SNI, before HTTP Host matching. Inspect the 443 blocks, SNI names and certificate paths; changing only the HTTP block cannot fix the handshake certificate.
Recommended Free Tools
Why did editing a site file not change anything?
The file may not be included, may be disabled, or the service may not have been reloaded. Confirm the block appears in nginx -T, run nginx -t, reload successfully, and repeat an explicit Host test.
Should an unknown hostname receive a page, redirect or error?
Choose the fallback policy deliberately. A default block can serve a landing page, issue a redirect, or reject the request. Apply the policy separately to HTTP and HTTPS and mark the intended fallback with default_server.
The Bottom Line
NGINX first chooses the listening address and port, then matches the hostname. Verify both with nginx -T, validate with nginx -t, test an explicit Host, and use exactly one intentional default_server per listener. For HTTPS, verify 443 and SNI because the certificate is selected before HTTP routing.
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.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →
