A 500 response for a long URL does not establish that Nginx ran out of memory. Buffers for incoming requests and upstream responses serve different purposes. First correlate the actual status, the error log at that time, and whether the upstream received the request.
Observations from a separate server with a 1 KB limit
An unprivileged temporary Nginx 1.24.0 listened on a separate 127.0.0.1 port. With large_client_header_buffers 2 1k, an 1,800-character path returned 414 and an 1,800-character single request header returned 400. In a separate location with proxy_buffer_size 1k, a mock upstream sending an 1,800-character response header produced 502. Each case used one small request and never targeted public WordPress.
The request-header directive describes the single-buffer constraint on the request line and each header. Increasing only the buffer count is not a fix for one oversized request line. The proxy buffer concerns the upstream response instead.
Choose a change that matches the failing boundary
For 414, inspect why the client places large state or tokens in a URL and define the service’s intended limit. For 400, measure cookies and individual headers. For 502 accompanied by an upstream response-header error, inspect generated Set-Cookie or duplicate headers. For 500, check application logs and error-page transformations that may mask the original failure.
If a buffer change is justified, size it using measured legitimate traffic and concurrency. Do not apply 128 KB or 256 KB everywhere on a small server. Preserve the previous configuration, test syntax, explicitly reload, then recheck the failing and normal requests. HTTP/2, CDN and WAF paths need separate validation from this HTTP/1.1 loopback result.