How to Fix HTTP 413 'Request Entity Too Large' Upload Errors in Plesk

Last reviewed: 27 July 2026, against Plesk Obsidian 18.0.x, nginx, and ModSecurity 2.9.x (Imunify360 ruleset).

Official documentation:

• Plesk: Upload of a big file fails: client intended to send too large body
• Plesk: Unable to upload a file when Imunify is present (ModSecurity request-body limit)
• ModSecurity v2 Reference Manual: SecRequestBodyLimit / SecRequestBodyNoFilesLimit

Applies to

Any website on a Plesk server running nginx in front of Apache, where large file uploads (media, backups, recordings, documents) fail. It applies equally to PHP sites and to application sites such as Node.js, Python, or Ruby served through Phusion Passenger.

Symptom

An upload fails and the browser or application reports:

413 Request Entity Too Large

The application may dress this up in its own wording ("the file is too large", "the server rejected this file"), but the underlying HTTP status is 413. The upload is being rejected by the server before it reaches the application.

Why this happens

On a Plesk site with nginx in front, a 413 can be produced at two independent layers, each with its own limit. Raising one does not raise the other, which is why an upload can still fail after the first limit is increased. Read the logs, identify which layer is rejecting the request, then raise that layer.

Step 1: Read the logs

Open Domains > (domain) > Logs in Plesk, or read the log files directly over SSH. The nginx rejection appears in the domain's proxy error log:

grep "too large body" /var/www/vhosts/system/*/logs/proxy_error_log 2>/dev/null | grep example.com | tail -20

ModSecurity rejections appear in the domain's Apache error log. The number in the message is the limit that was hit, in bytes. For example, 134217728 = 128 MB, which is the default SecRequestBodyLimit.

Step 2: Raise the nginx limit

1. Go to Domains > (domain) > Apache & nginx Settings.
2. Set Maximum allowed HTTP request body size to a value comfortably above the largest upload you need to support (for example, 1 GB). This configures the nginx client_max_body_size directive and applies only to this domain.
3. Click OK. Plesk validates the configuration and reloads nginx automatically, so no manual restart is required.

Step 3: Raise the ModSecurity limit (per domain)

If the log shows a ModSecurity rejection, the WAF is refusing the request body. On this platform the request-body limit ships at 128 MB (via the Imunify360 ruleset). It can be raised for a single domain without affecting any other site or the server default.

Go to Domains > (domain) > Apache & nginx Settings and add the following to Additional directives for HTTPS (uploads are almost always over TLS). Add the same block to Additional directives for HTTP as well, so it applies regardless of protocol:

<IfModule mod_security2.c>
SecRequestBodyLimit 1073741824
</IfModule>

This overrides the server-wide 128 MB limit for this domain only. It is placed in the domain's own <VirtualHost> block (the only Apache context in which SecRequestBodyLimit is valid), and it survives Imunify360 ruleset updates because it lives in the subscription's configuration, not the server-level WAF config. The value shown is 1 GB in bytes (1073741824); set it to match the nginx limit from Step 2.

If, after raising SecRequestBodyLimit, the log then shows Request body no files data length is larger than the configured limit (1048576), the application is sending the upload as a raw or base64-encoded body rather than a multipart file field. Add SecRequestBodyNoFilesLimit to the same block at the same value:

<IfModule mod_security2.c>
SecRequestBodyLimit 1073741824
SecRequestBodyNoFilesLimit 1073741824
</IfModule>

Click OK. Plesk validates and reloads Apache automatically. If the configuration is accepted without an error, the change is live.

Step 4: PHP sites: allow the upload through PHP as well

Skip this step for Node.js, Python, or other application sites, because there is no PHP in the request path, so PHP settings have no effect. For PHP sites, the limits above stop the 413, but PHP will still discard the upload body unless its own limits are raised. Go to Domains > (domain) > PHP, set post_max_size and upload_max_filesize to match or exceed the nginx value, and click Apply. Keep nginx, post_max_size, and upload_max_filesize aligned, because the lowest of the three wins.

Step 5: Verify

Retry the upload. If it succeeds, the matter is resolved. If it still returns 413, re-read the log, because the signature will tell you which remaining layer is rejecting the request, and you return to the corresponding step above.

Notes

• The application has its own limit too. Even with every server-side limit raised, the application (for example, a Node.js body parser or a PHP framework) may impose its own upload ceiling. If the logs show no server-side rejection but the upload still fails, the limit is in the application and must be raised there.
• Shared and reseller subscriptions. The ModSecurity directive requires the Additional Apache directives field, which is an administrator-controlled setting. On a shared or reseller subscription without that access, the change must be requested from Noiz. Sites with recurring large-upload requirements are better placed on a dedicated or standalone package where these limits can be tuned directly.
• Large limits and server resources. Raising these limits does not consume proportional memory, because ModSecurity streams large uploads to disk rather than buffering them in RAM. The cost is temporary disk space during inspection.