Kaip diagnozuoti 502 ir 504 klaidas Nginx?

Question

IT Interview Practice · Accepted Answer

Prieš ilgindami timeout nustatykite, kur užklausa sugedo. 502 dažnai rodo nepavykusį upstream ryšį, o 504 – pasibaigusį upstream laukimą. Tikrą gedimą atskiria žurnalai.

## Pavyzdys: programa nesiklauso

Tarkime, klaidų žurnalo ištrauka sako:

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

Nginx bandė jungtis į 3000 prievadą ir buvo atmestas. Patikrinkite, ar programa veikia ir klausosi tuo adresu. Iš paties Nginx kompiuterio ar konteinerio išbandykite `curl -i http://127.0.0.1:3000/products`. Konteineryje šis adresas reiškia patį konteinerį, o ne automatiškai kitos programos konteinerį.

## Pavyzdys: prisijungė, bet laiku negavo atsakymo antraščių

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

Tai rodo atsakymo antraščių laukimą. Susiekite užklausą su programos žurnalais ir lėtomis duomenų bazės užklausomis. Patikrinkite prisijungimo bei upstream atsako laiką, kad atskirtumėte tinklo ryšio parengimą nuo programos darbo.

## Patvirtinkite pataisymą

Pirmu atveju pataisykite adresą arba atkurkite sugedusią programą; antru – tirkit lėtą darbą. Pakartokite paveiktą maršrutą ir stebėkite klaidų dažnį bei delsą. Ilgesnis `proxy_read_timeout` leidžia ilgesnį tarpą tarp skaitymų; jis nesukuria backend pajėgumo. Jei klaidą sukūrė CDN ar programa, tikrinkite ir jų žurnalus.

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

Pavyzdys: programa nesiklauso

Pavyzdys: prisijungė, bet laiku negavo atsakymo antraščių

Patvirtinkite pataisymą

Susiję klausimai