In Nginx, il messaggio upstream timed out while reading response header segnala un timeout mentre il server attende gli header dal servizio a monte. La diagnosi deve collegare la richiesta del proxy al lavoro svolto dal backend nello stesso intervallo.
Indice dei contenuti
Trovare la richiesta e il backend coinvolto
- Conserva la riga completa dell’error log con orario, richiesta e upstream.
- Individua la configurazione che gestisce quel percorso: il backend può essere un servizio HTTP oppure un processo FastCGI.
- Confronta access log del proxy e log applicativi. Se sono già registrati, usa i tempi di connessione, ricezione degli header e risposta per distinguere le fasi.
- Controlla se, nello stesso intervallo, il backend attende query, servizi esterni o un processo disponibile.
Intervenire sulla causa dell’attesa
Se il backend è rallentato, risolvi il collo di bottiglia confermato dai log. Aumentare il timeout può lasciare più richieste in attesa senza aumentare la capacità del servizio.
Se invece l’operazione richiede legittimamente più tempo, valuta il limite del percorso interessato e quelli degli altri componenti. Per un upstream HTTP il parametro di lettura è proxy_read_timeout; una configurazione FastCGI usa le proprie direttive.
Il timeout di lettura misura l’intervallo tra letture successive, non necessariamente la durata totale della risposta. Per lavori lunghi può essere preferibile una procedura asincrona, se prevista dall’applicazione.
Confrontare il risultato prima e dopo
Se hai modificato Nginx, valida la configurazione prima di ricaricarla. Ripeti la stessa richiesta e controlla tempi, risposta e nuove occorrenze dell’errore.
Verifica anche il comportamento con più richieste contemporanee: una prova isolata può riuscire mentre il problema ricompare sotto carico. Su un servizio gestito, invia al supporto la riga del log e l’intervallo della prova.
Guide Xlogic correlate
- Nginx: upstream sent too big header
- Nginx: upstream sent invalid chunked response
- Nginx: host not found in upstream