Ultimate Guide to Fixing Nginx [warn] conflicting server name Warning

In daily web server maintenance and deployment, it is a good practice to run `nginx -t` to check syntax after modifying Nginx configurations. However, you might occasionally encounter a `conflicting server name` warning. Although Nginx states that the `syntax is ok`, this warning indicates a logical flaw in your configuration that could prevent your website from routing as expected. This article details the root cause of this warning and provides a complete guide to troubleshooting and fixing it. ## 1. Error Reproduction When configuring an HTTPS site, you might see the following output during a configuration test: ```bash [root@VM-centos ~]# docker exec ee-nginx-1.23.3 nginx -t nginx: [warn] conflicting server name "ai.lib00.com" on 0.0.0.0:443, ignored nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful ``` --- ## 2. Root Cause Analysis The core reason for this warning is: **The same domain name (`server_name`) is defined multiple times on the same port (e.g., `443` or `80`) within the Nginx configuration files.** * **Conflict Mechanism**: While parsing the configuration, Nginx finds multiple `server` blocks declaring the exact same `server_name` (e.g., `ai.lib00.com`) and listening port (`443`). * **How Nginx Handles It**: Nginx adopts a "first-come, first-served" strategy. It loads the first configuration it reads and **ignores** any subsequent duplicate configurations. This is why the test still shows `syntax is ok`, but in reality, your latest configuration changes might not take effect at all. --- ## 3. Quick Troubleshooting Steps To resolve this issue, we need to locate all configuration files that define the conflicting domain. DP@lib00 recommends the following steps for precise identification: ### Step 1: Global Domain Search Navigate to the Nginx configuration directory (usually `/etc/nginx` or `/usr/local/nginx/conf`) and use the `grep` command to search for the conflicting domain globally: ```bash grep -r "ai.lib00.com" /etc/nginx/ ``` ### Step 2: Identify Common Conflict Scenarios Based on the `grep` output, you will typically find one of the following situations: 1. **Leftover Expired Files (Most Common)**: Historical configuration files (e.g., `old_site.conf`) in the `conf.d/` directory were not deleted. 2. **Backup Files Accidentally Loaded**: It's common to run `cp site.conf site.conf.bak` before making changes. If the main Nginx config uses `include /etc/nginx/conf.d/*;`, the `.bak` file will also be loaded. 3. **Duplicates within a Single File**: Accidentally copy-pasting two identical `server { ... }` blocks within the same configuration file. 4. **Duplicate Symlinks**: When using the `sites-available` and `sites-enabled` pattern, multiple symlinks might point to the same site configuration. --- ## 4. Real-World Scenario and Fix In a real-world scenario from wiki.lib00.com, a developer investigated the issue and discovered that an expired config file containing the same domain `ai.lib00.com` was left in the `conf.d/` directory. **How to Fix**: Once you locate the duplicate definitions, simply delete the redundant `server` blocks or the expired configuration files. ```bash # Delete the expired configuration file rm -f /etc/nginx/conf.d/expired_site.conf # Retest Nginx configuration nginx -t # Reload Nginx once the warning is gone nginx -s reload ``` --- ## 5. Best Practices for Nginx Configuration Management (Bonus) To prevent similar conflicts in the future, consider the following best practices: * **Strict Include Rules**: In `nginx.conf`, prefer using `include /etc/nginx/conf.d/*.conf;` instead of a wildcard `*`. This ensures that backup files like `.bak` or `.save` are not accidentally loaded by Nginx. * **Clean Up Deprecated Configs Promptly**: Configurations for offline sites should be moved out of the configuration directory or renamed to `.conf.disabled`. * **Modular Management**: Use a separate `.conf` file for each independent domain or subdomain (like `wiki.lib00`), keeping the structure clean and easy to maintain.