Erreur HTTP 502 : Bad Gateway

L'erreur HTTP 502 "Bad Gateway" est un code de statut indiquant qu'un serveur agissant comme passerelle ou proxy a reçu une réponse invalide du serveur upstream vers lequel il transmettait la requête. C'est l'une des erreurs 5xx les plus fréquentes dans les architectures modernes utilisant des reverse proxies, load balancers ou CDN.

Contrairement au 504 (Gateway Timeout) où le serveur upstream ne répond pas du tout, le 502 signifie que le serveur a bien reçu une réponse, mais que cette réponse était invalide ou incompréhensible. Cela peut provenir d'un crash de l'application, d'une réponse HTTP mal formée, ou d'une fermeture de connexion inattendue.

Pour les équipes DevOps et les administrateurs système, comprendre et résoudre rapidement les erreurs 502 est crucial. MoniTao surveille vos endpoints en continu et vous alerte dès qu'une erreur 502 est détectée, permettant une intervention rapide avant que vos utilisateurs ne soient impactés massivement.

Causes courantes de l'erreur 502

L'erreur 502 peut avoir de nombreuses origines, toutes liées à la communication entre le proxy et le serveur backend :

• Application backend crashée : l'application PHP, Python, Node.js ou autre a crashé ou a été tuée par le système (OOM killer). Le process manager (PHP-FPM, Gunicorn, PM2) n'a plus de worker disponible pour traiter les requêtes.
• Timeout PHP-FPM ou Gunicorn : le worker timeout est atteint avant que l'application ne génère sa réponse. Le process manager tue le worker, fermant brutalement la connexion et générant un 502 côté proxy.
• Socket backend saturé : les connexions socket vers le backend (TCP ou Unix socket) sont toutes utilisées ou le listen backlog est dépassé. Les nouvelles connexions sont refusées.
• Réponse HTTP malformée : l'application backend renvoie une réponse qui ne respecte pas le protocole HTTP (headers invalides, contenu corrompu, encodage incorrect). Le proxy ne peut pas interpréter la réponse.

Architectures où survient le 502

Comprendre où se situe le proxy dans votre stack permet de mieux diagnostiquer l'origine du 502 :

• Nginx → PHP-FPM : configuration classique LEMP. Le 502 survient quand PHP-FPM est arrêté, surchargé, ou quand le script PHP crash avant de générer une réponse.
• HAProxy → Backend : en load balancing, le 502 indique qu'aucun backend du pool n'a pu répondre correctement. Vérifiez les health checks et l'état de chaque backend.
• Cloudflare → Origin : Cloudflare génère un 502 quand votre serveur d'origine renvoie une réponse invalide. Le Ray ID dans l'erreur aide au diagnostic.
• API Gateway → Microservice : dans une architecture microservices, le 502 peut indiquer qu'un service downstream est en erreur. Tracez la requête pour identifier le service fautif.

Diagnostic de l'erreur 502

Un diagnostic méthodique permet d'identifier rapidement la cause du 502 :

• Vérifier les processus backend : assurez-vous que PHP-FPM, Gunicorn ou votre serveur applicatif tourne (ps aux, systemctl status). Vérifiez qu'il écoute sur le bon port ou socket.
• Consulter les logs : examinez les logs du proxy (Nginx error.log) ET de l'application. Les erreurs PHP fatales, les segfaults, les OOM kills y sont consignés.
• Tester le backend directement : si possible, accédez au backend sans passer par le proxy (curl http://127.0.0.1:9000/). Cela isole le problème entre proxy et application.
• Vérifier les connexions : utilisez netstat ou ss pour voir l'état des connexions socket. Un grand nombre de connexions en TIME_WAIT ou CLOSE_WAIT peut indiquer un problème.

Exemple de configuration Nginx pour éviter les 502

Une bonne configuration des timeouts et du nombre de connexions prévient de nombreux 502 :

# /etc/nginx/nginx.conf
upstream php_backend {
    server unix:/var/run/php/php8.2-fpm.sock;
    keepalive 32;  # Pool de connexions persistantes
}

server {
    location ~ \.php$ {
        fastcgi_pass php_backend;
        fastcgi_connect_timeout 60s;
        fastcgi_send_timeout 60s;
        fastcgi_read_timeout 60s;

        # Buffer pour éviter les réponses tronquées
        fastcgi_buffer_size 32k;
        fastcgi_buffers 8 16k;

        # Réessayer sur un autre backend si disponible
        fastcgi_next_upstream error timeout;
        fastcgi_next_upstream_tries 2;
    }
}

Cette configuration établit un pool de connexions keepalive vers PHP-FPM, définit des timeouts adaptés, et configure des buffers suffisants pour éviter les réponses tronquées.

Surveillance des erreurs 502 avec MoniTao

MoniTao offre plusieurs fonctionnalités pour détecter et réagir aux erreurs 502 :

• Détection automatique : chaque monitor HTTP capture le code de réponse. Un 502 déclenche immédiatement le processus de vérification.
• Double vérification : pour éviter les faux positifs, MoniTao effectue une seconde vérification après un délai configurable avant d'envoyer l'alerte.
• Alertes multi-canal : recevez les alertes par email, SMS, Slack, ou webhook selon votre configuration et l'urgence.
• Historique et tendances : analysez l'historique des erreurs 502 pour identifier des patterns (heure de pointe, après déploiement, etc.).

Questions fréquentes sur l'erreur 502

Conclusion

L'erreur HTTP 502 Bad Gateway est un symptôme d'un problème de communication entre votre proxy et votre backend. La résolution passe par un diagnostic méthodique : vérifier que le backend tourne, consulter les logs, tester la connexion directe, et ajuster les timeouts si nécessaire.

Avec MoniTao, vous êtes alerté dès qu'une erreur 502 survient, vous permettant d'intervenir avant que l'impact utilisateur ne devienne critique. Configurez des monitors sur vos endpoints sensibles et utilisez l'historique pour identifier les patterns récurrents.

Prêt à dormir sur vos deux oreilles ?

Commencez gratuitement, sans carte bancaire.

Créer mon compte Voir les tarifs