Overview

A client uploads a file or posts a large payload and gets back 413 Request Entity Too Large. This is the ingress proxy — not your application — rejecting the request because its body exceeds the proxy’s configured maximum. ingress-nginx defaults proxy-body-size to 1m (1 MB), so any request body larger than that is refused before it ever reaches your backend. The 413 comes straight from nginx, and your app logs show nothing because the request never arrived.

The literal response looks like this:

HTTP/1.1 413 Request Entity Too Large
Content-Type: text/html
<html>
<head><title>413 Request Entity Too Large</title></head>
<body><center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx</center></body>
</html>

The fix is to raise the allowed body size at every layer that can enforce a limit — the ingress (globally or per-Ingress annotation) and, if present, the backend web server and application. Because the default is small, this bites almost every app that accepts uploads.

Symptoms

Large POST/PUT requests return 413 Request Entity Too Large; small ones succeed.
The response Server header is nginx and the body is nginx’s default 413 page.
Application logs show no corresponding request — it was rejected at the proxy.
Increasing the upload size makes previously-working requests start failing at a threshold (often exactly 1 MB).

curl -sS -o /dev/null -w '%{http_code}\n' -X POST -F file=@big.zip https://app.example.com/upload

Common Root Causes

1. ingress-nginx default proxy-body-size (1m)

The default limit is 1 MB. Any body over that is rejected. This is the single most common cause.

kubectl get ingress app -o jsonpath='{.metadata.annotations}'

{}

No proxy-body-size annotation means the 1 MB default applies.

2. Annotation set too low (or wrong units)

A proxy-body-size value that is smaller than the largest legitimate upload, or one missing units, still rejects large requests.

nginx.ingress.kubernetes.io/proxy-body-size: "8m"

If uploads exceed 8 MB, they still 413. Use 0 to disable the limit (with caution) or set a value above your max.

3. The backend web server enforces its own limit

Even with the ingress raised, an upstream nginx, Apache, or app framework (client_max_body_size, LimitRequestBody, Spring max-file-size) can return 413 itself.

kubectl logs deploy/app | grep -i '413\|too large'

4. A cloud/L7 load balancer in front caps the body

A managed load balancer or WAF ahead of the ingress may impose its own request-size limit, returning 413 before nginx.

5. Buffering settings interacting with large bodies

With request buffering on and a large body, temp-file limits can also surface as 413/500; the body-size annotation is still the primary control.

Diagnostic Workflow

Step 1: Confirm the 413 comes from nginx

curl -sSI -X POST -F file=@big.zip https://app.example.com/upload | head

A Server: nginx header on the 413 confirms the ingress proxy is rejecting it.

Step 2: Check the current annotation

kubectl get ingress <NAME> -o jsonpath='{.metadata.annotations.nginx\.ingress\.kubernetes\.io/proxy-body-size}{"\n"}'

Empty means the 1 MB default is in force.

Step 3: Raise proxy-body-size on the Ingress

kubectl annotate ingress <NAME> \
  nginx.ingress.kubernetes.io/proxy-body-size=50m --overwrite

For a cluster-wide default, set proxy-body-size in the ingress-nginx ConfigMap instead.

Step 4: Verify the reload took effect

kubectl -n ingress-nginx logs deploy/ingress-nginx-controller | grep -i reload | tail -1

Step 5: Confirm the backend limit is not lower

kubectl logs deploy/<APP> | grep -i 'too large\|413'

Example Root Cause Analysis

Users report that document uploads over ~1 MB fail on a new environment:

curl -sS -o /dev/null -w '%{http_code}\n' -X POST -F file=@report.pdf https://app.example.com/upload

Confirming the proxy is the source:

curl -sSI -X POST -F file=@report.pdf https://app.example.com/upload | grep -i server

Server: nginx

Checking the Ingress shows no body-size annotation:

kubectl get ingress app -o jsonpath='{.metadata.annotations}'

{"nginx.ingress.kubernetes.io/rewrite-target":"/"}

So the 1 MB default applies. The largest legitimate upload is ~40 MB, so we raise the limit and re-test:

kubectl annotate ingress app \
  nginx.ingress.kubernetes.io/proxy-body-size=50m --overwrite

curl -sS -o /dev/null -w '%{http_code}\n' -X POST -F file=@report.pdf https://app.example.com/upload

The upload succeeds. We also confirm the backend’s own client_max_body_size is at least 50 MB so it does not become the next bottleneck.

Prevention Best Practices

Set proxy-body-size explicitly on every Ingress that accepts uploads rather than relying on the 1 MB default.
Keep the ingress limit and every upstream limit (backend nginx/Apache, app framework) in sync; the smallest one wins.
Prefer a per-Ingress annotation over 0 (unlimited), which can expose you to memory-exhaustion via huge uploads.
Document the chosen max upload size and enforce it in the app so clients get a clear error rather than a raw nginx 413.
Include a large-upload test in CI/smoke tests so a body-size regression is caught before users hit it. See more in Kubernetes & Helm guides.

Quick Command Reference

# Confirm nginx is returning the 413
curl -sSI -X POST -F file=@big.zip https://app.example.com/upload | head

# Check the current annotation (empty = 1m default)
kubectl get ingress <NAME> -o jsonpath='{.metadata.annotations.nginx\.ingress\.kubernetes\.io/proxy-body-size}{"\n"}'

# Raise the limit on the Ingress
kubectl annotate ingress <NAME> \
  nginx.ingress.kubernetes.io/proxy-body-size=50m --overwrite

# Confirm the controller reloaded
kubectl -n ingress-nginx logs deploy/ingress-nginx-controller | grep -i reload | tail -1

# Check the backend is not the lower limit
kubectl logs deploy/<APP> | grep -i 'too large\|413'

Conclusion

413 Request Entity Too Large from an ingress means the proxy rejected a request body larger than its configured maximum. The usual causes:

The ingress-nginx default proxy-body-size of 1 MB.
An annotation set too low for real uploads.
A backend web server/framework enforcing its own smaller limit.
A cloud load balancer or WAF capping the body ahead of nginx.
Buffering/temp-file limits interacting with large bodies.

Raise proxy-body-size on the Ingress (or the controller ConfigMap) and keep every upstream limit in sync. For ad-hoc triage, the free incident assistant can turn a 413 response into the exact annotation and backend change.

Kubernetes Error Guide: Ingress '413 Request Entity Too Large' — Fix Upload Limits

Fixing errors like this? Get 500 free DevOps AI prompts