Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides 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.
When Nginx appears to ignore a server block, the usual problem is request routing rather than the file syntax itself. 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. A wrong DNS record, IPv4/IPv6 mismatch, missing include, incorrect port, or TLS configuration can therefore send a perfectly valid request to another block.
Use the sequence below: test the configuration, inspect what Nginx actually loaded, verify DNS and address family, check listen and server_name, then inspect the selected block’s content directives and logs. Do not reload an untested configuration.
How Nginx chooses a server block
Understanding the selection order prevents you from changing the wrong directive.
1. Nginx selects the local address and port
Every request arrives on a socket identified by an IP address and port. Nginx compares that socket with the listen directives in the loaded configuration. A block listening on port 80 cannot receive a request sent to port 443, and a block bound only to IPv4 cannot receive traffic that reaches the machine over IPv6.
#1 Best Overall
Make the intended bindings obvious. Typical declarations are listen 80; for HTTP and listen 443 ssl; for HTTPS. If you publish IPv6, configure an IPv6 listener as well, such as listen [::]:80; or the corresponding TLS listener. The exact address can be specified when the host has several interfaces.
2. Nginx compares the Host header with server_name
When several server blocks share an address and port, Nginx evaluates the hostname sent by the client. The matching order is:
- an exact name;
- 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.
The name is taken from the HTTP Host header. A request made directly to an IP address sends that IP as the host, so a block containing only example.com will not match it. Include every public hostname that should reach the site, commonly both the apex name and its www variant.
3. Nginx falls back to the default server
If no server_name matches, Nginx uses the default server for the selected address and port. The default is a property of the listen port, not of the server name. Only one deliberate default_server should exist for each address-and-port combination; an accidental default can make an unrelated site appear whenever matching fails.
Start with a safe diagnostic process
Run these checks as a user who can read the Nginx configuration and use sudo. Record the current configuration before editing so you can restore a known working state. Perform checks from the same network path that exhibits the problem: a browser, an external client, or a local test may resolve the hostname differently.
Step 1: test syntax and referenced files
- Run
sudo nginx -t. - Read the complete output. A successful test reports that the syntax is valid and the configuration test is successful. Errors identify the file and line that must be corrected.
- Fix missing certificate files, invalid directives, permission errors, or malformed braces before attempting a reload.
- Run
sudo nginx -tagain after each correction. Do not use a restart as a way to discover syntax errors; a failed restart can leave you without a working service.
The test validates syntax and checks files referenced by the configuration, but it does not prove that a client reaches the intended block. Continue with the effective-configuration and network checks even after a successful test.
PC 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 & 11Outdated 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 matchStep 2: inspect the configuration Nginx actually loaded
A file can look correct on disk yet be irrelevant if no active include reaches it. The running binary may also use a different configuration path than the one you edited.
Rank #2
- Run
sudo nginx -V. Inspect the compiled options for the configuration path and other build details. This is the path against which the mainnginx.confand its includes should be evaluated. - Run
sudo nginx -T. Nginx tests the configuration and prints the complete expanded configuration, including files reached throughincludedirectives. - Search that output for the intended filename, every expected
listenline, and each hostname inserver_name. For example, pipe the output to a pager or search it with your system’s text tools. - Confirm that the file appears in the expanded output and that its block is not enclosed in an unintended context or overridden by a later edit.
- After correcting an include or path, run
sudo nginx -tand reload Nginx. A changed file has no effect until the master process loads it.
nginx -T is the authoritative view for this investigation: it shows what the binary can parse through its active include chain, rather than what a directory listing suggests should be active.
Step 3: prove that DNS reaches this machine
Before changing server blocks, verify that the hostname resolves to the host you are testing. Compare the address returned by your DNS tools with the machine’s public addresses. If an old address, a load balancer, CDN, or another server is returned, requests will never reach the local Nginx process.
Check both address families when the domain publishes both records. An A record sends clients over IPv4; an AAAA record can send them over IPv6. If the IPv6 address points here but Nginx listens only on IPv4, IPv6 clients can receive a different service or a connection failure. Conversely, an IPv6 listener aimed at the wrong host can make only some users see the wrong site.
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 →For a controlled test, connect to the intended address while preserving the real hostname in the HTTP request. Tools that support a host-to-address override, such as curl with --resolve, let you distinguish DNS problems from Nginx routing problems. Use the production hostname in the URL and the candidate address in the override; then compare the response with an ordinary request.
Step 4: audit listen directives and defaults
Once DNS is confirmed, compare the request’s destination port and address family with every relevant block.
- HTTP normally arrives on port 80. Confirm the block has
listen 80;or an explicitly equivalent address-and-port declaration. - HTTPS normally arrives on port 443. Confirm the intended TLS block has
listen 443 ssl;and the certificate directives required by your Nginx version. - If you use explicit addresses, verify that the address belongs to this host and that the service is bound to it.
- For IPv6, verify a matching
[::]listener rather than assuming an IPv4 listener covers it. - Search the expanded configuration for
default_server. Ensure there is one intentional default per address and port, not several competing declarations.
Remember that the default is selected independently for each listen socket. The default on port 80 does not control port 443, and an HTTP block cannot determine which certificate is presented during a TLS handshake.
Step 5: make server_name match the request exactly
Write down the hostname the client actually sends, then compare it character by character with server_name. Common mismatches include a missing www name, a typo, an unexpected subdomain, or a wildcard that does not cover the requested level.
Useful naming patterns
- List both names when both are valid:
server_name example.com www.example.com;. - Use a wildcard only when its scope is intentional. A wildcard does not automatically match the bare domain unless that name is listed separately.
- Do not expect a name-only block to match a request made to the server’s numeric IP address.
- Check for duplicate names in different blocks. The most specific match wins; if two equivalent candidates remain, the first matching regular expression or the configuration order can determine the result.
To see what a browser is sending, inspect the request host in developer tools or issue a command that sets the Host header explicitly. Test each hostname separately, including redirects from the bare domain to www or the reverse.
Step 6: separate routing from content errors
A correctly selected server block can still show the wrong page or status because its content directives point somewhere unexpected. Only investigate these directives after address, port, hostname, and inclusion are confirmed.
Static files
Check the block’s root path and make sure the expected file exists beneath it. Confirm the index directive names the file you expect, and verify that nested location blocks do not replace the root or apply a different handler. Files must be readable by the Nginx worker account, and every parent directory must be searchable.
Location precedence
A more specific location can handle a URI before the block-level settings you are looking at. Review exact, prefix, and regular-expression locations for the requested path. A location that uses alias, a rewrite, or a separate root can produce a page that appears to belong to another site.
Recommended Free Tools
Reverse proxies
For an application, inspect proxy_pass and the upstream definition after routing is proven. A selected block may return a gateway error because the upstream process is stopped, the socket or port is wrong, or the proxy URI changes the path. Those are content-path or upstream failures, not evidence that Nginx selected the wrong server block.
Step 7: watch access and error logs during a real request
Logs connect the configuration to an observed request. The access log confirms whether the request reached Nginx and records the resulting status. The error log explains startup failures, filesystem problems, upstream errors, and TLS issues. As F5 NGINX documentation puts it, “Logging is essential for troubleshooting and understanding how traffic flows through your infrastructure.”
- Find the active log destinations in the effective configuration. The
error_logdirective controls the destination and severity; a build’s compiled defaults can also be revealed withnginx -V. - Start a live view of the relevant access and error logs using your platform’s log tools.
- Make one request with the exact failing hostname and protocol.
- Match the timestamp, host, URI, status, and upstream details. A missing access-log entry means the request did not reach this Nginx instance or listener.
- Fix the first error in sequence, retest the request, and avoid changing several unrelated directives at once.
If normal logging is insufficient, assign a per-server error_log at debug level after confirming that the build supports debugging. A server-specific setting limits the extra volume to the virtual host under investigation. Return to the normal severity when the issue is resolved.
Why HTTPS can select the wrong site
TLS negotiation occurs before Nginx receives the HTTP request. The client first connects to a 443 listener and receives a certificate; only after the secure connection is established does HTTP hostname routing proceed. If the wrong 443 listener or default TLS server is selected, the browser can display the wrong certificate or site even when the port-80 block is correct.
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 →- Confirm DNS for the HTTPS hostname, including IPv4 and IPv6.
- Confirm that the intended block is loaded and listens on 443 with SSL enabled.
- Place the certificate and private-key directives in the block that should answer for that hostname. Verify the files exist and are readable by the Nginx master process.
- Check whether another 443 block is the intentional default. A certificate from that block is expected when no suitable TLS name match exists.
- Test with the real hostname, then inspect access, error, and TLS-related log entries during the handshake and request.
Do not diagnose an HTTPS certificate mismatch by changing only the HTTP block. The two ports have separate listeners and separate defaults.
Fixing server-name hash startup errors
Large numbers of names or unusually long names can exceed the defaults used for Nginx’s server-name hash. Affected starts or reloads report an error such as could not build the server_names_hash. Apply the remedy only when that specific startup error appears.
- For a bucket-size error, increase
server_names_hash_bucket_sizein the appropriatehttpcontext. - For a hash-size error, increase
server_names_hash_max_sizeas indicated by the logged condition. - Run
sudo nginx -tafter the change, then reload and verify that the error has disappeared.
Do not add these directives merely because a server block appears to be ignored; ordinary hostname mismatches and missing includes require different fixes.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common symptoms and the fastest branch to test
The default Nginx page appears
First prove DNS and the address family. Then inspect nginx -T for the intended block, compare its listen and server_name values with the request, and identify which block is marked as the default for that socket. If the request is reaching Nginx but no name matches, correct the hostname declaration rather than replacing the default page files.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
HTTP works but HTTPS shows another site
Inspect the 443 listener, certificate block, and TLS default independently of port 80. Test both the certificate presented during handshake and the HTTP response after the connection is established.
One hostname works while its www variant fails
Check that DNS contains the required record and that both names are listed in the intended block. If one name redirects, test the destination as a separate request because it may use another block.
Changes have no effect
Use nginx -T to determine whether the edited file is included, then run nginx -t and reload. If the expanded output still shows the old values, you edited a path that this Nginx binary does not use.
The response is a 404, 403, or 502 instead of the expected page
Routing may already be correct. Follow the selected block’s root, index, location, permissions, and upstream settings, using the error log to distinguish a missing file, access denial, or proxy failure.
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 problemsA safe edit, reload, and rollback cycle
- Copy the current configuration or commit it to your normal administration system.
- Make one focused change: inclusion, listener, hostname, certificate, content path, or upstream.
- Run
sudo nginx -t. Stop if it fails and correct the reported file first. - Run
sudo nginx -s reloador the reload command used by your service manager. A reload lets the master process validate and hand off workers without needlessly stopping the service. - Repeat the failing request with the exact hostname and protocol.
- Watch the access and error logs while testing. Confirm the status, selected content, and absence of new startup or TLS errors.
- If the change worsens the result, restore the last known configuration, run the syntax test, reload, and verify recovery before attempting another change.
Minimal configuration patterns to compare against
The following examples show the relationships that must be present; adapt paths, names, and certificate files to your host.
HTTP block
server {
listen 80;
server_name example.com www.example.com;
root /srv/www/example;
index index.html;
}HTTPS block
server {
listen 443 ssl;
server_name example.com www.example.com;
root /srv/www/example;
index index.html;
ssl_certificate /etc/ssl/example/fullchain.pem;
ssl_certificate_key /etc/ssl/example/privkey.pem;
}These blocks still depend on the main configuration including their file, DNS resolving to this host, and filesystem permissions allowing Nginx to read the content and certificates. A syntactically valid example cannot compensate for a request arriving at another address or port.
Decision framework: identify the failing layer
Use the first failed check as the boundary of your investigation:
- DNS or address family: the hostname resolves elsewhere, or only one of IPv4 and IPv6 reaches this host.
- Listener: the request reaches this machine but no block listens on its destination address and port.
- Name matching: the listener is correct, but the host header does not match the intended names, so the socket’s default handles it.
- Configuration loading: the edited file is absent from
nginx -Tor the reload did not occur. - Content handling: the intended block is selected, but
root,location, permissions, index files, rewrites, or proxy settings produce the response. - TLS: certificate or handshake behavior is wrong before HTTP routing can be evaluated.
- Startup capacity: a server-name hash error prevents the configuration from loading until the documented hash setting is adjusted.
This separation keeps routing fixes from masking application, filesystem, or certificate problems. Nginx’s effective configuration, DNS answers, and logs together provide enough evidence to identify which layer failed.
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.
