Jak diagnozować błędy 502 i 504 w Nginx?

Question

IT Interview Practice · Accepted Answer

Zanim zwiększysz timeouty, ustal, gdzie żądanie zawiodło. 502 często wskazuje nieudaną komunikację z upstream, a 504 przekroczony czas oczekiwania na niego. Logi pozwalają rozpoznać faktyczny problem.

## Przykład: aplikacja nie nasłuchuje

Załóżmy taki fragment logu błędów:

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

Nginx próbował połączyć się z portem 3000 i został odrzucony. Sprawdź, czy aplikacja działa i nasłuchuje pod tym adresem. Z maszyny lub kontenera samego Nginx sprawdź `curl -i http://127.0.0.1:3000/products`. W kontenerze ten adres oznacza sam kontener, a nie automatycznie kontener innej aplikacji.

## Przykład: połączono, lecz nagłówki odpowiedzi nie przyszły na czas

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

To wskazuje oczekiwanie na nagłówki odpowiedzi. Powiąż żądanie z logami aplikacji i wolnymi zapytaniami bazy. Sprawdź czas połączenia i odpowiedzi upstream, aby oddzielić ustanawianie sieci od pracy aplikacji.

## Potwierdź poprawkę

W pierwszym przypadku popraw adres lub przywróć aplikację; w drugim zbadaj wolne operacje. Ponów żądanie problematycznej trasy i monitoruj błędy oraz opóźnienie. Dłuższy `proxy_read_timeout` pozwala na większy odstęp między odczytami, ale nie tworzy pojemności backendu. Sprawdź też logi CDN i aplikacji, jeśli to one wygenerowały błąd.

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

Przykład: aplikacja nie nasłuchuje

Przykład: połączono, lecz nagłówki odpowiedzi nie przyszły na czas

Potwierdź poprawkę

Powiązane pytania