Nginx Server Blocks Not Working? Troubleshooting Guide

If Nginx server blocks are not working, the usual causes are a configuration error, a block that is not loaded, a hostname mismatch, or a request reaching a different server or proxy. Check the active configuration, test it before reloading, and verify the request’s hostname and port; the steps below help isolate the fault without changing unrelated settings.

How Nginx server blocks work

A server block is an Nginx configuration section that describes how to handle requests matching particular conditions, especially the listening address and port and the requested hostname. Nginx may serve several websites from one IP address by selecting a block according to the request. The directive is named server; “server block” is the conventional term, while “virtual host” is often used for the same idea.

For HTTP, the browser sends a hostname in its request. Nginx first considers which server blocks listen on the destination address and port, then uses the hostname to select a matching server_name. If no name matches, Nginx uses the default server for that listening socket—often the first applicable block unless one is explicitly marked with default_server. A default site appearing instead of your website can therefore mean the request did reach Nginx, but did not match the block you expected.

HTTPS adds a layer: Nginx must select a TLS configuration and certificate during the TLS handshake, before it can process the encrypted HTTP request. A wrong certificate can indicate a listener, hostname, or TLS configuration issue even if the eventual page content is correct.

Start with the active configuration

Do not assume that a file you edited is being read. Nginx loads a main configuration file and may include additional files through include directives. The paths and conventions vary by operating system and installation method. To inspect the configuration Nginx actually parses, run:

sudo nginx -T

This prints the loaded configuration, including included files, and may reveal a missing include or an old duplicate server block. Review the output for your hostname, listen directives, root or proxy settings, and any warnings. Be aware that configuration output can expose paths and other operational details; avoid publishing it indiscriminately.

Common layouts use a directory of available site files and a separate directory of enabled sites, with enabled entries linked into the included configuration. That is a convention, not a universal Nginx requirement. If your system uses it, confirm the enabled link points to the file you edited and that the main configuration includes the enabled directory.

Test, then reload safely

After editing, validate the full configuration before asking Nginx to apply it:

sudo nginx -t

If the test reports an error, fix the stated file and line before proceeding. Typical causes include a missing semicolon, an unmatched brace, a misspelled directive, or a file that cannot be read. A successful test checks syntax and referenced configuration files; it does not prove that DNS points to this server, that the hostname matches, or that an application behind a proxy is healthy.

When the test succeeds, reload the service so workers adopt the new configuration without an intentional full stop:

sudo systemctl reload nginx

Service-management commands can differ across systems. If the reload fails, inspect the service status and system logs, then run the Nginx test again. Do not repeatedly restart Nginx while a syntax error remains; a restart may fail to start with the broken configuration.

Check hostname, listener, and default block

• Match the hostname: Ensure the block’s server_name includes the exact name being requested, such as example.com and, if needed, www.example.com. These are distinct names unless both are configured.
• Check the port and address: Confirm the block listens on the port receiving traffic. HTTP commonly uses port 80 and HTTPS commonly uses 443, but a proxy, container, or custom setup may use another port.
• Identify the default: If an unmatched hostname should show a particular site, set an intentional default for the relevant listener. Avoid adding default_server to multiple blocks on the same address and port, which can cause a conflict.
• Look for duplicate names: Two loaded blocks claiming the same name on the same listener can produce warnings or surprising selection. Search the output of nginx -T, not just one file.

To test name-based routing before DNS is changed, send a request directly to the server while supplying the intended hostname:

curl -I -H 'Host: example.com' http://SERVER_IP/

Replace the placeholder with the server’s IP address. For HTTPS, a plain custom Host header does not by itself test certificate selection, because TLS negotiation happens first. Use a client option such as curl --resolve example.com:443:SERVER_IP https://example.com/ to connect to that IP while using the hostname for TLS and HTTP. Certificate validation may fail if the server’s certificate is not valid for the name; that failure is useful diagnostic information.

Verify DNS, files, and proxy targets

If a direct request to the server behaves correctly but normal browsing does not, check DNS records for the hostname and whether they point to the intended address. Also consider IPv6: a hostname may have an AAAA record directing some clients to a different server even when its IPv4 record is correct. DNS changes can take time to appear consistently because resolvers cache records.

For a static site, confirm that the configured root points to the directory containing the requested files, that the URL maps to the expected path, and that Nginx can read the files and traverse their parent directories. Check the error log for “permission denied” or “file not found” messages. A file owned by the right user can still be inaccessible if its directory permissions or security policy block access.

For a reverse proxy, verify the proxy_pass destination is reachable from the Nginx host and that the application is listening on the expected address and port. Check whether the URI path is being passed or rewritten as intended: the placement of a trailing slash in a proxy location and its proxy_pass target can affect the resulting URI. Nginx’s access log shows request outcomes; its error log often explains upstream connection failures, permissions, or file lookup problems.

Separate Nginx faults from network and TLS issues

A server block cannot fix a request that never reaches the relevant Nginx instance. Check that the service is running and listening on the expected interface and port, and that host-level or network firewalls and upstream load balancers permit traffic. In container or cloud deployments, confirm the published port and routing rules as well.

For HTTPS, check that the matching block has the intended certificate and private-key paths, that the files are readable by the service, and that the certificate covers the requested hostname. A browser may also show an old response due to a cache or a CDN; compare a direct request to the origin with the public hostname. If a CDN or another reverse proxy sits in front, its configuration can determine which origin, protocol, and hostname Nginx receives.

A practical troubleshooting sequence

1. Run sudo nginx -T and confirm the edited file is included and the intended block appears once.
2. Run sudo nginx -t; resolve every reported error or relevant warning.
3. Reload Nginx, then inspect service status and logs if the reload does not succeed.
4. Test the server directly with the correct Host header, and use curl --resolve for HTTPS hostname testing.
5. If direct tests work, investigate DNS, IPv6, firewalls, proxies, CDNs, and client caching.
6. Use access and error logs to distinguish a wrong block from a missing file, permission problem, or unavailable upstream.

Make one change at a time and keep a copy of the previous working configuration. This makes it easier to identify which adjustment mattered and to roll back if the result is worse.

Frequently Asked Questions

Why does Nginx show the default page instead of my site?
Usually the request did not match the intended block, or the edited block was not loaded. Check the hostname, listener, enabled configuration, duplicate names, and the default block for that address and port.

Do I need to restart Nginx after changing a server block?
You need to apply the changed configuration. After nginx -t succeeds, a service reload is generally suitable and avoids an intentional full stop. Exact service commands vary by system.

Why does the site work by IP but not by domain?
The domain may resolve to a different address, or its hostname may not match server_name. A request by IP can also select the default block, so test with the intended Host header and check DNS, including any IPv6 record.

Why does HTTP work but HTTPS show the wrong site or certificate?
HTTP and HTTPS use separate listeners and may have different server-block settings. Check the HTTPS block, its hostname, certificate, key, and port 443 routing. TLS certificate selection occurs before Nginx receives the encrypted HTTP request.

Where are the Nginx error and access logs?
Their paths are set by configuration and vary by installation. Look for error_log and access_log directives in the loaded configuration, and check the system service journal when diagnosing startup or reload failures.

Related

• Integrate AI Coding Tools Into Agile Teams
• Learn Git: A Beginner’s Step-by-Step Guide
• Blockchain Rails for AI Agents: How They Work