Fix Nginx Duplicate Location Config Error

If Nginx fails to start with an error like duplicate location, the cause is almost always two location blocks with the same matching pattern in the same server or location context. The fix is to merge the duplicate blocks into one, or change one of the patterns so each is unique; this article explains exactly how to find, fix, and prevent the error.

What the Error Means

Nginx parses its configuration files into a tree of contexts (http, server, location). Within any single context, each location directive must have a unique “matchâ€� — the part after the word location, like /images/ or ~ \.php$. If you write two location blocks with the same match in the same context, Nginx cannot decide which one should own that request, so it refuses to start and prints an error naming the duplicate pattern and the file and line number.

This is a configuration error, not a runtime crash. The server will not start until you edit the file and run nginx -t to test it. The error message usually looks like:

nginx: [emerg] duplicate location "/api" in /etc/nginx/sites-enabled/default:42

Common Causes

• Copy-paste blocks — you copied a location block and forgot to change the path.
• Included files — the same include file is loaded twice, or two different include files define the same location.
• Editing an active config — you edited a file that is symlinked into sites-enabled and also edited the original in sites-available, then reloaded and Nginx sees both.
• Default config leftovers — the default server block already has location / and you added another location / in the same file.

How to Find the Duplicate

Nginx gives you the file and line number, but sometimes the duplicate is in an included file that is not obvious. Follow these steps:

1. Run nginx -t and read the error message carefully. It names the exact pattern and file.
2. Open that file and search for the pattern (e.g., grep -n "location /api" /etc/nginx/sites-enabled/default).
3. Check if any included files also define the same pattern. Look for include directives in the same context.
4. If you use symlinks, verify that sites-enabled points to the file you are editing, and that you are not editing a copy.
5. If still stuck, run nginx -T (capital T) which dumps the entire resolved configuration, including all included files, so you can see every location block in one place.

How to Fix It

The correct fix depends on what you intended. The three options are:

• Merge the blocks — if both blocks contain directives you need, combine them into one block. For example, if one has proxy_pass and the other has add_header, put both inside a single location /api block.
• Change the pattern — if you actually need two different behaviors for two different paths, change one pattern to a more specific one, like location /api/v1 and location /api/v2.
• Delete the extra block — if one block is a leftover, simply remove it. Then run nginx -t again to confirm the error is gone.

After editing, always test with nginx -t before reloading. If the test passes, reload with systemctl reload nginx or nginx -s reload.

Nginx Location Matching Rules You Should Know

To avoid future duplicates, understand how Nginx chooses a location. The matching rules are:

• location = /path — exact match, highest priority.
• location ^~ /path — prefix match that stops searching once found.
• location ~ regex — case-sensitive regular expression, checked in order.
• location ~* regex — case-insensitive regular expression.
• location /path — plain prefix match, lowest priority among prefixes.

Two blocks with the same prefix (like location /api twice) are always a duplicate. But two blocks with different prefixes (like location /api and location /api/) are not duplicates — Nginx treats them as different patterns, though they may overlap in practice. The error only fires for identical match strings.

Preventing the Error in the Future

Good file organization helps. Use separate files for each site or each API group, and include them with a clear naming convention. For example:

# /etc/nginx/conf.d/api.conf
location /api {
    proxy_pass http://backend;
}

Then in your server block, include it once: include /etc/nginx/conf.d/api.conf;. Avoid including the same file from multiple places. Also, before every reload, run nginx -t — it is fast and catches most mistakes.

If you use a configuration management tool (like Ansible or Puppet), make sure the template does not generate duplicate blocks when a variable repeats. Test the generated config in a staging environment.

Frequently Asked Questions

Why does Nginx say “duplicate location� but I only see one in my file?

Because the duplicate is in an included file. Run nginx -T to see the full resolved config, or search all files under /etc/nginx for the pattern. Also check if you have both sites-available and sites-enabled versions of the same file, and that you are not editing a symlink target that is loaded twice.

Can I have two location blocks with the same path if they are in different server blocks?

Yes. The duplicate error only applies within the same context. Each server block can have its own location / or location /api without conflict. The error appears only when two identical locations exist in the same server or location block.

Does the order of location blocks matter for duplicates?

No. Nginx reads the entire context before checking for duplicates, so reordering does not help. You must remove or merge the duplicate.

What is the difference between location /api and location = /api?

They are different patterns, so they are not duplicates. location = /api matches only the exact URL /api, while location /api matches any URL starting with /api, like /api/users. If you have both, Nginx uses the exact match for /api and the prefix match for everything else.

Can I use regular expressions to avoid duplicates?

Yes, but you must ensure the regex patterns are different. For example, location ~ ^/api/ and location ~ ^/api/v1/ are distinct. However, be careful: regex locations are evaluated in order, so the first matching one wins. Duplicate regexes (identical patterns) still trigger the error.

What if I get the error after a reload, not a start?

That can happen if you edited a config file while Nginx was running and then reloaded. The reload fails, and Nginx keeps running with the old configuration. Fix the file, run nginx -t, and reload again. The old config remains active until a successful reload.

Related

• AI Automation vs Augmentation: Department Fit
• Non-Dedicated Server in ARK: What It Is & When to Use
• Best One Piece Couple Ships Ranked for Fans