Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsNginx serves the wrong website when the request lands on a different listen socket, fails to match the intended server_name, or selects a different HTTPS server during the TLS handshake. The usual result is the first virtual host, an explicitly marked default_server, or a block with a certificate and content meant for another domain.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
Fix it by checking the loaded configuration—not just the file you edited—confirming DNS and the destination address, matching both the bare and www names on ports 80 and 443, correcting SNI and certificates, then validating, reloading, and testing each protocol separately.
As an Amazon Associate I earn from qualifying purchases.
What Nginx is actually choosing
Nginx does not begin by searching every website configuration for a domain name. It first selects a listening socket using the destination IP address and port. Only after that does it compare the request’s host information with the server_name values available on that socket.
For ordinary HTTP, the relevant inputs are the address and port that accepted the connection and the HTTP Host header. Nginx evaluates names in this order:
#1 Best Overall
- An exact name, such as
example.com. - The longest wildcard that begins with an asterisk, such as
*.example.com. - The longest wildcard that ends with an asterisk.
- The first regular expression server name in configuration order.
If no name matches, Nginx uses the default server for that address and port. The default is normally the first server block listed for the socket, unless a listen directive explicitly includes default_server.
This is why adding a name such as _ to server_name does not, by itself, create a catch-all. default_server belongs to the listen socket, not to the server_name directive.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Why the wrong website appears
The request does not match any server name
A typo, a missing www alias, an unexpected port, or a request arriving at another IP can leave the Host value unmatched. Nginx then serves the default block for that port. The familiar Nginx welcome page is often simply the distribution’s first or default virtual host, not evidence that the web server is broken.
The site block listens on the wrong socket
A block containing server_name example.com but listening only on an address that does not receive the connection cannot win the match. Check the exact address and port in every relevant listen directive. A block on listen 127.0.0.1:80, for example, is not a replacement for one receiving traffic on a public interface.
A duplicate name makes the result dependent on order
If several loaded blocks claim the same exact name on the same address and port, only one can be selected for a request. The effective winner can depend on configuration order and included files. Remove stale or duplicate declarations instead of trying to compensate with a broader wildcard.
Rank #2
HTTP and HTTPS are using different blocks
Port 80 and port 443 are independent sockets. Correcting an HTTP block does not correct HTTPS. It is common for http://example.com to reach the intended site while https://example.com displays another site or certificate because the 443 block is missing, misnamed, or still points at a default configuration.
SNI selects the HTTPS context before HTTP exists
HTTPS introduces an earlier decision. During the TLS handshake, the client sends the requested hostname through Server Name Indication (SNI). Nginx can use that value to select a server context and certificate before it receives the HTTP request and its Host header. A wrong 443 block can therefore present the wrong certificate as well as the wrong page, even when port 80 is perfect.
Start with the loaded configuration
Inspect the configuration Nginx has actually loaded. Looking only at a file in a sites directory can miss included files, generated snippets, distribution defaults, or a second declaration elsewhere.
- Run the configuration dump with the account and privilege level used by your installation, commonly
nginx -T. Save or page through the complete output. - Locate every
server { ... }block containinglisten 80,listen 443 ssl, an address-specific equivalent, or another port used by the domain. - Record each block’s
server_name,listenaddress,default_serverflag, document root, proxy target, certificate and key paths. - Search the dump for the domain and its
wwwform. Duplicate names and an unexpected included file are frequent causes of an apparently ignored edit.
Before changing routing, establish where the name resolves. DNS must point to the intended server address. If a reverse proxy, load balancer, or content-delivery service is in front, a browser response may be coming from that layer rather than from the Nginx host you are editing. Test the origin directly when your infrastructure permits it, using an explicit host name so the origin performs the same virtual-host match.
Repair the HTTP virtual host
Use one narrow, explicit block for the names that should serve the site. Include both forms when the site is intended to answer on both the bare domain and www.
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
root /var/www/example;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}The exact content handling can differ for a reverse proxy or an application server; the routing principles are the same. The important parts are that the block listens on the address receiving traffic and that every required hostname appears in its server_name.
If you want one canonical hostname, use a separate redirect block for the alternate name rather than relying on an accidental default:
server {
listen 80;
listen [::]:80;
server_name www.example.com;
return 301 http://example.com$request_uri;
}
server {
listen 80;
listen [::]:80;
server_name example.com;
root /var/www/example;
}Do not add a broad wildcard merely to make a symptom disappear. Exact names reduce the chance that an unrelated hostname will be served by the wrong application.
Repair the HTTPS block and certificate
Configure 443 separately, with the same hostnames and a certificate whose names cover the requested domain. A minimal file-backed site looks like this:
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →server {
listen 443 ssl;
listen [::]:443 ssl;
server_name example.com www.example.com;
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
root /var/www/example;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}For a proxied application, keep the certificate and host matching in this block and place the proxy directives in its location. Verify that the certificate subject or Subject Alternative Name covers the exact name the client requests. A valid certificate for one domain does not make a different 443 server block correct.
If HTTP should redirect to HTTPS, make that policy explicit on port 80:
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}Test the 443 block independently. A successful redirect from port 80 proves only that the HTTP block answered; it does not prove that SNI, the certificate, and the HTTPS content are aligned.
Decide what unmatched hostnames should do
Every address and port needs an intentional fallback policy. You can serve a controlled default page, redirect to a canonical site, or reject unknown hosts. Do not let the first file in an include directory make that decision accidentally.
Serve a deliberate default
Mark exactly one block as the default for a socket:
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name default.example;
root /var/www/default;
}Use this when there is a legitimate generic landing page. Keep the block’s content and security policy appropriate for requests whose hostname did not match a named site.
Reject unknown hosts
Nginx documents an empty server_name with a return code such as 444 for a catch-all that rejects requests without an accepted host. One example is:
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name "";
return 444;
}Apply the same policy deliberately to 443, with the TLS behavior your deployment requires. A rejection policy prevents an arbitrary hostname pointed at the address from receiving a real site’s content, but it should not replace a needed redirect or health-check endpoint.
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 reinstallValidate, reload, and test in the right order
- Run the syntax check, commonly
nginx -t. Do not reload if it reports an error; fix the referenced file, directive, or certificate path first. - Reload Nginx using the service manager or reload mechanism provided by your operating system. A reload applies the validated configuration without requiring a full stop, but confirm that the service accepted it.
- Resolve the domain and confirm the returned address is the server you changed. Check both the bare and
wwwnames if both are intended to work. - Request HTTP with the intended host and inspect the status,
Locationheader, response headers, and body. - Request HTTPS and inspect the certificate subject/SAN as well as the response content. Check the exact name sent through SNI.
- Repeat the test against the origin address with an explicit host where a proxy or CDN could otherwise hide the origin’s response.
For an origin test from a machine that can reach the server directly, curl --resolve example.com:80:203.0.113.10 http://example.com/ sends the named request to the specified address while preserving the host used for virtual-host matching. The HTTPS form, curl --resolve example.com:443:203.0.113.10 https://example.com/, also supplies the hostname needed for TLS SNI. Replace the address with the intended origin and use an address you control; these commands do not correct DNS or configuration by themselves.
Compare the two protocols rather than relying on a browser cache. An HTTP response from the right root combined with an HTTPS certificate for another name points to a 443/SNI problem. A wrong response on both ports points first to DNS, the destination address, or unmatched names.
Use debug logging only when normal inspection is inconclusive
If the loaded blocks, DNS, and protocol-specific tests still do not explain the result, enable targeted Nginx debug logging according to the platform’s debugging guidance. An error_log directive at debug level can reveal which server context handled a connection and where selection diverged. Debug logs are verbose and may contain request details, so enable them for the shortest practical interval, reproduce the request, inspect the result, and return to the normal log level.
Common symptoms and the most likely correction
| Symptom | What it usually means | Check or correction |
|---|---|---|
| Nginx welcome page on a new domain | The host did not match and the distribution’s first/default block answered. | Inspect all loaded blocks, add the exact name to the intended port-80 block, and remove or control the accidental default. |
Bare domain works but www does not |
www is absent from server_name, has different DNS, or has its own stale block. |
Check DNS and include both names or create an explicit redirect block. |
| HTTP is correct; HTTPS shows another site | The 443 block, certificate, or SNI match is wrong. | Inspect every listen 443 ssl block, align names and certificate SANs, then retest with HTTPS SNI. |
| The certificate is for a different domain | A different HTTPS server context was selected before the HTTP request. | Check SNI-aware selection, duplicate 443 names, and the default 443 server. |
| Editing a file has no effect | The file is not included, another block wins, or Nginx was not reloaded. | Use the complete configuration dump, run the syntax check, reload, and verify the running process accepted the change. |
| Only some networks see the wrong site | DNS answers, IPv4/IPv6 bindings, or an intermediary differ by path. | Compare returned addresses and inspect both IPv4 and IPv6 listen directives and any proxy layer. |
| An unrelated hostname receives your site | A wildcard or default block is serving unmatched traffic. | Narrow the named block and choose an explicit fallback that serves, redirects, or rejects unknown hosts. |
Operational choices and risks
- Exact names versus wildcards: exact names are safer when only a few domains belong to an application. Wildcards reduce repetition but can unintentionally claim subdomains.
- Separate protocol blocks: keeping 80 and 443 blocks visibly separate makes certificate, redirect, and SNI errors easier to identify.
- One default per socket: designate a single fallback for each address/port pair. Multiple default declarations on the same socket cause configuration failure, while no deliberate default leaves behavior dependent on order.
- Catch-all behavior: reject unknown hosts when accidental content exposure is unacceptable; redirect only when every unmatched request should have the same canonical destination.
- Configuration as evidence: the effective dump, syntax check, reload result, and a Host/SNI-aware request are stronger proof than the name of a file or what a cached browser displays.
A compact decision path
- If the domain resolves to the wrong address, fix DNS or the intermediary before changing Nginx.
- If the address is correct but HTTP is wrong, find the port-80 block that receives the connection and match the exact
Hostname. - If HTTP is right but HTTPS is wrong, inspect 443 independently: SNI, duplicate names,
default_server, certificate names, and content. - If the intended names are present but the result is unchanged, inspect included files and confirm a successful reload.
- If unmatched names should not receive a real site, implement and test an explicit default or rejection block.
The durable fix is not to copy the welcome page’s settings into another file. It is to make address, port, hostname, TLS identity, fallback policy, and loaded configuration agree, then verify that agreement with separate HTTP and HTTPS tests.
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.
