Free tools Windows power users keep installed
One-click scans. No signup required.
If NGINX shows its default page instead of your site, the request usually reached a different listen socket than you expected, failed to match the request’s Host name, or never loaded the server block you edited. HTTPS adds another possibility: the wrong certificate can be selected during TLS negotiation before HTTP hostname routing begins.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
The dependable fix is to inspect the effective configuration, verify the address and port, test the intended Host explicitly, correct name or fallback rules, run nginx -t, reload, and test again.
As an Amazon Associate I earn from qualifying purchases.
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 →What NGINX is doing when it serves the default page
NGINX makes two related decisions for each request. It first chooses a listening socket by address and port. Only after that does it compare the request’s hostname with server_name values in the server blocks attached to that socket.
- Listener selection: the destination address and port select the relevant
listengroup. A block listening on port 8080 cannot receive a request that arrived on port 80. - Hostname selection: NGINX compares the HTTP
Hostheader with theserver_namevalues in that group. - Fallback: if the header is absent or no name matches, NGINX sends the request to the default server for that address and port.
The fallback is created by default_server on the listen directive. The commonly used server_name _; line is only a conventional, invalid-looking name; it does not create a catch-all by itself.
#1 Best Overall
| What you observe | What NGINX may have selected | Useful first check |
|---|---|---|
| Domain on HTTP shows the distribution’s welcome page | The port 80 default server | Compare the request URL with every listen 80 block and test the domain in a Host header |
| Opening the server IP shows a different site | A block whose name matches the IP, or the port’s default server | Remember that a direct IP request sends the IP as the Host value |
| HTTPS displays the wrong certificate | The default 443 TLS server during SNI negotiation | Inspect listen 443, certificate directives, and the hostname used for SNI |
| A corrected file has no effect | The file is not in the active include tree | Use nginx -T and verify that the file’s contents appear |
First confirm the request destination
Before changing a server block, write down the exact URL being requested. Note whether it is HTTP or HTTPS, the port if one is shown, and whether a proxy or load balancer sits between the client and NGINX. Then compare that destination with the block’s listen directive.
HTTP and HTTPS are different listener groups
http://example.com/normally reaches port 80.https://example.com/normally reaches port 443.http://example.com:8080/reaches port 8080 and cannot be handled by a block that only listens on 80.
A common mistake is to edit a block with listen 8080; while the browser continues to request port 80. Another is to fix the HTTP block while testing an HTTPS URL, which exercises an entirely separate set of listeners and certificate settings.
Test the socket without relying on DNS
Use the server address and an explicit hostname to separate DNS from NGINX name matching:
curl -i http://203.0.113.10/ -H 'Host: example.com'If this returns the expected site, the server block can match the hostname and the remaining problem is likely DNS, a proxy destination, or the URL being tested. If it still returns the fallback, continue with the active-configuration and name-matching checks.
Inspect the configuration NGINX actually loaded
Editing a file is not the same as changing the running configuration. NGINX starts with its main configuration file and follows its include directives. A site file that is not included is inert, even if its syntax is perfect.
Print the merged configuration
Run the dump command with the privileges used to read the main configuration and included files:
sudo nginx -T 2>&1 | lessSearch the output for every occurrence of:
listen, including the address and port;server_name;default_server;include.
You can narrow the output while investigating:
sudo nginx -T 2>&1 | grep -E 'listen|server_name|default_server|include'The full dump is preferable when several files define similar names. It shows duplicate blocks, unexpected defaults, and whether the file you edited is present in the effective configuration.
Rank #2
Check the include path, not just the filename
Many installations use a directory of available site files and a separate directory of enabled files. Other installations include a wildcard directory directly. The layout is distribution-specific, so do not assume that creating a file in a familiar directory enables it. The decisive test is whether nginx -T prints that file’s server block.
Validate syntax before any reload
Run the configuration test before applying changes:
sudo nginx -tDo not reload until this command reports a successful syntax test. Fix every reported issue, including:
- a malformed directive or missing semicolon;
- an
includepath that does not exist; - two
default_serverdeclarations for the same address and port; - a missing or unreadable certificate file for an SSL listener.
A clean test confirms that NGINX can parse the configuration; it does not prove that the intended name, listener, or certificate will win. Use the merged dump and explicit requests for that.
Make the hostname match the request exactly
The Host value must match one of the names on the selected listener. Include every public name you intend to serve, including www when it is used.
Use explicit names for ordinary sites
server {
listen 80;
server_name example.com www.example.com;
root /var/www/example;
}This block handles requests whose Host is example.com or www.example.com on port 80. It does not handle an arbitrary hostname, an IP request, port 8080, or HTTPS on port 443.
Understand IP testing
When you browse to http://203.0.113.10/, the browser sends an IP address as the Host value. That is not equivalent to browsing to http://example.com/. Unless the IP is listed in server_name, the request can correctly land on the default server even while the domain works.
Use an explicit Host header, as shown earlier, to test the domain name against the server’s address. This avoids changing public DNS while diagnosing routing.
Account for trailing dots and alternate names
Names that users actually send must be represented by matching server-name rules. If an application, health check, or proxy uses a different hostname, test that exact value rather than assuming the browser’s name is the only one in use.
Choose and declare the fallback deliberately
For each address-and-port pair, decide what should happen to unknown names. A fallback can serve a neutral site, redirect where appropriate, or reject the request. Mark only the intended block as default_server.
Reject unknown HTTP names
server {
listen 80 default_server;
server_name _;
return 444;
}Here, default_server makes the block the port 80 fallback. The underscore merely gives the block a conventional name that is unlikely to match a real hostname. The return 444; action is a deliberate policy choice for unknown HTTP names; use a normal response or redirect instead when clients should receive a useful page.
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 errorsServe a neutral default site
If unknown names should receive an informational page, point the default block at a separate document root or return a short response. Keep it distinct from a production site so that an unmatched hostname cannot expose the wrong application.
Avoid duplicate defaults
Do not mark two server blocks as default_server on the same address and port. NGINX will report a conflict during nginx -t. A default on port 80 does not control port 443; each listener group needs its own intentional policy.
Check name precedence when wildcards or regular expressions are involved
When several names could match, NGINX evaluates them by precedence and stops at the first matching variant. The practical order is:
- an exact name;
- 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, evaluated in configuration order.
For predictable routing, add frequently used hostnames explicitly instead of relying on a broad wildcard. If a wildcard is required, inspect all competing patterns in nginx -T and verify which one is more specific. Regular-expression blocks deserve extra care because moving their order can change the selected server without changing the expressions themselves.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Fix HTTPS when the certificate is wrong
HTTPS has an additional decision that occurs before the HTTP request is available. During the TLS handshake, the client sends the hostname through SNI; NGINX chooses a certificate and TLS server for the 443 listener. Only after the handshake does HTTP Host routing select a server block.
Therefore, a wrong certificate can indicate a 443 listener or SNI/default-server problem even if a later HTTP name match would select the correct application. Configure the intended 443 listener and certificate together, and test with the real hostname.
server {
listen 443 ssl;
server_name example.com www.example.com;
ssl_certificate /etc/nginx/tls/example.com.crt;
ssl_certificate_key /etc/nginx/tls/example.com.key;
root /var/www/example;
}Ensure the certificate covers every hostname you advertise in that block. If you also use a 443 fallback, give it a separate, intentional policy and mark only that block with default_server. A certificate from the fallback can still be presented when a client omits SNI or sends a name for which no 443 server matches.
Test SNI without changing DNS
The --resolve option makes curl connect to the specified address while requesting the named HTTPS site and sending that name for TLS and HTTP:
curl -vk --resolve example.com:443:203.0.113.10 https://example.com/Inspect the certificate details and the response body. This test distinguishes a certificate-selection problem from public DNS pointing at the wrong endpoint.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Reload only after the configuration passes
Once the intended block appears in nginx -T, the syntax test succeeds, and the listener/name rules are correct, apply the change with a reload:
sudo systemctl reload nginxA reload asks NGINX to read the new configuration while existing request processing continues. If your installation uses a different service manager, use its equivalent reload action, then repeat the tests rather than assuming the running workers changed.
Use this symptom-to-fix checklist
The domain still shows the default page over HTTP
- Confirm the browser is using port 80, not 8080 or 443.
- Confirm the domain appears in a
server_nameon alisten 80block. - Run the explicit-
Hostcurl test against the server address. - Check that the edited file appears in
nginx -T. - Run
nginx -t, reload, and test again.
The IP shows the default site while the domain works
This is expected when the IP is not a configured server name. Test the domain with an explicit Host header, or add the IP to a server_name only if serving it directly is an intentional requirement.
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 →www works differently from the bare domain
List both names explicitly or create a deliberate redirect from one to the other. A block containing only example.com does not automatically match www.example.com.
HTTPS has the wrong certificate but HTTP is correct
Inspect every listen 443 block, certificate path, and server_name. Test with --resolve so the intended SNI name reaches the intended address. Check for a 443 default server that is presenting its certificate before HTTP routing.
Changes have no visible effect
Look for an omitted include, a different NGINX instance or configuration prefix, a failed nginx -t, or a reload that was never executed. The effective dump and service logs are more reliable than the filename you believe is active.
A complete verification sequence
Use the following order whenever a server block appears not to work:
Recommended Free Tools
- Record the exact URL, protocol, port, hostname, and destination address.
- Run
sudo nginx -Tand locate the relevant listener, names, includes, and default. - Confirm that the site file is included in the merged output.
- Run
sudo nginx -tand resolve every error. - Send an HTTP request to the address with an explicit
Hostheader. - For HTTPS, use
curl -vk --resolveand inspect the certificate as well as the response. - Reload NGINX only after a clean test.
- Repeat both the direct test and a normal DNS-based request.
This sequence isolates listener errors, hostname errors, inactive files, syntax failures, and TLS selection problems instead of treating every default page as a DNS issue.
Decide what unknown hostnames should do
A fallback is not merely something to remove. It is a security and operations decision:
- Serve a neutral site when users may arrive through an alternate name and need an explanation.
- Redirect when every valid request should converge on one canonical hostname and the redirect is safe for that protocol.
- Reject unknown names when exposing a random virtual host would be misleading or undesirable.
Implement that policy with an explicit default_server on each relevant address-and-port pair. Keep the policy separate for HTTP and HTTPS because their routing and, for HTTPS, certificate selection are different.
Quick Recap
Key points to remember
- The listener address and port are selected before
server_namematching. - An absent or unmatched
Hostgoes to that port’s default server. default_serverbelongs onlisten;server_name _;is only a naming convention.- Exact names, then the most specific wildcards, then regular expressions determine name precedence.
- An un included file cannot affect NGINX, and a configuration that has not passed
nginx -tshould not be reloaded. - HTTPS certificate selection happens during TLS negotiation, before HTTP hostname routing.
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.
