Hoe onderzoek je 502- en 504-fouten in Nginx?

Question

IT Interview Practice · Accepted Answer

Bepaal waar het verzoek mislukte voordat je time-outs verhoogt. Een 502 wijst vaak op mislukte upstreamcommunicatie; een 504 vaak op een verlopen wachttijd voor de upstream. Logs onderscheiden de daadwerkelijke fout.

## Voorbeeld: de applicatie luistert niet

Stel dat een fragment uit het foutenlog meldt:

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

Nginx probeerde poort 3000 te bereiken en werd geweigerd. Controleer of de applicatie draait en op dat adres luistert. Test vanaf de machine of container van Nginx zelf `curl -i http://127.0.0.1:3000/products`. Binnen een container verwijst dat adres naar de container zelf, niet automatisch naar een andere applicatiecontainer.

## Voorbeeld: verbonden, maar niet op tijd antwoordheaders

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

Dit wijst op wachten op antwoordheaders. Koppel het verzoek aan applicatielogs en trage databasequery's. Bekijk verbindingstijd en upstreamantwoordtijd om netwerkopbouw van applicatiewerk te onderscheiden.

## Bevestig de oplossing

Corrigeer het adres of herstel de applicatie in het eerste geval; onderzoek traag werk in het tweede. Probeer de betrokken route opnieuw en bewaak foutpercentage en latency. Een langere `proxy_read_timeout` staat meer tijd tussen leesacties toe, maar creëert geen backendcapaciteit. Controleer ook CDN- en applicatielogs als een van die componenten de fout produceerde.

[Officiële documentatie](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout).

Voorbeeld: de applicatie luistert niet

Voorbeeld: verbonden, maar niet op tijd antwoordheaders

Bevestig de oplossing

Gerelateerde vragen