▶ Structure technique dédiée — Expertise web & mobile — Basée en France

Erreurs serveur 500, 502, 503, 504 : comprendre, diagnostiquer et réagir

Votre site affiche une erreur 500, 502, 503 ou 504. L'écran est blanc ou affiche un message cryptique. Vos visiteurs repartent, votre activité est à l'arrêt. Ces quatre codes d'erreur représentent la grande majorité des pannes serveur — et chacun raconte une histoire technique différente. Ce guide vous explique ce que chaque erreur signifie concrètement, quelles sont les causes probables selon votre environnement (WordPress, Symfony, serveur dédié), quels sont les premiers gestes utiles et à quel moment il faut passer la main à un professionnel.

Tester votre situation en 1 minute Besoin d'une intervention immédiate ?
http · 5xx · diagnostic rapide

500

Internal Server Error — application ou config

502

Bad Gateway — PHP-FPM / proxy

503

Unavailable — maintenance, surcharge

504

Gateway Timeout — requête trop lente

5xx · Le problème est côté serveur, pas côté visiteur
4xx et 5xx

Pourquoi ces erreurs sont différentes des autres

Le code HTTP indique si la défaillance est côté visiteur (4xx) ou côté infrastructure / application (5xx).

Toutes les erreurs HTTP ne se valent pas. Les erreurs 4xx (403, 404…) signifient que le problème vient du côté visiteur : mauvaise URL, accès interdit, page supprimée. Les erreurs 5xx, elles, indiquent que le problème vient du serveur. Le visiteur a fait une demande correcte, mais le serveur n'a pas réussi à y répondre.

C'est une distinction importante : une erreur 5xx signifie que quelque chose dysfonctionne dans votre infrastructure, votre code ou votre hébergement. Ce n'est pas un problème de navigateur ou de réseau côté visiteur.

Les quatre erreurs les plus fréquentes dans cette famille sont les codes 500, 502, 503 et 504. Elles couvrent la quasi-totalité des pannes serveur rencontrées en production.

Erreur 500

Internal Server Error

Ce que ça signifie

Le serveur a bien reçu la requête du visiteur, mais quelque chose l'a empêché de la traiter. C'est l'erreur la plus courante et la plus vague : le serveur dit simplement « quelque chose a mal tourné » sans préciser quoi.

En pratique, c'est presque toujours un problème applicatif — du code qui plante, une configuration qui bloque ou une ressource manquante.

Causes fréquentes selon l'environnement

WordPress / PrestaShop

  • Fichier .htaccess corrompu ou contenant des règles conflictuelles
  • Plugin ou thème qui provoque une erreur fatale PHP (souvent après une mise à jour)
  • Limite mémoire PHP atteinte (memory_limit trop basse pour un plugin gourmand)
  • Version de PHP incompatible avec un plugin ou le CMS lui-même
  • Fichier wp-config.php mal configuré (identifiants base de données incorrects, constante mal définie)

Symfony / PHP custom

  • Exception non interceptée dans le code applicatif
  • Fichier .env absent ou mal configuré (connexion base de données, paramètres applicatifs)
  • Cache applicatif corrompu (var/cache/ à vider)
  • Dépendance Composer manquante ou incompatible après un déploiement
  • Droits d'écriture insuffisants sur les dossiers var/log/ ou var/cache/

Serveur (Apache / Nginx / Linux)

  • Espace disque plein (les logs, les sauvegardes ou les sessions PHP peuvent saturer un disque en quelques jours)
  • Fichier de configuration Apache/Nginx avec une directive invalide
  • Module PHP manquant ou désactivé après une mise à jour système
  • Processus PHP-FPM qui ne démarre pas correctement

Premiers gestes

Si vous avez un accès FTP ou SSH :

  1. Consultez les logs d'erreur — c'est le geste le plus utile. Sous Apache : /var/log/apache2/error.log. Sous Nginx : /var/log/nginx/error.log. Sur WordPress avec un hébergeur mutualisé, activez le debug dans wp-config.php (define('WP_DEBUG', true); define('WP_DEBUG_LOG', true);) et consultez wp-content/debug.log.
  2. Si WordPress : renommez le fichier .htaccess en .htaccess_backup et rechargez le site. Si le site revient, regénérez les permaliens depuis Réglages > Permaliens.
  3. Si WordPress : renommez le dossier /wp-content/plugins/ en /wp-content/plugins_disabled/ pour désactiver tous les plugins d'un coup. Si le site revient, réactivez-les un par un pour identifier le coupable.
  4. Si Symfony : videz le cache avec php bin/console cache:clear --env=prod. Si le cache ne se vide pas, supprimez manuellement le dossier var/cache/prod/.

Ce qu'il ne faut pas faire

  • Ne supprimez jamais de fichiers sans avoir une sauvegarde.
  • Ne changez pas la version de PHP « pour essayer » — une incompatibilité peut casser davantage de choses.
  • Ne modifiez pas les fichiers de configuration serveur (Apache, Nginx) si vous n'êtes pas certain de ce que vous faites. Une erreur de syntaxe peut rendre le serveur entièrement inaccessible.

Quand escalader

Si vous n'avez pas accès aux logs, si l'erreur persiste après les premiers gestes, ou si vous ne comprenez pas le message d'erreur dans les logs : transmettez vos observations (capture d'écran, heure de début, changement récent identifié) à un prestataire technique.

Erreur 502

Bad Gateway

Ce que ça signifie

Le serveur web (Nginx, Apache) a bien reçu la requête et a essayé de la transmettre à l'application (PHP-FPM, Node.js, Gunicorn…), mais cette application n'a pas répondu correctement. Le serveur web joue ici le rôle d'intermédiaire (proxy), et c'est cet intermédiaire qui vous dit : « je n'ai pas réussi à obtenir une réponse valide. »

En termes simples : la porte d'entrée fonctionne, mais personne ne répond derrière.

Causes fréquentes selon l'environnement

WordPress / PrestaShop

  • PHP-FPM a crashé ou est surchargé (trop de requêtes simultanées, plugin qui génère des processus longs)
  • Timeout entre Nginx et PHP-FPM (une requête met trop longtemps à s'exécuter, typiquement un import WooCommerce ou une requête SQL lourde)
  • Hébergeur mutualisé qui limite les ressources PHP allouées à votre site

Symfony / PHP custom

  • Processus PHP-FPM saturé ou en erreur (tous les workers sont occupés ou bloqués)
  • Requête longue non optimisée (import de données, calcul lourd, appel API externe qui ne répond pas)
  • Mauvaise configuration du pool PHP-FPM (nombre de workers insuffisant pour le trafic)
  • Script qui boucle indéfiniment et consomme tous les workers disponibles

Serveur (Apache / Nginx / Linux)

  • PHP-FPM arrêté ou qui ne redémarre pas après un crash
  • Socket PHP-FPM mal configurée (Nginx essaie de communiquer sur un chemin qui n'existe pas)
  • Reverse proxy mal configuré (l'upstream n'est pas joignable)
  • Mémoire RAM saturée — le système a tué le processus PHP-FPM (OOM Killer)

Premiers gestes

  1. Si hébergement mutualisé : contactez le support de l'hébergeur. Dans la majorité des cas, le problème est de leur côté (ressources partagées, PHP-FPM mutualisé). Demandez-leur de vérifier l'état du service PHP.
  2. Si VPS ou serveur dédié avec accès SSH : vérifiez si PHP-FPM tourne avec sudo systemctl status php8.x-fpm (remplacez 8.x par votre version). S'il est arrêté, redémarrez-le avec sudo systemctl restart php8.x-fpm.
  3. Vérifiez la mémoire disponible avec free -h. Si la RAM est saturée, un processus a probablement consommé toutes les ressources.
  4. Consultez les logs Nginx (/var/log/nginx/error.log) — le message d'erreur précisera si c'est un timeout, un refus de connexion ou un socket introuvable.

Quand escalader

Si PHP-FPM redémarre mais crashe à nouveau quelques minutes plus tard, si la RAM est régulièrement saturée, ou si le problème survient à chaque pic de trafic : le serveur est probablement sous-dimensionné ou l'application a un problème de performance qui nécessite un diagnostic approfondi.

Erreur 503

Service Unavailable

Ce que ça signifie

Le serveur est en ligne mais temporairement incapable de traiter les requêtes. C'est souvent une situation volontaire (maintenance) ou une surcharge passagère. Contrairement à la 502 où le proxy n'obtient pas de réponse, ici le serveur dit explicitement : « je suis là, mais je ne peux pas vous servir pour le moment. »

Causes fréquentes selon l'environnement

WordPress / PrestaShop

  • Mode maintenance activé (fichier .maintenance à la racine, créé automatiquement pendant les mises à jour WordPress — parfois il n'est pas supprimé si la mise à jour échoue)
  • Plugin de maintenance actif (coming soon, maintenance mode)
  • Hébergeur qui a désactivé le site (dépassement de quota, facturation, abus détecté)
  • Trop de connexions simultanées à la base de données MySQL

Symfony / PHP custom

  • Page de maintenance déployée volontairement (fichier maintenance.html servi par le serveur web)
  • Processus de déploiement en cours (le site est temporairement indisponible pendant la mise en production)
  • Rate limiting côté applicatif ou serveur qui bloque les requêtes
  • Base de données surchargée ou inaccessible

Serveur (Apache / Nginx / Linux)

  • Tous les workers Apache ou PHP-FPM sont occupés (MaxClients / pm.max_children atteint)
  • Attaque DDoS en cours — le serveur est submergé de requêtes
  • Cron job ou script de sauvegarde qui monopolise les ressources
  • Hébergeur qui effectue une maintenance sur l'infrastructure

Premiers gestes

  1. Vérifiez si la 503 est liée à une maintenance programmée. Sur WordPress : cherchez un fichier .maintenance à la racine du site via FTP et supprimez-le. Sur Symfony ou un serveur custom : vérifiez s'il existe une page de maintenance active dans la config Nginx/Apache.
  2. Vérifiez le statut de votre hébergeur. La plupart des hébergeurs ont une page de statut publique (status.ovhcloud.com, status.scaleway.com…). Si une maintenance infrastructure est en cours, il n'y a rien à faire de votre côté.
  3. Si VPS/dédié : vérifiez la charge serveur avec top ou htop. Si le load average est anormalement élevé (supérieur au nombre de CPU), identifiez le processus responsable.
  4. Vérifiez que la base de données est accessible. Un simple test de connexion MySQL peut confirmer ou exclure cette piste.
Point important : l'erreur 503 est souvent temporaire par nature. Si elle se résout seule en quelques minutes, c'était probablement un pic de charge passager ou une maintenance courte. En revanche, si elle persiste au-delà de 15-20 minutes sans maintenance annoncée, il y a un problème sous-jacent à investiguer.

Quand escalader

Si la 503 dure plus de 20 minutes, si elle revient régulièrement aux mêmes heures (signe d'un cron ou d'un pic de trafic récurrent non absorbé), ou si l'hébergeur ne signale aucune maintenance de son côté.

Erreur 504

Gateway Timeout

Ce que ça signifie

Le serveur web a transmis la requête à l'application (PHP-FPM, base de données, API externe…), mais n'a pas reçu de réponse dans le délai imparti. Il a attendu, puis abandonné. C'est un timeout — littéralement, le temps a expiré.

La 504 est souvent confondue avec la 502. La différence : en 502, l'application répond mal ou pas du tout. En 504, l'application met trop longtemps à répondre et le proxy perd patience.

Causes fréquentes selon l'environnement

WordPress / PrestaShop

  • Requête SQL très lente (base de données volumineuse, plugin qui exécute des requêtes non optimisées)
  • Import/export de données volumineux (WooCommerce, catalogue produit, migration)
  • Plugin qui fait un appel API externe lent (passerelle de paiement, service tiers qui ne répond pas)
  • Page d'administration qui charge trop de données en une seule requête

Symfony / PHP custom

  • Requête SQL non optimisée ou absence d'index sur une table volumineuse
  • Appel à une API tierce qui ne répond pas (sans timeout configuré côté application, le processus attend indéfiniment)
  • Traitement batch lancé via une requête HTTP au lieu d'une commande CLI
  • Transaction base de données bloquée (deadlock ou verrou non libéré)

Serveur (Apache / Nginx / Linux)

  • Valeur proxy_read_timeout trop basse dans Nginx (défaut : 60 secondes)
  • max_execution_time PHP trop bas ou, à l'inverse, trop élevé (un script tourne pendant 5 minutes et bloque un worker)
  • Serveur MySQL surchargé ou mal configuré (requêtes en file d'attente)
  • Connexion réseau instable entre le serveur web et le serveur de base de données (architectures multi-serveurs)

Premiers gestes

  1. Identifiez quelle page ou action déclenche la 504. Si c'est une page spécifique (typiquement une page d'export, un tableau de bord avec beaucoup de données, ou un formulaire de recherche complexe), le problème est probablement une requête SQL ou un traitement trop lourd sur cette page.
  2. Si le problème est général (toutes les pages sont en 504) : vérifiez l'état de la base de données. MySQL est-il accessible ? Lancez un simple mysqladmin ping en SSH. Si MySQL ne répond pas, redémarrez-le avec sudo systemctl restart mysql.
  3. Vérifiez les slow query logs de MySQL si ils sont activés (/var/log/mysql/slow-query.log). Ils révèlent quelles requêtes prennent trop de temps.
  4. Si un appel API externe est en cause : testez l'API directement (via curl ou le navigateur). Si le service tiers est down, la 504 est un effet collatéral et reviendra à la normale quand le service sera rétabli.

Quand escalader

La 504 est rarement un problème qu'on résout avec un simple redémarrage. Elle révèle généralement un problème de performance sous-jacent (requête mal optimisée, infrastructure sous-dimensionnée, architecture non adaptée à la charge). Si elle se reproduit régulièrement, un audit de performance est recommandé.

Tableau récapitulatif

Code Signification Origine la plus fréquente Gravité typique
500 Le serveur ne peut pas traiter la requête Code applicatif, configuration, espace disque Variable — souvent résolvable rapidement
502 L'application ne répond pas au serveur web PHP-FPM crashé, socket cassée, RAM saturée Modérée à élevée
503 Le serveur est temporairement indisponible Maintenance, surcharge, DDoS Souvent temporaire — critique si persistante
504 L'application met trop longtemps à répondre Requête SQL lente, API tierce, timeout Élevée — souvent signe d'un problème de fond

Quand pouvez-vous résoudre seul, et quand faut-il de l'aide ?

Vous pouvez tenter de résoudre seul si :

  • Vous avez un accès FTP ou SSH à votre serveur.
  • Le problème est survenu juste après un changement identifiable (mise à jour, déploiement, modification de configuration).
  • L'erreur concerne un environnement WordPress et les gestes décrits ci-dessus correspondent à votre situation.
  • Vous comprenez le message d'erreur dans les logs.

Vous devriez faire appel à un professionnel si :

  • Vous n'avez pas accès aux logs serveur.
  • L'erreur persiste après les premiers gestes de diagnostic.
  • Le problème revient régulièrement (même heure, même page, même action).
  • Vous ne savez pas quelle version de PHP tourne, ni comment est configuré votre serveur.
  • Le site est en production avec un impact business direct (e-commerce, application métier, tunnel de conversion actif).
  • Plusieurs codes d'erreur apparaissent de manière intermittente — signe d'un problème d'infrastructure plus global.

Testez votre situation en 1 minute

Ce guide vous a aidé à comprendre les erreurs 5xx. Pour obtenir un diagnostic personnalisé adapté à votre code d'erreur, votre environnement et votre type d'hébergement, utilisez notre outil interactif.

Lancer le diagnostic

Votre site affiche une erreur et vous êtes bloqué ?

Transmettez-nous le code d'erreur, l'heure de début, les changements récents et une capture d'écran. Nous analysons la situation et vous orientons rapidement.

Décrire la situation Voir nos interventions techniques

Ressources complémentaires