Alexis Kestler
Trying to upload a file or theme for your WordPress site and running into a mysterious 413 error from Nginx? You‘re not alone. The "request entity too large" message pops up from time to time, leaving site owners confused and unable to update their content.
The good news is this error is easily addressed once you understand what‘s causing it. In this comprehensive guide, we‘ll dive into Nginx‘s 413 status code, explain what client_max_body_size does, and show you how to tweak settings to allow larger uploads for your unique use case.
Let‘s start by taking a quick look at what the 413 error means and some common reasons you might encounter it.
What is the 413 Request Entity Too Large Error?
The 413 status code appears in your Nginx error logs when a request exceeds the configured maximum size allowed. Specifically, it means the client (your browser or app making the request to the Nginx server) tried to send a request body larger than what Nginx is configured to accept.
By default, many Nginx installations set client_max_body_size to just 1-2MB. This works fine for smaller sites, but can become a problem when uploading larger files like themes, media, or big forms and requests. Suddenly you get the 413 error when trying to publish new content.
Some common cases that can trigger 413 errors include:
- Uploading large WordPress themes (often 5-15MB)
- Publishing lots of new media to a site – high res photos & videos
- Submitting large forms with file attachments
- API requests with big JSON payloads
- Bulk import/exports like large databases
- Large file downloads/transfers
The good news is Nginx‘s 413 error protects your server resources from being abused with huge, unwieldy requests. But it can also get in your way during legitimate activities like publishing new content.
Let‘s look at how to configure Nginx appropriately to raise or remove the 413 error when needed.
Understanding Nginx’s client_max_body_size Setting
The Nginx directive responsible for controlling the max request size is called client_max_body_size. As you may have guessed from the name, this sets the maximum size request body Nginx will accept before returning a 413 error.
Some key things to know about client_max_body_size:
- Specified in bytes – so 10MB would be
client_max_body_size 10M; - Can be set at the overall server, location, or if level for granular control
- Default is often 1-2MB which can be very small
- Must balance size vs security – don‘t want unlimited!
- Requires Nginx reload/restart to take effect after changing
Adjusting this directive higher is the primary method for increasing the upload/request size your Nginx server will accept before hitting the limit.
For example, to allow file uploads up to 10MB in size, you‘d configure:
client_max_body_size 10M;But before raising the limit arbitrarily high, let‘s talk about best practices for setting an optimal size.
Finding the Right client_max_body_size Value
Choosing the ideal client_max_body_size is about balancing your site‘s functionality needs vs good security practices. Some guidelines to follow:
Start Generously High
Begin with a value on the higher side of what you need. This gives you breathing room as your media library, form submissions, etc grow over time. Nothing worse than constantly bumping into upload limits.
But don‘t go overboard here – 100-200MB is plenty for many use cases. The key is leaving room for reasonable growth.
Tweak It Down Over Time
After setting client_max_body_size, pay attention to your actual usage. Analyze your Nginx access logs and keep an eye on error logs for 413 warnings.
If you find you‘re maxing out at around 15MB uploads, maybe bump the limit down to 20M or so. The goal is the least permissive level that doesn‘t trigger constant 413s under normal usage.
Limit Risk of DOS Attacks
One risk of very high client_max_body_size limits is opening yourself up to denial of service attacks. A malicious user could target your site with ginormous requests to try consuming resources and crashing your server.
That‘s why you generally want to keep it under 100-200MB or so. There are also other server protections like incoming request rate limiting to implement rather than relying solely on body size limits.
Use More Granular Locations When Needed
Rather than globally increasing client_max_body_size, you can target specific URL paths where you tend to upload larger data:
location /api/ {
client_max_body_size 50M;
}
location /admin/ {
client_max_body_size 20M;
} This allows more control over where you implement higher limits vs standard paths.
Now let‘s look at how to actually configure client_max_body_size within your Nginx setup.
Configuring client_max_body_size in Nginx
To adjust client_max_body_size, you‘ll edit your nginx.conf file on your server. The location varies by install method, but is often:
/etc/nginx/nginx.confor
/usr/local/nginx/conf/nginx.confThe main options for setting client_max_body_size are:
Globally
Add it in your top-level http {} config section to make it apply to all requests:
http {
# Other settings
client_max_body_size 20M;
}On Specific Server Block
For more fine grained control, set it within individual server {} blocks:
server {
# Other server settings
client_max_body_size 100M;
}Within Locations
Set custom values for particular location paths:
location /api/ {
client_max_body_size 50M;
}
location /uploads/ {
client_max_body_size 20M;
}After updating the setting, reload Nginx to have it take effect:
sudo nginx -s reloadThen test uploading larger files to confirm the new limit is in effect. Check your access and error logs for any issues.
Finding the Request Size from 413 Errors
When testing out client_max_body_size changes, you‘ll likely still run into 413 errors until tuned properly for your site.
When this happens, check your Nginx error log (often at /var/log/nginx/error.log) for details on the request size. You‘ll see something like:
2019/06/12 15:40:27 [error] 32149#0: *23 client intended to send too large body: 38418302 bytesThis shows the upload attempt was around 38MB here. You can then use this to gauge an appropriate client_max_body_size to configure.
Also double check your Nginx configuration syntax when troubleshooting 413s to make sure the directive is valid and in the right location. Test with different file upload sizes if issues persist.
Alternatives Beyond client_max_body_size
While adjusting client_max_body_size is the main solution for 413 errors, there are also some additional options:
- Adjust proxy buffer sizes – if sitting behind a reverse proxy, tune proxy_buffers and proxy_max_temp_file_size
- Use multipart/form-data for forms – allows submitting in chunks vs all at once
- Compress large requests with gzip to fit more data under the limit
- Offload file uploads to cloud storage like S3 rather than your own server
Combining these options with smart limits from client_max_body_size will give you the most flexibility.
Summary & Next Steps
Getting the Nginx 413 error while uploading WordPress themes or other files can be frustrating. But now you understand what‘s going on and how to tweak settings to raise limits for your unique needs.
Some key points to remember:
- The 413 error appears when request bodies exceed the Nginx client_max_body_size setting
- Small defaults like 1-2MB can be problematic for larger uploads
- Start generous with client_max_body_size but don‘t go overboard
- Tweak the setting down over time based on usage patterns
- Use more granular server/location overrides when needed
- Watch your Nginx logs for clues when troubleshooting 413s
Adjusting client_max_body_size thoughtfully along with techniques like proxy buffer tuning, multipart forms, and request compression or offloading will give you a robust, balanced configuration.
Your site should now be able to handle those larger theme uploads and asset publishes without pesky 413 errors getting in the way. As always, monitor your logs over time and tune things further as your site‘s functionality needs change.
Happy content updating! Let us know if you have any other tips for dealing with the Nginx request entity too large error.
