Fix Nginx “conflicting server name … ignored” warnings

Find duplicate hostname mappings on the same listening address and port, and verify which virtual host receives each request.

Best practices
Illustration of server operations and request logs

This warning means a hostname mapping conflicts with an earlier mapping for the same listening address and port. Nginx ignores the later conflicting name. It does not necessarily discard the entire later server block: that block may still serve other names, addresses, or default-server traffic.

Inspect the configuration Nginx actually parses

sudo nginx -t
sudo nginx -T > /tmp/nginx-config.txt
grep -n -E 'configuration file|listen|server_name' /tmp/nginx-config.txt

Read the surrounding server blocks in the complete dump. Count hostname-and-listener combinations, not just repeated hostname strings. A recursive search of /etc/nginx can also find disabled backups and both ends of a symlink, so its duplicates are only leads.

Protect the dump if your configuration includes credentials or private endpoints.

Remove duplicate includes or definitions

A common case is enabling both a sample default site and a replacement site containing the same hostname:

ls -l /etc/nginx/sites-enabled/

Identify the redundant symlink before removing it. Also check whether the same file is included through both conf.d and sites-enabled. Consolidate the intended directives into one hostname mapping per listener. Do not use filename ordering as an override mechanism: the later conflicting mapping is ignored rather than merged.

Separate HTTP and HTTPS listeners

The same hostname can legitimately appear on ports 80 and 443. For example, the HTTP redirect can be:

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

The content server then uses listen 443 ssl with its own certificate settings. Accidentally leaving both blocks on port 80 produces a conflict. Different explicit IP-and-port combinations can also legitimately reuse a hostname.

Verify hostname routing after the reload

sudo nginx -t && sudo systemctl reload nginx
curl -I --resolve example.com:80:192.0.2.10 http://example.com/

Replace the documentation address with your server address. Test HTTPS separately using the correct hostname so certificate and SNI checks remain meaningful. Confirm that the warning disappears and the expected site handles each request.

For multi-host logging, include $host and $server_name in the configured format before using DataKit log collection to compare requests. Traffic reaching one healthy hostname does not prove that all duplicate mappings are fixed.

FAQ

Does the warning prevent startup?

Usually this warning alone does not. That makes it easy to miss: the process can run while some hostnames select an unintended configuration. Check for any separate fatal errors as well.

How does default_server relate to this?

It controls the fallback for an unmatched name on a listening address and port. It does not resolve duplicate explicit names. If no block is marked as default, the first block for that listener is the default.

Can one server block contain several names?

Yes. Only its conflicting entries are affected by this warning; unique names in the same block may still work. Test every intended hostname after consolidating the configuration.

Reference: Nginx server-name selection.

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting