413 Request Entity Too Large: The Four Limits You Have to Raise

The First Hops That Can Say No

When an upload fails as 413 Request Entity Too Large, it means that the request was considered too large by the first hop that checks the request size.

Nginx as the Common Gatekeeper

If Nginx is serving your app, it is often the first to reject a large upload. By default, Nginx allows only 1 megabyte (MB) of client request body, overriding that with the client_max_body_size directive. This directive sets a hard limit on the allowed size of the client request body; Nginx will reject the request before it even reaches the upstream if the body exceeds that limit.

The client_max_body_size directive can be set in the http, server, or location block. If you want to turn off the Nginx request-body size check, you can set this value to 0.

However, keep in mind that if Nginx is set up as a reverse proxy, it will reject oversized requests before the backend server ever sees them. When following this troubleshooting guide, think about where Nginx is placed (CDN, L7 LB, reverse-proxy, etc.) and which client_max_body_size is relevant to your upload success.

Why Backend-Only Fixes Fail

If you assumed that increasing PHP's upload_max_filesize and post_max_size would resolve the issue, you might be missing the bigger picture. Similarly, framework-specific limits like Django's DATA_UPLOAD_MAX_MEMORY_SIZE can be ineffective when earlier layers—such as a CDN, L7 load balancer, or reverse proxy—have already filtered out the oversized request.

Let's look at an example. You want to upload a 50 MB file through a reverse proxy that has a 10 MB request body limit. The upload fails as 413 Request Entity Too Large, but backend log files indicate a successful upload! What's happening here is that the reverse proxy rejected the large request, and the backend (which has a much larger limit) never received anything.

The Layers after Nginx

Of course, multiple layers can impose their own limits. For example, Apache uses the LimitRequestBody directive to limit the size of incoming requests. When using PHP for file uploads, the upload_max_filesize and post_max_size settings in the php.ini file control the maximum upload size. Django, on the other hand, employs DATA_UPLOAD_MAX_MEMORY_SIZE and FILE_UPLOAD_MAX_MEMORY_SIZE for managing file uploads.

Edge Layers Before Origin

Consider the source of the rejection before troubleshooting the origin server. The connection between the client and the origin server often traverses CDN nodes, hashing algorithms, HTTP/2 queues, anti-DDoS appliances, and other edge services. Each of these interposed layers has its own enforced limits on request size.

It's common to see a 413 error page branded by a CDN, indicating that the edge layer rejected the upload before it even was sent to your origin server. If you see no record of the rejected upload in your origin logs, it strongly suggests that an edge service stopped the request, not your app.

Understanding the request-flow diagram for your system can narrow down which edge services you need to check or exclude from the troubleshooting process. If a WAF or CDN sits in front of a reverse proxy, with your app served by the origin server, you will need to check each configured limit, in order from the outermost to the innermost. Unsure where to look first?

The Fix Order That Actually Works

If your file upload returns 413, identify the rejecter by its error page or missing request log. That layer is the one whose limit you must raise first.

Next, ensure that every other configured limit in the request path allows a larger allowable size. Raise the next limit inward; repeat for the rest.

Finally, confirm that the outermost limit is no smaller than every other configurable limit in that hop-by-hop path. This step ensures that no other configured limit could reject the request, even if the rejecting hop gave you a 200 OK.

With an exhaustive change-list, retry the upload. Should the problem persist, consider these possibilities:

-has a new limit been introduced that you didn't add? -has your actual upload size grown? The error reports the limit, not the file size. Are you sure that the file is below the allowed value? -elements upstream have been updated independently of those you adjusted. Did a limit change by way of new software or config sync or application-support updates?

If none of these is likely, you may be facing a 413 that comes from network equipment, or a CDN/subscription-required limit, or even a storage limit that the original outermost hop was masking. Guess which team to contact.