Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsiTechGuides 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
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
If www.example.com shows the wrong site, NGINX is usually doing exactly what its request-selection rules tell it to do: the request reached a particular address and port, then no matching server_name was found for that listener, so NGINX used that port’s default server. A stale DNS or IPv6 record can produce the same symptom by sending the request to a different machine. Verify DNS first, inspect the configuration NGINX actually loaded, define the hostname in one authoritative HTTP and one authoritative HTTPS block, test the configuration, reload, and then verify each DNS address with a hostname-preserving request.
How NGINX decides which server block handles www
NGINX does not choose a virtual host from the filename of a configuration file. It first selects a listening address and port. For ordinary HTTP, it then compares the request’s Host header with the server_name values on the server blocks attached to that listener. Exact names have priority over wildcards and regular expressions. If no name matches, NGINX uses the default server for that address and port.
Free tools Windows power users keep installed
One-click scans. No signup required.
The default is a property of the listen port, not of the name. If no block is marked default_server, the first loaded server block for that address and port becomes the implicit default. Consequently, a harmless-looking file-order change, an enabled site, or a generated include can change which site receives unmatched requests.
HTTPS adds another selection step. During the TLS handshake, the client normally sends the requested hostname through Server Name Indication (SNI). NGINX can select a TLS context and certificate before it receives the HTTP Host header. Port 80 can therefore be correct while port 443 returns another site’s certificate or content.
#1 Best Overall
| Stage | What NGINX uses | Typical failure |
|---|---|---|
| Destination | Resolved IP address and destination port | www resolves to an old server, load balancer, CDN, or stale IPv6 address |
| HTTP virtual-host match | Host header compared with server_name |
www.example.com is missing, misspelled, or duplicated in another block |
| Fallback | default_server, otherwise first loaded block |
The default site serves unmatched requests |
| TLS selection | SNI and the 443 listener | The wrong certificate or HTTPS server block is selected |
1. Confirm that DNS reaches this NGINX instance
Do this before changing NGINX. A perfect server block cannot affect a request that never reaches that machine. Check both the apex name and www, and check both address families. An A record supplies IPv4 addresses; an AAAA record supplies IPv6 addresses. Many clients prefer IPv6 when it is available, so an obsolete AAAA record can make only some users see the wrong site.
dig +short example.com A
dig +short example.com AAAA
dig +short www.example.com A
dig +short www.example.com AAAA
Compare every returned address with the public IPv4 and IPv6 addresses configured on the NGINX host. If a proxy, CDN, cloud load balancer, or ingress controller is in front, the public DNS answer may intentionally be that intermediary rather than the origin server. In that design, inspect the intermediary’s routing rules as well as the origin configuration.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Test from the same network path as the affected reader when possible. A local resolver cache, split-horizon DNS, corporate DNS, or an ISP cache can produce a different answer from the one returned by your workstation. If one address is old, remove or correct the DNS record and allow its TTL to expire; do not try to compensate with another local server block.
2. Inspect the configuration NGINX actually loaded
Editing a file is not proof that the running master process reads it. Distribution packages commonly include directories of snippets or enabled sites, and container images may generate configuration at startup. Use nginx -T with the privileges required to read all included files:
sudo nginx -TThis command performs a configuration test and prints the complete expanded configuration, including files pulled in by include. Search its output for every occurrence relevant to the hostname:
sudo nginx -T 2>&1 | grep -nE 'listen|server_name|default_server|return|rewrite|proxy_set_header'Do not rely on the grep expression alone; read the surrounding server { ... } blocks. Record which files define:
listen 80andlisten [::]:80;listen 443 sslandlisten [::]:443 ssl;server_name example.com www.example.com;- any
default_serverparameter; - redirects, rewrites, and proxy headers that can change the apparent destination; and
- the access and error log paths used by each candidate block.
If the expected block is absent from nginx -T, NGINX is not loading the file you edited. Fix the relevant include, enabled-site link, image template, or deployment generator rather than making further edits to an unused file.
Rank #2
3. Declare the exact names in the intended HTTP block
Put both names on the block that should serve them. The exact spelling matters, including hyphens and the absence or presence of a trailing dot. A basic static-site block looks like this:
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
root /srv/www/example;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
For an application proxy, keep the same host declaration and replace the location with the upstream behavior required by the application:
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
The IPv6 listener is important when clients can reach the host over IPv6. If you configure only IPv4 while DNS publishes an AAAA address, IPv6 traffic may be refused or may land on a different NGINX instance. Whether you need the bracketed listener depends on how the host is configured, so verify that the address is assigned before adding it.
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 →4. Find and remove competing host declarations
Search the complete nginx -T output, not just the file you expect to be active. Another block may contain server_name www.example.com, a wildcard such as *.example.com, or a regular expression that catches the request. Exact names outrank wildcard and regex names, but duplicate exact names are an operational conflict: one block will win according to the loaded configuration and ordering, while the other may never receive requests.
Keep one authoritative owner for each hostname on each listener. Consolidate duplicate definitions, remove an accidental enabled-site link, or change a retired block’s names. Be especially careful with generated files: a deployment tool can recreate a duplicate after you delete it manually.
Also inspect redirects. A block can match correctly and still send the browser to another hostname through return or rewrite. Follow the Location header with curl rather than assuming the first response body identifies the block that made the decision.
5. Make the fallback server deliberate
Unknown hostnames should not silently receive a real site. Define a separate catch-all for each relevant port. A common HTTP policy is to reject unmatched requests:
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
return 444;
}
Code 444 is an NGINX-specific behavior that closes the connection without a response body. If your monitoring, clients, or compliance requirements need a conventional response, use an appropriate 4xx status instead. A neutral response is safer than redirecting an unknown host to a trusted site; redirects should be used only when the destination is explicitly intended.
There must be only one deliberate default per address and port. A default on port 80 does not control port 443, and a default on an IPv4 listener does not control a separate IPv6 listener. Declare each one explicitly when you need predictable behavior.
6. Configure HTTPS separately, including certificate coverage
Port 443 requires its own correct server block. Include every hostname clients are allowed to request and install a certificate whose names cover those hostnames:
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name example.com www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
A certificate for only example.com does not automatically cover www.example.com. Use one certificate with both names in its Subject Alternative Name list, or use separate certificates and matching blocks. The choice does not change the need for an exact server_name on 443.
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 →If HTTP works but HTTPS shows another site, inspect the 443 blocks and the certificate first. A wrong 443 default can present another site’s certificate during SNI selection, after which the browser may stop before an HTTP request is made. Check both the certificate identity and the response content; either can reveal a different virtual host.
If your policy is to force HTTPS, make the port-80 behavior explicit after the names are matched:
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
Use a fixed canonical hostname instead of $host when you intentionally redirect one name to the other. That prevents an unrecognized host from being reflected into a redirect.
7. Test, then reload the running master
Validate before applying any change:
sudo nginx -tThe test checks syntax and attempts to open referenced files such as certificates and included configuration. Do not reload while it reports an error. Correct missing files, permission problems, duplicate or invalid directives, and certificate path mistakes first.
After a successful test, perform a graceful reload:
sudo nginx -s reloadIf your system uses a service manager, its reload action is equivalent when configured correctly. A reload asks the master to start workers with the new configuration while existing workers finish current requests. Confirm that the process you reloaded is the process receiving traffic; in a container or multi-instance deployment, reload the active instance or redeploy the generated configuration.
8. Verify the result with hostname-preserving requests
Start with normal requests and inspect headers:
curl -I http://www.example.com/
curl -Ik https://www.example.com/Check the status code, Location, Server, and any application-specific diagnostic header. For HTTPS, also verify that the certificate presented contains www.example.com. A header alone is not proof of a particular server block because proxies and applications can add or replace it.
To test a specific address without changing DNS, use --resolve. It maps the name to the chosen address while preserving the HTTP Host header and TLS SNI:
curl --resolve www.example.com:80:203.0.113.10 -I http://www.example.com/
curl --resolve www.example.com:443:203.0.113.10 -Ik https://www.example.com/Repeat those commands for every IPv4 and IPv6 address returned by DNS. If one address returns the wrong site, the problem is isolated to that destination. If all addresses do, inspect the loaded configuration, redirects, and upstream application behavior.
9. Use logs to identify the block receiving the request
Tail the access and error logs while reproducing the request:
sudo tail -F /var/log/nginx/access.log /var/log/nginx/error.logThe actual paths may differ; use the paths shown by nginx -T. Look for the client address, request line, status, upstream status, and the file that receives the entry. If multiple blocks write to separate logs, the destination log is a direct clue to which block handled the request.
For a short diagnostic window, add a distinctive response header to the intended block:
add_header X-Debug-Vhost example-www always;Reload only after nginx -t succeeds, confirm the header with curl -I, and remove the header when finished. Do not leave internal topology or debug identifiers exposed indefinitely.
Common symptoms and the fastest branch to investigate
| Symptom | Most likely branch | Check |
|---|---|---|
| Both HTTP and HTTPS show an unrelated site | DNS points elsewhere, or both listeners lack the exact name | Compare all A/AAAA answers, then inspect nginx -T |
| HTTP is correct; HTTPS shows a different certificate | Wrong 443 default, missing 443 name, or incomplete certificate | Inspect every 443 block and test with curl -Ik |
| Only some users see the wrong site | Different DNS answers, stale resolver data, or IPv6 preference | Test every returned address, including AAAA |
| Changing a file has no effect | The file is not included, is overwritten, or another instance serves traffic | Find it in nginx -T; verify the active process and deployment |
| A redirect goes to an unexpected hostname | return, rewrite, application redirect, or unsafe host reflection |
Inspect Location and search those directives |
| The default site appears for an unknown hostname | No matching exact name and no deliberate catch-all | Set one explicit default per listener |
Choose a consistent hostname and protocol policy
Fixing selection is separate from deciding what the site should do after selection. Choose one policy and implement it explicitly:
- Canonical apex: serve the application on
example.comand permanently redirectwww.example.comto it. - Canonical
www: serve the application onwww.example.comand redirect the apex towww. - Both names: serve both names intentionally, with certificates and application URL settings covering both.
- Protocol: redirect HTTP to HTTPS, or deliberately serve HTTP separately. Ensure the redirect block itself lists only the trusted names.
- Unknown hosts: reject them, return a neutral 4xx response, or redirect only to a fixed, trusted destination.
Certificate design follows the hostname policy. A single certificate with both names simplifies a shared block; separate certificates can be appropriate when the names have different owners or deployment lifecycles, but they require separate, unambiguous TLS configuration.
Deployment models that change where to fix the problem
One NGINX instance
DNS should resolve directly to that host. The authoritative fix is normally the loaded server blocks, listeners, certificates, and fallback configuration described above.
Recommended Free Tools
Multiple IPs or multiple NGINX instances
Every address must have equivalent hostname, certificate, and redirect policy. Test each address with --resolve; correcting only one node creates an intermittent failure.
CDN or load balancer in front
The front-end must route the hostname to the correct origin and preserve the intended host information. The origin still needs a matching server_name, but an origin-only test may not reproduce the public path. Compare direct-origin and public requests without exposing an origin that should remain private.
Containers or generated configuration
Find the template or mounted configuration that produces the running file. A manual edit inside a disposable container can disappear on restart. Run nginx -T inside the serving container or instance, validate there, and reload or redeploy through the system’s normal mechanism.
Safe change checklist
- Record every A and AAAA answer for the apex and
www; identify which machine or front end owns each address. - Run
sudo nginx -Tand locate all HTTP and HTTPS blocks, names, defaults, redirects, and proxy settings. - Remove duplicate exact names and unintended wildcard or regex matches.
- Declare the intended names in one authoritative block for each listener, including IPv6 listeners where applicable.
- Set a deliberate catch-all default for each address and port.
- Install certificates covering every hostname served on 443.
- Run
sudo nginx -tand fix every reported error. - Reload with
sudo nginx -s reloador the correct service-manager action. - Test HTTP and HTTPS normally, then test every DNS address with
curl --resolve. - Watch the correct logs while reproducing the issue and remove temporary diagnostics.
What should be true when the fix is complete
Each public DNS address reaches the intended NGINX instance or front end. The loaded configuration contains one clear owner for www.example.com on port 80 and one on port 443. Unknown hosts cannot fall through to a production site, and the 443 certificate covers the name requested by the client. A successful nginx -t, graceful reload, and hostname-preserving tests against every address confirm that the change is active rather than merely present in an unused file.
Windows 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 reinstallCrashes, 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 minuteQuick 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.
