Come diagnostichi gli errori 502 e 504 in Nginx?

Question

IT Interview Practice · Accepted Answer

Individua dove è fallita la richiesta prima di aumentare i timeout. Un 502 indica spesso comunicazione upstream fallita; un 504 indica spesso un'attesa upstream scaduta. I log distinguono il guasto effettivo.

## Esempio: l'applicazione non è in ascolto

Supponi che un estratto dell'error log riporti:

```text
connect() failed (111: Connection refused) while connecting to upstream
upstream: "http://127.0.0.1:3000/products"
```

Nginx ha provato a connettersi alla porta 3000 ed è stato rifiutato. Verifica che l'applicazione sia avviata e in ascolto su quell'indirizzo. Dalla macchina o dal container di Nginx, prova `curl -i http://127.0.0.1:3000/products`. Dentro un container, quell'indirizzo indica il container stesso, non automaticamente quello di un'altra applicazione.

## Esempio: connesso, ma header di risposta non arrivati in tempo

```text
upstream timed out while reading response header from upstream
```

Questo indica l'attesa degli header di risposta. Correla la richiesta con i log applicativi e le query lente del database. Controlla tempo di connessione e tempo di risposta upstream per separare l'avvio della comunicazione di rete dal lavoro applicativo.

## Conferma la correzione

Nel primo caso correggi l'indirizzo o ripristina l'applicazione guasta; nel secondo indaga il lavoro lento. Riprova la rotta interessata e monitora tasso di errore e latenza. Un `proxy_read_timeout` più lungo permette un intervallo maggiore tra letture, ma non crea capacità backend. Controlla anche i log di CDN e applicazione se l'errore è stato prodotto da uno di essi.

[Documentazione ufficiale](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout).

Esempio: l'applicazione non è in ascolto

Esempio: connesso, ma header di risposta non arrivati in tempo

Conferma la correzione

Domande correlate