Nginx Serving Wrong Site for the Domain (Default Server Block Issue)
When Nginx serves the wrong site for a domain — showing a different project's content, or a generic default page, instead of what you configured — the cause is almost always that no server block explicitly matches the requested domain, and Nginx falls back to whichever block it considers the default.
The Problem
Visiting your domain shows content from a completely different site hosted on the same server, or a generic "Welcome to nginx" placeholder page, instead of the application you actually configured for that domain.
Why It Happens
When multiple sites are hosted on the same Nginx instance (common on a single VPS running several projects), Nginx uses the server_name directive within each server block to determine which block should handle a request based on the domain in the request. If no block's server_name matches the requested domain, Nginx falls back to a default server, which may not be the one you expect. Common causes:
- A new site was added without a
server_namedirective matching its actual domain, so requests for that domain don't match it and fall through to whichever block Nginx treats as the default - The intended default server block (marked implicitly as the first one defined, or explicitly with
default_server) is actually a different, older project rather than the one you expect, especially likely if sites were added over time without deliberately managing which one should be the fallback - DNS for the domain isn't actually pointing at this server at all, so what you're seeing is a completely different server's response — this looks identical to an Nginx configuration issue but has nothing to do with Nginx itself
- A typo in the
server_namevalue, so what looks correct at a glance doesn't actually match the domain being requested character-for-character
The Fix
First, confirm DNS is actually pointing to this server, ruling out a completely different cause before investigating Nginx configuration:
dig your-domain.com +short
Compare the returned IP against your server's actual public IP — if they don't match, the issue is DNS, not Nginx, and no configuration change here will fix it.
If DNS is correct, check every server_name directive across your Nginx configuration for the exact domain, including checking for typos:
grep -r server_name /etc/nginx/sites-enabled/
Confirm the domain you're troubleshooting has its own dedicated server block with a matching server_name:
server {
listen 80;
server_name your-domain.com www.your-domain.com;
root /var/www/your-site;
# ...
}
Explicitly designate which server block should act as the fallback for any request that doesn't match a specific server_name, rather than leaving it to whichever block happens to be defined first (which can change unexpectedly as you add or reorder configuration files):
server {
listen 80 default_server;
server_name _;
return 444; # or serve a deliberate fallback page
}
Using return 444; (a non-standard Nginx status that closes the connection without a response) is a common choice for the fallback block when you specifically don't want unmatched requests to reach any real site — useful for preventing unexpected domains or direct-IP requests from displaying one of your actual sites by accident.
After making changes, always test the configuration before reloading, since a syntax error in one file can prevent the entire configuration from loading correctly:
sudo nginx -t
sudo systemctl reload nginx
Still Not Working?
If everything above checks out but the wrong site still loads, check whether you're testing over HTTPS while the correct server_name match only exists in the HTTP (port 80) block, or vice versa — Nginx evaluates server_name matching separately for each listen directive and port, so a site correctly configured for port 80 but missing an equivalent block for port 443 will fall back to the default server specifically for HTTPS requests, even though HTTP requests to the same domain work correctly.