Hvordan diagnosticerer du 502- og 504-fejl i Nginx?

Question

IT Interview Practice · Accepted Answer

Find ud af, hvor forespørgslen fejlede, før du øger timeouts. En 502 peger ofte på fejlet upstream-kommunikation; en 504 peger ofte på en udløbet ventetid på upstream. Logs skelner mellem de faktiske fejl.

## Eksempel: applikationen lytter ikke

Antag, at et uddrag af fejlloggen siger:

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

Nginx forsøgte at forbinde til port 3000 og blev afvist. Kontroller, om applikationen kører og lytter på adressen. Test `curl -i http://127.0.0.1:3000/products` fra Nginx' egen maskine eller container. Inde i en container refererer adressen til containeren selv, ikke automatisk til en anden applikations container.

## Eksempel: forbundet, men ingen svar-headere i tide

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

Dette peger på ventetid på svar-headere. Sammenhold forespørgslen med applikationslogs og langsomme databaseforespørgsler. Kontroller forbindelsestid og upstream-svartid for at skelne netværksoprettelse fra applikationsarbejde.

## Bekræft rettelsen

Ret adressen eller genopret den fejlende applikation i første tilfælde; undersøg langsomt arbejde i det andet. Prøv den berørte rute igen, og overvåg fejlrate og latenstid. En længere `proxy_read_timeout` tillader et længere mellemrum mellem læsninger; den skaber ikke backend-kapacitet. Kontroller også CDN- og applikationslogs, hvis fejlen blev dannet dér.

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

Eksempel: applikationen lytter ikke

Eksempel: forbundet, men ingen svar-headere i tide

Bekræft rettelsen

Relaterede spørgsmål