nginx 413 Request Entity Too Large: client_max_body_size Fix

An HTTP 413 means the server refused a request because its body, usually a file upload or a large POST, exceeds a size limit. In nginx the limit is client_max_body_size, and it defaults to 1 MB, which is why even a modest photo upload can fail on a fresh server.

You see a page reading "413 Request Entity Too Large" with nginx below it, a failed upload in a CMS, or a JavaScript console error from an API client. The error log records the details:

[error] 1234#1234: *56 client intended to send too large body: 1048576 bytes, client: 203.0.113.7, server: example.com, request: "POST /wp-admin/async-upload.php HTTP/1.1"

Newer HTTP specifications call this status "Content Too Large", but servers and browsers still show the older phrase. See the HTTP 413 reference.

Causes, most likely first

1. nginx client_max_body_size is at its 1 MB default, or set lower than the uploads you accept.
2. Another layer in front has its own limit: a reverse proxy, Kubernetes ingress, load balancer or CDN.
3. PHP limits that are lower than nginx's. These cause a different failure (the form silently drops or the app reports a size error), but you must raise them together.
4. An Apache backend with LimitRequestBody.
5. A genuinely oversized or runaway request, such as a client sending a huge JSON body in a loop.

Fix 1: raise client_max_body_size in nginx

The directive is valid in http, server and location contexts. Set it as narrowly as you can:

server {
    server_name example.com;
    client_max_body_size 64m;          # whole site

    location /api/upload {
        client_max_body_size 512m;     # only the upload endpoint
    }
}

Apply it:

sudo nginx -t && sudo systemctl reload nginx

Setting the value to 0 turns the check off entirely, which allows unlimited request bodies. Avoid that on public sites, since anyone can then push very large payloads at you. The directive is checked against the Content-Length header, so the error is returned before nginx reads the body.

Fix 2: raise PHP limits to match

If your backend is PHP, both of these must be at least as large as the biggest upload, and post_max_size must be larger than upload_max_filesize:

upload_max_filesize = 64M
post_max_size = 70M
memory_limit = 256M

Put them in the php.ini that PHP-FPM loads, then reload: sudo systemctl reload php8.2-fpm. In WordPress you can confirm the effective limit under Media, Add New. Also consider max_execution_time and nginx's fastcgi_read_timeout for slow uploads; see nginx upstream timed out.

Fix 3: check every layer in front

The body must pass every hop. Identify who returned the 413 by looking at the response headers and error page:

curl -s -o /dev/null -D - -X POST -H "Content-Type: application/octet-stream" \
  --data-binary @bigfile.bin https://example.com/upload | head -n 15

A Server: nginx header with a plain page points to your own nginx. A cf-ray header or Cloudflare branding points to the CDN. The HTTP Header Checker और CDN डिटेक्टर help from the outside.

• Kubernetes ingress-nginx: use the annotation nginx.ingress.kubernetes.io/proxy-body-size: "64m" on the Ingress.
• Apache backend: LimitRequestBody 67108864 (bytes) in the relevant Directory or Location. 0 means unlimited.
• Cloudflare: the proxy caps upload size by plan; the documented figures are currently 100 MB on Free and Pro, and higher on Business and Enterprise. Check Cloudflare's current limits page. Uploads beyond the cap must bypass the proxy, for example through a DNS-only subdomain, or use chunked or direct-to-storage uploads.
• Cloud load balancers often have their own request size limits; check your provider's docs.

Fix 4: change the design for very large files

Instead of raising limits ever higher, use chunked uploads or send files straight to object storage with a pre-signed URL. This avoids tying up PHP workers and avoids proxy caps.

How to verify

Upload a test file just under your new limit and one just over it. The first should succeed and the second should fail with 413, proving the limit is where you intended. From the command line:

head -c 10M /dev/urandom > test10m.bin
curl -i -X POST --data-binary @test10m.bin https://example.com/upload

Check the status code with the HTTP स्टेटस चेकर if the endpoint accepts a plain request, and confirm no new too large body entries appear in the nginx error log. Keep an अपटाइम मॉनिटर on your upload form page so a config change does not silently break it.

अगले कदम

• Inspect headers with the HTTP Header Checker.
• See which CDN fronts the site with the CDN डिटेक्टर.
• Read Fix 500 Internal Server Error if raising limits produces a different failure.
• Review the HTTP 413 reference.

सामान्य प्रश्न

What is the default client_max_body_size?

1 MB in nginx, unless you set it. Browsers upload single images larger than that regularly, so most sites need to raise it.

I set it in nginx.conf but it still fails. Why?

A narrower server or location block may set a different value, or the 413 comes from another layer such as a CDN, ingress or Apache. Dump the effective config with nginx -T and check the response headers to find who answered.

Is it safe to set client_max_body_size to 0?

It disables the limit, which lets any client send arbitrarily large bodies. Prefer a specific maximum, and a higher one only on the endpoints that need it.

Does the PHP limit matter if nginx allows it?

Yes. PHP rejects uploads beyond upload_max_filesize and post_max_size independently, so raise nginx and PHP together.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.