Nginx

Nginx client_max_body_size, Fixing "413 Request Entity Too Large"

A 413 error means Nginx itself rejected the request before it ever reached your application, because the request body exceeded the configured client_max_body_size — this default limit (just 1MB) surprises a lot of people the first time they need to accept a larger file upload.

The Problem

Uploading a file — an image, a document, anything reasonably sized — fails with:

413 Request Entity Too Large
nginx

Your application's own upload handling code never even runs, since Nginx rejects the request before proxying it through, which can be confusing if you're only looking at application-level logs and seeing nothing there at all.

Why It Happens

Nginx enforces a default maximum request body size of 1MB specifically as a safety measure against overly large uploads consuming excessive server resources. Common causes of hitting this limit unexpectedly:

  • The default 1MB limit is simply too small for the actual use case — image uploads, document uploads, or API payloads that legitimately exceed this size
  • The client_max_body_size directive was set in the wrong scope (for example, only in the http block, but the relevant server or location block that actually handles the request has its own more restrictive value that overrides it)
  • A CDN or load balancer in front of Nginx has its own separate body size limit, independent of Nginx's own configuration, which can cause the same 413 error even after correctly adjusting Nginx itself

The Fix

Set client_max_body_size to an appropriate value for your use case. This can be set at the http, server, or location level, depending on how broadly you want it to apply:

http {
    client_max_body_size 20M;
}

For a more targeted change affecting only a specific upload endpoint rather than the entire server, set it within the relevant location block instead:

location /api/upload {
    client_max_body_size 20M;
    proxy_pass http://backend;
}

Understand the scoping rules: a directive set in a more specific block (like location) overrides one set in a broader block (like http or server) for requests handled by that specific block — but a directive isn't automatically inherited downward if a more specific block doesn't explicitly set it, depending on the directive and Nginx version, so it's worth being explicit at the level where the request is actually processed rather than assuming a broader setting definitely applies.

After changing the configuration, test it and reload Nginx for the change to take effect:

sudo nginx -t
sudo systemctl reload nginx

If you're running behind a CDN, cloud load balancer, or another reverse proxy layer in front of Nginx, check that layer's own body size limits as well — fixing Nginx alone doesn't help if an earlier layer in the request path already rejects large requests before they even reach Nginx. Each provider has its own configuration mechanism for this, typically documented under upload or request size limits in their respective settings.

If your application itself also has a body size limit configured at the framework level (many frameworks impose their own default, separate from Nginx), make sure that's raised to match as well — Nginx allowing a larger request through doesn't help if your application then rejects it independently for the same underlying reason.

Still Not Working?

If you've raised the limit and reloaded Nginx but still see 413 errors, confirm you actually edited the config file Nginx is loading, rather than a duplicate or unused file — check which config files are actually included in the running configuration:

sudo nginx -T | grep client_max_body_size

This dumps the fully resolved, active configuration (including all included files), showing every place client_max_body_size is actually set and at what value — if a lower value appears somewhere you didn't expect, that's the one actually taking effect for the relevant request, and needs to be updated at that specific location rather than wherever you initially assumed the setting lived.