Si diagnostikohen gabimet 502 dhe 504 në Nginx?

Question

IT Interview Practice · Accepted Answer

Gjeni ku dështoi kërkesa para se të rritni timeout-et. Një 502 shpesh tregon komunikim të dështuar me upstream; një 504 shpesh tregon pritje upstream që ka skaduar. Regjistrat dallojnë dështimin real.

## Shembull: aplikacioni nuk po dëgjon

Supozoni se një pjesë e regjistrit të gabimeve thotë:

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

Nginx provoi të lidhej me portën 3000 dhe u refuzua. Kontrolloni nëse aplikacioni punon dhe dëgjon në atë adresë. Nga makina ose container-i i Nginx, testoni `curl -i http://127.0.0.1:3000/products`. Brenda një container-i, kjo adresë i referohet atij vetë, jo automatikisht container-it të një aplikacioni tjetër.

## Shembull: lidhja u krijua, por header-at nuk erdhën në kohë

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

Kjo tregon pritje për header-at e përgjigjes. Lidheni kërkesën me regjistrat e aplikacionit dhe query-t e ngadalta të bazës. Kontrolloni kohën e lidhjes dhe të përgjigjes upstream për të ndarë ngritjen e rrjetit nga puna e aplikacionit.

## Konfirmoni rregullimin

Korrigjoni adresën ose riktheni aplikacionin me defekt në rastin e parë; hetoni punën e ngadaltë në të dytin. Riprovoni rrugën e prekur dhe monitoroni normën e gabimeve dhe vonesën. Një `proxy_read_timeout` më i gjatë lejon interval më të gjatë mes leximeve; nuk krijon kapacitet backend-i. Kontrolloni edhe regjistrat e CDN-së dhe aplikacionit nëse ndonjëri prodhoi gabimin.

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

Shembull: aplikacioni nuk po dëgjon

Shembull: lidhja u krijua, por header-at nuk erdhën në kohë

Konfirmoni rregullimin

Pyetje të ngjashme