How To Fix Nginx 413 Request Entity Too Large

In this tutorial, we will show you how to fix Nginx 413 request entity too large. Are you struggling with file uploads on your website? Have you encountered the frustrating “413 Request Entity Too Large” error message when trying to upload files through your Nginx server? This common issue can disrupt your workflow and create a poor user experience, but fortunately, it’s relatively straightforward to fix once you understand the underlying cause.

The 413 error occurs when users attempt to upload files that exceed the size limitations configured in your Nginx server. This restriction exists by default as a security measure, but it can become problematic when legitimate large files need to be uploaded. Whether you’re managing a content management system, file-sharing platform, or any web application that handles file uploads, knowing how to properly adjust these limitations is essential.

In this comprehensive guide, we’ll explore what causes the 413 error in Nginx environments and provide multiple detailed solutions to resolve it. By the end, you’ll have the knowledge to confidently adjust your server settings to accommodate your specific upload requirements while maintaining server security and performance.

Understanding the 413 Request Entity Too Large Error

The HTTP 413 status code, officially named “413 Payload Too Large” in the HTTP/1.1 specification (previously called “413 Request Entity Too Large”), is a server response indicating that the request body sent by the client is larger than what the server is willing or configured to process. In simpler terms, you’re trying to upload a file that’s bigger than what the server allows.

When this error occurs in an Nginx environment, users typically see one of these messages in their browser:

• “413 Request Entity Too Large”
• “413 Payload Too Large”
• “Request entity too large”
• “The file you are uploading is too large”

The error appears during various upload scenarios, including:

• Uploading media files to a content management system like WordPress
• Transferring large documents through web applications
• Submitting forms with substantial amounts of data
• Uploading backup files to restore a website
• API requests containing large payloads

Nginx implements this size limitation through the client_max_body_size directive, which defaults to 1 megabyte (1MB) in many installations. This conservative default setting serves as a security measure but frequently becomes an obstacle for legitimate uploads in modern web applications where files commonly exceed this size.

Why Does the 413 Error Occur in Nginx?

Nginx imposes upload size restrictions primarily for security and resource management reasons. The default client_max_body_size setting of 1MB represents a balance between functionality and protection against potential abuse.

Several factors contribute to this restriction:

1. Server Protection: Limiting upload sizes helps prevent denial-of-service attacks where malicious users might attempt to overwhelm your server with extremely large files.
2. Resource Conservation: Large file uploads consume significant server memory and processing power. The default limit helps prevent resource exhaustion.
3. Default Configuration Philosophy: Nginx follows a security-first approach, where default settings prioritize protection over convenience, expecting administrators to adjust limitations based on their specific needs.
4. Configuration Inheritance: The limit can be defined at multiple levels (http, server, location blocks), with more specific contexts overriding broader ones.

Common scenarios requiring larger upload limits include:

• Media-heavy websites handling high-resolution images and videos
• Document management systems for PDFs and large office files
• E-learning platforms with course materials and assignments
• Software distribution sites hosting installation packages
• Backup and migration tools for websites and applications

Understanding why these limitations exist helps you make informed decisions when adjusting them, balancing accessibility with security considerations.

Diagnosing the 413 Error on Your Server

Before implementing any solution, it’s crucial to confirm that Nginx’s size limitation is indeed the source of your upload problems. Here’s how to properly diagnose the issue:

1. Check Nginx Error Logs: The most direct confirmation comes from your server logs, typically located at /var/log/nginx/error.log. Look for entries containing “client intended to send too large body” which specifically indicate a 413 error:

2023/08/15 14:22:43 [error] 31245#0: *1 client intended to send too large body: 5242880 bytes

2. Verify Current Configuration: Determine your server’s existing client_max_body_size setting with:

grep -r "client_max_body_size" /etc/nginx/

If no results appear, the default 1MB limit is likely in effect.

3. Test Upload Capabilities: Create a simple test file of known size (for example, 2MB) and attempt to upload it through your application. If it consistently fails with a 413 error, you’ve confirmed the issue.
4. Browser Developer Tools: Examine the network tab in browser developer tools when attempting an upload. A failed request with status code 413 provides clear evidence of the problem.
5. Assess Actual Requirements: Before making changes, determine what maximum upload size your application genuinely needs. Consider:
   • Types of files users will upload
   • Typical file sizes for your use case
   • Storage capacity of your server
   • Processing capabilities of your application

Proper diagnosis ensures you’ll implement the right solution rather than making unnecessary configuration changes or overlooking other potential issues.

Solution 1: Modifying the Global Nginx Configuration

The most straightforward approach to fixing the 413 error is adjusting the global Nginx configuration. This method applies the change server-wide, affecting all hosted sites and applications.

Locating the Configuration File

The main Nginx configuration file location varies by operating system:

• Ubuntu/Debian: /etc/nginx/nginx.conf
• CentOS/RHEL: /etc/nginx/nginx.conf
• Alpine Linux: /etc/nginx/nginx.conf
• FreeBSD: /usr/local/etc/nginx/nginx.conf
• macOS (Homebrew): /usr/local/etc/nginx/nginx.conf

Step-by-Step Modification Process

1. Back up your existing configuration:

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup

2. Open the configuration file with your preferred text editor:

sudo nano /etc/nginx/nginx.conf

3. Add or modify the client_max_body_size directive within the http block:

http {
    # Other directives...
    client_max_body_size 20M;
    # More directives...
}

The value 20M represents 20 megabytes. You can adjust this according to your needs:

• 100M for 100 megabytes
• 1G for 1 gigabyte
• 0 to disable the limit entirely (not recommended for production servers)

4. Save the file (in nano: Ctrl+O, then Enter, then Ctrl+X)
5. Verify your configuration syntax:

sudo nginx -t

6. Apply changes by reloading Nginx:

sudo systemctl reload nginx

or

sudo service nginx reload

7. Verify the changes by attempting to upload a file that previously failed.

This global configuration change sets a new baseline limit for all sites hosted on your Nginx server. While simple, it might provide more generous limits than necessary for some applications, potentially creating security vulnerabilities if set too high.

Solution 2: Server-Specific Configuration Changes

If you’re managing multiple websites or applications on your Nginx server, you might prefer a more targeted approach by adjusting settings for specific virtual hosts (server blocks).

This method allows different upload limits for different domains or applications, providing better security through granularity.

Implementing Server Block Changes

1. Locate your server block configuration files. These are typically in:
   • /etc/nginx/sites-available/ (with symlinks in /etc/nginx/sites-enabled/) on Debian-based systems
   • /etc/nginx/conf.d/ on RHEL/CentOS systems
2. Identify the specific server block for the website experiencing 413 errors:

sudo grep -r "server_name yourdomain.com" /etc/nginx/

3. Edit the appropriate configuration file:

sudo nano /etc/nginx/sites-available/yourdomain.com

4. Add the client_max_body_size directive inside the server block:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    
    client_max_body_size 50M;
    
    # Other server directives...
    
    location / {
        # Location directives...
    }
    
    # More configurations...
}

5. Save the file and test the configuration:

sudo nginx -t

6. Apply changes by reloading Nginx:

sudo systemctl reload nginx

Example Configuration for Different Scenarios

For a WordPress site that requires larger media uploads:

server {
    server_name wordpress-site.com;
    client_max_body_size 100M;
    # Other directives...
}

For a document management system with very large files:

server {
    server_name documents.example.com;
    client_max_body_size 500M;
    # Other directives...
}

For a basic brochure site that doesn’t need large uploads:

server {
    server_name company-info.com;
    client_max_body_size 5M;
    # Other directives...
}

This approach balances security with functionality by providing appropriate limits based on each site’s specific requirements.

Solution 3: Location Block Configuration for Granular Control

For the most precise control over upload limits, you can configure the client_max_body_size directive within specific location blocks. This approach is particularly useful when:

• Only certain paths within your website need larger upload capabilities
• You want to create dedicated upload endpoints with special rules
• Different sections of your application have varying upload requirements

Implementing Location-Specific Settings

1. Edit your server configuration file as in the previous solutions.
2. Add or modify the client_max_body_size directive in specific location blocks:

server {
    server_name example.com;
    
    # Default limit for most paths
    client_max_body_size 5M;
    
    # Special limit for the upload area
    location /upload {
        client_max_body_size 100M;
        # Other location directives...
    }
    
    # Admin area with different limits
    location /admin/import {
        client_max_body_size 200M;
        # Other location directives...
    }
    
    # API endpoint with its own limit
    location /api/data {
        client_max_body_size 50M;
        # Other location directives...
    }
}

3. Save, test, and reload as in previous solutions.

Real-World Examples

For a WordPress installation:

server {
    server_name wordpress-blog.com;
    
    # Reasonable default
    client_max_body_size 10M;
    
    # For wp-admin uploads
    location ~ ^/wp-admin/.*upload\.php$ {
        client_max_body_size 200M;
        # Other directives...
    }
}

For a file-sharing application:

server {
    server_name fileservice.example.org;
    
    # Default limit
    client_max_body_size 2M;
    
    # Higher limit for premium users
    location /premium/upload {
        client_max_body_size 1G;
        # Other directives...
    }
    
    # Standard user uploads
    location /standard/upload {
        client_max_body_size 100M;
        # Other directives...
    }
}

This granular approach gives you precise control over which parts of your site can accept larger uploads, minimizing potential security vulnerabilities while ensuring functionality where needed.

Applying Changes and Restarting Nginx Properly

After making any configuration changes, it’s crucial to apply them correctly to avoid server downtime or configuration errors.

Testing Configuration Before Applying

Always verify your configuration syntax before reloading:

sudo nginx -t

This command checks for syntax errors without applying changes. A successful test produces output like:

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

If errors appear, review and correct your configuration before proceeding.

Reload vs. Restart

Nginx offers two ways to apply configuration changes:

1. Reload (preferred): Gracefully applies changes without dropping connections

sudo systemctl reload nginx
# or
sudo nginx -s reload

2. Restart: Completely stops and starts the server, potentially causing downtime

sudo systemctl restart nginx
# or
sudo service nginx restart

In production environments, always use reload unless a full restart is specifically required.

Verifying Applied Changes

After applying changes, confirm they’re in effect:

1. Check running configuration:

sudo nginx -T | grep client_max_body_size

2. Test with an appropriately sized file that previously triggered the 413 error.
3. Monitor error logs for any issues:

sudo tail -f /var/log/nginx/error.log

Following these proper application procedures ensures your configuration changes take effect reliably without causing server problems.

PHP Configuration Adjustments

For applications running PHP (like WordPress, Drupal, or Laravel), adjusting Nginx settings alone may not be sufficient. PHP has its own file size limitations that must be aligned with your Nginx configuration.

Key PHP Settings to Adjust

You’ll need to modify these PHP directives:

1. upload_max_filesize: Limits the maximum size of uploaded files
2. post_max_size: Limits the maximum size of POST data (should be larger than upload_max_filesize)
3. max_execution_time: Controls how long scripts can run (increase for large file processing)
4. max_input_time: Limits time for parsing input (increase for large uploads)
5. memory_limit: Controls maximum memory a script can use

Editing PHP Configuration

Depending on your setup, modify these settings in one of these files:

• Global php.ini (affects all sites): /etc/php/7.4/fpm/php.ini (version number may vary)
• Pool-specific configuration: /etc/php/7.4/fpm/pool.d/www.conf
• Site-specific .user.ini: In your site’s document root

Example changes in php.ini:

; Increase upload limits
upload_max_filesize = 50M
post_max_size = 55M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

After making changes, restart PHP-FPM:

sudo systemctl restart php7.4-fpm

Testing PHP Configuration

Create a simple PHP info file to verify your changes:

<?php phpinfo(); ?>

Access this file through your web browser and search for the modified directives to confirm they’ve been updated correctly.

Remember that PHP’s upload limits must be equal to or greater than your Nginx client_max_body_size setting, or you’ll encounter PHP errors after resolving the Nginx 413 issue.

CDN and Proxy Considerations

If your website uses a Content Delivery Network (CDN) or operates behind additional proxy servers, these intermediate layers may impose their own request size limitations that need to be addressed.

CDN Upload Limits

Popular CDNs have their own maximum request size settings:

• Cloudflare: Limits vary by plan (100MB for free plans, up to 500MB for enterprise)
• AWS CloudFront: Default limit of 30GB (adjustable)
• Akamai: Configurable limits based on your service agreement
• Fastly: Configurable with default of 500MB

If using Cloudflare, adjust limits in the dashboard under Speed → Optimization → Maximum Upload Size.

Configuring Reverse Proxies

When Nginx functions as a reverse proxy to application servers:

1. Match client and proxy timeouts:

# In http, server, or location block
client_max_body_size 100M;
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_send_timeout 300;
proxy_request_buffering off;  # Optional for very large uploads

2. Configure upstream server buffering:

proxy_buffer_size 16k;
proxy_buffers 8 16k;
proxy_busy_buffers_size 32k;

3. Ensure backend servers (like Apache) have corresponding limits:

For Apache, edit .htaccess or httpd.conf:

LimitRequestBody 104857600  # 100MB in bytes

Testing the entire request path is crucial, as the most restrictive limit in your infrastructure chain will determine the maximum upload size your users can achieve.

WordPress-Specific Solutions

WordPress users frequently encounter the 413 error when uploading large media files or importing content. Here are WordPress-specific approaches to resolve the issue:

WordPress Configuration File Adjustments

Edit your wp-config.php file to increase PHP limits directly within WordPress:

// Increase WordPress upload limits
@ini_set('upload_max_filesize', '64M');
@ini_set('post_max_size', '64M');
@ini_set('max_execution_time', '300');
@ini_set('memory_limit', '256M');

// Define maximum upload size for WordPress itself
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

Nginx Configuration for WordPress

Create an optimized server block for WordPress:

server {
    server_name wordpress-site.com;
    
    # Global upload limit for the site
    client_max_body_size 64M;
    
    # Higher limit specifically for admin uploads
    location ~ ^/wp-admin/.*upload\.php$ {
        client_max_body_size 150M;
    }
    
    # WordPress-specific optimizations
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_read_timeout 300;
    }
    
    # Other WordPress configuration...
}

Plugin-Based Solutions

If you can’t modify server configurations directly (common on shared hosting), consider these plugins:

1. WP Maximum Upload File Size: Helps increase upload limits through WordPress settings
2. Increase Maximum Upload File Size: Simple interface to adjust PHP settings
3. WP Offload Media: Offloads media handling to cloud storage, bypassing server limitations

Remember that plugin solutions only work if your hosting provider allows the underlying PHP settings to be adjusted through user configuration.

Security Considerations When Increasing Limits

While increasing upload limits resolves the 413 error, it potentially creates security vulnerabilities. Implement these additional safeguards:

File Type Restrictions

Limit allowed file types to prevent malicious uploads:

# In your server or location block
location ~ \.php$ {
    # Prevent upload of PHP files to non-PHP directories
    deny all;
}

# Only allow specific extensions in upload directories
location ~* ^/uploads/.*\.(jpg|jpeg|gif|png|pdf|doc|docx)$ {
    allow all;
}

Implement Rate Limiting

Prevent upload-based attacks with rate limiting:

# Create a zone for tracking upload requests
limit_req_zone $binary_remote_addr zone=uploads:10m rate=10r/m;

# Apply rate limiting to upload paths
location /upload {
    client_max_body_size 50M;
    
    # Allow bursts of 5 requests, queue excess requests
    limit_req zone=uploads burst=5 nodelay;
    
    # Other directives...
}

File Scanning and Validation

1. Implement server-side validation for all uploads
2. Scan files with antivirus solutions like ClamAV
3. Process images through image manipulation libraries to neutralize malicious code
4. Store uploaded files outside the web root when possible
5. Use cloud storage services with built-in security scanning

These security measures balance the need for larger upload capabilities with robust protection against potential threats.

Troubleshooting Persistent 413 Errors

If you’ve adjusted Nginx configurations but still encounter 413 errors, investigate these common causes:

Multiple Server Layers

Check for cascading web server setups:

1. Frontend proxy servers (load balancers, WAFs) may have their own limits
2. Container or application limits separate from Nginx configuration
3. Cloud provider limitations on request sizes

Use curl with verbose output to test the full request path:

curl -v -F "file=@large_test_file.zip" https://yourdomain.com/upload

Application-Level Restrictions

Examine application code for hardcoded limitations:

1. Form field attributes limiting file sizes:

<input type="file" name="document" max="5242880">

2. Server-side validation in application code:

// PHP example of application-level restriction
if ($_FILES['upload']['size'] > 5000000) {
    die("File too large");
}

3. Framework-specific configurations (e.g., Laravel’s upload limits in validation rules)

Configuration Inheritance Issues

Nginx applies the most specific configuration, which may override your changes:

1. Check all configuration files for competing directives:

grep -r "client_max_body_size" /etc/nginx/

2. Review include statements that might import conflicting settings
3. Check for configuration in unexpected locations:
   • /etc/nginx/conf.d/
   • /etc/nginx/sites-enabled/
   • Custom include paths

Using detailed logging at debug level can help identify where the 413 error originates:

error_log /var/log/nginx/debug.log debug;

Performance Optimization for Large Uploads

When allowing larger uploads, consider these optimizations to maintain server performance:

Server Resource Management

1. Adjust worker settings for handling large files:

worker_processes auto;
worker_connections 1024;
worker_rlimit_nofile 2048;

2. Configure buffering appropriately:

client_body_buffer_size 16k;
client_body_in_file_only off;  # or "on" for very large uploads

3. Monitor resource usage with tools like htop or iotop during large uploads

Client-Side Improvements

Implement modern upload capabilities:

1. Chunked uploads using JavaScript libraries like Dropzone.js or Fine Uploader
2. Progress indicators to improve user experience during lengthy uploads
3. Client-side validation to prevent obvious failures before transmission
4. Resumable uploads for very large files or unreliable connections

Storage Optimization

Configure appropriate storage handling:

1. Set up a dedicated upload partition separate from system files
2. Use a temporary file system (tmpfs) for transient uploads
3. Implement automatic cleanup of temporary upload files
4. Consider object storage (S3, Google Cloud Storage) for scalable storage

These optimizations ensure your server remains responsive and stable while handling larger file uploads.