When Nginx ignores a server block, the cause is usually request routing rather than the HTML or application inside the block. Nginx first chooses a local address and port from listen, then compares the request’s Host header with server_name. If no name matches, it serves the default server for that address and port. Work through syntax, the loaded configuration, DNS and address family, listener and name matching, then logs and content settings in that order.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
How Nginx chooses a server block
Understanding the selection process prevents you from changing the wrong directive. For each incoming connection, Nginx performs these checks:
As an Amazon Associate I earn from qualifying purchases.
- Address and port: It compares the destination IP address and port with every
listendirective. - Host name: If several blocks share that address and port, it compares the HTTP
Hostheader with theirserver_namevalues. - Fallback: If no name matches, Nginx uses the default server assigned to that listen socket.
Name matching has a defined priority:
| Priority | Match type | Example |
|---|---|---|
| 1 | Exact name | example.net |
| 2 | Longest wildcard at the beginning | *.example.net |
| 3 | Longest wildcard at the end | mail.* |
| 4 | First matching regular expression | ~^shop. |
The default server is a property of the listen port, not of server_name. Therefore, a block can be syntactically valid yet never receive your test request if the request reaches another address, port, or address family.
Typical symptoms and what they indicate
| Symptom | Most likely area | First check |
|---|---|---|
| The stock Nginx welcome page appears | Your block is not selected, or its root points to that page |
Run nginx -T; inspect listen, server_name, and the default server |
| One domain always shows another site | Host-name mismatch, wrong default server, or DNS pointing elsewhere | Check the request’s resolved IP and the exact Host value |
| HTTP works but HTTPS opens the wrong site | Wrong 443 block, certificate/default TLS server, or missing IPv6 TLS listener | Inspect every listen 443 ssl block and test TLS by hostname |
| Changes have no effect | The edited file is not included, or Nginx was not reloaded | Find the file in nginx -T, test syntax, then reload |
| Nginx will not reload after adding names | Syntax error, missing file, or server-name hash limits | Run sudo nginx -t and read its exact error |
1. Test the configuration before reloading
Always validate first. The test parses the configuration and checks referenced files without replacing the running worker processes.
#1 Best Overall
sudo nginx -tA successful test reports that the syntax is OK and the test is successful. Do not reload when it reports an error. Fix the filename, line number, directive, certificate path, permission problem, or other item named in the output, then test again.
After a successful test, reload rather than restarting for ordinary configuration changes:
Free tools Windows power users keep installed
One-click scans. No signup required.
sudo systemctl reload nginxOn systems without a systemd service, use the service manager supplied by that operating system. A reload applies the new configuration while existing connections finish; a restart is more disruptive and does not solve an incorrect routing rule.
2. Inspect the configuration Nginx actually loaded
Looking at a file in /etc/nginx/sites-available is not proof that Nginx reads it. The file must be reached through an active include directive, often by a symlink in a directory such as sites-enabled.
Print the complete effective configuration:
sudo nginx -TSearch that output for the intended filename, its listen directives, and every expected server_name. For example:
sudo nginx -T 2>/dev/null | grep -nE 'server_name|listen|your-site.conf'If your block is absent, trace the include chain instead of editing more directives. The compiled configuration path can differ between distributions and custom builds. Display it with:
Recommended Free Tools
nginx -VIn the output, identify the compiled --conf-path, then check that the main configuration includes the directory or file containing your server block. A common failure is creating a new file while the active nginx.conf includes a different directory.
nginx -T also reveals duplicate or later definitions that are easy to miss when inspecting files individually. Compare the complete list of blocks sharing the same address and port, not just the block you intended to use.
Rank #2
3. Verify DNS, the destination IP, and IPv4 versus IPv6
Before changing Nginx, prove that the hostname reaches this machine. Query both address families when the domain publishes both:
dig +short A example.net
dig +short AAAA example.netUse your operating system’s equivalent DNS utility if dig is unavailable. Compare the returned addresses with the server’s public addresses. A perfectly configured block cannot answer if the domain still points to an old host, a proxy, or another machine.
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 minuteIPv6 creates a frequent split result: a browser may prefer the AAAA address while your block listens only on IPv4. In that case, IPv4 tests succeed and normal browser requests select a different IPv6 listener or fail. Publish and configure both families deliberately, for example:
server {
listen 80;
listen [::]:80;
server_name example.net www.example.net;
...
}Use the equivalent pair on port 443, including ssl where required by your Nginx version and configuration style. Confirm that the IPv6 address is assigned to this host and that firewalls allow the port.
For a temporary routing test, send a request directly to a known address while preserving the intended host name:
curl -i --resolve example.net:80:203.0.113.10 http://example.net/Replace the address with your server’s actual test address. This isolates Nginx name selection from public DNS; it does not fix DNS, so remove the workaround after diagnosis.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
4. Check every listen directive
The listener must match the request’s destination. A block listening on port 8080 will not receive a request sent to port 80, and a block bound to one local address will not receive traffic arriving on another address unless an appropriate listener exists.
For a conventional HTTP and HTTPS site, verify the relevant blocks resemble the intended arrangement:
server {
listen 80;
listen [::]:80;
server_name example.net www.example.net;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name example.net www.example.net;
ssl_certificate /etc/ssl/example/fullchain.pem;
ssl_certificate_key /etc/ssl/example/privkey.pem;
}The exact certificate paths and security settings depend on your deployment. The important routing properties are address, port, address family, and the name list.
Designate only one deliberate default_server for each address-and-port combination. If multiple blocks claim the same socket as the default, the configuration test will normally identify the conflict. Remember that an HTTP default on port 80 does not become the HTTPS default on port 443; each listen port has its own selection.
5. Make server_name match the real request
List every hostname users actually send. The bare domain and its www variant are different names:
server_name example.net www.example.net;Check spelling, punctuation, and wildcard scope. A wildcard such as *.example.net matches a subdomain but does not match the bare example.net. A name-only block also does not match a request made directly to an IP address: the Host header contains that IP, not the domain.
Use a controlled request to see which virtual host answers:
curl -i -H 'Host: example.net' http://203.0.113.10/This is useful for HTTP routing. For HTTPS, the TLS handshake also uses the hostname through SNI, so test with the real name and certificate path rather than relying only on an HTTP Host header.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →If regular-expression names are involved, remember that the first matching expression wins. Put a more specific expression earlier than a broad one, or replace it with exact and wildcard names when those express the intended routing more clearly.
6. Treat HTTPS as a two-stage routing problem
TLS negotiation occurs before Nginx receives the encrypted HTTP request. The client therefore needs the correct 443 listener and TLS server before ordinary HTTP name routing can select content. If the wrong 443 block is the default, the browser may receive the wrong certificate even though port 80 routes correctly.
Check all of the following in the intended HTTPS block:
listen 443 ssl;(and the IPv6 equivalent if used)- The exact
server_namevalues, including every public variant - A certificate containing the requested hostname
- A private-key path that exists and is readable by the Nginx master process
- DNS and firewall reachability for both published address families
Inspect the certificate and selected virtual host with a hostname-aware TLS request:
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 problemsopenssl s_client -connect example.net:443 -servername example.netRead the certificate subject and Subject Alternative Names, then compare them with the requested name. A certificate warning is not fixed by changing root; first correct the 443 listener, SNI selection, certificate, or key.
7. Separate routing from content and application errors
Once you have proved that the intended block is selected, inspect what it does next. A correct server block can still return an unexpected page or status because its content directives point elsewhere.
root: Confirm the directory contains the file you expect and that the path is interpreted in the intended location context.index: Verify the configured index filename exists; otherwise a directory request may produce a listing denial or another status.location: Check prefix and regular-expression locations for a more specific rule that overrides the apparent one.proxy_pass: Confirm the upstream address, URI behavior, service status, and connectivity after Nginx routing is established.- Permissions: Ensure the Nginx worker user can traverse parent directories and read static files, or connect to the Unix socket used by an upstream.
A response from the wrong application proves only that some block handled the request. It does not by itself identify whether the problem is name selection, a nested location, a proxy target, or application output.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.8. Watch access and error logs while making one real request
Logs provide the evidence that configuration inspection cannot. An access.log entry confirms that the request reached Nginx and records the status, method, URI, and often the host. The error.log explains startup failures, missing files, permission errors, upstream failures, and TLS problems.
Find the configured destinations in the effective configuration:
sudo nginx -T 2>/dev/null | grep -n error_log
sudo nginx -T 2>/dev/null | grep -n access_logThen follow the relevant files while making a single request:
sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.logYour distribution may use different paths, and a server-level or location-level directive may override the global destination. The compiled defaults and build options shown by nginx -V help explain unexpected paths.
Use a per-server diagnostic log only when normal logging is insufficient:
server {
...
error_log /var/log/nginx/example-debug.log debug;
}This requires a build that supports debug logging. Keep the scope and duration narrow: debug output is verbose and can expose sensitive request details. Remove or lower the level after the routing issue is understood.
9. Fix server-name hash startup errors only when they occur
Large numbers of names or unusually long names can exceed Nginx’s server-name hash defaults. The configuration test or error log may report an error such as could not build the server_names_hash. That message is different from an ordinary routing mismatch.
When this specific startup error appears, adjust the documented hash settings in the http context, commonly server_names_hash_bucket_size or server_names_hash_max_size, according to the condition reported. Test the change with sudo nginx -t before reloading. Do not raise these values preemptively for a site with a normal, short name list; it adds complexity without correcting DNS, listeners, or host matching.
A repeatable troubleshooting sequence
Use this order so each test eliminates a separate class of failure:
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 →- Run
sudo nginx -t. Resolve every reported error before continuing. - Run
sudo nginx -Tand confirm the intended file,listenlines, names, certificate paths, and include chain are present. - Run
nginx -Vto identify the active compiled configuration path when file locations are uncertain. - Check
AandAAAADNS records and compare them with the machine’s addresses. - Verify that the request port and address family correspond to a listener in the intended block.
- Confirm exact hostnames, wildcard boundaries, and whether an IP-address request is being used.
- Check which block is the intentional default for each address and port; remove accidental defaults.
- For HTTPS, inspect the 443 block, certificate names, private-key readability, and SNI selection separately from HTTP.
- After routing is correct, inspect
root,index,location, proxy settings, and filesystem or upstream permissions. - Tail the access and error logs during one controlled request, then enable narrowly scoped debug logging only if the evidence remains ambiguous.
- Run
sudo nginx -tagain and reload only after the final change passes validation.
How to decide between competing fixes
When several changes appear plausible, evaluate each against these five questions:
- Destination: Does the request reach the intended IP and address family?
- Listener and name: Do the port, address, and
server_namematch what the client sends? - Inclusion: Does the effective configuration contain the edited block?
- Default behavior: Is the selected default intentional for that exact listen socket?
- Evidence: Do access and error logs show the expected block, file, upstream, certificate, or failure?
These checks keep routing problems separate from static-file, permission, upstream, and TLS problems. Changing a content directive cannot repair a DNS mismatch, and changing DNS cannot repair a missing include.
When the default page is useful
The default page is not merely an annoyance: it is evidence that Nginx is reachable and that some server block answered. Use it as a boundary test. If the default page appears, first determine whether your request reached the expected address and port. Then inspect the loaded blocks sharing that socket and their name-matching rules. Only after the intended block is selected should you replace its document root or index file.
What a successful fix looks like
A complete fix has three independent confirmations: sudo nginx -t passes; nginx -T shows the intended block through the active include chain; and a real request, observed in the logs, reaches the expected listener, hostname, certificate (for HTTPS), and content or upstream. If one of those confirmations is missing, the page may appear correct by accident while another address family, hostname, or port remains broken.
Recommended Free Tools
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.
