Erreur 500 : trouver la cause dans les journaux du serveur

Une erreur 500 ne se corrige pas depuis le navigateur, elle se lit d’abord dans les journaux. Pour un administrateur avec accès SSH, la bonne méthode consiste à faire apparaître le message réel derrière la page blanche, puis à remonter la chaîne des causes dans un ordre strict : serveur web, PHP-FPM, journal système, droits, configuration, mémoire, délais et base de données. C’est aussi la manière la plus rapide de distinguer un code erreur 500 applicatif d’une erreur interne du serveur 500 déclenchée en amont de l’application, par la configuration du serveur web, les droits ou le service PHP-FPM.

Les chemins exacts dépendent de la distribution, du serveur web et de l’hébergement, mais les emplacements courants suffisent pour démarrer sans tâtonner. Si vous administrez déjà un serveur, cette routine de lecture des logs fait gagner du temps sur presque toutes les pannes web.

Trouver le bon journal avant de toucher à la configuration

Devant une erreur HTTP 500, la première question n’est pas pourquoi, mais où le message a été écrit. Les emplacements dépendent de la famille de distribution :

Consultez-les dans cet ordre :

• Journal d’erreurs du serveur web : c’est souvent là que remonte l’erreur PHP elle-même, sous la forme FastCGI sent in stderr sur Nginx ou AH01071: Got error 'PHP message: …' sur Apache.
• Journal applicatif PHP : les erreurs fatales peuvent aussi être écrites dans le fichier défini par la directive error_log (php.ini ou pool FPM, à vérifier avec php -i | grep error_log), ou dans wp-content/debug.log sur WordPress si WP_DEBUG_LOG est actif.
• Journal PHP-FPM : il contient surtout les messages du gestionnaire de processus (workers tués, pool saturé), rarement l’erreur applicative.
• Journal système : journalctl -xe ou journalctl -u <service> avec le nom de service adapté ci-dessus.

Ouvrez ensuite le journal en suivi temps réel dans un terminal, puis rechargez la page fautive dans le navigateur pour redéclencher l’erreur. Sur Debian/Ubuntu :

• tail -f /var/log/apache2/error.log (ou /var/log/nginx/error.log)
• journalctl -fu php8.2-fpm

Sur RHEL et dérivés, remplacez par /var/log/httpd/error_log et journalctl -fu php-fpm. La ligne qui s’ajoute au moment du rechargement est celle qui compte. Sans cette corrélation temporelle, on finit souvent par corriger un ancien message sans lien avec la panne actuelle.

Sur WordPress, cette étape évite beaucoup d’essais inutiles. Une erreur 500 WordPress peut venir d’un plugin, d’un thème, de PHP-FPM, d’un .htaccess cassé ou d’un dépassement mémoire. Le journal, lui, tranche rapidement. Pour pouvoir revenir rapidement à un état sain, il vaut mieux prévoir des sauvegardes automatiques du serveur testées, pas seulement activées.

Lire ce que dit le journal, sans interpréter trop vite

Le message exact compte plus que le code 500 lui-même. Voici les formulations fréquentes et la suite logique à vérifier.

Ne corrigez rien tant que vous n’avez pas une ligne explicite. Certains messages trompent sur le code : upstream sent too big header, connect() failed vers le socket FastCGI ou un PHP-FPM arrêté renvoient une 502, pas une 500, et relèvent d’un autre diagnostic. Si le journal d’erreurs reste vide alors que le journal d’accès montre bien un 500, c’est en général l’application elle-même qui renvoie ce code en masquant l’erreur : activez sa journalisation (log_errors = On, WP_DEBUG_LOG sur WordPress) plutôt que de chercher côté serveur.

Vérifier les droits sur les fichiers et le contexte d’exécution

Les erreurs de permissions provoquent des 500 plus souvent qu’on ne le croit, surtout après un déploiement manuel, une restauration ou un transfert entre machines. Les contrôles utiles sont factuels :

• ls -l pour le propriétaire et le groupe
• find pour repérer des permissions incohérentes
• ps aux | grep php-fpm pour voir sous quel utilisateur tourne PHP-FPM
• namei -l chemin/fichier pour vérifier les droits sur chaque répertoire parent

Sur un site PHP, le problème ne vient pas toujours du fichier appelé, et tous les défauts de droits ne donnent pas une 500 : un répertoire parent sans bit d’exécution renvoie le plus souvent une 403 sur Apache, ou Primary script unknown sous PHP-FPM. La 500 apparaît surtout quand PHP échoue à écrire là où l’application en a besoin (cache, uploads, sessions) et s’arrête sur une erreur fatale. Le journal mentionne alors Permission denied avec le chemin exact. C’est ce chemin qu’il faut suivre, pas une supposition sur le dossier public.

Sur RHEL, AlmaLinux ou Rocky, pensez aussi à SELinux : des droits Unix corrects ne suffisent pas si le contexte de sécurité du fichier est mauvais. Vérifiez avec ls -Z et cherchez les refus avec ausearch -m avc -ts recent.

Si votre pile change selon l’OS ou le panneau d’administration, les comportements des services et des permissions varient aussi selon que vous êtes sur un serveur Linux ou Windows, d’où l’intérêt d’identifier d’abord le processus réel qui exécute le code.

Contrôler .htaccess, vhost et configuration du serveur web

Quand le journal mentionne une erreur de syntaxe, un module inconnu ou une directive interdite, la cause se situe avant même l’exécution de l’application. Sur Apache, un .htaccess invalide peut produire directement une erreur interne du serveur 500. Les cas fréquents :

• directive non autorisée en .htaccess
• module requis non chargé
• copier-coller d’une configuration prévue pour une autre version
• encodage ou caractère parasite dans le fichier

Les commandes de validation doivent précéder tout rechargement ou redémarrage du service :

• apachectl -t ou httpd -t
• nginx -t

Attention : apachectl -t ne vérifie que la configuration principale et les VirtualHost, pas les fichiers .htaccess, qui sont lus à chaque requête. Pour un .htaccess, la validation passe par le journal d’erreurs au rechargement de la page.

Nginx ne lit pas de .htaccess et génère rarement une 500 lui-même : le cas typique est une boucle de réécriture, signalée par rewrite or internal redirection cycle. Un socket FastCGI introuvable ou un PHP-FPM arrêté donnent une 502, et une 500 servie par Nginx vient le plus souvent de PHP qui a renvoyé ce code. Là encore, le fichier d’erreur du serveur web vous dira si la panne se situe dans la configuration ou dans l’amont.

Si le site est sous CMS, désactiver à l’aveugle les modules via le back-office n’aide pas quand l’accès web est coupé. Sur WordPress, passez par SSH : wp plugin deactivate --all avec WP-CLI, ou renommez temporairement wp-content/plugins, puis réactivez les extensions une à une en gardant le journal ouvert. Si l’extension fautive s’avère aussi obsolète, c’est l’occasion de revoir comment sécuriser un site WordPress.

Remonter ensuite vers PHP : mémoire épuisée, délai dépassé, crash

Dès que le serveur web relaie une erreur PHP, lisez le message PHP complet, dans le journal du serveur web ou le journal applicatif. Les deux messages les plus parlants sont :

• Allowed memory size of N bytes exhausted : la mémoire attribuée au processus PHP est insuffisante pour cette exécution.
• Maximum execution time of N seconds exceeded : le script ne termine pas dans le délai autorisé.

Ces erreurs ne donnent pas toujours la cause finale. Une mémoire épuisée peut signaler une boucle, une génération d’image trop lourde, un import massif ou une requête qui ramène trop de données. Un timeout peut venir d’un appel HTTP sortant, d’une base lente, d’un verrou ou d’une extension externe.

Pour confirmer, regardez :

• la ligne PHP fautive et le fichier mentionné
• la valeur de memory_limit
• les workers FPM actifs, et le message server reached pm.max_children dans le journal PHP-FPM (une saturation donne plutôt des 502 ou 504)
• les requêtes longues côté base

Si les 500 apparaissent seulement en charge, il faut aussi examiner la capacité du serveur web et de PHP-FPM. Une pile trop tendue peut exposer des défauts applicatifs invisibles à faible trafic. À ce stade, optimiser les performances du site aide autant au diagnostic qu’à la prévention.

Vérifier la connexion à la base et les dépendances amont

Quand le journal parle de connexion refusée, d’identifiants invalides ou de serveur indisponible, le 500 n’est qu’un symptôme applicatif. Les vérifications utiles restent simples :

• le service MySQL ou MariaDB tourne-t-il vraiment ?
• les identifiants dans la configuration sont-ils cohérents ?
• le socket ou le port indiqué existe-t-il ?
• la résolution DNS locale renvoie-t-elle l’hôte attendu ?

Un message comme SQLSTATE[HY000] [2002] ou Access denied for user oriente tout de suite la recherche. Et si l’application masque l’erreur SQL et renvoie seulement un 500, activez sa journalisation : le message n’apparaîtra que dans le journal applicatif. Chercher dans le code avant d’avoir lu le message complet fait perdre du temps.

Distinguer un 500 applicatif d’un 500 renvoyé par le serveur lui-même

C’est la séparation la plus utile pour aller vite. Un code erreur 500 applicatif signifie que le serveur web a pu transmettre la requête à l’application, mais que celle-ci a échoué. Un 500 serveur signifie que l’échec arrive plus tôt, avant l’exécution du code : directive invalide, .htaccess cassé, boucle de réécriture, droits empêchant l’exécution.

Vous pouvez les distinguer avec trois indices :

• Le journal touché : si tout se passe dans PHP-FPM ou dans l’application, la panne est applicative. Si Apache ou Nginx se plaint d’une directive ou d’une réécriture, la panne est côté serveur. Un backend PHP-FPM absent, lui, donne une 502.
• Le moment de l’échec : avant exécution du script, on est plutôt côté serveur. Pendant l’exécution, plutôt côté application.
• La répétabilité : si une URL précise casse toujours, cherchez le code ou la requête liée. Si tout le site renvoie 500 après un rechargement de configuration, cherchez la couche web ou PHP.

Cette distinction sert aussi en prévention. Un bon niveau de sécurité des serveurs réduit les modifications hasardeuses de configuration et facilite l’audit lorsqu’une panne survient après mise à jour ou intrusion.

Les limites de la méthode

Lire les journaux règle une grande partie des pannes, mais pas toutes. Certains hébergements mutualisés exposent peu ou mal les logs, et certaines applications masquent encore l’erreur réelle derrière plusieurs couches. Autre limite : un journal peut donner le symptôme immédiat sans dévoiler la cause racine, par exemple une mémoire épuisée due à une requête SQL lente ou à une extension qui fuit. Enfin, sur un serveur très actif, le volume d’événements rend la corrélation plus délicate si vous ne filtrez pas par service, heure et PID.

La bonne pratique reste donc la même : reproduire, lire la ligne exacte, confirmer avec une commande de test, puis corriger une seule variable à la fois.

Questions fréquentes sur l'erreur 500

Comment corriger l’erreur 500 ?

Depuis le serveur, corrigez d’abord la cause écrite dans les journaux, pas le code 500 lui-même. Suivez le journal d’erreurs du serveur web avec tail -f, rechargez la page pour redéclencher l’erreur, puis consultez le journal applicatif PHP et enfin journalctl si rien n’apparaît. Les causes courantes sont des droits insuffisants, un .htaccess ou une configuration invalide, une mémoire PHP épuisée, un délai dépassé ou une connexion base de données en échec. Validez ensuite la configuration avec nginx -t ou apachectl -t avant tout rechargement, en sachant que ce test ne couvre pas les fichiers .htaccess.

Que signifie l’erreur 500 sur un site web ?

Une erreur 500 signifie qu’une requête a bien atteint le serveur, mais qu’un échec interne a empêché de renvoyer une réponse normale. Ce code ne désigne pas une cause unique. Il peut venir de l’application, par exemple une erreur PHP fatale ou une requête SQL cassée, ou du serveur lui-même, par exemple une directive invalide, un .htaccess cassé ou des permissions incohérentes. Un backend PHP-FPM indisponible renvoie en revanche une 502. Pour un administrateur, la seule définition utile est celle donnée par les journaux au moment exact de l’échec.

Comment résoudre l’erreur HTTP 500 dans Google Chrome ?

Chrome n’est presque jamais la cause d’une erreur HTTP 500 quand vous administrez le serveur. Le navigateur n’affiche que la réponse reçue. La résolution se fait côté machine distante : consultez les journaux Nginx ou Apache, puis ceux de PHP-FPM et du système. Si vous devez tester depuis votre poste, utilisez aussi les outils réseau du navigateur ou curl -I pour confirmer le statut, mais la correction passe par les logs, la configuration et les services du serveur.