Watch at EaseStories. Answers. Perspective.

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.

HTTP 413 hop ownership map
Original illustration: identify the first rejecting layer. Watch at Ease

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.

HTTP body-limit boundary test
Original illustration: change one finite layer and test both sides. Watch at Ease