413 Payload Too Large Checklist

Problem

The final response code for the request is 413 Payload Too Large (now formally named 413 Content Too Large in RFC 9110, and still shown by many servers as 413 Request Entity Too Large).

Symptoms

• HTTP Check shows a final status code of 413.
• A small request works; a file upload or a large JSON/XML body fails.
• The form, API call, or upload dies at a specific size threshold every time.

What 413 Actually Means

RFC 9110 (§15.5.14) defines 413 as a request whose content is “larger than the server is willing to process.” That’s the whole story — nothing is wrong with your data, your auth, or your route. Some layer in the path measured the body, decided it was too big, and refused it. The spec lets the server close the connection rather than read a body it has already rejected, which is why a 413 sometimes arrives as a half-finished upload or an abrupt reset instead of a tidy response.

The trap is assuming “the server” means your application. In a modern stack the body passes through a CDN, then a reverse proxy, then maybe an ingress controller, then the app — and each one has its own size limit, set independently. The first one to say no wins. Fixing the limit in your app does nothing if nginx already returned 413 two hops earlier.

Top 3 Causes

1. The reverse proxy cap is too low - nginx defaults client_max_body_size to 1 MB and returns 413 the moment a body exceeds it, before your application sees a single byte. This is the single most common 413 by a wide margin. Apache’s LimitRequestBody and your framework’s body-parser limit are the same idea in different config files.
2. The CDN or platform has a hard ceiling - Cloudflare caps request bodies at 100 MB on Free and Pro plans (200 MB Business, 500 MB Enterprise) and returns 413 at the edge — your origin never gets the request, so origin config can’t fix it. Most managed platforms have an equivalent limit you can’t raise.
3. IIS / ASP.NET is enforcing two separate limits - IIS Request Filtering caps content at ~28.6 MB by default and reports 404.13, not 413. ASP.NET layers its own maxRequestLength (4096 KB) on top. You have to raise both, in the right config sections, or the lower one keeps winning.

Diagnose with DechoNet

• HTTP Check to confirm the final code is 413 and read the response headers — a Retry-After header points to a transient rate/size limit, while a server banner (nginx, cloudflare, Microsoft-IIS) tells you which layer rejected the body.
• DNS Lookup to confirm the request is reaching the host you think it is, and whether it routes through a CDN that imposes its own ceiling before your origin is involved.

Resolution Checklist

• Identify the exact size where it breaks — 1 MB points at nginx defaults, ~28.6 MB at IIS, 100 MB at Cloudflare Free/Pro. The number names the culprit.
• Read the Server header on the 413 response to see which layer answered (nginx, cloudflare, Microsoft-IIS, your app framework).
• Raise client_max_body_size in nginx (and reload), or LimitRequestBody in Apache, to a value above your real maximum upload.
• On IIS, raise requestLimits maxAllowedContentLength and ASP.NET maxRequestLength — both, or the lower one still blocks you.
• If a CDN imposes the ceiling, route large uploads around it (direct-to-storage signed URLs) rather than trying to lift a limit you don’t control.
• Re-run HTTP Check and confirm a full-size request no longer returns 413.

When to Escalate

• Escalate to whoever owns the CDN or platform if the limit is theirs and not configurable on your plan — the only real fix is a different upload path.
• If raising every documented limit still produces 413, look for a WAF or security rule inspecting and rejecting the body by size before the normal size checks run.