Nginx Server Blocks: Fix Configuration and Routing

If Nginx serves the wrong site, shows its default page, or works for only one domain, the server blocks may not be loaded or matched as expected. This guide walks through checking the configuration, correcting host and file settings, and safely testing changes before you reload Nginx.

What You’ll Need

Shell access to the server and permission to edit its Nginx configuration.
The domain names you expect each server block to handle, plus access to check their DNS records.
A way to test the site, such as a browser and the curl command.
The path to the site’s document root or application upstream, if you know it.

Step-by-Step

Confirm what “works only” means. Test each hostname separately and note the result: wrong website, default page, connection error, redirect loop, or failure only over HTTPS. Check from a device outside the server if possible. A server block selects a site based chiefly on the requested hostname and listening address and port; it does not repair DNS, firewall, or application problems by itself.
Check DNS and reachability first. Verify that each domain’s A record points to the server’s IPv4 address and that any AAAA record points to a working IPv6 address. A stale AAAA record can make some clients reach a different or unavailable server. Confirm ports 80 and, for HTTPS, 443 are allowed through the host firewall and any network firewall. You can inspect DNS with dig example.com A and dig example.com AAAA, replacing the example domain.
Find the configuration Nginx actually reads. Run sudo nginx -T to test and print the combined configuration, including included files. Look for the relevant server blocks and any “conflicting server name” warnings. Common layouts use /etc/nginx/sites-available and /etc/nginx/sites-enabled, but not every system does. The include directives in the main configuration determine which files are active. Do not assume that editing a file automatically enables it.
Check that each intended block is enabled once. On systems using the sites-available/sites-enabled layout, a block is commonly enabled by a symbolic link in sites-enabled. Check links with ls -l /etc/nginx/sites-enabled/. Avoid duplicate copies of the same block, and inspect includes for accidental overlaps. If you create a link, use the actual paths for your system and verify the result with nginx -T.
Match the hostnames and listening ports. A basic HTTP block might look like this; substitute your real domain and document root:
```
server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}
```
Check spelling, punctuation, and that every hostname you use appears in the intended server_name. A request for www.example.com will not necessarily match a block listing only example.com. For IPv6, a listener may also need listen [::]:80;, depending on the system’s network configuration.
Check the default block and duplicate names. For each address-and-port combination, Nginx uses a default server when no server name matches; if none is explicitly marked, the first applicable block is generally the default. A default block is not a substitute for listing your domains in their own blocks. Search the output of nginx -T for duplicate server_name entries and conflicting listeners. Remove or correct unintended duplicates rather than relying on file order.
Verify the site root and permissions. Confirm the configured root directory exists and contains the expected index file or application files. Nginx’s worker process must be able to traverse parent directories and read the files. Check the service’s error log for “permission denied” or “not found” messages. Avoid fixing access by making the entire site world-writable; grant only the necessary read and directory-traverse permissions.
Check HTTPS separately. HTTPS requests use a listener on port 443 and TLS certificate settings, so a correct port-80 block does not guarantee the HTTPS site works. Confirm the HTTPS block has the intended server_name, a 443 listener with SSL enabled as appropriate for the installed Nginx configuration, and certificate and key paths that exist and are readable. Ensure the certificate covers the hostname. If HTTP works but HTTPS does not, inspect the TLS block and certificate rather than changing the HTTP block at random.
Test before applying changes. Run sudo nginx -t. Do not reload if it reports an error; follow the file and line information to correct the issue, then test again. When the test succeeds, apply changes with sudo systemctl reload nginx. A reload applies configuration without the usual full service stop, but it does not make invalid configuration safe—testing first is essential.
Test each hostname directly and review logs. Try curl -I http://example.com and the equivalent HTTPS URL. To test a hostname against a particular server IP without changing DNS, use curl -I --resolve example.com:80:SERVER_IP http://example.com/, replacing SERVER_IP. Check the Nginx access and error logs, commonly under /var/log/nginx/, and compare which block receives the request. If the response is correct locally but not externally, revisit DNS, IPv6, caching, and network routing.

Common Mistakes

Editing a configuration file that is not included, or forgetting to enable its link.
Leaving out a hostname variant such as www, or putting the name in the wrong block.
Assuming the default server handles every domain correctly. It only catches requests that do not match a more specific server name on that listener.
Using the wrong document root, or confusing root with alias. These directives map request paths differently.
Changing permissions broadly, restarting Nginx without testing, or overlooking a broken IPv6 DNS record.
Fixing HTTP while leaving the separate HTTPS block, certificate, or redirect configuration incorrect.

Tips

Keep one clearly identifiable server block per site and listener, and use comments to record its purpose.
Save a copy of the working configuration before substantial edits. Change one issue at a time so you can identify what fixed or broke routing.
Use nginx -T to inspect the effective configuration, not just the file you most recently edited.
Test apex and www hostnames, HTTP and HTTPS, and IPv4 and IPv6 where the site publishes those records.

Troubleshooting

Nginx shows its welcome or default page: The request may be reaching the default block because the intended file is not included, the hostname is missing or misspelled, or DNS points elsewhere. Check nginx -T, the request hostname, and DNS. Confirm the default block is not unintentionally serving the same root.

You see “502 Bad Gateway”: If the block proxies to an application, Nginx may be unable to reach its upstream. Check the upstream address and port, confirm the application is running and listening there, and read the error log. A server-block hostname fix will not resolve an unavailable backend.

You see “403 Forbidden” or “404 Not Found”: Check the document root, requested file, index directive, and filesystem permissions. A 403 may also result when directory listing is disabled and no index file exists; that is often expected behavior.

The configuration test fails: Read the reported file and line, then check braces, semicolons, paths, and directive placement. Use sudo nginx -t after each correction. If Nginx will not reload, keep the last known-good configuration and do not repeatedly restart the service.

Only HTTPS fails, or the browser warns about a certificate: Inspect the 443 block, certificate paths, certificate hostname coverage, and error log. Confirm the certificate files are current and readable. Avoid disabling certificate checks as a workaround.

It works on the server but not elsewhere: Test the public DNS answers, both A and AAAA records, firewall rules, and whether a proxy or load balancer sits in front of Nginx. Use curl --resolve to separate DNS problems from Nginx routing.

Frequently Asked Questions

Do I need one server block for every domain?
Usually, use separate blocks when domains need different roots, applications, certificates, or behavior. Domains that should serve the same site can share a block by listing them in server_name.

What does the default server do?
It handles requests that do not match another server name for the same listening address and port. Set one intentionally if you want predictable behavior for unknown hostnames.

Why does the site work with the bare domain but not www?
The www name may be missing from server_name, or its DNS record may be absent or point elsewhere. Check both DNS and the active Nginx configuration.

Should I restart or reload Nginx?
After a successful nginx -t, a reload is generally suitable for applying configuration changes. Use a restart only when there is a specific reason a reload cannot apply the change.

Can several server blocks listen on port 80?
Yes. Nginx can select among blocks sharing a listener using the request hostname. Their server names should not conflict, and each block should have the intended configuration.

Why do changes not appear immediately?
The edited file may not be included, the reload may have failed, or the request may reach a different server because of DNS, caching, or a proxy. Check the reload status, effective configuration, and the server receiving the request.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →