Cum diagnostichezi erorile 502 și 504 în Nginx?

Question

IT Interview Practice · Accepted Answer

Află unde a eșuat cererea înainte să mărești timeouturile. Un 502 indică adesea comunicare upstream eșuată; un 504 indică adesea expirarea așteptării upstream. Jurnalele disting eroarea reală.

## Exemplu: aplicația nu ascultă

Presupune că un fragment din jurnalul de erori spune:

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

Nginx a încercat să se conecteze la portul 3000 și a fost refuzat. Verifică dacă aplicația rulează și ascultă la acea adresă. De pe mașina sau containerul Nginx, testează `curl -i http://127.0.0.1:3000/products`. Într-un container, adresa indică acel container, nu automat containerul altei aplicații.

## Exemplu: conexiune stabilită, dar antetele nu sosesc la timp

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

Aceasta indică așteptarea antetelor răspunsului. Corelează cererea cu jurnalele aplicației și interogările lente ale bazei de date. Verifică timpul de conectare și timpul de răspuns upstream pentru a separa inițializarea rețelei de munca aplicației.

## Confirmă remedierea

Corectează adresa sau restabilește aplicația defectă în primul caz; investighează munca lentă în al doilea. Reîncearcă ruta afectată și monitorizează rata erorilor și latența. Un `proxy_read_timeout` mai mare permite un interval mai lung între citiri; nu creează capacitate în backend. Verifică și jurnalele CDN și ale aplicației dacă unul dintre ele a produs eroarea.

[Documentație oficială](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout).

Exemplu: aplicația nu ascultă

Exemplu: conexiune stabilită, dar antetele nu sosesc la timp

Confirmă remedierea

Întrebări conexe