Hogyan diagnosztizáljuk az Nginx 502 és 504 hibáit?

Question

IT Interview Practice · Accepted Answer

Az időkorlát növelése előtt állapítsuk meg, hol hibázott a kérés. Az 502 gyakran sikertelen upstream kommunikációra, az 504 gyakran lejárt upstream várakozásra utal. A tényleges hibát a naplók különítik el.

## Példa: az alkalmazás nem figyel a címen

Tegyük fel, hogy a hibanapló részlete ezt tartalmazza:

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

Az Nginx a 3000-es portra próbált csatlakozni, de visszautasították. Ellenőrizzük, hogy az alkalmazás fut-e és figyel-e azon a címen. Az Nginx saját gépéről vagy konténeréből teszteljük: `curl -i http://127.0.0.1:3000/products`. Konténeren belül ez a cím magára a konténerre mutat, nem automatikusan egy másik alkalmazás konténerére.

## Példa: kapcsolódott, de a válaszfejlécek nem érkeztek meg időben

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

Ez a válaszfejlécek várására utal. Kapcsoljuk össze a kérést az alkalmazásnaplókkal és a lassú adatbázis-lekérdezésekkel. Vizsgáljuk a kapcsolódási időt és az upstream válaszidejét a hálózati felépítés és az alkalmazásmunka szétválasztásához.

## Igazoljuk a javítást

Az első esetben javítsuk a címet vagy állítsuk helyre a hibás alkalmazást; a másodikban vizsgáljuk a lassú munkát. Próbáljuk újra az érintett útvonalat, és figyeljük a hibaarányt és a késleltetést. Hosszabb `proxy_read_timeout` nagyobb szünetet enged az olvasások között, de nem növeli a backend kapacitását. Ha a hibát CDN vagy alkalmazás állította elő, azok naplóit is nézzük meg.

[Hivatalos dokumentáció](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout).

Példa: az alkalmazás nem figyel a címen

Példa: kapcsolódott, de a válaszfejlécek nem érkeztek meg időben

Igazoljuk a javítást

Kapcsolódó kérdések