Comment diagnostiquer les erreurs 502 et 504 dans Nginx ?

Question

IT Interview Practice · Accepted Answer

Localisez l'échec de la requête avant d'augmenter les délais d'attente. Une erreur 502 indique souvent une communication upstream défaillante ; une 504 indique souvent une attente upstream expirée. Les journaux permettent de distinguer la panne réelle.

## Exemple : l'application n'écoute pas

Supposons que le journal d'erreurs contienne cet extrait :

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

Nginx a essayé de se connecter au port 3000 et la connexion a été refusée. Vérifiez que l'application fonctionne et écoute sur cette adresse. Depuis la machine ou le conteneur de Nginx, testez `curl -i http://127.0.0.1:3000/products`. Dans un conteneur, cette adresse désigne le conteneur lui-même, pas automatiquement celui d'une autre application.

## Exemple : connecté, mais sans en-têtes de réponse à temps

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

Cela désigne l'attente des en-têtes de réponse. Corrélez la requête avec les journaux applicatifs et les requêtes lentes de la base de données. Vérifiez le temps de connexion et le temps de réponse upstream pour séparer l'établissement réseau du travail applicatif.

## Confirmer la correction

Corrigez l'adresse ou rétablissez l'application défaillante dans le premier cas ; recherchez le travail lent dans le second. Réessayez la route concernée et surveillez le taux d'erreurs et la latence. Un `proxy_read_timeout` plus long autorise un intervalle plus grand entre lectures ; il ne crée pas de capacité backend. Consultez aussi les journaux du CDN et de l'application si l'un d'eux a produit l'erreur.

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

Exemple : l'application n'écoute pas

Exemple : connecté, mais sans en-têtes de réponse à temps

Confirmer la correction

Questions connexes