Erreur 502 Bad Gateway : ce que ça veut dire
Une erreur 502 Bad Gateway signifie « passerelle incorrecte » : un serveur intermédiaire (proxy, CDN ou répartiteur de charge) a transmis votre requête au serveur suivant et en a reçu une réponse invalide. L’intermédiaire fonctionne. C’est ce qui se trouve derrière lui qui est arrêté, coupé ou illisible.
C’est gérable, et le diagnostic suit toujours le même ordre. Sur n’importe quel site (WordPress, boutique, application Node), la méthode est identique : trouver quelle couche répond 502, puis pourquoi la couche suivante ne répond pas correctement.
Un proxy inverse est un serveur placé devant votre site, qui reçoit les requêtes des visiteurs et les transmet au serveur qui fabrique la page. Nginx, Apache en mode proxy et Cloudflare jouent ce rôle. PHP-FPM désigne le gestionnaire de processus qui exécute le code PHP pour le compte de Nginx.
Ce que dit la norme, et pourquoi ça arrive
La RFC 9110, section 15.6.3 définit le 502 : le serveur, agissant comme passerelle ou proxy, a reçu une réponse invalide d’un serveur qu’il a contacté pour traiter la requête. Le code appartient à la classe 5xx, celle des erreurs côté serveur. MDN donne la même définition et renvoie à cette spécification comme référence.
Les causes les plus fréquentes :
- le service applicatif est arrêté ou a planté (PHP-FPM, Node, Gunicorn) ;
- Nginx cherche le backend au mauvais endroit (socket ou port qui ne correspondent pas) ;
- le backend ferme la connexion avant d’avoir répondu, souvent à cause d’un délai trop court ;
- un pare-feu ou un WAF coupe la connexion entre le proxy et l’origine ;
- les en-têtes de réponse sont trop gros pour les buffers du proxy ;
- le CDN ne joint plus l’origine après un changement d’IP ou de DNS.
1. Visiteur : trois gestes avant de conclure
Le 502 vient presque toujours du serveur, pas de votre ordinateur. Trois essais suffisent avant d’abandonner :
- Rechargez la page avec Ctrl+F5 (Cmd+Maj+R sur Mac). Un 502 peut être ponctuel, le temps qu’un service redémarre.
- Ouvrez la page en navigation privée, ou dans un autre navigateur, ou en 4G. Cela écarte un cache local ou un réseau d’entreprise capricieux.
- Attendez quelques minutes, puis réessayez. Si le site reste en erreur, prévenez son propriétaire en indiquant l’URL et l’heure.
Vider le cache ne répare pas un 502 réel, mais ça élimine le doute.
2. Propriétaire : identifier la couche qui répond 502
Avant de toucher à quoi que ce soit, savoir qui renvoie l’erreur évite de chercher au mauvais endroit. Derrière Cloudflare, la lecture est contre-intuitive : une page 502 aux couleurs de Cloudflare signifie que votre serveur d’origine a lui-même répondu 502, alors qu’une page blanche, sans le logo Cloudflare, signale une erreur côté Cloudflare, comme l’indique la documentation Cloudflare. Sans CDN, une page « nginx » brute vient de votre propre serveur. Si le code est un 520 ou un 521 plutôt qu’un 502, lisez plutôt l’erreur 520 Cloudflare.
3. Lire le log d’erreur du proxy
Le log dit exactement ce qui a échoué. Sous Nginx, ouvrez-le en SSH :
sudo tail -n 50 /var/log/nginx/error.logLe numéro d’erreur est le vrai diagnostic, comme l’explique KernelHost :
| Message dans le log | Cause probable | Action |
|---|---|---|
connect() failed (2: No such file or directory) | Socket PHP-FPM absent : service arrêté ou chemin faux | Redémarrer PHP-FPM, vérifier le chemin |
connect() failed (111: Connection refused) | Rien n’écoute sur le port du backend | Démarrer le service, vérifier le port |
connect() failed (13: Permission denied) | Nginx n’a pas le droit d’accéder au socket | Corriger propriétaire et permissions du socket |
upstream sent too big header | En-têtes de réponse trop volumineux | Augmenter les buffers FastCGI |
upstream prematurely closed connection | Le backend a planté ou été tué en cours de route | Lire les logs PHP-FPM, vérifier les timeouts |
4. Vérifier que le backend tourne
C’est la cause n° 1 selon KernelHost : PHP-FPM arrêté. Le nom du service dépend de la version de PHP installée :
sudo systemctl status php8.4-fpm
sudo systemctl restart php8.4-fpmSi le service s’arrête à nouveau, ne vous contentez pas du redémarrage : lisez journalctl -u php8.4-fpm pour trouver pourquoi. Puis contrôlez que la ligne listen du pool PHP-FPM (souvent www.conf) correspond exactement au fastcgi_pass de Nginx, comme le rappelle GetPageSpeed. Testez la configuration avec sudo nginx -t avant de recharger Nginx.
Pour les causes propres à WordPress (extension, thème, mémoire), suivez le guide 502 WordPress et la limite de mémoire PHP.
5. Comparer les délais entre Nginx et le backend
Quand Nginx attend trop longtemps, il renvoie un 504. Un 502 apparaît quand PHP-FPM coupe le travail avant, ou quand le worker meurt. Le délai par défaut de fastcgi_read_timeout dans Nginx est de 60 secondes source : KernelHost, 2026. Trois réglages interagissent :
| Directive | Rôle | Symptôme si trop bas | Où la régler | Valeur de départ |
|---|---|---|---|---|
fastcgi_read_timeout | Temps que Nginx attend la réponse de PHP | 504 sur les pages longues | Bloc http, server ou location de Nginx | 60 à 120 s |
request_terminate_timeout | Durée après laquelle PHP-FPM tue un worker | 502 si inférieur au délai Nginx | Pool PHP-FPM (www.conf) | Supérieur à celui de Nginx, ou désactivé |
max_execution_time | Durée maximale d’un script PHP | Script interrompu, erreur ou page vide | php.ini ou panel de l’hébergeur | 60 s |
La règle : le délai le plus court coupe en premier, et c’est lui qui détermine le code d’erreur. Selon Datadog, un request_terminate_timeout plus court que celui de Nginx produit un 502. Vérifiez la valeur réelle sur votre serveur, car les défauts varient selon les configurations. Augmenter les délais soulage le symptôme, mais une requête qui dure plus de deux minutes mérite d’être optimisée.
6. Pare-feu, CDN, DNS
Si le backend tourne et que les délais sont cohérents, regardez entre les couches :
- Pare-feu et WAF : un pare-feu qui bloque les IP du CDN ou du proxy coupe la connexion. Autorisez-les explicitement.
- CDN : l’origine doit être configurée pour répondre au domaine sur l’IP ciblée, notamment après un changement d’enregistrement DNS, comme le rappelle la communauté Cloudflare.
- Logs vides : si le serveur qui sert la page n’affiche rien, l’erreur vient d’un équipement intermédiaire (répartiteur de charge, proxy local). Consultez aussi leurs logs.
- DNS : un domaine qui pointe vers l’ancienne IP après migration produit des erreurs trompeuses, voir le diagnostic DNS.
502, 503, 504 : ne pas les confondre
| Code | Ce qui s’est passé | Article |
|---|---|---|
| 502 | Réponse invalide, vide ou connexion coupée | cet article |
| 503 | Service indisponible ou surchargé | Erreur 503 |
| 504 | Aucune réponse dans le délai | Erreur 504 |
Un 500, lui, est une erreur interne de l’application elle-même : voir l’erreur 500.
FAQ
Une erreur 502 vient-elle de mon ordinateur ?
Presque jamais. Le 502 se produit entre deux serveurs. Recharger la page et tester un autre réseau écarte le doute, mais la correction revient au propriétaire du site ou à son hébergeur.
Quelle différence entre 502 et 504 ?
Le 502 signale une réponse invalide ou une connexion coupée, le 504 une absence de réponse dans le délai imparti. Les deux viennent d’un problème entre un proxy et le serveur en amont.
Un 502 disparaît-il tout seul ?
Parfois, si c’est un redémarrage ou une surcharge brève. S’il dure plus de quelques minutes, un service est probablement arrêté et ne repartira pas sans intervention.
Le 502 est-il mauvais pour le référencement ?
Une erreur brève est tolérée par les moteurs de recherche, qui reviennent crawler. Une erreur qui dure des heures ou se répète nuit à l’indexation et à la confiance des visiteurs.
Quand passer la main à un pro
Passez la main si le service retombe après chaque redémarrage, si les logs sont vides ou illisibles, ou si vous n’avez pas d’accès SSH. Envoyez à votre hébergeur l’URL, l’heure exacte de l’erreur, la couche qui l’affiche et les dernières lignes du log : le diagnostic ira deux fois plus vite. Et si les 502 reviennent chaque mois, le sujet n’est plus la panne mais la maintenance : surveillance, mises à jour et ressources serveur adaptées.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout, hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy
