Hvordan feilsøker du 502 og 504 i Nginx?

Question

IT Interview Practice · Accepted Answer

Finn hvor forespørselen feilet før du øker tidsavbrudd. En 502 peker ofte mot mislykket upstream-kommunikasjon; en 504 ofte mot utløpt ventetid på upstream. Logger skiller den faktiske feilen.

## Eksempel: applikasjonen lytter ikke

Anta at et utdrag fra feilloggen sier:

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

Nginx forsøkte å koble til port 3000 og ble avvist. Kontroller at applikasjonen kjører og lytter på den adressen. Fra Nginx sin egen maskin eller container tester du `curl -i http://127.0.0.1:3000/products`. I en container peker adressen på containeren selv, ikke automatisk på en annen applikasjonscontainer.

## Eksempel: tilkoblet, men ingen svarheadere i tide

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

Dette peker mot venting på svarheadere. Knytt forespørselen til applikasjonslogger og trege databasespørringer. Kontroller tilkoblingstid og upstream-svartid for å skille nettverksoppsett fra applikasjonsarbeid.

## Bekreft rettelsen

Korriger adressen eller gjenopprett applikasjonen i det første tilfellet; undersøk tregt arbeid i det andre. Prøv den berørte ruten på nytt og overvåk feilrate og forsinkelse. En lengre `proxy_read_timeout` tillater større avstand mellom lesinger; den skaper ikke backend-kapasitet. Kontroller også CDN- og applikasjonslogger hvis en av disse produserte feilen.

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

Eksempel: applikasjonen lytter ikke

Eksempel: tilkoblet, men ingen svarheadere i tide

Bekreft rettelsen

Relaterte spørsmål