nginx: upstream prematurely closed connection while reading response header from upstream

Come appare il messaggio

2026/10/29 11:20:45 [error] 1234#1234: *4521 upstream prematurely closed connection while reading response header from upstream, client: 203.0.113.5, server: example.com, request: "POST /api/export HTTP/2.0", upstream: "http://127.0.0.1:8080/api/export"

Cause frequenti

• Il processo del backend è andato in crash o è stato terminato durante la richiesta (segfault, kill per memoria esaurita, worker riciclato dopo un limite di richieste).
• Il backend è stato riavviato o ricaricato proprio in quel momento, per esempio da un deploy o da un service manager.
• Un conflitto di protocollo: proxy_pass http:// verso una porta che si aspetta HTTPS, oppure fastcgi_pass verso una porta HTTP semplice.
• Il backend chiude le connessioni keepalive inattive prima che nginx le riusi.
• Il backend rifiuta la richiesta, per esempio per un header o un body troppo grande, e chiude la connessione.

Verifica

1. Quanto spesso e per quali URL
   grep 'prematurely closed' /var/log/nginx/error.log | tail -n 10Copia
2. Il backend è caduto o riavviato? (esempio PHP-FPM)
   journalctl -u 'php*-fpm' --since '1 hour ago' --no-pager | tail -n 30Copia
3. Il kernel ha terminato un processo?
   sudo dmesg -T | grep -iE 'out of memory|killed process|segfault' | tail -n 10Copia
4. Il backend risponde direttamente? (adatta la porta)
   curl -sv -o /dev/null http://127.0.0.1:8080/Copia

Soluzione

• Scopri perché il backend muore: leggi il suo log e quello del kernel e correggi prima crash o esaurimento della memoria.
• Controlla lo schema: proxy_pass https://... per un backend TLS, fastcgi_pass solo per socket o porte FastCGI.
• Se usi keepalive verso il backend, imposta il timeout di inattività del backend più alto del keepalive_timeout di nginx nel blocco upstream.
• Evita di riavviare il backend sotto carico: nei deploy usa un reload graduale (systemctl reload ...).
• Testa e applica: nginx -t && systemctl reload nginx.

Domande frequenti

In cosa differisce da 111 Connection refused?

Con 111 nessuno è in ascolto sulla porta. Qui la connessione è stata accettata e poi chiusa senza risposta, quindi il processo è attivo ma fallisce o si disconnette.

Perché succede solo su alcune richieste?

Di solito sono proprio quelle richieste a causare il crash o a superare un limite, per esempio un export o un upload grosso. Confronta gli URL che falliscono nel log.