A plugin ZIP upload can return 413 before WordPress displays its normal upload error. If the response carries a CDN marker and PHP logs nothing, changing upload_max_filesizeinside WordPress cannot affect the intermediary that already rejected the body.
Fingerprint the response, compare small and failing payloads and change the first layer that enforces the lower request limit.
What it means
HTTP 413 Content Too Large means a server or intermediary refuses a request body because it exceeds a configured size or policy. The responder may be a CDN, WAF, reverse proxy, web server, hosting gateway or PHP.
When rejection occurs before PHP, neither WordPress nor the PHP upload settings see the request. Response headers, body style, request IDs and logs help identify that boundary.
A realistic WordPress example
A 30 MB plugin upload fails at the public URL with a branded edge response. The origin accepts a smaller test, and there is no matching PHP access or error entry for the large request.
The team changes the body limit for the required administrative path at the CDN, then tests payloads below and above the new ceiling and confirms that PHP receives the accepted request.
Why it matters and when to use it
Finding the responder prevents ineffective PHP edits and duplicate policy changes. It also keeps a broad increase from exposing endpoints that never needed larger bodies.
Raise a ceiling only for a legitimate workflow whose storage, processing and security consequences are understood. Otherwise use chunking, CLI or direct object storage where supported.
A straightforward route for beginners
- Record the exact URL, method, payload size, time and 413 response headers.
- Compare the response from a small successful request.
- Check CDN, WAF, proxy, web-server and PHP logs for the same request ID or timestamp.
- Identify the first layer that does not forward the failing body.
- Adjust only the required path and choose a bounded size.
- Retest below and above the boundary and verify that WordPress receives the accepted request.
The advanced route
Test the public edge and an authorized origin route with identical payloads. Account for decompression, HTTP/2 or HTTP/3 gateways and route-specific policies that can make nominal limits differ.
Confirm how the body is buffered and where temporary storage is consumed. If the application receives the request, then compare PHP POST and upload limits; until then, those values are not the controlling evidence.
Risks, common mistakes, backup, and rollback
Raising every body limit expands resource-exhaustion exposure and may fill proxy or PHP temporary storage. A global change can also affect unauthenticated endpoints that never need large requests.
Record the old and new effective ceilings and keep the previous configuration ready. Roll back if resource pressure or unrelated traffic changes, and choose a bounded alternative workflow.
How AIOWS helps:
AIOWS PHP Limits
AIOWS PHP Limits can show the active PHP size limits, attempt supported changes and verify their effective values. For a 413, use that information only after evidence shows the request reaches PHP.
If an upstream device emitted the response, change its route-specific policy instead. Once the body reaches WordPress, compare the PHP POST and upload settings with the measured request.
AIOWS cannot raise CDN, WAF, proxy or web-server ceilings, and hosting policy may still reject a PHP override. The response-producing layer remains the correct owner of the fix.
Related AIOWS articles
- Increase WordPress Upload Size: Complete Limit Guide
- post_max_size vs upload_max_filesize in WordPress
- How to Fix Maximum Execution Time Exceeded in WordPress
Conclusion and recommended route
Identify who returned 413 before changing PHP. Move only the proven boundary, verify payloads on both sides of the new ceiling and use a chunked or out-of-band workflow when a larger public request is not safe.
