Erreur 502, 503, 504 : le serveur abandonne en cours de route
Contrairement à une erreur 500, ces trois codes ne viennent presque jamais du code de votre site. Ils sont émis par l’intermédiaire placé devant lui — répartiteur, cache, proxy de l’hébergeur — qui a attendu une réponse et a fini par renoncer. Savoir lequel a renoncé, et au bout de combien de temps, mène directement à la cause.
Ce que dit chaque code
502 : l’intermédiaire a joint le service applicatif, mais celui-ci a renvoyé une réponse invalide ou s’est terminé brutalement. Typiquement, le processus qui exécute PHP a été tué en cours d’exécution, par manque de mémoire ou par le gestionnaire de ressources de l’hébergeur.
503 : le service est indisponible ou refuse de nouvelles demandes. C’est le code d’un service arrêté, d’une file d’attente pleine, ou d’un mode maintenance actif. C’est aussi celui qu’un CMS renvoie volontairement pendant une mise à jour.
504 : l’intermédiaire a bien transmis la demande, mais aucune réponse n’est arrivée dans le délai autorisé. Le site travaille encore quand la connexion est coupée. C’est le code d’une opération trop longue, pas d’une opération impossible.
Isoler l’opération trop longue
-
Chronométrer l’échec
Notez le nombre de secondes avant l’apparition de l’erreur. Un chiffre rond et toujours identique — 30, 60, 120, 300 — est une limite configurée, pas un hasard. Ce chiffre identifie souvent le composant qui coupe.
-
Repérer les pages concernées
Une seule page d’administration, un export, un import, une recherche : l’erreur suit presque toujours une opération lourde précise, pas le site entier.
-
Vérifier si le travail se fait quand même
Un import qui renvoie une erreur 504 mais dont les produits apparaissent quand même en base signifie que le traitement continue côté serveur. Le relancer double alors les données.
-
Regarder les tâches planifiées
Une tâche automatique lourde qui se déclenche à heure fixe peut saturer le serveur et provoquer des 502 ou 504 sur les pages publiques pendant sa durée.
-
Demander les limites en vigueur
Durée maximale d’exécution, mémoire allouée, nombre de processus simultanés : ces trois valeurs déterminent le seuil, et l’hébergeur les communique.
Les causes que je rencontre le plus
- Un import ou un export de catalogue lancé d’un seul bloc sur plusieurs milliers de lignes.
- Une page d’administration qui liste tous les enregistrements sans pagination réelle, alors que la table a grossi pendant des années.
- Un appel à un service externe — transporteur, logiciel de gestion, fournisseur — qui ne répond plus, et dont l’attente bloque le chargement de la page entière.
- Un pic de trafic sur un hébergement mutualisé, où le nombre de processus simultanés est plafonné.
- Une requête en base sans index adapté, qui parcourt une table entière à chaque affichage.
Continuer sur la bonne page
-
Choisir un hébergement e-commerce
Quelles limites regarder quand les ressources sont réellement en cause.
-
Diagnostiquer une boutique lente
Si les erreurs accompagnent une lenteur générale, la méthode de mesure.
-
Tâches cron qui ne s’exécutent pas
Quand une tâche planifiée sature le serveur ou ne se termine jamais.
-
Les index de base de données
Pourquoi une requête sans index fait basculer une page dans le délai dépassé.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.