Hur diagnostiserar du 502- och 504-fel i Nginx?

Question

IT Interview Practice · Accepted Answer

Hitta var förfrågan misslyckades innan du höjer timeoutvärden. Ett 502 pekar ofta på misslyckad upstream-kommunikation; ett 504 på att väntan på upstream tog slut. Loggarna skiljer den verkliga orsaken åt.

## Exempel: applikationen lyssnar inte

Anta att ett utdrag ur felloggen säger:

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

Nginx försökte ansluta till port 3000 och nekades. Kontrollera att applikationen körs och lyssnar på adressen. Testa `curl -i http://127.0.0.1:3000/products` från Nginx egen maskin eller container. I en container avser adressen containern själv, inte automatiskt en annan applikations container.

## Exempel: ansluten, men inga svarshuvuden i tid

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

Detta pekar på väntan på svarshuvuden. Koppla förfrågan till applikationsloggar och långsamma databasfrågor. Kontrollera anslutningstid och upstream-svarstid för att skilja nätverksuppkoppling från applikationsarbete.

## Bekräfta åtgärden

Rätta adressen eller återställ den felande applikationen i första fallet; undersök långsamt arbete i det andra. Försök den berörda rutten igen och övervaka felfrekvens och latens. Ett längre `proxy_read_timeout` tillåter längre mellanrum mellan läsningar; det skapar inte backendkapacitet. Kontrollera även CDN- och applikationsloggar om någon av dem skapade felet.

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

Exempel: applikationen lyssnar inte

Exempel: ansluten, men inga svarshuvuden i tid

Bekräfta åtgärden

Relaterade frågor