Technology · PRACTICAL GUIDE
NGINX still returns 413? Prove which hop enforces the body limit
Do not raise every proxy or set an unlimited size. Mark one request, identify the first rejecting hop, dump that layer’s effective configuration, change one finite scope, then prove just-below and just-above behavior.

Do not raise every proxy or set an unlimited size. Mark one request, identify the first rejecting hop, dump that layer’s effective configuration, change one finite scope, then prove just-below and just-above behavior.
HTTP 413 can come from any server or proxy hop on the request path. NGINX client_max_body_size defaults to 1m and is valid in http, server and location contexts.
1. Freeze one reproducible request
Create inert bodies with recorded byte counts around the intended limit. Send them to the exact route with the same method, authentication and content type plus a unique request ID; save status, headers, response prefix, timing and client trace. Do not use browser wording as ownership evidence or expose an origin for testing.
2. Attribute the first rejecting hop
Match response headers, TLS endpoint, server signature and request ID against access and error logs at every hop. The first layer that creates 413 owns the rejection; an application with no matching request is evidence the body never arrived.
3. Prove the effective policy
For standalone NGINX capture nginx -T from the running instance and locate every http, server and location value governing the URI. For ingress-nginx save the Ingress, annotation, controller version, ConfigMap and generated host/path block; inspect edge and application caps separately.
4. Change one bounded layer
Choose a finite value supported by memory, buffering, timeouts, scanning and storage. Change only the first enforcing layer and intended scope; avoid client_max_body_size 0 without explicit security review. Validate syntax and save the new worker, pod or generation identity.
5. Test both sides of the boundary
Repeat the same marked request just below, at the limit when semantics allow, and just above it. The smaller request must reach the application; the larger must be rejected by the intended layer. Record bytes, route, config hash, logs, result, rollback and small-request health.
