If you run WordPress on an unmanaged VPS with Nginx, you may see the “413 Request Entity Too Large” error when uploading files. This issue appears when Nginx blocks requests bigger than its default size limit. The good news is that the fix is simple. In this guide, you’ll learn how to increase upload limits on Ubuntu or Virtualmin and get your site working again.
When running WordPress on your own unmanaged VPS with Nginx and Virtualmin, you’ll eventually run into the “413 Request Entity Too Large” error. It usually appears when you try to upload a large file — a plugin, theme package, database export, or even a big image via the Media Library.
Good news: this isn’t a server-breaking problem. It simply means Nginx is blocking requests bigger than the size limit defined in its configuration.
Let’s fix it.
Why This Error Happens?
The 413 error is triggered when the file being sent to the server is bigger than what Nginx is allowed to accept.
The most common situations are:
- Uploading large files through WordPress
- Restoring backups from plugins like All-in-One, UpdraftPlus, etc.
- Importing large SQL files in phpMyAdmin
- Uploading PDFs or media assets
WordPress defaults often aren’t the real issue — Nginx limits the request size by default.
So, the fix is simple: Increase client_max_body_size.
🛠️ Step 1: Edit Nginx Configuration
Open your Nginx site configuration. On Virtualmin setups, this is usually:
nano /etc/nginx/sites-available/yourdomain.com.conf
Look for the server {} block and add:
client_max_body_size 64M;
You can adjust the size as needed:
32Mfor moderate uploads64Mfor backups and zips100M+if you’re restoring full WordPress bundles
Example:
server {
listen 80;
server_name yourdomain.com www.yourdomain.com;
client_max_body_size 64M;
# rest of your config...
}
If you have SSL enabled, repeat the same line inside the HTTPS block too.
🛠️ Step 2: Reload Nginx
Once added, reload Nginx:
sudo systemctl reload nginx
If you see errors, test config first:
nginx -t
If the syntax is OK, reload again.
🛠️ Step 3: Update PHP Limits (Optional But Recommended)
Sometimes Nginx isn’t the only limiter.
Open the correct PHP-FPM config, change the php version accordingly:
nano /etc/php/8.1/fpm/php.ini
Update:
upload_max_filesize = 64M
post_max_size = 64M
Restart PHP-FPM:
systemctl restart php8.1-fpm
🛠️ Step 4: Virtualmin Users — Also Update Per-Domain PHP Limits
If your VPS uses Virtualmin, each domain has its own PHP execution settings.
Go to Virtualmin
Select the affected domain
Navigate to:
Web Configuration → PHP-FPM Configuration → Resource LimitsLook for PHP upload limits and match them to your Nginx/PHP values.
Many users miss this step and assume things are fixed when PHP still blocks uploads.
🧪 Step 5: Test the Fix
Go to:
WordPress → Media → Add New
Try uploading the same file that failed earlier.
If the upload succeeds — problem solved.
If not, restart all services just to be safe:
systemctl restart nginx
systemctl restart php8.1-fpm
Sometimes caching layers can hold stale limits.
🟡 Less Common Cases
Nginx Conflicting Includes
If you manage multiple config layers, search for another client_max_body_size definition:
grep -R "client_max_body_size" /etc/nginx
If another block sets a lower value, update it to match.
Reverse Proxy Users
If you run Cloudflare or another reverse proxy, set the same larger limit there as well.
🎉 Final Thoughts
The “413 Request Entity Too Large” error is one of the most common frustrations on self-managed WordPress VPS setups. Fortunately, the fix is straightforward once you know where the upload limits live:
Nginx config
PHP upload limits
Virtualmin per-domain settings
Once these are aligned, your uploads should work properly — whether you’re restoring a site, installing a plugin, or uploading large media files.
If you run into related issues (timeout errors, 504 gateway timeout, broken uploads in phpMyAdmin), they usually stem from similar configuration mismatches.
Feel free to drop the error in the comments and I’ll write a guide for that too!
