Erreur HTTP 504 : Gateway Timeout

L'erreur HTTP 504 Gateway Timeout se produit lorsqu'un serveur agissant comme passerelle ou proxy n'a pas reçu de réponse du serveur upstream dans le délai imparti. C'est une erreur de la famille 5xx indiquant un problème côté serveur, spécifiquement dans la chaîne de communication entre différents composants de l'infrastructure.

Contrairement au 502 Bad Gateway où le backend répond mais de manière invalide, le 504 indique une absence totale de réponse dans le temps alloué. Le proxy a bien transmis la requête au backend, mais ce dernier n'a pas répondu avant que le timeout ne soit atteint. Le silence du backend est le problème.

Dans les architectures modernes avec reverse proxies, CDN et load balancers, le 504 est une erreur fréquente qui peut avoir des causes variées : backend surchargé, requêtes trop longues, problèmes réseau, ou simplement des timeouts mal configurés. MoniTao surveille vos endpoints et vous alerte immédiatement lors d'erreurs 504.

Causes courantes de l'erreur 504

Le 504 indique toujours un problème de temps de réponse. Voici les causes les plus fréquentes à investiguer :

• Backend surchargé : le serveur applicatif est sous forte charge (CPU à 100%, mémoire saturée, trop de requêtes simultanées). Il ne peut pas traiter les requêtes assez rapidement et certaines dépassent le timeout.
• Timeout proxy trop court : le timeout configuré sur le proxy (Nginx, HAProxy, Cloudflare) est inférieur au temps de traitement normal de certaines requêtes. C'est souvent le cas après ajout de fonctionnalités plus lentes.
• Requêtes base de données lentes : des requêtes SQL non optimisées, des tables non indexées, ou des deadlocks peuvent bloquer l'application pendant de longues secondes, causant des timeouts.
• Problème réseau : la connexion entre le proxy et le backend est instable, avec des pertes de paquets ou une latence excessive. Le backend répond peut-être, mais la réponse n'arrive pas à temps.

Où survient le 504 dans votre architecture

Identifier le composant qui génère le 504 est la première étape du diagnostic :

• Nginx → PHP-FPM : configuration classique LEMP. Le 504 survient quand le script PHP dépasse le fastcgi_read_timeout de Nginx ou le request_terminate_timeout de PHP-FPM.
• Cloudflare → Origin : Cloudflare impose des timeouts stricts (100s plan gratuit, jusqu'à 6000s Enterprise). Si votre serveur d'origine est plus lent, Cloudflare génère un 504.
• Load Balancer → Backend : un backend du pool ne répond plus ou est trop lent. Le load balancer timeout et peut retry sur un autre backend si configuré.
• API Gateway → Microservice : dans une architecture microservices, un service downstream peut être lent ou bloqué, propageant des 504 en cascade à travers la chaîne.

Solutions pour corriger l'erreur 504

La résolution dépend de la cause identifiée. Voici les approches les plus efficaces :

• Augmenter les timeouts : si les requêtes longues sont légitimes, augmentez les timeouts du proxy. Attention : cela ne résout pas le problème de fond et peut masquer des problèmes de performance.
• Optimiser le backend : analysez les requêtes lentes (slow query log MySQL, APM), ajoutez des index, optimisez le code applicatif. C'est la solution durable.
• Implémenter du caching : pour les requêtes répétitives et coûteuses, ajoutez une couche de cache (Redis, Memcached, Varnish) pour réduire la charge backend.
• Passer en asynchrone : pour les opérations vraiment longues (génération de rapports, exports), utilisez un système de jobs asynchrones avec notification quand c'est prêt.

Configuration des timeouts pour éviter les 504

Voici les configurations recommandées pour les différents composants de votre stack :

# Nginx - /etc/nginx/nginx.conf
location ~ \.php$ {
    fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
    fastcgi_read_timeout 300s;     # 5 minutes max
    fastcgi_send_timeout 300s;
    fastcgi_connect_timeout 60s;
}

# Pour un proxy vers un backend HTTP
location /api/ {
    proxy_pass http://backend;
    proxy_read_timeout 300s;
    proxy_connect_timeout 60s;
    proxy_send_timeout 300s;
}

# PHP-FPM - /etc/php/8.2/fpm/pool.d/www.conf
request_terminate_timeout = 300

# MySQL - Slow query log pour identifier les requêtes lentes
slow_query_log = 1
long_query_time = 2

Ces configurations définissent un timeout de 5 minutes, suffisant pour la plupart des opérations. Adaptez selon vos besoins spécifiques. Le slow query log MySQL aide à identifier les requêtes à optimiser.

Surveillance des erreurs 504 avec MoniTao

MoniTao vous aide à détecter et résoudre rapidement les erreurs 504 :

• Détection en temps réel : dès qu'un endpoint retourne un 504, MoniTao le capture et entre en phase de vérification.
• Mesure du temps de réponse : chaque vérification enregistre le temps de réponse. Vous pouvez identifier les endpoints qui approchent du timeout avant qu'ils ne cassent.
• Alertes configurables : définissez des seuils d'alerte non seulement sur le code de réponse mais aussi sur le temps de réponse (alerter si > 5s par exemple).
• Historique de performance : analysez l'évolution des temps de réponse dans le temps pour détecter les dégradations progressives avant qu'elles ne causent des 504.

Questions fréquentes sur l'erreur 504

Conclusion

L'erreur HTTP 504 Gateway Timeout signale un problème de temps de réponse dans votre infrastructure. La cause est généralement un backend surchargé, des requêtes trop lentes, ou des timeouts mal configurés. Le diagnostic passe par l'identification du composant fautif et l'analyse des temps de réponse.

La solution durable consiste à optimiser les performances backend plutôt qu'à simplement augmenter les timeouts. MoniTao vous aide en surveillant non seulement les codes de réponse mais aussi les temps de réponse, vous alertant avant que les problèmes de performance ne deviennent des erreurs 504.

Prêt à dormir sur vos deux oreilles ?

Commencez gratuitement, sans carte bancaire.

Créer mon compte Voir les tarifs