Fixing Nginx 'conflicting server name' - Stop Your Virtual Hosts from Being Ignored

TL;DR: The 30-Second Fix

This warning triggers when the same server_name appears in multiple configuration files for the same port. Nginx simply picks the first file it loads and ignores every other instance.

Find the duplicates: sudo grep -ri "example.com" /etc/nginx/
Delete the redundant server_name entry or merge the files.
Check your syntax: sudo nginx -t.
Apply changes: sudo systemctl reload nginx.

Why Nginx is Ignoring Your Config

Think of Nginx as a traffic controller. It uses the server_name directive to decide which folder or proxy should handle an incoming request. If you define example.com in two different places, Nginx gets confused.

Nginx cannot map a single domain to two different logic blocks simultaneously. To keep running, it chooses the first configuration it encounters—usually the one that comes first alphabetically in /etc/nginx/sites-enabled/. It then discards the others. This is why your latest updates might not show up in the browser.

Common Scenarios

The Copy-Paste Oversight: You cloned site-a.conf to create site-b.conf but forgot to update the domain inside the file.
The Default File Conflict: A default or 000-default file in your config folder still claims the domain you're trying to move to a new file.
Backup File Interference: You left a mysite.conf.bak file in a directory that Nginx scans. If your nginx.conf includes *.conf, it will load both the active and the backup file.
Port Overlap: You accidentally defined the same domain twice for port 443 (SSL) while trying to set up a redirect.

Step-by-Step Troubleshooting

1. Locate the Duplicates Fast

Don't waste time opening every file manually. Use grep to search the entire configuration directory. The -r flag searches recursively, and -i ignores case sensitivity.

# Search for your specific domain
sudo grep -ri "example.com" /etc/nginx/

A typical output showing a conflict looks like this:

/etc/nginx/sites-enabled/prod-site.conf:    server_name example.com;
/etc/nginx/sites-enabled/old-site.conf:     server_name example.com;

In this case, old-site.conf is the culprit stealing the traffic from your production file.

2. Check the Default Catch-all

If the domain doesn't show up twice in the grep results, check if a default server is acting as a wildcard. Run this to see what your default server is doing:

grep -r "default_server" /etc/nginx/sites-enabled/

3. Resolve the Conflict

Once you find the two files fighting for the domain, you have two choices:

Option A: Remove the old config

If old-site.conf is a relic from a previous setup, delete its symlink to stop Nginx from loading it:

sudo rm /etc/nginx/sites-enabled/old-site.conf

Option B: Consolidate aliases

If you want one site to respond to multiple names, put them all in one server block. Separate them with spaces on a single line:

server {
    listen 443 ssl;
    server_name example.com www.example.com dev.example.com;
    # ... rest of your config
}

4. Test and Reload

Always verify your changes before applying them. A single missing semicolon can crash your entire web server. Run the internal Nginx tester:

sudo nginx -t

If the output says test is successful, reload the service. Reloading is safer than restarting because it doesn't drop current connections.

sudo systemctl reload nginx

Docker-Specific Issues

When using the official nginx:alpine or nginx:latest images, a default config is often baked in at /etc/nginx/conf.d/default.conf. If you mount your own config files into that directory without overwriting the default, you'll hit this conflict immediately.

To find the conflict inside a running container, use:

docker exec -it  grep -r "example.com" /etc/nginx/

Fix this by ensuring your Dockerfile deletes the default config or by mounting your file directly over /etc/nginx/conf.d/default.conf.

How to Verify the Fix Works

You can prove Nginx is using the right file by adding a custom tracking header to your active config:

server {
    server_name example.com;
    add_header X-Config-Status "Correct-File-Loaded";
    # ...
}

After reloading, check the response headers with curl:

curl -I https://example.com

If you see X-Config-Status: Correct-File-Loaded, you've successfully resolved the conflict.