How to fix HTTP 413: request body too large

HTTP 413 means a request body exceeds a limit enforced by a server in its path. Identify which layer rejected it before changing settings. An Express parser, multipart upload handler, reverse proxy, CDN, or gateway can each enforce a separate limit.

Set limits around the uploads your service actually accepts. Removing them entirely can expose the application to memory, disk, and concurrency exhaustion.

Configure the application: Express

Express 4.16 and later include JSON and URL-encoded body parsers:

const express = require('express');
const app = express();

// These parsers do not handle multipart file uploads.
app.use(express.json({ limit: '50mb' }));
app.use(express.urlencoded({ limit: '50mb', extended: true }));

For multipart uploads, configure the upload middleware separately. This Multer example allows one file of up to 50 MiB:

const multer = require('multer');
// The destination must be writable. Add authentication, file validation,
// and a retention/cleanup policy before using this in a service.
const upload = multer({
  dest: '/var/lib/app/uploads',
  limits: { fileSize: 50 * 1024 * 1024, files: 1, fields: 10, parts: 11 }
});

app.post('/upload', upload.single('file'), (req, res) => {
  res.json({ message: 'Upload complete' });
});

Handle Multer errors explicitly. A LIMIT_FILE_SIZE error does not by itself guarantee an HTTP 413 response; map it to the response you want in error-handling middleware.

Other stacks have corresponding settings. For PHP, check both upload_max_filesize and post_max_size. For Spring Boot multipart requests, check spring.servlet.multipart.max-file-size and the overall request limit as well.

Configure Nginx's request-body limit

Nginx's default client_max_body_size is 1m, or 1 MiB. Increasing the application limit will not change that proxy limit:

server {
    client_max_body_size 55m; # Also valid in http or location context
}

A 50 MiB file needs room for multipart boundaries and other fields, so this example allows a 55 MiB total request body. Choose the actual margin and limits from your request format and capacity budget.

Check the configuration before reloading:

nginx -t && nginx -s reload

Send test requests below and above the intended thresholds, then compare proxy and application logs. With multiple instances, Guance DataKit log collection can bring access logs together so you can filter 413 responses by path and entry point.

Check the rest of the request path

Consider a different path for large files

For substantial uploads, evaluate multipart/chunked application workflows or direct object-storage uploads. With a presigned upload URL, the client sends the file to S3 or OSS instead of routing the body through the application server.

That reduces pressure on the application path but does not remove storage limits, signature expiry, authorization requirements, multipart rules, or cleanup responsibilities. It is an architectural option, not a guarantee that every upload will succeed.

Frequently asked questions

Why do I still get 413 after increasing Express's limit?

The request may be rejected before it reaches Express. Response headers and body formatting provide clues, but proxies can customize pages or forward upstream errors. Correlate logs across the CDN, load balancer, Nginx, and application to identify the rejecting layer.

Can I use an unlimited body size?

Use a bounded business limit instead. The service must budget not only bytes per request but also concurrent parsing, temporary files, and retained uploads.

How is 413 different from a timeout?

A server can reject an excessive body based on Content-Length or after reading enough bytes to exceed a limit. A 504 specifically means a gateway did not receive a timely upstream response. Slow client uploads may trigger other timeouts, such as Nginx's client-body timeout and a 408 response. Diagnose the phase and layer before changing size or timeout settings.

References

• Apache LimitRequestBody
• Multer configuration and errors
• Nginx request-body settings

The snippets are configuration examples; validate them against your deployed versions and upload flow.

Related reading

• Fix Elasticsearch index_not_found_exception
• Count the fields in an Elasticsearch index