If Nginx serves its welcome page, sends a different site, or routes HTTP and HTTPS inconsistently, the usual cause is that the request is not selecting the server block you edited. Nginx chooses a block by local IP address and port first, then by the request’s Host name. If no name matches, it uses the default server for that listening port.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Work from the outside in: test the configuration, inspect the complete loaded configuration, verify DNS and IPv4/IPv6, then check listen, server_name, TLS, and content directives. This order separates routing errors from document-root, proxy, permission, and application failures.
As an Amazon Associate I earn from qualifying purchases.
Recommended Free Tools
How Nginx chooses a server block
Nginx does not select a virtual host merely because a configuration file exists on disk. For every connection it evaluates the address and port accepted by a listen directive. When multiple server blocks share that address and port, it compares the HTTP Host header with each block’s server_name.
Name matching has a defined priority:
- An exact name, such as
www.example.com. - The longest wildcard beginning with an asterisk, such as
*.example.com. - The longest wildcard ending with an asterisk, such as
mail.*. - The first matching regular expression name.
If none of the names matches, Nginx sends the request to the default server for that address and port. The default server is a property of the listening port, not of server_name. A block can therefore be syntactically valid yet never receive the request you are testing.
#1 Best Overall
Start with a symptom-to-cause check
| What you see | Likely routing issue | First check |
|---|---|---|
| Nginx welcome page or another site | The request selected a different block or the default server. | Run nginx -T; inspect listen, server_name, and any default_server. |
| HTTP works, but HTTPS opens the wrong site | The 443 listener, TLS default, certificate, or IPv6 path differs from port 80. | Inspect every listen 443 block and test TLS with the intended hostname. |
| The domain works on one network but not another | Different DNS answers, often an IPv4/IPv6 mismatch. | Check both address records and test each address family. |
| Editing a file has no effect | The file is not included by the active configuration, or a different Nginx installation is running. | Compare nginx -V with the filename shown by nginx -T. |
| The correct site is selected but content is wrong | root, index, location, or proxy_pass points elsewhere. |
Inspect the selected block’s content directives after routing is confirmed. |
| Nginx will not reload after adding names | The server-name hash cannot be built with current defaults. | Read the exact startup error before changing hash settings. |
1. Test syntax before reloading
Always validate the configuration and referenced files before a reload or restart:
sudo nginx -tA successful test reports that the syntax is valid and the test is successful. If it fails, fix the file and line identified in the error before investigating request routing. Common blockers include a missing semicolon, an unmatched brace, a misspelled directive, a certificate file that does not exist, or an include path that cannot be read.
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 →Do not use a restart as a diagnostic shortcut. A failed restart can take a working service down, while nginx -t lets you correct the configuration without replacing the running process.
2. Inspect the configuration Nginx actually loaded
The file you edited is not necessarily the file Nginx is using. Display the complete effective configuration with:
sudo nginx -TSearch that output for three things:
- The intended filename or a distinctive comment from it.
- Every
listenline for the address and port you are testing. - Every relevant
server_name, includingwwwand wildcard variants.
If your block does not appear, follow the include directives from the active main configuration. The compiled configuration path is shown by:
nginx -VRead the output carefully: the configure arguments identify the main configuration path and can reveal that a package, container, or custom build is using a different location than the one you edited. A typical mistake is changing a file in an “available” directory while no include reaches it, or creating a symlink that points to a filename excluded by the active configuration.
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 & 11Confirm which process and installation you are testing
Run the commands with the same administrative context used to manage the service. On systems with multiple installations, the nginx binary in your shell may not be the binary launched by the service manager. Compare the executable and compiled path reported by nginx -V with the service definition and with the configuration dump. If they differ, make one installation authoritative before editing further.
Rank #2
- Durable Carbon Steel: Rack mount screws and cage nuts are made of high-quality carbon steel with a black finish for high strength and dependable durability.
- Easy Installation: Clear metric threads and uniform pitch for better grip. Nylon washers help secure screws and protect equipment surfaces.
- Organized Storage: All parts are packed in a portable storage box for easy organization and access.
- Wide Compatibility: Fits most square-hole racks and cabinets—ideal for server racks, network cabinets, equipment enclosures, and A/V gear.
- 20-Set Kit: Includes 20 mounting screws with nylon washers (M6 x 20 mm) and 20 square cage nuts—40 pieces in total—meeting daily install and replacement needs.
3. Verify DNS reaches this machine
A perfect server block cannot answer a request that arrives at another address. Confirm that the hostname resolves to the machine you are testing. Check every published address record, not only the first IPv4 result. If the domain has both IPv4 and IPv6 records, a client may choose IPv6 while your block listens only on IPv4.
Compare the destination address with the machine’s public addresses. Test the two paths independently when both are published:
- For IPv4, connect to the IPv4 address while preserving the intended hostname in the request.
- For IPv6, connect to the IPv6 address while preserving the same hostname.
If one family reaches a different host, update DNS or configure Nginx on the missing address family. Do not diagnose server_name until the request is reaching the correct machine; Nginx cannot match a block on a server that never receives the connection.
Remember what an IP-address request sends
When you browse directly to an IP address, the HTTP Host header contains that IP. A block whose names contain only example.com will not match an IP-address request, so Nginx may intentionally select the default server. Test with the real hostname whenever you are checking name-based routing.
4. Audit every listen directive
The listening socket must match the connection exactly. Make the intended address and port explicit while troubleshooting. A basic HTTP block commonly contains:
listen 80;An HTTPS block commonly contains:
listen 443 ssl;Check for these failure modes:
- The request uses port 80 but the block listens on another port.
- The block listens on a specific address while the request arrives on a different local address.
- Only an IPv4 listener exists even though DNS sends clients to IPv6.
- HTTPS is configured on 443 but the tested service is terminating TLS elsewhere.
- Several blocks claim the same address and port with an unintended default.
For each address and port combination, choose one deliberate default_server. If no block is marked explicitly, Nginx uses the first block loaded for that socket as the default. File naming or alphabetical order can therefore change the fallback after an include is added. Treat the default as an intentional safety net, not as a substitute for correcting a hostname mismatch.
Inspect the complete listener set
In the nginx -T output, group blocks by socket: IPv4 port 80, IPv6 port 80, IPv4 port 443, and IPv6 port 443 where applicable. Record which block is marked default_server in each group. A configuration can be correct on IPv4 port 80 and still fail on IPv6 port 80 or on either 443 socket.
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 →5. Correct server_name matching
List the exact hostnames clients send. If visitors use both the bare domain and the www form, include both deliberately:
server_name example.com www.example.com;Check spelling, punctuation, and the level of each name. A typo, an omitted subdomain, or a wildcard that does not cover the requested label sends the request to another matching block or to the default. Wildcards do not match arbitrary depth: a pattern intended for one subdomain level may not match a name with additional labels.
Remember that the name used for testing matters. A browser request to https://www.example.com carries a different host from https://example.com; an IP-address URL carries neither name. Test each public hostname separately and decide whether one should redirect to another or serve the same content.
Use a temporary routing marker
When several blocks look similar, give the suspected block a temporary, unmistakable response or header, then test with the real hostname. Remove the marker after confirming the route. This is safer than inferring selection from a shared document root, because two blocks may currently point to identical files while still having different TLS, proxy, or logging settings.
6. Separate routing from content configuration
Once the request reaches the intended block, inspect what that block does with it. A correctly selected server can still show an unexpected page or status when its content directives point somewhere else.
Static files
rootdetermines the filesystem base used to build a file path.indexcontrols which filename Nginx tries for a directory request.locationmatching can send a URI to a different root, a static file, or a special handler.
Verify that the requested URI maps to the file you expect, that the file exists under the effective root, and that the Nginx worker can traverse the directories and read the file. A 404 after the correct block is selected is a content-path issue, not evidence that the server block was ignored.
Reverse proxy applications
For proxied sites, inspect proxy_pass and the matching location. Confirm that the upstream address and port are the intended ones and that the application is running. An upstream connection failure, an application-generated error, or a URI rewrite can look like a wrong virtual host when the request actually selected the correct block.
Check the response status and the Nginx error log together. The access log tells you that Nginx received the request; the error log can identify an unavailable upstream, a missing file, or a permission problem.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
7. Watch access and error logs during a real request
Generate one request with the exact hostname and protocol that fails, then inspect the logs immediately. The access log confirms whether the request reached Nginx and records the resulting status. The error log explains startup, filesystem, upstream, and TLS failures.
The error_log directive controls the destination and severity. If you are unsure where the active logs are written, inspect the effective configuration and the compiled defaults reported by nginx -V. A common diagnostic mistake is watching a log file from an inactive configuration while the running instance writes elsewhere.
Increase detail only for the affected server
After ordinary logs identify a routing question that remains unresolved, assign a per-server error_log with debug severity in the suspected block, validate with nginx -t, and reload. Debug logging can expose request-processing details without making every virtual host verbose. Remove or reduce the setting after the test; sustained debug output can grow quickly and obscure normal errors.
8. Troubleshoot HTTPS separately
TLS negotiation occurs before Nginx receives the HTTP request. If the 443 listener or its default TLS server is wrong, a browser can receive the wrong certificate before HTTP server_name routing has a chance to select the intended content block.
Check the 443 block first
- In
nginx -T, find everylisten 443 sslline for the address families in use. - Confirm the intended certificate and private-key directives are in the block that should answer the hostname.
- Check that the certificate files exist, are readable by the Nginx master process, and cover the hostname being tested.
- Ensure an unintended 443
default_serveris not catching the connection. - Make a fresh HTTPS request using the real hostname and compare the certificate, status, and response body.
If HTTP reaches the right site but HTTPS does not, do not assume the port-80 block controls TLS. Each protocol has its own listening socket, default, certificate, and logs.
Use logs to distinguish TLS from HTTP errors
A certificate warning or handshake failure points to the TLS listener, certificate, key, protocol, or address-family path. A valid certificate followed by the wrong page points to 443 server selection or content directives. Keep those stages separate when reading browser errors and Nginx logs.
Best Value
9. Fix server-name hash startup errors only when present
Large numbers of names or unusually long names can exceed the defaults used to build Nginx’s server-name hash. The startup error may say that Nginx could not build the server_names_hash. Apply the remedy only when that specific error appears:
- Increase
server_names_hash_bucket_sizewhen the logged condition concerns bucket size. - Increase
server_names_hash_max_sizewhen the logged condition concerns the maximum hash size.
Place the setting in the appropriate HTTP configuration context, run sudo nginx -t, and reload only after the test succeeds. Changing hash values will not repair a DNS, listener, include, or hostname mismatch.
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 errors10. Apply the smallest verified change
When several fixes seem possible, compare them in this order:
- Destination: Does the hostname reach the intended IP and address family?
- Socket: Does the request arrive on the address and port covered by the block?
- Name: Does the
Hostvalue exactly match the intendedserver_name? - Loading: Does
nginx -Tprove that the edited file is included? - Fallback: Is the default server for that socket deliberate?
- Evidence: Do access and error logs show the expected block and outcome?
Change one layer at a time. After each edit, run sudo nginx -t, reload the service, repeat the same request, and record the result. This prevents a content change from masking a routing error and makes rollback straightforward.
Practical diagnostic sequence
Use this condensed runbook when a site appears to ignore its server block:
- Run
sudo nginx -t; fix every reported error. - Run
sudo nginx -T; verify the intended file, listeners, names, roots, proxies, and logs are present. - Run
nginx -V; confirm the active binary’s configuration path matches the files you edited. - Verify DNS points to this machine on IPv4 and, if published, IPv6.
- Check the exact
listenaddress and port for the failing protocol. - Check exact hostnames, aliases, and wildcard scope in
server_name. - Identify one intentional default server for each address-and-port combination.
- For HTTPS, validate the 443 certificate, key, listener, and TLS logs independently.
- After routing is proven, inspect
root,index,location, andproxy_pass. - Watch access and error logs while repeating the real request.
- Use per-server debug logging only if normal logs cannot explain the selection.
When the default Nginx page is actually expected
The default page is not proof that Nginx is malfunctioning. It is the normal response when the request reaches a socket but no server_name matches, when you browse to an IP address, or when the intended file is not included. It can also be the deliberate default chosen for an unknown hostname. Replace or disable that fallback only after confirming that the intended hostname, address, port, and include path are correct; otherwise you may hide the diagnostic signal and make future misroutes harder to recognize.
Quick Recap
Final verification checklist
sudo nginx -tsucceeds.sudo nginx -Tcontains the block you edited.nginx -Videntifies the configuration path you expect.- DNS sends the hostname to this server on every published address family.
- The request’s port and local address match a deliberate
listendirective. - The exact
Hostvalue appears inserver_name. - Only the intended block is default for each relevant socket.
- The 443 block has the correct certificate and key for HTTPS.
root,index,location, andproxy_passpoint to the intended content.- Access and error logs confirm the request and explain any remaining failure.
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.
