Un proxy n’a pas reçu de réponse à temps.
Quand l’utiliser
L’application en amont est trop lente ou bloquée.
Causes courantes et solutions
Le proxy a renoncé à attendre l’upstream. Causes typiques : une requête de base de données ou un appel d’API externe lent, un worker bloqué par un deadlock, trop peu de workers pour le trafic, ou un pare-feu qui jette silencieusement des paquets. Les délais d’expiration s’empilent et le plus court l’emporte : proxy_read_timeout de nginx vaut 60 secondes par défaut, AWS ALB coupe après 60 secondes d’inactivité, API Gateway après 29, et Cloudflare affiche sa propre erreur 524 après 100 secondes.
Trouvez où passe le temps : consultez les logs de l’application pour la durée des requêtes, cherchez les requêtes SQL lentes, et chronométrez la même requête directement sur l’origine, sans passer par le proxy. Augmenter les délais d’expiration ne fait que masquer le problème ; déplacez les tâches longues vers un worker en arrière-plan et renvoyez un 202 avec une URL de statut. Le traitement peut se terminer après le 504 : réessayer des requêtes non idempotentes peut donc le dupliquer.
Erreur serveur (5xx)
Les codes 5xx sont des erreurs serveur : la requête est peut-être correcte, mais le serveur ou un composant derrière lui a échoué. Ils méritent une alerte.
À quoi ça ressemble
HTTP/1.1 504 Gateway TimeoutComment l’envoyer
| Node.js / Express | res.status(504).end() |
|---|---|
| Python / Flask | return '', 504 |
| nginx | return 504; |
Comment le vérifier
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/