How to Fix Nginx 413 Request Entity Too Large on Ubuntu

A 413 Request Entity Too Large response means an upload or other request body exceeds a limit somewhere in the request path. On an Ubuntu server with Nginx, the first setting to inspect is client_max_body_size. A CDN, another proxy, PHP, or the application may impose an additional limit.

To fix Nginx 413 errors, identify the layer rejecting the request, choose an upload policy, and make the relevant limits consistent. This guide includes an example for a PHP-FPM application accepting one file up to 20 MiB. For Node.js or Python applications, use the same Nginx checks, then inspect the framework or upload middleware instead of the PHP settings.

1. Identify which layer returns the 413

Reproduce the failure with a non-sensitive test file through the normal upload form. Record the time, hostname, upload URL, file size, response status, and any request identifier. Compare a small successful upload with the failing one.

Inspect the site's configured Nginx error log. On a typical Ubuntu installation, this is a useful starting point:

sudo tail -n 100 /var/log/nginx/error.log

Check a site-specific log if your configuration uses one. A message such as client intended to send too large body is strong evidence that this Nginx instance rejected the request. Correlate it with the request time and path.

A branded error page or response header is only a clue; proxies can replace responses. Likewise, a missing origin log entry can reflect the wrong log or disabled logging. Use the strongest available evidence before changing settings.

2. Choose a per-file and whole-request limit

A multipart upload contains the file plus field values and multipart boundaries. The whole-request ceiling needs room beyond the permitted file size.

Here is an example policy for one attachment up to 20 MiB with small additional form fields. These are illustrative settings, not a recommended limit for every application.

MiB means 1,048,576 bytes. For multiple attachments, separately define the per-file size, file count, and combined request budget. Two permitted 20 MiB files will not fit in this example's 25 MiB request ceiling.

3. Set client_max_body_size in the correct Nginx configuration

Nginx documents a default of 1m for client_max_body_size. The directive is valid in http, server, and location contexts. See the official request-body limit reference.

Inspect the loaded configuration:

sudo nginx -T

Find the server_name serving the upload hostname, including its HTTPS server block. Check included files and any location-specific override. Keep the output private if configuration files contain credentials.

For the example policy, add or update this directive inside the existing server block for the site:

client_max_body_size 25m;

Do not create a second server block just to insert the line. If a hosting panel generates the configuration, use its supported custom configuration mechanism so the change survives regeneration.

Validate the configuration, then reload only if the test passes:

sudo nginx -t && sudo systemctl reload nginx

The Nginx command reference describes the test and configuration-output options. If Nginx runs in a container or under a different supervisor, use that deployment's validation and reload process.

4. Align PHP-FPM settings for PHP applications

PHP distinguishes the limit for one uploaded file from the total POST body. Its post_max_size must leave room beyond upload_max_filesize. If the full POST exceeds its limit, PHP can leave $_POST and $_FILES empty. See the PHP upload and data-handling directives.

For this example, set the following in the configuration used by the site's PHP-FPM runtime:

upload_max_filesize = 24M
post_max_size = 25M

Identify the PHP version and pool serving the site. Running php --ini in SSH describes the command-line runtime; it does not prove which configuration PHP-FPM uses. Inspect the loaded settings through a protected diagnostic or your hosting panel. PHP's configuration-file documentation explains how configuration is loaded.

Also check pool overrides. FPM can supply php_value and php_admin_value settings; admin values cannot be changed with ini_set(). See the FPM configuration reference.

On an Ubuntu installation using the packaged PHP 8.3 service, validation and reload would look like this:

sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm

Replace both versioned names with the runtime actually serving your site. This is a command example, not a recommendation to change PHP versions. For mixed hosting environments, our guide to running multiple PHP versions on one server helps keep those mappings clear.

5. Keep application validation in place

The infrastructure ceiling protects the request path. The application still needs to enforce the upload policy and tell the user what went wrong.

For a Laravel form whose file field is named attachment, the following example allows PDF, JPEG, or PNG content with a 20 MiB size limit:

$request->validate([
    'attachment' => [
        'required',
        'file',
        'mimes:pdf,jpg,jpeg,png',
        'max:20480',
    ],
]);

Laravel evaluates file-size rules in kilobytes. The mimes rule inspects content to infer a MIME type; it does not simply trust the filename. Review the Laravel file-validation documentation and adapt the field name and allowed types to your actual form.

The higher PHP ceiling in this example gives application validation room to reject a 21 MiB file with a useful message. Requests beyond the infrastructure ceiling will still be rejected earlier. Keep authorization, storage controls, and any required scanning as part of the existing upload workflow.

If you are checking the wider stack, continue with our Laravel deployment guide for Nginx and PHP-FPM.

6. Check the proxy or CDN upload ceiling

When an edge service sits in front of Nginx, its limit applies before the request reaches your server. Raising an origin setting cannot override an edge rejection.

For Cloudflare, review the current plan limit and the zone's Maximum Upload Size setting in the official 413 troubleshooting guide. Other providers have their own request and upload restrictions.

Choose a supported upload design if the required size exceeds that boundary. Large-media workflows may need application-supported resumable uploads or direct uploads to object storage. Those designs must still enforce authorization, size limits, and completion checks.

7. Test accepted and rejected uploads

Use the real form and authentication flow, preferably in staging. For the example policy, verify these cases with valid test files and small additional fields:

• A small allowed file uploads successfully.
• A 19 MiB allowed file completes and is usable after storage.
• A 21 MiB file reaches application validation and receives the size error.
• A request exceeding 25 MiB is rejected by an infrastructure limit.
• A disallowed file type remains blocked.

Check logs alongside each result. Confirm the correct hostname, PHP pool, and application release were tested. If the symptom changes to a timeout, storage error, or upstream failure, investigate that new error rather than continuing to raise the upload ceiling. Our Nginx 502 troubleshooting guide covers upstream failures.

Frequently asked questions

Should I set client_max_body_size to zero?

Zero disables Nginx's body-size check. Keep a finite limit that matches your upload policy unless you have deliberately designed equivalent controls elsewhere.

Will increasing client_body_buffer_size fix a 413?

That setting controls request-body buffering, not the permitted request size. Inspect client_max_body_size and the other layers' limits instead.

Why did changing php.ini make no difference?

The request may be rejected before PHP, the site may use another PHP version or configuration, or an FPM pool may override the value. Confirm effective settings in the web runtime and retest the same upload route.

Make upload limits part of hosting operations

Record the per-file, file-count, and request-size policy with the site's deployment settings. Recheck it after switching PHP versions, changing a proxy, or regenerating web-server configuration.

When evaluating a server control panel for Laravel, include configuration visibility and repeatable upload tests in your checklist. Review the Core Panel documentation and validate the workflow on an isolated non-production server; Core Panel is currently classified as pre-production.