Le code erreur 502 Bad Gateway fait partie de la famille des erreurs HTTP 5xx, qui regroupent les problèmes côté serveur. Aux côtés des erreurs 500 (Internal Server Error), 503 (Service Unavailable) et 504 (Gateway Timeout), le 502 occupe une place particulière : il indique spécifiquement qu’un serveur intermédiaire — qu’il s’agisse d’un reverse proxy NGINX, d’Apache en frontal, d’un CDN comme Cloudflare ou d’un répartiteur de charge — a reçu une réponse non valide du serveur d’origine.
Dans cet article, nous allons décortiquer cette erreur sous tous ses angles : définition technique précise, symptômes visibles pour l’utilisateur, principales causes côté serveur, impact sur l’expérience utilisateur et le SEO, solutions pratiques pour les visiteurs comme pour les administrateurs, et bonnes pratiques de prévention. Que vous soyez un internaute confronté à ce message ou le propriétaire d’un site internet cherchant à résoudre le problème, vous trouverez ici les réponses à vos questions.
Note d’actualisation — août 2026 : cet article a été revu afin d’actualiser le diagnostic des erreurs 502, les pratiques WordPress, les recommandations liées à PHP-FPM, aux proxys, aux CDN et à l’impact des erreurs serveur sur l’exploration Google.
Sommaire de l’article
Points clés
- L’erreur 502 Bad Gateway signale qu’un serveur intermédiaire (passerelle, proxy ou CDN) a reçu une réponse invalide ou incomplète du serveur en amont chargé de traiter la requête.
- Cette erreur est généralement temporaire, causée par des pics de trafic, une maintenance ou un bug applicatif, mais des occurrences répétées révèlent souvent un problème d’infrastructure plus profond.
- Côté utilisateur : recharger la page, tester en navigation privée ou avec un autre navigateur, vider le cache du navigateur et le cache DNS.
- Côté propriétaire de site : vérifier l’état du serveur et analyser les logs, contrôler la configuration du CDN, du pare-feu et du DNS, inspecter le code applicatif et surveiller la charge serveur.
- Une approche structurée de diagnostic et une prévention proactive (monitoring, capacité adaptée, mises à jour régulières) limitent l’impact sur les visiteurs, le chiffre d’affaires et le référencement.
Définition technique de l’erreur 502 Bad Gateway
Pour comprendre comment corriger l’erreur 502, il faut d’abord saisir ce qu’elle signifie techniquement. La définition de référence figure aujourd’hui dans la RFC 9110 : un serveur agissant comme passerelle ou proxy renvoie un statut 502 lorsqu’il reçoit une réponse invalide du serveur en amont sollicité pour traiter la requête.
- Définition officielle : le statut HTTP 502 indique que la passerelle ou le serveur proxy n’a pas reçu de réponse valide du serveur principal (serveur en amont) auquel il a transmis la requête du client.
- Rôles typiques des passerelles :
- Reverse proxy (NGINX, HAProxy)
- Serveur frontal Apache avec mod_proxy
- CDN (Cloudflare, Fastly, Akamai)
- Répartiteur de charge (load balancer)
- Pare-feu applicatif (WAF)
- Localisation du problème : le navigateur lui-même n’est généralement pas à l’origine du 502. Le code provient d’un intermédiaire agissant comme passerelle ou proxy ; un proxy local, un VPN ou une infrastructure réseau d’entreprise peut toutefois faire partie de cette chaîne.
- Comparaison avec d’autres codes HTTP :
| Code | Signification | Cause typique |
|---|---|---|
| 500 | Internal Server Error | Bug interne sur un serveur unique |
| 502 | Bad Gateway | Réponse invalide d’un serveur en amont |
| 503 | Service Unavailable | Maintenance ou surcharge temporaire |
| 504 | Gateway Timeout | Délai d’attente dépassé, aucune réponse |
Comment l’erreur 502 se manifeste côté utilisateur
L’affichage d’une erreur proxy 502 varie selon le navigateur utilisé, le serveur web concerné (NGINX, Apache) et les services intermédiaires comme les CDN. L’expérience utilisateur peut donc différer significativement d’un site à l’autre.
Textes courants affichés :
- « 502 Bad Gateway »
- « HTTP 502 »
- « 502 Bad Gateway nginx » (très fréquent)
- « 502 Bad Gateway Apache »
- « 502. That’s an error. » (message Google)
- Pages personnalisées d’hébergeurs (OVH, Scaleway, AWS)

Ce que l’utilisateur voit généralement :
- Une page blanche ou minimaliste
- Un logo du navigateur ou du fournisseur (Cloudflare, OVH, etc.)
- Un simple code 502 sans explication détaillée
- Parfois un message invitant à réessayer plus tard
Le message affiché ne permet pas de déterminer si le problème vient du site lui-même, de l’hébergeur du CDN, du FAI ou même du réseau local. Cette opacité peut être source de confusion pour les utilisateurs non techniques.
Impact immédiat :
- Impossibilité d’afficher la page web demandée
- Interruption de parcours critique (paiement, formulaire, connexion)
- Frustration et perte de confiance envers le site
Principales causes d’une erreur 502 Bad Gateway côté serveur
Dans la grande majorité des cas, l’erreur 502 bad gateway trouve son origine côté serveur : hébergeur, proxy, CDN ou application web. Même si un problème local peut exposer l’erreur, la cause racine se situe presque toujours dans l’infrastructure du site.
Cette section s’adresse principalement aux administrateurs systèmes, développeurs web et propriétaires de sites qui cherchent à identifier et réparer une erreur 502.
Problèmes sur le serveur en amont (application, code, base de données)
Les causes applicatives représentent une part significative des erreurs 502, particulièrement sur les sites dynamiques utilisant PHP, Node.js, Python ou Ruby.
- Bugs dans le code applicatif : une erreur fatale PHP, une exception non gérée dans Node.js ou une boucle infinie peuvent empêcher le serveur du site web de renvoyer une réponse HTTP valide.
- Exemples concrets :
- Erreurs PHP fatales après une mise à jour de WordPress (incompatibilité de plugin)
- Processus PHP interrompu ou socket PHP-FPM indisponible
- Script qui meurt avant d’envoyer les en-têtes HTTP
- Problèmes de base de données :
- Connexions MySQL/MariaDB saturées (trop de requêtes simultanées)
- Requêtes SQL trop lentes bloquant les workers
- Tables corrompues après une migration
- Base de données temporairement indisponible
- Délais et ruptures côté application : une réponse upstream invalide, une connexion interrompue ou un processus FastCGI/PHP-FPM qui se termine anormalement peut conduire à un 502. Une absence de réponse dépassant le délai attendu correspond plus classiquement à un 504, même si le comportement exact dépend de la couche proxy et de l’hébergement.
Surcharge du serveur et pics de trafic
La surcharge du serveur constitue une cause fréquente d’erreurs 502 lorsque le serveur d’origine ou les processus applicatifs ne disposent plus de ressources suffisantes pour répondre correctement à la passerelle.
- Pics de trafic : les soldes, campagnes publicitaires ou événements viraux peuvent multiplier le nombre de requêtes. Par exemple, un site e-commerce pendant le Black Friday peut voir son trafic décupler en quelques heures.
- Épuisement des ressources : lorsque le CPU, la RAM ou les I/O du serveur d’origine atteignent leurs limites, les requêtes ne peuvent plus être traitées dans les temps impartis.
- Attaques DDoS : une attaque par déni de service distribué sature l’infrastructure et peut déclencher des 502 à travers le reverse proxy ou le CDN.
- Cas pratique : un site e-commerce en hébergement mutualisé qui lance une campagne Google Ads et dépasse ses limites de ressources allouées verra immédiatement apparaître des erreurs 502 pour ses visiteurs.
- Limites de connexion : les pools de connexion à la base de données ou les workers PHP-FPM (pm.max_children) peuvent être saturés, générant des 502 via la passerelle.

Mauvaises configurations réseau, proxy, CDN ou pare-feu
Les erreurs de configuration entre les différents maillons de la chaîne technique constituent une source majeure de problèmes 502, particulièrement après des modifications d’infrastructure.
- Erreurs de configuration proxy :
- Directive proxy_pass NGINX pointant vers une mauvaise adresse IP
- Port incorrect dans la configuration upstream
- Backend marqué « down » dans un load balancer
- Pare-feu mal paramétré : un WAF (Web Application Firewall), des règles iptables trop restrictives ou des paramètres de sécurité cloud peuvent bloquer des requêtes légitimes du CDN ou du proxy.
- Problèmes spécifiques aux CDN :
- Serveur d’origine injoignable depuis le réseau du CDN
- Erreur de certificat SSL/TLS entre CDN et origine
- Propagation DNS incomplète après changement d’hébergeur
- Vérification essentielle : toujours contrôler la chaîne complète, du client jusqu’à l’application : proxy → CDN → load balancer → serveur d’application.
Erreurs de cache et de DNS
Le cache DNS et les systèmes de cache HTTP jouent un rôle souvent sous-estimé dans l’apparition des erreurs 502 bad gateway.
- Cache DNS obsolète : après une migration ou un changement d’adresse IP, certains résolveurs peuvent continuer à utiliser une ancienne valeur jusqu’à l’expiration de leur cache. La durée dépend principalement du TTL et de l’état des caches intermédiaires.
- Enregistrements DNS mal configurés : des enregistrements A, AAAA, CNAME ou MX incorrects chez le registrar ou le fournisseur DNS peuvent faire pointer le domaine vers un serveur qui ne sert pas correctement le site.
- Communication CDN → origine : un mauvais serveur d’origine, une connexion refusée, une erreur TLS ou une règle WAF peuvent empêcher le CDN d’obtenir une réponse exploitable et conduire à un 502.
- TTL trop longs : des valeurs TTL élevées compliquent la correction rapide en cas d’erreur, car les modifications DNS mettent plus de temps à se propager.
Problèmes de connectivité et d’infrastructure (FAI, réseau, data center)
Certaines causes de 502 échappent au contrôle direct du propriétaire du site et concernent les couches basses de l’infrastructure réseau.
- Pannes de data center : une rupture réseau BGP ou un incident majeur chez un hébergeur (comme les pannes documentées chez OVHcloud ou AWS ces dernières années) peut provoquer des 502 en cascade pour tous les sites hébergés.
- Problèmes de peering : des routes instables entre FAI et hébergeurs peuvent engendrer des erreurs intermittentes, particulièrement difficiles à diagnostiquer.
- Bonne pratique : en cas de signalements multiples d’utilisateurs sur différents réseaux, consulter immédiatement les pages de statut des hébergeurs et CDN pour vérifier l’existence d’un incident en cours.
Impact de l’erreur 502 : expérience utilisateur, business et SEO
L’impact d’une erreur 502 bad gateway peut varier considérablement selon sa fréquence et sa durée. Quelques occurrences isolées passent souvent inaperçues, mais des erreurs répétées peuvent avoir des conséquences sérieuses.
Expérience utilisateur :
- Quelques 502 isolés sur une courte période sont généralement tolérés par les visiteurs
- Des erreurs répétées entraînent une perte de confiance et une image de site peu fiable
- Les utilisateurs habitués à des services performants (Google, Amazon) ont peu de patience pour les erreurs
Impact e-commerce :
- Chute directe des conversions lors de 502 sur les pages de paiement
- Abandon de panier si l’erreur survient au moment critique
- Impossibilité de suivre une commande ou d’accéder à son compte client
- Perte de chiffre d’affaires proportionnelle à la durée de l’incident
Impact SEO :
- Googlebot interprète des 502 répétés comme des problèmes de disponibilité
- Baisse de la fréquence de crawl si les erreurs persistent
- Retrait temporaire de certaines URL du cache pour les pages inaccessibles
- Des erreurs 502 répétées ou durables réduisent la capacité de Google à explorer les URL concernées. Si elles persistent, certaines pages peuvent finir par sortir de l’index jusqu’au retour d’une réponse valide
Solutions rapides côté utilisateur (dépannage utilisateur)
Cette section s’adresse aux visiteurs qui rencontrent un message 502 sur un site qu’ils ne gèrent pas. Bien qu’un utilisateur ne puisse pas corriger le problème serveur lui-même, il peut contourner certains problèmes locaux ou temporaires.
Les solutions suivent un ordre logique, du geste le plus simple au plus avancé.
Actualiser la page et attendre quelques minutes
Le premier réflexe face à une erreur 502 devrait toujours être de recharger la page, car beaucoup de ces erreurs sont liées à un redémarrage de service ou une montée en charge très courte côté hébergeur.
- Raccourcis pour actualiser :
- Windows : F5 ou Ctrl+F5 (rechargement forcé)
- macOS : Cmd+R ou Cmd+Shift+R
- Patience recommandée : réessayez après un court délai, notamment lorsqu’un service vient de redémarrer ou traverse un pic de charge.
- Si l’erreur persiste : passez aux étapes suivantes.
Tester un autre navigateur ou le mode navigation privée
Le navigateur lui-même provoque rarement un véritable 502. En revanche, un VPN, un proxy local, un antivirus réseau ou une extension qui modifie la chaîne de connexion peut influencer le résultat observé. Un test dans un autre navigateur ou sans ces intermédiaires aide surtout à isoler cette hypothèse.
- Testez la même URL dans un autre navigateur courant (Chrome, Firefox, Edge, Safari)
- Ouvrez la page en mode navigation privée ou incognito (généralement Ctrl+Shift+N ou Cmd+Shift+N)
- Le mode privé désactive la plupart des extensions et utilise un profil vierge
Si le site fonctionne en mode privé :
- Désactivez vos extensions une par une pour identifier la responsable
- Réinitialisez les paramètres du navigateur si nécessaire
Vider le cache du navigateur et les cookies du site
Le cache du navigateur peut conserver l’affichage d’une ancienne page d’erreur, mais il n’est généralement pas la cause du 502 lui-même. Vider les données du site constitue donc un test secondaire lorsque l’erreur semble limitée à un seul navigateur.
- Videz le cache et les cookies pour le site concerné uniquement (si votre navigateur le permet) afin de préserver vos connexions sur d’autres sites
- La procédure se trouve généralement dans : Paramètres > Confidentialité > Effacer les données de navigation
- Cochez « Images et fichiers en cache » et « Cookies et autres données de site »
Vider ou changer le DNS côté utilisateur
Le système de votre ordinateur garde en mémoire (cache DNS) la correspondance entre noms de domaine et adresses IP. Ces informations peuvent devenir obsolètes après une modification DNS côté serveur.
Vider le cache DNS local :
- Windows : ouvrez l’invite de commandes et tapez ipconfig /flushdns
- macOS : sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
- Linux : sudo systemd-resolve –flush-caches
Changer de serveur DNS (si le problème persiste) :
- Google DNS : 8.8.8.8 et 8.8.4.4
- Cloudflare DNS : 1.1.1.1 et 1.0.0.1
Cela permet de vérifier si le problème vient du résolveur DNS de votre FAI.
Tester sur un autre appareil ou un autre réseau
Pour isoler définitivement un problème local d’un problème serveur :
- Testez le site depuis un smartphone en 4G/5G si le problème apparaît sur un PC en Wi-Fi
- Ou inversement, testez sur PC si l’erreur survient sur mobile
Si le site fonctionne sur un autre réseau : le problème provient probablement de votre réseau local ou de votre FAI, pas du site lui-même.
Actions complémentaires :
- Redémarrez votre modem/routeur et votre ordinateur
- Consultez les sites de suivi d’incidents (Downdetector) pour vérifier si d’autres utilisateurs signalent des problèmes
- Contactez le support de votre FAI en cas de suspicion de panne

Diagnostic et correction côté propriétaire de site / administrateur
Cette section technique s’adresse aux administrateurs, webmasters, développeurs et équipes d’exploitation confrontés à des erreurs 502 sur leurs sites.
Approche recommandée :
- Vérifier l’état général des services
- Analyser les logs
- Contrôler la configuration
- Tester sans services intermédiaires (CDN, WAF)
- Corriger le code et ajuster les limites de ressources
En environnement de production, il est souvent utile de reproduire le problème sur un environnement de préproduction ou de test avant d’appliquer des corrections.
Vérifier l’état du site et des services (hébergeur, CDN, FAI entreprise)
En premier lieu, consultez les pages de statut des fournisseurs impliqués dans votre infrastructure :
| Fournisseur | Page de statut typique |
|---|---|
| OVHcloud | status.ovhcloud.com |
| AWS | status.aws.amazon.com |
| Cloudflare | cloudflarestatus.com |
| Scaleway | status.scaleway.com |
- Lors d’incidents importants (panne réseau, bug de mise à jour), les hébergeurs publient généralement un ticket d’incident avec heure de début et résolution prévue
- Vérifiez aussi les canaux de communication officiels (compte X/Twitter, emails de maintenance)
- En hébergement mutualisé, vérifiez si d’autres clients rapportent des 502 sur le même cluster
Analyser les journaux d’erreurs et de requêtes (logs)
Les logs serveur sont la source d’information clé pour identifier la cause exacte d’une erreur 502.
Fichiers courants à examiner sur un serveur Linux autogéré ; sur un hébergement WordPress managé, utilisez en priorité les logs et outils fournis par l’hébergeur :
- NGINX : /var/log/nginx/error.log et access.log
- Apache : /var/log/apache2/error.log ou /var/log/httpd/error_log
- PHP-FPM : /var/log/php-fpm/error.log
- Applications : logs spécifiques (Node.js, Python, etc.)
- Base de données : /var/log/mysql/error.log
Pour WordPress et autres CMS :
- Pour un diagnostic WordPress temporaire, activez le journal de debug de préférence sur staging :
define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false); @ini_set('display_errors', 0); - Consultez le fichier wp-content/debug.log
Conseil pratique : filtrez les logs sur la fenêtre temporelle exacte où les 502 ont été observés, et sur les URL impactées (pages de paiement, API, etc.).
Désactiver temporairement CDN, proxy ou pare-feu applicatif
Pour isoler le problème, effectuez un « bypass » des services intermédiaires :
- Utilisez le mode bypass ou développement du CDN lorsqu’il existe, ou testez directement l’origine sans modifier les DNS publics
- Désactivez le proxy inverse si possible
- Testez via la ligne de commande directement sur l’IP/port de l’application :
curl -vk --resolve votredomaine.com:443:IP_ORIGINE https://votredomaine.com/page-test
Interprétation :
- Si le 502 disparaît sans CDN → problème côté CDN (règle WAF, cache, configuration SSL/TLS)
- Si le 502 persiste → problème côté serveur d’origine
Important : ne laissez ce mode « bypass » que le temps du diagnostic (risques de sécurité, perte de performance du CDN).
Contrôler la configuration serveur (NGINX, Apache, PHP-FPM, timeouts)
Les paramètres de configuration sont souvent à l’origine des erreurs 502, particulièrement après une mise à jour ou une modification récente.
Pour NGINX :
# Vérifier la cible upstream
proxy_pass http://backend;
fastcgi_pass unix:/var/run/php/php-fpm.sock;
# Contrôler ensuite les timeouts réellement définis
# proxy_read_timeout
# proxy_connect_timeout
# fastcgi_read_timeout
Pour Apache :
- Vérifiez la configuration de mod_proxy, mod_fcgid ou proxy_fcgi
- Contrôlez les timeouts et les limites de workers
Pour PHP-FPM :
; Paramètres à contrôler selon le pool, la mémoire et la charge réelle
; pm.max_children
; pm.max_requests
; request_terminate_timeout
Règle d’or : commencez par identifier pourquoi le serveur en amont répond mal ou trop lentement. L’augmentation d’un timeout ne corrige pas un backend défaillant et peut seulement retarder l’apparition de l’erreur.
Inspecter le code, les plugins et les thèmes (WordPress et autres CMS)
Sur WordPress, Drupal, Joomla, Magento et autres CMS, un plugin, une extension ou un thème peut être responsable du problème (boucle infinie, requêtes SQL lourdes, appels API externes bloquants).
Méthodologie de diagnostic :
- Commencez par les dernières modifications et, lorsque c’est possible, reproduisez le problème sur staging ou en mode Troubleshooting avant de désactiver des extensions
- Isolez ensuite les extensions suspectes une par une en vous appuyant sur les logs et notre guide consacré aux conflits entre plugins ou thèmes WordPress
- Si le thème semble impliqué, testez temporairement un thème WordPress par défaut compatible dans un environnement de diagnostic
Tests de charge : utilisez des outils comme k6 ou JMeter pour reproduire les 502 sous forte utilisation et identifier les points de blocage.
Vérifier la base de données et les ressources serveur
Les problèmes de base de données et l’épuisement des ressources serveur sont des causes fréquentes qu’il ne faut pas négliger.
Métriques base de données à examiner :
- Nombre de connexions simultanées
- Requêtes lentes (slow queries)
- Locks et contentions
- Taille des tables
Optimisations possibles :
- Optimiser les requêtes les plus lourdes
- Ajouter des index appropriés
- Mettre en place un cache applicatif (Redis, Memcached)
Surveillance des ressources serveur :
- CPU, RAM, disque, réseau
- Outils recommandés : Prometheus, Grafana, New Relic, Datadog, ou les outils fournis par l’hébergeur
En cas de saturation régulière : envisagez un changement de plan d’hébergement (VPS, serveur dédié, cloud managé) et/ou une meilleure répartition de charge avec du load balancing.
Bonnes pratiques pour prévenir les erreurs 502 Bad Gateway
La prévention reste la meilleure stratégie pour éviter que les erreurs 502 n’impactent vos utilisateurs, votre chiffre d’affaires et votre positionnement SEO.
Surveillance proactive :
- Mettez en place des alertes (emails, Slack, PagerDuty) en cas de hausse soudaine de 502 ou de temps de réponse élevés
- Sur WordPress, privilégiez une surveillance continue de la disponibilité, des erreurs et des performances ; les outils d’observabilité avancés comme Prometheus, Grafana, New Relic ou Datadog restent pertinents pour les infrastructures qui les nécessitent
- Surveillez les métriques clés : taux d’erreur 5xx, latence upstream, utilisation CPU/RAM
Notre reco : chez Evolyon, la supervision des sites WordPress s’appuie notamment sur WP Umbrella pour le suivi de disponibilité et les alertes, en complément de l’infrastructure Kinsta et de notre assistance WordPress 7j/7 lorsqu’une anomalie nécessite une analyse.
Tests de charge réguliers :
- Effectuez des tests de montée en charge avant les grands événements (soldes, campagnes marketing, lancements produits)
- Identifiez les points de rupture de votre infrastructure avant qu’ils ne causent des problèmes en production
Documentation technique :
- Documentez la chaîne technique complète (DNS, CDN, reverse proxy, application, base de données)
- Maintenez à jour les procédures de diagnostic et d’escalade
- Cela accélère considérablement les diagnostics futurs
Mises à jour et sécurité :
- Appliquez régulièrement les mises à jour (serveur web, PHP, CMS, plugins)
- Configurez le WAF de manière équilibrée (sécurité sans blocages excessifs)
- Prévoyez une architecture robuste avec redondance et haute disponibilité
Architectures avancées : l’auto-scaling, le serverless ou Kubernetes peuvent améliorer l’absorption des pics de charge lorsqu’ils sont correctement conçus. Ils ne suppriment toutefois pas les risques de 502 et introduisent leurs propres limites, timeouts et contraintes de configuration.
FAQ sur l’erreur 502 Bad Gateway
Une erreur 502 Bad Gateway peut-elle venir de mon ordinateur ?
Dans la grande majorité des cas, le navigateur n’est pas la cause d’un véritable 502 : le code est généré par une passerelle ou un proxy. Un VPN, un proxy local, un antivirus réseau ou une infrastructure d’entreprise peut toutefois faire partie de cette chaîne.
Pour isoler un problème local, testez le site depuis un autre réseau ou sans ces intermédiaires. Si l’erreur apparaît pour plusieurs utilisateurs, le diagnostic doit se concentrer sur le serveur, le CDN, le proxy ou l’hébergement.
Combien de temps une erreur 502 dure-t-elle en général ?
Il n’existe pas de durée standard pour une erreur 502. Un redémarrage de service ou un pic de charge peut produire un incident très court, tandis qu’une mauvaise configuration, un backend indisponible ou une saturation récurrente peut prolonger le problème.
Une erreur répétée ou persistante mérite donc un diagnostic fondé sur les logs, l’état des services et la chaîne proxy → serveur d’origine, plutôt qu’un seuil de temps arbitraire.
Quelle est la différence entre les erreurs 500, 502, 503 et 504 ?
Ces quatre codes appartiennent à la famille HTTP 5xx, mais correspondent à des situations différentes :
– 500 Internal Server Error : le serveur rencontre une condition inattendue qui l’empêche de traiter la requête.
– 502 Bad Gateway : une passerelle ou un proxy reçoit une réponse invalide d’un serveur en amont.
– 503 Service Unavailable : le service est temporairement indisponible, par exemple en raison d’une surcharge ou d’une maintenance.
– 504 Gateway Timeout : la passerelle ne reçoit pas à temps la réponse attendue du serveur en amont.
L’erreur 502 Bad Gateway peut-elle nuire durablement à mon référencement Google ?
Des erreurs 502 ponctuelles n’entraînent pas automatiquement une perte de position. En revanche, des réponses 5xx répétées ou durables empêchent Googlebot d’explorer correctement les URL concernées ; Google peut réduire temporairement son rythme d’exploration et, si l’indisponibilité persiste, certaines URL peuvent finir par sortir de l’index.
Après un incident, surveillez le rapport Indexation des pages et les Statistiques sur l’exploration dans Search Console, puis vérifiez le retour durable de réponses HTTP valides.
Dois-je contacter mon hébergeur en cas d’erreur 502 répétée ?
Oui, lorsque l’erreur touche plusieurs utilisateurs ou persiste après les vérifications applicatives de base, le support de l’hébergeur ou du CDN peut aider à isoler la cause. Transmettez l’horodatage des erreurs, les URL concernées, des captures du message et, lorsque vous y avez accès, les extraits de logs correspondants.
L’objectif est d’identifier précisément si le problème vient des ressources, du réseau, du proxy, de PHP-FPM ou d’un autre composant de l’infrastructure avant de modifier les réglages ou de changer d’offre.
Conclusion
L’erreur 502 Bad Gateway est avant tout un symptôme : celui d’un problème de communication entre serveurs dans votre infrastructure web. Qu’il s’agisse d’une surcharge temporaire, d’une configuration défaillante ou d’un bug applicatif, cette erreur mérite une attention particulière lorsqu’elle se répète.
Pour les utilisateurs, les gestes simples — recharger la page, vider le cache, tester en navigation privée — permettent souvent de contourner un problème ponctuel. Pour les propriétaires de sites et administrateurs, une démarche structurée de diagnostic (logs, configuration, code, ressources, CDN/DNS) est essentielle pour identifier et résoudre le problème rapidement.
La solution durable repose sur une surveillance continue, une infrastructure dimensionnée selon la charge réelle et une méthode de diagnostic documentée. Pour un site WordPress, cette organisation s’intègre naturellement à une maintenance suivie et à une capacité d’intervention rapide, notamment grâce à l’assistance WordPress 7j/7 proposée par Evolyon.