🚨 Nginx Error: 'client intended to send too large body' — Cause, Fix, and Troubleshooting Guide

What this error means

Nginx writes this line to error.log when the size of an incoming request body exceeds the configured client_max_body_size for the matching location or server. It is the server-side record of the same event the client sees as an HTTP 413 response:

2026/07/12 16:03:22 [error] 2841#2841: *91237 client intended to send too large body: 27262976 bytes, client: 203.0.113.44, server: example.com, request: "POST /upload HTTP/1.1", host: "example.com"

The 27262976 bytes is the value nginx read from the request’s Content-Length header (here ~26 MB) against a limit it will not exceed (the default is 1m). Nginx rejects the request before reading the full body, so the upload never reaches your application. The impact is failed file uploads, API POST/PUT calls, or multipart form submissions — anything with a body larger than the configured cap.

How the server responds

• File uploads and large POST/PUT requests fail while small ones succeed.
• Clients receive 413 Request Entity Too Large, and error.log shows the client intended to send too large body line.
• The failure is deterministic by size: everything under the limit works, everything over it fails.
• The bytes value in the log roughly matches the size of the file or payload the user tried to send.
• Multipart form uploads fail because the boundary-wrapped body exceeds the limit even when the raw file is close to it.
• When nginx proxies to a backend, the request may be rejected either at nginx (this error) or at the backend with its own size error.

Testing the server configuration

Confirm the error and the size involved by reading the log:

sudo tail -n 50 /var/log/nginx/error.log | grep "too large body"

Check the effective client_max_body_size across the full merged config and see which contexts set it:

sudo nginx -T | grep -n "client_max_body_size"

Identify which server and location actually handle the failing request (the server: and request: fields in the log line tell you the vhost and path). Then confirm the default is in play if the directive is absent — nginx uses 1m when nothing sets it.

If nginx proxies to a backend, reproduce the request to see where it is rejected. A 413 with the nginx error line means nginx blocked it; a 413/400 with no matching nginx error line means the backend rejected it:

curl -sS -o /dev/null -w '%{http_code}\n' -X POST \
  -F 'file=@./sample-26mb.bin' https://example.com/upload

Server configuration causes

• Default client_max_body_size of 1 MB — nginx ships with a 1 MB cap, which is far too small for file uploads, image posts, or bulk API payloads.
• Limit set in the wrong context — client_max_body_size set in http but overridden (or not set) in the specific server/location that handles uploads, so the effective value for /upload is still the default.
• Multipart overhead ignored — a multipart form body includes boundary markers, headers per part, and base64 expansion, so the on-the-wire body is larger than the file itself and can cross a limit sized only for the raw file.
• Backend has its own smaller limit — nginx allows the body, but the proxied application (or its framework/upload middleware) rejects it, so raising only the nginx value does not fix uploads end to end.
• Chunked uploads without Content-Length — nginx still enforces the limit as it reads the body; setting it to 0 disables the check but removes a useful guardrail.

The fix

Set client_max_body_size to a value large enough for your uploads, in the context that governs the upload endpoint. Setting it in http establishes a site-wide default; overriding it in a specific location keeps the limit tight everywhere else:

http {
    # Site-wide default
    client_max_body_size 10m;

    server {
        server_name example.com;

        # Allow large uploads only on the upload endpoint
        location /upload {
            client_max_body_size 50m;
            proxy_pass http://backend_upload;
        }
    }
}

client_max_body_size 0; disables the check entirely — use it only for a trusted, isolated upload path, never site-wide, because it removes protection against oversized-body abuse.

When nginx proxies the upload to an application, raise the backend’s limit too, or nginx will forward a body the backend then rejects. Also make sure request buffering matches your needs — with the default proxy_request_buffering on;, nginx buffers the whole body (to memory up to client_body_buffer_size, then to a temp file) before contacting the backend:

location /upload {
    client_max_body_size 50m;
    client_body_buffer_size 256k;   # in-memory buffer before spilling to disk
    proxy_request_buffering on;     # buffer body before sending upstream (default)
    proxy_pass http://backend_upload;
}

Common backend caps to raise alongside nginx: PHP upload_max_filesize and post_max_size, an application-framework body limit, or an object-storage gateway’s max object size.

After editing, validate and reload — a size-directive change does not require a restart:

sudo nginx -t && sudo systemctl reload nginx

Safe configuration practice

• Set the limit in the narrowest context that needs it; a large site-wide client_max_body_size invites oversized-body abuse on endpoints that should only receive small requests.
• Remember multipart and encoding overhead: size the limit above the largest expected file plus headroom, not exactly at the raw file size.
• Raising nginx’s limit alone is not enough behind a proxy — the backend’s own upload limit must match, or uploads still fail past nginx.
• 413 also comes from client_max_body_size, so the response status and this error line describe the same event from two sides; correlate them by timestamp and client IP.
• Watch for a spike in 413/too large body in your logs after a client or app change; it often signals a new upload feature that outgrew the limit. Wire it into your monitoring dashboard.
• Avoid client_max_body_size 0; except on a deliberately isolated path — it disables a safety limit and lets a single request consume disk via body temp files.

Related server errors

• Nginx Error: 413 Request Entity Too Large — the HTTP response clients receive for the same oversized-body condition this log line records.
• Nginx Error: 400 Request Header Too Large — the related limit for oversized request headers rather than bodies, tuned with different directives.
• Nginx Error: Upstream Sent Too Big Header — the mirror-image limit on the response side when a backend’s headers exceed nginx’s buffers.

See the NGINX category for more guides.