502 Bad Gateway, 500, 403 et 404 : que corriger

Une erreur 502 Bad Gateway signale surtout une rupture entre proxy, CDN et serveur d’origine. Les erreurs 500, 403 et 404 pointent ailleurs : application, droits ou URL absente. La bonne réaction consiste à identifier la couche fautive avant de vider les caches au hasard.

Lire le code avant de toucher au serveur

Le piège classique consiste à mettre toutes les pages d’erreur dans le même sac : “l’hébergement est en panne”. C’est confortable, mais trop grossier. Le code HTTP donne déjà le premier atelier à inspecter : passerelle, application, autorisation ou routage.

La requête 502 bad gateway est fortement demandée dans le corpus de recherche supervisé. Rien d’étonnant : l’erreur apparaît souvent sur un site public, avec peu d’indices pour le visiteur. Le propriétaire doit donc séparer l’écran visible du journal serveur. Diagnostic avant recommandation.

Cette lecture évite deux mauvais réflexes : redémarrer toute l’infrastructure pour une URL supprimée, ou accuser le navigateur quand le proxy ne reçoit plus de réponse valide. Un serveur se dépanne comme un atelier : on regarde d’abord où la chaîne s’est arrêtée.

502 Bad Gateway : le cas CDN et origine

Une 502 apparaît quand un intermédiaire parle au nom du site mais ne reçoit pas une réponse exploitable. Avec un CDN comme Cloudflare, la panne peut venir de l’origine, d’un certificat TLS, d’un pare-feu, d’un port fermé ou d’un délai côté application.

Ne commencez pas par purger le cache. Si l’origine ne répond pas, la purge ne répare rien ; elle peut même rendre la panne plus visible. Testez d’abord l’adresse d’origine, puis le certificat, puis la règle qui autorise le CDN à joindre le serveur.

Pour un site hébergé chez OVHcloud, Infomaniak, o2switch ou IONOS France, le support n’a pas besoin d’un simple “ça ne marche pas”. Il lui faut l’heure, l’URL, l’adresse IP cliente si disponible, et la couche déjà testée.

500, 403, 404 : ne pas confondre les familles

Une 500 est une panne interne. Elle se traite dans l’application, l’environnement PHP, Node, Python, la base de données ou le quota de ressources. Un thème WordPress cassé, une migration incomplète ou une variable d’environnement manquante peuvent produire le même écran.

Une 403 est un refus. Elle peut être volontaire, par exemple une zone privée, ou accidentelle après un changement de droits. Elle peut aussi venir d’un pare-feu applicatif trop strict, d’une règle anti-DDoS ou d’un pays bloqué.

Une 404 est une absence. Elle peut être bénigne si l’URL n’existe plus. Elle devient coûteuse quand une refonte casse des liens internes, des redirections, des pages produits ou des ressources chargées par le thème.

Visiteur ou propriétaire : la réponse change

Pour un visiteur, le diagnostic reste limité. Rechargez la page, essayez un autre réseau et vérifiez si le problème touche plusieurs sites. Si seule une page échoue, le propriétaire doit intervenir.

Pour le propriétaire, la bonne question est plus sèche : quelle couche a changé juste avant l’erreur ? Déploiement, certificat, DNS, règle CDN, extension, migration de base, quota CPU, sauvegarde restaurée ou changement de droits : l’historique court vaut mieux qu’une collection de recettes.

À noter avant d’ouvrir l’interface d’administration :

• Changement récent : déploiement, certificat, DNS ou règle CDN.
• Portée visible : une page, un répertoire, tout le domaine ou seulement l’API.
• Preuve disponible : journal applicatif, métrique de charge ou réponse de l’origine.

Chez un hébergeur mutualisé, vous dépendez souvent du support pour lire certains journaux. Sur un VPS ou un serveur dédié, vous avez plus de preuves, mais aussi plus de responsabilité. Scaleway, OVHcloud et Infomaniak couvrent des usages différents ; le bon choix dépend de votre besoin d’accès aux journaux et aux métriques.

Quand changer de fournisseur devient rationnel

Changer d’hébergeur pour une seule erreur est rarement rationnel. En revanche, changer devient défendable si le fournisseur ne donne pas accès aux journaux, masque les limites de ressources, ferme les demandes sans cause, ou facture des sauvegardes inutilisables lors d’une restauration réelle.

Le signal le plus fiable n’est pas la promesse d’uptime. C’est la capacité à isoler vite la panne : journaux lisibles, métriques de charge, restauration testable, support qui distingue CDN, application et serveur d’origine. Demandez le plan de panne avant de signer pour le plan marketing.

Fraîcheur et méthode

Cette base de diagnostic s’appuie sur les codes HTTP publics et sur le contexte HostScout des fournisseurs francophones et internationaux suivis. Les données de recherche montrent une demande forte autour de 502 bad gateway, mais l’article privilégie le triage opérationnel plutôt qu’une répétition des définitions génériques.