Serveur en panne : que vérifier en premier, et dans quel ordre

Ce guide concerne le serveur lui-même : un VPS, un serveur dédié ou un serveur cloud que vous administrez. Si un seul site tombe alors que tout le reste fonctionne sur la machine, ou si votre site est sur un hébergement mutualisé, commencez plutôt par le guide Site inaccessible. Ici, on s'intéresse à la machine : répond-elle encore, pouvez-vous vous y connecter, et qu'est-ce qui s'est arrêté ?

Étape 1 : qu'est-ce qui est en panne, exactement ?

« Le serveur est en panne » peut vouloir dire trois choses très différentes, chacune avec sa solution. Vérifiez d'abord depuis l'extérieur, depuis un réseau qui n'est pas le vôtre. Pour les sites hébergés sur le serveur, le Site down checker vous dit en quelques secondes si le nom se résout, si le port répond et quel code de statut revient. Pour la machine elle-même, utilisez ping et un test de port depuis votre poste :

ping -c 3 203.0.113.10
nc -zv -w 5 203.0.113.10 22
nc -zv -w 5 203.0.113.10 443

Lisez les résultats ensemble :

• Pas de ping, pas de SSH, pas de port web : la machine est éteinte, figée, ou le réseau devant elle est coupé. Passez à l'étape 2.
• Le ping répond, SSH non : la machine tourne, mais SSH est bloqué, arrêté, ou le serveur est trop surchargé pour répondre. Passez à l'étape 3.
• SSH fonctionne, le site non : le serveur va bien, un service non. Passez à l'étape 4.

Certains serveurs ignorent le ping volontairement. Si le ping n'a jamais fonctionné, fiez-vous aux tests de port.

Étape 2 : plus rien ne répond

Ouvrez d'abord l'espace client ou la console cloud de votre fournisseur. Trois questions règlent la plupart des cas en une minute :

1. Le serveur est-il démarré ? Une instance arrêtée, un compte suspendu ou un paiement refusé ressemblent exactement à une panne vus de l'extérieur.
2. Y a-t-il un incident connu ? Consultez la page de statut du fournisseur pour votre région ou votre centre de données.
3. Que montre la console ? La console web ou série affiche l'écran de la machine, même sans réseau. Un kernel panic, « Out of memory: Killed process » en boucle ou un démarrage bloqué sur la vérification du système de fichiers indiquent où se trouve le problème.

Si la machine est figée, un redémarrage depuis la console la ramène en général. Avant de redémarrer, faites une capture de la console : après le redémarrage, l'indice a disparu. Si elle ne démarre plus, la plupart des fournisseurs proposent un mode rescue, depuis lequel vous montez le disque, lisez les journaux et corrigez /etc/fstab ou une configuration réseau cassée.

Étape 3 : le ping répond, SSH non

La machine est vivante, la cause se trouve donc sur elle. Connectez-vous par la console et vérifiez les suspects habituels :

sudo ufw status verbose
sudo iptables -S | head -n 30
sudo fail2ban-client status sshd
sudo systemctl status ssh sshd 2>/dev/null | grep -E 'Loaded|Active'

Une règle de pare-feu ajoutée à la hâte, votre propre adresse IP bannie après quelques mots de passe erronés, ou une configuration SSH qui n'a pas passé son test sont les blocages les plus fréquents. Débannissez votre adresse avec sudo fail2ban-client set sshd unbanip VOTRE_IP, et lancez toujours sudo sshd -t avant de redémarrer SSH. Si SSH tourne mais répond très lentement, le serveur est surchargé : passez à l'étape 4.

Étape 4 : vous êtes connecté, lisez quatre chiffres

uptime
free -m
df -h
df -i
sudo dmesg -T | grep -iE 'oom|killed process|i/o error|read-only' | tail -n 20

• Charge (uptime) : bien au-dessus du nombre de cœurs, la machine est surchargée. top ou htop montre quel processus en est la cause.
• Mémoire (free -m) : plus de mémoire libre ni de swap, et « Killed process » dans dmesg, signifie que le noyau a arrêté un processus pour survivre. C'est souvent la base de données ou PHP.
• Disque (df -h) : un disque plein est la cause la plus fréquente de panne serveur. Les bases de données n'écrivent plus, les journaux s'arrêtent, les sessions échouent. df -i vérifie les inodes : un disque peut être « plein » avec des gigaoctets libres si des millions de petits fichiers occupent tous les inodes.
• Erreurs d'E/S ou système de fichiers en lecture seule dans dmesg : le disque lui-même a un problème. Arrêtez d'écrire, sauvegardez ce qui peut l'être et contactez votre fournisseur.

Pour libérer de la place sans risque, commencez par le journal système et les vieilles archives :

sudo journalctl --vacuum-size=200M
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -n 15

Ne supprimez jamais de fichiers de base de données ni de fichiers du site pour faire de la place.

Étape 5 : quel service s'est arrêté, et pourquoi ?

systemctl --failed
sudo journalctl -u nginx -n 50 --no-pager
sudo nginx -t

systemctl --failed liste chaque service arrêté sur une erreur. Son journal en donne la raison : un port déjà utilisé, une erreur de syntaxe dans un fichier de configuration, un certificat manquant, plus de place. Testez la configuration avant chaque redémarrage (nginx -t, apachectl configtest, php-fpm -t), puis lancez sudo systemctl restart SERVICE. Un redémarrage sans test peut faire tomber un service qui tournait encore à moitié.

Étape 6 : qu'est-ce qui a changé ?

Une panne a une cause, et c'est le plus souvent le dernier changement. Cherchez-le :

grep -E ' (install|upgrade) ' /var/log/dpkg.log | tail -n 20
last -n 10
sudo journalctl --since "2 hours ago" -p err --no-pager | tail -n 40

Des mises à jour automatiques, un nouveau noyau qui attend un redémarrage, un déploiement, une tâche cron qui a rempli le disque de sauvegardes, un certificat expiré ou une modification de configuration faite par quelqu'un d'autre : si l'un d'eux coïncide avec le début de la panne, vous tenez votre piste.

Quand les mêmes pannes reviennent

Un serveur tombé une fois à cause d'un disque plein ou d'une base de données arrêtée recommencera. La vérification depuis l'extérieur vous dit quand il est en panne ; la vérification depuis l'intérieur vous prévient avant. L'agent serveur remonte la charge, la mémoire, les disques et les services depuis la machine et vous alerte quand un disque dépasse votre seuil ou qu'un service coché s'arrête, tant qu'il est encore temps d'agir. Le monitoring serveur avec agent fait partie des offres payantes.

Quand vous ne voulez pas faire tout cela à 3 heures du matin

Si votre serveur est en panne et que vous préférez le faire réparer plutôt que chercher vous-même, une intervention rapide traite les causes courantes à prix fixe : elle redémarre un service arrêté si son test de configuration réussit, libère un disque plein et renouvelle un certificat expiré, avec une sauvegarde préalable. Si cela ne suffit pas, une intervention approfondie prend le relais 24 h/24, facturée par tranches de 15 minutes, avec le prix affiché avant la commande. Les deux passent par le Responder, SSH en root ou un accès SSH à votre hébergement mutualisé. Tous les détails sur la page dépannage et urgence serveur.