Web Server Intermediate

Resolving Nginx 413 Request Entity Too Large Error on Ubuntu 22.04 LTS

Fix Nginx 413 'Request Entity Too Large' errors on Ubuntu 22.04 LTS by adjusting client_max_body_size. Prevent file upload failures with this expert guide.

👨‍💻
Written & Tested by Johnathon Wheeler Senior Systems Architect • Verified in Staging Labs
Updated: Sep 16, 2026

Fix Nginx 413 'Request Entity Too Large' errors on Ubuntu 22.04 LTS by adjusting client_max_body_size. Prevent file upload failures with this expert guide.

When managing web servers, particularly those handling file uploads or large data submissions, encountering an "Nginx 413 Request Entity Too Large" error is a common scenario. This issue typically manifests when a client attempts to send an HTTP request with a body size exceeding the server's configured limit, resulting in a rejected connection and a frustrating user experience. As a seasoned SysAdmin and DevOps engineer, understanding and rectifying this misconfiguration is a fundamental skill.

This guide will walk you through the precise steps to diagnose and resolve the Nginx 413 error on Ubuntu 22.04 LTS, ensuring your web applications can handle larger data payloads as intended.

Symptom & Error Signature

Users attempting to upload files or submit forms with substantial data payloads will typically encounter one of the following symptoms:

  • Browser Error Page: A standard Nginx 413 error page displayed in the browser.
    <html>
<head><title>413 Request Entity Too Large</title></head>
<body>
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx</center>
</body>
</html>
  • Application-Specific Error: The web application might display its own error message, indicating a failed upload or submission, often without directly showing the 413 status code to the end-user, but revealing it in browser developer tools.
  • Nginx Error Logs: The most definitive signature appears in the Nginx error logs (commonly /var/log/nginx/error.log).
    2023/10/26 10:30:15 [error] 12345#12345: *6 client intended to send too large body: 123456789 bytes, client: 192.168.1.100, server: example.com, request: "POST /upload HTTP/1.1", host: "example.com"
    The client intended to send too large body message is the key indicator.

Root Cause Analysis

The "413 Request Entity Too Large" error directly stems from the client_max_body_size directive in your Nginx configuration. This directive is designed as a security and resource management mechanism, limiting the maximum size of the client request body that Nginx will accept.

Here's why this directive exists and how it causes the error:

  1. Resource Protection: Large request bodies can consume significant server memory and processing power. Limiting them prevents potential denial-of-service (DoS) attacks where an attacker floods the server with excessively large requests to exhaust resources.
  2. Misconfiguration or Default Limits: By default, client_max_body_size is often set to a conservative value, commonly 1M (1 megabyte) or 0 (which means no limit, but many distributions default to 1M or other small values for security). If your web application requires uploading files or receiving data larger than this configured limit, Nginx will reject the request with a 413 status code before it even reaches the application server (e.g., PHP-FPM, Node.js).
  3. Configuration Contexts: The client_max_body_size directive can be specified in various Nginx configuration contexts:
    • http context: Applies globally to all virtual hosts.
    • server context: Applies to a specific virtual host (website).
    • location context: Applies to a specific URL path within a virtual host. Nginx applies the most specific directive it finds. If it's set in the http block, it applies everywhere unless overridden in a server or location block.

To resolve the error, we need to adjust this directive to accommodate the expected maximum size of client request bodies.

Step-by-Step Resolution

Follow these steps to increase the client_max_body_size in your Nginx configuration on Ubuntu 22.04 LTS.

1. Identify the Nginx Configuration Files

Nginx configurations on Ubuntu are typically organized as follows:

  • /etc/nginx/nginx.conf: The main Nginx configuration file.
  • /etc/nginx/sites-available/: Contains individual virtual host (website) configuration files. These files are usually symlinked to /etc/nginx/sites-enabled/ to activate them.
  • /etc/nginx/conf.d/: Can contain additional global configuration snippets.

You'll need to locate the specific configuration file that serves your application. This is usually within /etc/nginx/sites-available/your-site.conf.

2. Determine the Correct Context for client_max_body_size

Decide where to place the client_max_body_size directive:

  • Globally (HTTP block): If all your sites on this Nginx instance need to accept larger file sizes. Edit /etc/nginx/nginx.conf.
  • Per-Site (Server block): If only a specific website needs a higher limit. Edit the relevant file in /etc/nginx/sites-available/. This is often the recommended approach for granular control.
  • Per-Location (Location block): If only a specific URL path within a site (e.g., /upload) needs a higher limit. Edit the relevant server block file.

When setting client_max_body_size, higher-level directives (e.g., in http) are inherited by lower-level ones (e.g., server, location) unless explicitly overridden. It's generally best practice to set it in the server block for a specific site or location block for a specific endpoint that requires it.

3. Edit Nginx Configuration to Increase client_max_body_size

Use a text editor like nano or vi to modify the configuration file.

Option A: Global setting (http block)

Edit /etc/nginx/nginx.conf:

sudo nano /etc/nginx/nginx.conf

Inside the http { ... } block, add or modify the client_max_body_size directive. For example, to allow files up to 50MB:

# /etc/nginx/nginx.conf
http {
    ...
    client_max_body_size 50M; # Add or modify this line
    ...
}

Option B: Per-site setting (server block)

Edit your site's configuration file, e.g., /etc/nginx/sites-available/your_domain.conf:

sudo nano /etc/nginx/sites-available/your_domain.conf

Inside the server { ... } block for your domain, add or modify the client_max_body_size directive:

# /etc/nginx/sites-available/your_domain.conf
server {
    listen 80;
    server_name your_domain.com www.your_domain.com;

    root /var/www/your_domain;
    index index.html index.htm index.nginx-debian.html;

    client_max_body_size 50M; # Add or modify this line

    location / {
        try_files $uri $uri/ =404;
    }
    # ... other configurations
}

Option C: Per-location setting (location block)

If you only need to allow larger uploads for a specific endpoint (e.g., /api/upload):

sudo nano /etc/nginx/sites-available/your_domain.conf

Inside a location block within your server block:

# /etc/nginx/sites-available/your_domain.conf
server {
    listen 80;
    server_name your_domain.com;
    root /var/www/your_domain;

    location /api/upload {
        client_max_body_size 100M; # Specific limit for this upload endpoint
        # ... other location-specific directives (e.g., proxy_pass)
    }

    location / {
        client_max_body_size 10M; # General limit for other requests
        # ...
    }
}

Choose a client_max_body_size value that is appropriate for your application's needs, but avoid setting it excessively high (e.g., 1G or 0 for no limit) without careful consideration. Very large values can still expose your server to resource exhaustion if not properly handled by your application layer. For typical file uploads, values like 20M, 50M, 100M, or 250M are common.

4. Test Nginx Configuration Syntax

Before restarting Nginx, always test your configuration for syntax errors. This prevents Nginx from failing to start.

sudo nginx -t

You should see output similar to this:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

If you encounter any errors, carefully review your changes, paying attention to semicolons, braces, and correct directive names.

5. Reload/Restart Nginx Service

Once the syntax test is successful, apply the changes by reloading Nginx. Reloading is preferred as it avoids dropping active connections.

sudo systemctl reload nginx

If reload doesn't seem to apply the changes or you prefer a full restart (which might briefly interrupt service), you can use:

sudo systemctl restart nginx

Verify the service status:

sudo systemctl status nginx

Ensure it shows "active (running)".

6. (Optional) PHP-FPM Configuration Adjustment

If your Nginx server is acting as a reverse proxy for a PHP application (using PHP-FPM) that handles file uploads, Nginx's client_max_body_size is only one part of the equation. PHP also has its own limits for upload size. You'll need to adjust upload_max_filesize and post_max_size in your php.ini file.

On Ubuntu 22.04, PHP 8.1 is common, so the path would typically be:

sudo nano /etc/php/8.1/fpm/php.ini

Locate and modify the following directives. Ensure they are set to a value equal to or greater than your Nginx client_max_body_size. For example, if Nginx is set to 50M, you might set PHP to 50M or 51M.

; Maximum allowed size for uploaded files.
upload_max_filesize = 50M

; Maximum size of POST data that PHP will accept.
post_max_size = 50M

The post_max_size value should always be greater than or equal to upload_max_filesize. If you're uploading multiple files or other form data along with a file, post_max_size should accommodate the total size.

After modifying php.ini, you must reload the PHP-FPM service for the changes to take effect:

sudo systemctl reload php8.1-fpm

(Adjust php8.1-fpm to your specific PHP version if different, e.g., php7.4-fpm).

7. Test the Upload

Finally, attempt to perform the action that previously triggered the 413 error (e.g., upload a file). Make sure the file size is now within your newly configured limits. If everything is correctly configured, your upload or submission should succeed without the "Request Entity Too Large" error.

By following these steps, you've successfully diagnosed and resolved the Nginx 413 error, ensuring your web server can handle the necessary data payloads for your applications.

👨‍💻

Johnathon Wheeler

Senior Systems Architect & DevOps Engineer • Austin, TX

Connect on LinkedIn →

Johnathon has over 16 years of hands-on experience designing, debugging, and scaling Linux web hosting stacks, container clusters, and high-availability database architectures. Every guide on ButItWorkedLocal is independently tested against Debian 12, Ubuntu 24.04/22.04 LTS, Rocky Linux, and Docker environments to guarantee reproducibility in production.

🛡️

Our Production Verification Guarantee

Encountering a bug not covered here or running a non-standard kernel configuration? Our solutions are continually refined against real production incidents. Submit an environment trace for our editorial team to replicate.