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 & 11iTechGuides 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.
If Nginx keeps showing its default page, the request is usually reaching a different server block than the one you edited. Nginx chooses a listening address and port first, then compares the request’s Host value with server_name. If no name matches—or no Host header is present—it sends the request to the default server for that port.
Use the sequence below to identify the failing layer: destination port, effective configuration, syntax, hostname matching, fallback policy, or HTTPS certificate selection. The same method works whether you are testing a domain, an IP address, HTTP, or HTTPS.
Free tools Windows power users keep installed
One-click scans. No signup required.
How Nginx chooses a server block
Nginx does not begin by searching every server_name. It makes two decisions in order:
- Listener selection: It selects a
listenaddress and port, such as port 80 for HTTP or port 443 for HTTPS. - Hostname selection: Within that address-and-port group, it compares the request’s
Hostvalue with theserver_namevalues in the available blocks.
If the hostname is absent or does not match any configured name, Nginx routes the request to the default server for that port. A block listening on port 8080 cannot handle a request that arrived on port 80, even if both blocks contain the same server_name.
#1 Best Overall
What “default” means
The fallback is controlled by the default_server parameter on listen. It is not created by a special hostname. For one address-and-port pair, only the block intended to receive unmatched requests should be marked as the default.
server {
listen 80 default_server;
server_name _;
return 444;
}Here, default_server makes the block the fallback. The underscore is only a conventional invalid name; it does not create catch-all behavior by itself.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
First check: are you testing the same port and address?
Before changing names or files, compare the destination in your browser or command with the block’s listen directive. Check all of these details:
- Protocol:
http://normally reaches port 80;https://normally reaches port 443 unless a different port is written. - Explicit port: A URL such as
http://example.com:8080does not use the port-80 block. - Address: A block can listen on a specific address, while another listens on all addresses or a different address.
- Intermediaries: A reverse proxy, load balancer, or forwarding rule may terminate the client connection and send Nginx a different destination.
Make a small inventory before troubleshooting:
| What you test | What Nginx must have | Common mismatch |
|---|---|---|
http://example.com |
A matching listener on port 80 and a name for example.com |
Only a port-443 block was edited |
https://example.com |
A matching listener on port 443, TLS settings, and a name for example.com |
The intended site exists only on port 80 |
http://server-address |
A listener for that address and a server name matching the IP, or an intentional default | Expecting an IP request to select a domain-only block |
http://example.com:8080 |
A listener on port 8080 | Testing a port-80 configuration on 8080 |
Inspect the effective configuration, not just the file you edited
Nginx builds its running configuration from the main configuration file and every file named by an include directive. A correctly written site file has no effect if it is not included in the active configuration.
Print the merged configuration with appropriate privileges:
sudo nginx -TSearch the output for every occurrence of:
listenserver_namedefault_serverinclude
Do not rely on the order of files in a directory or on a symbolic link you assume exists. The nginx -T output is the configuration Nginx can actually parse from the main file and its includes. Confirm that your block appears there, that the expected include is active, and that the listener and names are spelled as intended.
Recommended Free Tools
Signs that the file is inert
- Your edited
serverblock never appears innginx -T. - The output contains a different root, proxy target, or
server_namethan the file you opened. - A distribution-provided default block is still present and is the only block listening on the tested port.
- The include path is conditional, misspelled, or points to a different directory than expected.
Fix the include or file placement first. Changing server_name in a file that Nginx never loads cannot change routing.
Rank #2
Validate syntax before reloading
Run a configuration test before applying any change:
sudo nginx -tDo not reload until the command reports a successful syntax test. Correct every reported error, including:
- Malformed directives or missing semicolons
- Invalid or unreadable include paths
- Certificate and private-key path errors in HTTPS blocks
- More than one
default_serverfor the same address-and-port pair - Unbalanced braces or a block placed outside the expected context
A file can look correct in isolation while the merged configuration fails because another included file defines a conflicting default or references a missing certificate. Testing the complete configuration catches those interactions.
Make the hostname match the actual Host value
server_name must match what the client sends. Include each hostname users actually enter, including the www form when it is intended to work.
server {
listen 80;
server_name example.com www.example.com;
root /var/www/example;
}These requests carry different host values:
http://example.comsendsHost: example.com.http://www.example.comsendsHost: www.example.com.http://203.0.113.10sends the IP address as the host value.
An IP test is therefore not equivalent to a domain test. A block containing only example.com will not match a request whose host is 203.0.113.10; Nginx will use the default server for that listener instead.
Separate DNS problems from Nginx matching
Send the request to the server’s address while specifying the expected host explicitly:
curl -i http://203.0.113.10/ -H 'Host: example.com'If this returns the intended site, Nginx’s name matching is working and the remaining problem is likely DNS, the client’s resolver, or an intermediary. If it still returns the fallback, continue checking the listener, included configuration, and name precedence.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsUnderstand name precedence before changing wildcards
When several names could match, Nginx uses a defined priority:
- Exact names are preferred over wildcard names.
- Among wildcard names, the longest matching wildcard wins.
- Regular-expression names are checked in configuration order after the other name types.
For predictable behavior, add every important public hostname explicitly where practical. Broad wildcards can capture names you intended for another block, while regular expressions can change behavior when their order changes.
Examples of unintended matches
- A request for
www.example.comfalls back because the block lists onlyexample.com. - A broad wildcard takes the request before a more specific block because the specific name was not configured correctly.
- A regular-expression block appears earlier than another expression and wins for the same host.
- The client uses an IP address, which cannot match a domain-only name.
Inspect all names in nginx -T, not only the block you expect to win.
Choose an intentional HTTP fallback
An unmatched request must go somewhere. Decide whether unknown names should receive a site, redirect, or rejection, then make that policy explicit.
Serve a designated default site
Mark the intended block as the default for the listener:
server {
listen 80 default_server;
server_name default.example;
root /var/www/default;
}Other blocks on port 80 can still match their configured names. The default is used only when no name matches (or when the request lacks a host header).
Reject unknown names
A minimal fallback can refuse requests that do not belong to a configured site:
server {
listen 80 default_server;
server_name _;
return 444;
}The status behavior is a policy choice. The important routing detail is default_server on the listener; changing server_name _; alone does not make a catch-all.
Redirect an HTTP fallback
If every unknown HTTP request should go to a canonical HTTPS hostname, put the redirect in the block marked default_server. Test the result with an unmatched host as well as the intended domain so that a redirect loop or accidental site exposure is not hidden.
Why HTTPS can show the wrong certificate
HTTPS adds a decision that occurs before ordinary HTTP host routing. During the TLS negotiation, the client sends the hostname through Server Name Indication (SNI), and Nginx selects a certificate for the 443 listener. Only after TLS is established does the HTTP request and its Host value arrive.
A wrong certificate can therefore indicate a 443 listener or SNI/default-server problem even if a later HTTP name match appears correct. Check that:
- The intended block listens on 443 for the address receiving the connection.
- The certificate and key directives in that block point to the intended files.
- The hostname used by the client is covered by that certificate.
- There is not another 443 block marked
default_serverfor the same address. - The block is present in the output of
nginx -T.
Test HTTPS with the real hostname, not only the server IP. An IP-only test can select the default certificate because it supplies a different SNI name or none that corresponds to your domain. A certificate warning is not fixed by changing only an HTTP port-80 block.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Reload safely after the fix
Once the merged configuration passes validation, reload Nginx so it reads the corrected files without interrupting current request processing:
sudo nginx -t
sudo nginx -s reloadUse the reload mechanism provided by your service manager if that is how your installation is operated. The essential order is the same: test first, reload second.
After reloading, repeat both kinds of test:
- Use an explicit address and
Hostheader to verify Nginx name selection independently of DNS. - Use the real domain over the real protocol and port to verify DNS, TLS, and any proxy path.
If the explicit test succeeds but the real-domain test fails, investigate DNS or the intermediary. If both fail, inspect the active listeners, names, defaults, and included files again.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.A complete troubleshooting workflow
- Record the exact URL. Note HTTP versus HTTPS, the port, hostname, and whether you opened an IP address.
- Check for intermediaries. Determine whether a proxy or load balancer terminates TLS or changes the destination before Nginx receives the request.
- Print the merged configuration. Run
sudo nginx -Tand locate every relevantlisten,server_name,default_server, andinclude. - Confirm the edited block is loaded. If it is absent from the output, correct the include or file placement.
- Validate syntax. Run
sudo nginx -tand fix every reported issue before reloading. - Verify the listener. Make sure the address and port in the request match the block you intend to use.
- Verify names. Add exact names for every intended hostname, including
wwwor an IP only when you deliberately want those requests to match. - Review precedence. Check exact names, wildcard length, and regular-expression order.
- Review the fallback. Ensure only the intended block is marked
default_serverfor that address and port. - Check HTTPS separately. For port 443, inspect SNI-related certificate selection and certificate paths.
- Reload and retest. Apply the valid configuration, then repeat explicit-host and real-domain tests.
Symptoms and their most likely causes
| Symptom | Likely cause | What to inspect |
|---|---|---|
| The default page appears for every domain | The intended block is not loaded, or the request reaches a different listener | nginx -T, include, and listen |
| The domain works, but the IP shows the default page | The IP host value does not match the domain-only server_name |
Test with an explicit Host header; decide whether the IP should match |
www fails while the bare domain works |
www is missing from server_name |
Add the intended exact hostname |
| HTTP works, HTTPS shows another site | The 443 listener, SNI selection, or certificate block is wrong | Port-443 blocks, defaults, certificate paths, and the real HTTPS hostname |
| Nginx refuses to reload | Syntax, include, duplicate-default, or certificate error | Run nginx -t and fix the reported file and line |
| A wildcard captures an unexpected hostname | Name precedence selects the wildcard or a regular expression earlier than expected | All exact, wildcard, and regex names in nginx -T |
Configuration patterns that avoid fallback surprises
Keep HTTP and HTTPS blocks deliberate
Define the intended listener and names for each protocol instead of assuming a port-80 block will govern HTTPS. HTTP and HTTPS are separate listener groups, and HTTPS certificate selection adds a TLS-stage decision.
Use exact names for important sites
Exact names make the routing decision easy to audit. Add wildcard or regular-expression names only when their broader behavior is intentional and documented.
Reserve one clear default per listener
For each address-and-port pair, identify the block that should receive unknown names. Avoid marking multiple blocks as default for the same pair; Nginx reports that conflict during validation.
Verify the running configuration after deployment
Configuration management can update files without activating them. Treat nginx -T, nginx -t, reload, and a post-reload request as one deployment sequence rather than assuming that saving a file changed the running server.
What the default-page result actually tells you
Seeing a default page proves that a request reached an Nginx listener and that some server block generated the response. It does not prove that DNS is wrong, that your edited block is syntactically invalid, or that Nginx ignored server_name. The result is consistent with several distinct conditions: the wrong port, an unmatched host, an unloaded file, a competing name, or an intentional default block.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →That is why changing the root directory or copying the same configuration into another file is rarely the first fix. Identify the selected listener, inspect the merged configuration, test the actual host value, and only then change the routing or fallback policy.
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.
