Erreur 500 / page blanche : diagnostic méthodique

Une erreur 500 ne dit rien sur la cause. Le vrai travail, c'est d'ouvrir le bon log, reconnaître le motif et réparer ce qui doit l'être. Ce guide suit l'ordre dans lequel un admin chevronné regarde les choses : on lit avant de changer.

500, 502, 503, page blanche : qui fait quoi

• 500 Internal Server Error : le serveur a bien reçu la requête mais quelque chose a cassé pendant le traitement (fatal PHP, .htaccess invalide, permissions bloquantes). La cause est côté serveur, souvent dans votre code ou votre config.
• 502 Bad Gateway — le reverse proxy (Nginx, Cloudflare) a contacté le backend et n'a pas reçu de réponse exploitable. Sur Plesk, c'est typiquement PHP-FPM crashé ou qui a mis trop de temps.
• 503 Service Unavailable : le serveur refuse temporairement la requête (maintenance, surcharge, fail2ban, worker PHP saturé). Ça repart souvent seul, mais regardez quand même le log.
• Page blanche, aucun code HTTP affiché, le navigateur reçoit un corps vide. C'est presque toujours un fatal PHP avec display_errors = Off. On ne voit rien, mais le log en sait long.

Étape 1 : lire le bon log

Sur Plesk, chaque domaine a ses propres logs, isolés sous son user Linux. Trois façons d'y accéder :

Via l'interface Plesk

Domaine → Logs. Par défaut l'error log du domaine s'affiche, filtrable par type. Pratique quand on n'a pas de SSH.

Via SSH (recommandé)

# Log d'erreurs du domaine (Apache + PHP-FPM)
tail -f /var/www/vhosts/system/mon-domaine.fr/logs/error_log

# Log d'accès, utile pour corréler une requête
tail -f /var/www/vhosts/system/mon-domaine.fr/logs/access_ssl_log

Le -f suit le fichier en temps réel : laissez tourner, rechargez la page qui bug dans un autre onglet, l'erreur apparaît à la seconde près.

Erreurs PHP typiques

Mémoire dépassée

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted
(tried to allocate 20480 bytes) in /var/www/.../plugin.php on line 312

Le script a dépassé memory_limit. Augmentez-le dans Plesk (Paramètres PHP du domaine) ou dans un .user.ini à la racine :

memory_limit = 256M

Si la mémoire monte de façon absurde (1 Go pour afficher une page), c'est un plugin qui fuit : il faut isoler le coupable, pas masquer le symptôme.

Script trop long

PHP Fatal error:  Maximum execution time of 30 seconds exceeded

Augmenter max_execution_time fonctionne pour les imports et crons lourds. Pour une page web normale, 30 s est déjà énorme : cherchez plutôt la requête SQL ou l'appel HTTP qui traîne.

Fonction inconnue

PHP Fatal error:  Uncaught Error: Call to undefined function imagecreatetruecolor()

Une extension PHP manque (ici php-gd). Côté Plesk, elles s'activent par version de PHP dans les Paramètres PHP. Si l'extension n'est pas dispo, ouvrez un ticket Datacampus.

Voir aussi la doc dédiée : Limites PHP : memory_limit, upload_max_filesize, max_execution_time.

Erreurs Apache typiques

.htaccess cassé

[Wed Apr 24 10:12:05 2026] [alert] /var/www/vhosts/.../httpdocs/.htaccess:
Invalid command 'RequireAll', perhaps misspelled or defined by a module
not included in the server configuration

Numéro de ligne bien visible. Soit la directive n'existe pas, soit le module Apache correspondant (mod_rewrite, mod_headers, mod_expires) n'est pas chargé. Commentez la ligne fautive et rechargez.

Accès refusé

AH01630: client denied by server configuration: /var/www/vhosts/.../httpdocs/.env

Apache protège un fichier par une règle. Si c'est un fichier sensible (.env, .git), c'est sain. Si c'est un fichier légitime, revoyez les directives <Files> ou <Directory>.

SNI / SSL

AH02032: Hostname provided via SNI and hostname provided via HTTP have no
compatible SSL setup

Le certificat SSL ne correspond pas au domaine appelé. Vérifiez dans Plesk que le bon certificat est attribué au domaine (et pas à un alias).

Permissions cassées

(13)Permission denied: [client x.x.x.x:x] AH01620: cannot read directory
'/var/www/vhosts/mon-domaine.fr/httpdocs/wp-content/uploads/'

Un fichier ou dossier n'est pas lisible par l'utilisateur système du site. Classique après un rsync mal calibré, un upload manuel en root, ou une restauration de backup. Règle d'or : sur Plesk, les fichiers appartiennent à <user-du-site>:psacln, pas à root ni www-data.

Procédure complète et commandes chown/chmod dans la doc dédiée : Permissions Linux expliquées (chmod, chown, umask).

Page blanche = fatal PHP masqué

Si vous avez une page blanche et que le log de domaine est vide, activez temporairement l'affichage des erreurs. Sur WordPress, dans wp-config.php :

@ini_set('display_errors', 1);
error_reporting(E_ALL);
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

L'erreur s'écrira dans wp-content/debug.log. Sur un script PHP brut, un .user.ini à la racine suffit :

display_errors = On
error_reporting = E_ALL
log_errors = On

Connexion base de données

Sur WordPress, message typique Error establishing a database connection. Trois pistes :

1. Les identifiants dans wp-config.php (DB_USER, DB_PASSWORD, DB_HOST) correspondent-ils à la base Plesk ?
2. Le service MySQL tourne-t-il ? systemctl status mariadb (ou mysql). Sur Plesk mutualisé, c'est nous qui vérifions — ouvrez un ticket.
3. La base est-elle pleine ou corrompue ? mysqlcheck -u root -p --all-databases ou via phpMyAdmin dans Plesk.

Le test du .htaccess neutralisé

Une technique simple et redoutablement efficace quand on soupçonne .htaccess :

cd /var/www/vhosts/mon-domaine.fr/httpdocs
mv .htaccess .htaccess.bak

Rechargez la page. Si le site remonte (ou affiche une autre erreur, plus parlante), le .htaccess est coupable. Remettez-le (mv .htaccess.bak .htaccess) et cherchez la règle fautive, ligne par ligne. Voir : Les directives .htaccess essentielles.

Checklist express — 5 minutes

Dans cet ordre, vous couvrez 90 % des cas :

1. Le log : tail -n 100 /var/www/vhosts/system/<domaine>/logs/error_log. Lisez la dernière erreur avant de toucher à quoi que ce soit.
2. Les permissions, ls -la sur la racine. Tout doit appartenir au user du site, pas à root.
3. La mémoire — cherchez memory_limit ou Allowed memory dans le log. Si oui, montez à 256 M et relisez.
4. Le .htaccess : renommez en .htaccess.bak, rechargez. Diagnostic immédiat.
5. La base, pour une app qui en dépend (WordPress, Prestashop, app maison), vérifiez les credentials et que MySQL répond.

Si votre espace disque est au taquet, aucune des étapes ci-dessus ne suffira : consultez Disque saturé : identifier et libérer de l'espace.

Quand ouvrir un ticket Datacampus

Ouvrez un ticket (servicedesk.datacampus.fr) quand :

• Le log d'erreur du domaine est vide alors que le site renvoie une 500 ou une 502 — c'est probablement au niveau PHP-FPM ou Nginx, auxquels vous n'avez pas accès.
• L'erreur mentionne un module ou une extension PHP à activer côté serveur.
• Vous voyez des 503 récurrents et corrélés à des pics de trafic : il peut falloir ajuster les workers PHP-FPM.
• Une erreur SSL / SNI persiste après vérification du certificat dans Plesk.
• Vous avez un doute, tout simplement. Un log collé dans un ticket nous fait gagner 10 minutes.

Pour apprendre à lire vos logs au quotidien, voir : Lire les logs de son site chez Datacampus.