## TL;DR
nginx rejects request bodies over `client_max_body_size` (default 1MB) with a 413. Set it higher in the `http`, `server`, or `location` block that serves uploads. Uploads succeed once the limit covers the payload.

## Error
```text
nginx: client intended to send too large body
```

## Steps
1. Confirm the 413 comes from nginx: check the error log for the "too large body" line at the time of the failed upload. Expected: the log names the limit as the cause.
2. Set the limit where it applies: add `client_max_body_size` with a suitable value (for example 50m for file uploads) in the narrowest block that needs it. Expected: uploads under the new limit pass.
3. Reload nginx and retry the upload. Expected: 200/201 instead of 413.
4. Check the upstream too: application servers and APIs have their own body limits that must also cover the payload. Expected: no second 413 from behind the proxy.
5. Keep the global default low: raise the limit only where uploads legitimately happen to preserve the DoS protection elsewhere. Expected: tight limits on non-upload routes.

## When to use
- Uploads fail with HTTP 413 through nginx
- API endpoints receiving large JSON payloads
- After adding file-upload features behind an existing proxy

## When not to use
- 413s from the upstream app directly (app-side limit)
- Timeouts on large uploads (different tuning)

## Tool compatibility
- nginx `client_max_body_size`; error log

## Variant phrasings
### nginx 413 request entity too large
Raise `client_max_body_size` in the upload location; the 1MB default is easy to hit.

### increase nginx upload size
Set the directive per location so the rest of the site keeps the safe default.

## Why it happens
nginx enforces the body cap before proxying to protect upstreams from huge payloads. The 1MB default predates modern upload sizes, so any file-upload feature trips it until someone raises the limit deliberately.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yhE8zn_BDF6ksx-rizlB0Q