413 Request Entity Too Large indicates that the client's request body exceeds the limit accepted by NGINX. Simply increasing client_max_body_size may not be enough; PHP, application, proxy, CDN, and temporary disk limits must match together.
2026/07/17 03:40:44 [error] 2284#2284: *821 client intended to send too large body: 52429187 bytes, client: 203.0.113.10, request: "POST /wp-admin/async-upload.php HTTP/2.0"
NGINX, returns 413 without sending the request to the backend when the client_max_body_size value exceeds the request body in a POST/PUT request. This might result in no log entries in the PHP log.
client_max_body_size can be defined at http, server or location level. A value defined in a narrower block overrides the higher level; therefore, adding it only to nginx.conf may not change the effective vhost settings.
After increasing the NGINX limit, PHP's upload_max_filesize and post_max_size, application limit, Nginx Proxy Manager or CDN limit should also be checked.
Large requests can be written to temporary file. Upload fails if /tmp or client_body_temp_path is full even if limit is sufficient.
Using unlimited values increases resource consumption and misuse risk. Set the limit to a reasonable size for the domain/location only.
Do not guess the active value; find the client_max_body_size line applied for the same domain and location in the nginx -T output.
Search for the phrase you see in the email, browser, or SSH log. Each card includes meaning, probable cause, and safe initial action.
Meaning: The request body exceeds the NGINX limit.
Possible cause: client_max_body_size is smaller than the uploaded file.
Meaning: NGINX rejected the request without forwarding it to the backend.
Possible cause: Server/location level body limit.
Meaning: The same HTTP status has different displays.
Possible cause: NGINX, proxy or API gateway limit.
Meaning: The file exceeds the PHP limit after NGINX.
Possible cause: PHP upload_max_filesize is low.
Meaning: Total POST body exceeds the PHP post_max_size value.
Possible cause: post_max_size is smaller than the file and form total.
Meaning: Temporary upload file could not be written.
Possible cause: Disk or inode is full.
Meaning: Backend framework applied its own body limit.
Possible cause: Django/Laravel/Node-like application setting.
Meaning: The request may have exceeded the CDN limit before reaching the origin.
Possible cause: Plan or proxy upload limit.
No records matching this expression were found.
Commands are for root access. Collect only status and logs first; Do not change the permanent setting without seeing the reason.
nginx -T | grep -n 'client_max_body_size'
Include files with all definitions.
grep -R 'too large body' /var/log/nginx 2>/dev/null | tail -n 100
Request size, URL, and domain are shown.
php -i | grep -E 'upload_max_filesize|post_max_size|memory_limit|max_execution_time'
CLI shows PHP values; web PHP must also be validated.
df -h
df -i
nginx -T | grep -n 'client_body_temp_path'
Checks the disk and inode space used during upload.
curl -sk -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://example.com/yukle
Performs a controlled upload test to the real endpoint.
nginx -t && systemctl reload nginx
Ensures safe implementation of the new limit.
Although the root cause of the NGINX error is the same, package paths, service names, security layers and virtual host management vary depending on the Linux distribution or Plesk infrastructure used.
Systemd, package path, and journald controls for NGINX 413 Request Entity Too Large.
nginx -T | grep -n client_max_body_size
php -i | grep -E 'upload_max_filesize|post_max_size'
tail -n 100 /var/log/nginx/error.logSELinux, PHP-FPM pool, and RHEL-based service controls for NGINX 413 Request Entity Too Large.
nginx -T | grep -n client_max_body_size
php -i | grep -E 'upload_max_filesize|post_max_size'
df -h; df -iNGINX virtual host files generated by Plesk: nginx 413 request entity too large control.
grep -R 'client_max_body_size' /var/www/vhosts/system/example.com/conf /etc/nginx 2>/dev/null
plesk repair web example.com -nMeasure and adjust the limits of which layer rejected the request of which size and make them compatible only in the required scope.
Not just a file, also consider multipart form data uploads.
stat -c '%n %s bytes' test.binPerform separate tests from Origin and CDN.
curl -skI https://example.com/; curl -skI --resolve example.com:443:ORIGIN_IP https://example.com/Check the smallest client_max_body_size value for the same server/location.
nginx -T | grep -nC 4 client_max_body_sizeThe PHP post_max_size and application setting must not be less than the NGINX limit.
php -i | grep -E 'upload_max_filesize|post_max_size'Large body being written to temporary disk requires free space and inodes.
df -h; df -iNot just a config test, upload to your application endpoint.
nginx -t && systemctl reload nginx
curl -sk -F '[email protected]' https://example.com/yukleNGINX, PHP, and WordPress multisite limits are checked together.
nginx -T | grep client_max_body_size; php -i | grep -E 'upload_max|post_max'Body limit next to PHP duration and upload temp area is important.
df -h /tmp; php -i | grep upload_tmp_dirNGINX after framework or API gateway may apply limits.
curl -sv -H 'Content-Type: application/json' --data-binary @data.json https://example.com/apiChanges should be written to the container-internal effective config or custom location field.
docker exec nginx nginx -T | grep client_max_body_sizeDistinguish the CDN plan limit with a direct test to Origin.
curl --resolve example.com:443:ORIGIN_IP -skI https://example.com/Additional nginx directives can define domain-based limits in this area.
plesk repair web example.com -nThe request body exceeds the client_max_body_size value, and NGINX returns 413 without sending it to the backend.
In NGINX Open Source documentation, the default value is specified as 1 MB.
It can be written according to http, server or the narrowest location block as needed. The narrowest scope should be preferred for security reasons.
PHP upload_max_filesize, post_max_size, framework, CDN, proxy or disk space is set to a lower limit.
0 limit disables; it should only be considered in controlled scenarios as it increases the risk of abuse and resource consumption.
NGINX limit, active web PHP upload/post limits, and WordPress multisite upload limit should be set together.
For a configuration change, reloading after nginx -t is generally sufficient; a restart is not required.
By analyzing cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim and security layers together, we fix the root cause of the failure instead of just removing the service.