🚨 Nginx Error: 'shared memory zone 'one' conflicts with already declared size' — Cause, Fix, and Troubleshooting Guide

What this error means

the size <N> of shared memory zone "<name>" conflicts with already declared size <M> is a configuration-parse error. Several NGINX directives allocate a named block of shared memory — limit_req_zone ... zone=one:10m, limit_conn_zone ... zone=one:10m, proxy_cache_path ... keys_zone=one:10m, and others. A zone name is a global handle: NGINX expects each name to be declared once with a single size. When the same name appears twice with different sizes, NGINX cannot reconcile the allocations and refuses to load.

nginx: [emerg] the size 10485760 of shared memory zone "one" conflicts with already declared size 1048576 in /etc/nginx/nginx.conf:12
nginx: configuration file /etc/nginx/nginx.conf test failed

The sizes are shown in bytes (10485760 = 10m, 1048576 = 1m). The line cited is the second declaration. As with any parse [emerg], a reload leaves the old config in place and a cold start fails.

How the server responds

• nginx -t fails with [emerg] the size ... of shared memory zone "one" conflicts with already declared size ....
• Two byte counts in the message differ (e.g. 10485760 vs 1048576).
• systemctl reload nginx fails; a cold start leaves the service dead.
• Started after adding a second limit_req_zone/limit_conn_zone/proxy_cache_path, or after an include was pulled in twice.
• The cited file:line is the later of two declarations sharing one zone name.
• A related variant fires when the same name is used by two different zone types (rate-limit vs cache).

Testing the server configuration

Validate to get the conflicting name, both sizes, and the file:line.

sudo nginx -t

List every shared-memory zone declaration across the whole tree, regardless of directive:

grep -RnE 'zone=[A-Za-z0-9_]+|keys_zone=[A-Za-z0-9_]+' /etc/nginx/

Isolate the specific colliding name from the error (here, one):

grep -RnE '(zone|keys_zone)=one[: ]' /etc/nginx/

Because include order determines what is actually assembled, dump the resolved config and look at the two declarations together:

sudo nginx -T | grep -nE 'zone=|keys_zone='

Check whether an include is being pulled in more than once:

grep -RnE '^\s*include' /etc/nginx/nginx.conf /etc/nginx/conf.d/

Server configuration causes

• Duplicated include — the same snippet declaring limit_req_zone ... zone=one:1m is included from two places, so the second copy re-declares one with the same or a different size.
• Copy-pasted zone with an edited size — a block was copied to create a second limiter but the zone= name was left as one while the size was bumped to 10m.
• Name reused across directive types — limit_req_zone ... zone=api:10m and proxy_cache_path ... keys_zone=api:1m both claim api; the name space is shared, and the sizes clash.
• Generated config drift — a templating/config-management run emits the zone in two roles (base plus per-site) with inconsistent sizing.
• Global plus per-vhost declaration — the zone is declared once in http {} and again inside an included vhost, unintentionally, with a different size.
• Merged configs — two teams each added a zone=one limiter in separate files, both loaded under the same http context.

The fix

Pick one of two correct resolutions: give each zone a unique name, or declare the shared zone exactly once with a single size.

If the two blocks are genuinely different limiters, rename one so the names no longer collide:

http {
    # distinct names, distinct sizes — no conflict
    limit_req_zone $binary_remote_addr zone=login_rl:1m  rate=5r/s;
    limit_req_zone $binary_remote_addr zone=api_rl:10m   rate=50r/s;
}

If it is truly one logical zone declared in two places, keep a single declaration with one size and delete the duplicate:

http {
    # declare ONCE, in one place, with one size
    limit_req_zone $binary_remote_addr zone=one:10m rate=20r/s;
    # ...remove the second `zone=one:1m` declaration entirely
}

If a duplicated include is the cause, include the snippet a single time (typically at http scope) rather than per-vhost. Reference the zone in your limit_req/limit_conn/proxy_cache usage without re-declaring it:

server {
    location /api/ {
        limit_req zone=api_rl burst=100 nodelay;   # uses, does not re-declare
    }
}

Zone allocation happens at config load, so validate and reload:

sudo nginx -t && sudo systemctl reload nginx

Safe configuration practice

• Zone names share one global namespace across limit_req_zone, limit_conn_zone, proxy_cache_path (keys_zone), and similar — don’t reuse a name for two purposes.
• Sizes in the error are bytes; convert (1048576 = 1m, 10485760 = 10m) to spot which declaration is which.
• The zone is declared once but referenced many times — limit_req zone=.../limit_conn zone=... are usages, not re-declarations; only the _zone line sets the size.
• Watch duplicated includes: the same snippet loaded twice is the most common trigger in templated setups.
• Adopt a naming convention (login_rl, api_rl, cache_static) so per-purpose zones can’t accidentally collide.
• Size zones deliberately — a limit_req zone of 1m holds roughly 16k states; grep all zone= after any bulk change to keep sizes consistent.

Related server errors

• Nginx Error Invalid Number Of Arguments — another parse [emerg] from malformed directives, common when editing zone lines.
• Nginx Error Duplicate Location — a sibling “declared twice” parse error, but for location blocks instead of zones.
• Nginx Error Unknown Directive — the failure when a zone-related directive name itself is unrecognized or misspelled.

See the NGINX category for more guides.