upstream prematurely closed connection while reading response header from upstream

nginx logs upstream prematurely closed connection when a read from the backend socket returns end-of-file before the response is complete (ngx_http_upstream.c). The backend did not send a reset; it closed the connection normally, just too early. The text after while is the phase nginx was in, and it decides what the client sees:

The second case is why browsers sometimes show ERR_INCOMPLETE_CHUNKED_ENCODING or an empty download instead of a 502. The nginx documentation is explicit: "passing a request to the next server is only possible if nothing has been sent to a client yet" (proxy_next_upstream).

Do not confuse it with recv() failed (104: Connection reset by peer): that is a TCP RST. Here the backend sent a FIN.

The same log line appears for FastCGI and uwsgi upstreams, because they share the upstream core. A useful habit: the app server's timeout should be longer than the slowest legitimate request, and nginx's proxy_read_timeout (60 s by default, measured between two reads, not for the whole response) should be longer still, so the proxy times out last and logs a clear upstream timed out instead of a confusing early close.

For Node.js, an HTTP server closes idle keep-alive sockets after server.keepAliveTimeout; current releases use 5 seconds, with a change to 65 seconds pending upstream (Node.js http docs). If nginx keeps idle upstream connections longer than the app does, the race above is likely. Set the app's keep-alive timeout explicitly rather than relying on the default of whatever version you run.

1. Correlate timestamps.

   grep 'prematurely closed' /var/log/nginx/error.log | tail -5
   journalctl -u myapp --since '-10 min' | grep -iE 'timeout|killed|error|exit'

   A worker timeout or restart at the same second is the answer.
2. Reproduce without nginx against the backend port: curl -sv http://127.0.0.1:8000/slow-endpoint -o /dev/null. curl reports Empty reply from server when the backend closes without answering.
3. Measure the request duration and compare with the app server timeout. Requests dying at exactly 30 s on gunicorn are the default worker timeout.
4. Check keep-alive. If the upstream block has keepalive, make sure the location sets proxy_http_version 1.1; and proxy_set_header Connection "";, and that the backend's idle timeout exceeds nginx's.
5. Let nginx retry idempotent requests on another server: proxy_next_upstream error timeout; is the default; POST requests are not retried unless you add non_idempotent.

A general walkthrough of nginx error logs: how to debug nginx errors.

for i in $(seq 1 30); do curl -s -o /dev/null -w '%{http_code} %{size_download}\n' https://example.com/slow-endpoint; done | sort | uniq -c
#      30 200 48213

Every response must have the same status and full size; varying sizes mean truncation is still happening. The error log should stay free of prematurely closed. To see what your public URL returns from outside, use the HTTP status checker.

• no live upstreams — every server in the group marked failed
• upstream connect error or disconnect/reset — the same early close behind Envoy
• EPIPE — writing to a socket the other side already closed
• ERR_EMPTY_RESPONSE — what a browser shows when nothing came back
• 502 Bad Gateway fixes — the other causes of nginx 502s