Un serveur qui ne répond plus vient le plus souvent d’une machine éteinte ou saturée, d’un réseau coupé, d’un pare-feu trop strict ou d’une panne de l’hébergeur. Consultez d’abord l’état dans l’espace client, ouvrez la console de secours KVM ou VNC, puis relisez les journaux du démarrage précédent avec journalctl -b -1.
« Ne répond plus » recouvre des situations très différentes. Le site peut être muet alors que SSH fonctionne : le problème se situe alors dans nginx, Apache ou la base de données. Si plus rien ne répond, ni le site, ni SSH, ni le ping, la machine est arrêtée, bloquée, privée de réseau ou coupée par un pare-feu.
L’ordre compte : on commence par ce qui ne coûte rien et ne modifie rien (état chez l’hébergeur, tests depuis l’extérieur), puis on passe à la console de secours, qui fonctionne même sans réseau. Les commandes ci-dessous visent Debian et Ubuntu.
Identifier ce qui ne répond pas
Depuis votre poste, testez séparément chaque service. ping -c 4 adresse-ip vérifie que la machine répond au niveau réseau (certains hébergeurs filtrent le ping, un échec seul ne prouve rien). nc -vz adresse-ip 22 teste le port SSH, nc -vz adresse-ip 443 le port HTTPS. Un curl -I https://votre-domaine.fr montre si le serveur web répond.
Interprétation : si tout échoue, pensez machine ou réseau. Si seul le web échoue, le serveur est vivant et le problème vient du service : voyez le guide sur nginx qui ne démarre pas. Si seul SSH échoue, passez au guide sur la connexion SSH refusée.
Consulter l’état chez l’hébergeur
Ouvrez l’espace client de l’hébergeur et cherchez, dans l’ordre : un incident ou une maintenance annoncés sur votre zone, l’état du serveur (en marche, arrêté, suspendu), une alerte de facturation ou de conformité qui aurait provoqué une suspension, et les graphiques de trafic, de CPU et de disque quand ils existent. Un pic juste avant la coupure oriente déjà le diagnostic. Si la machine est « arrêtée » sans que vous l’ayez demandé, le journal d’activité du compte indique souvent qui ou quoi l’a arrêtée.
Ouvrir la console de secours KVM ou VNC
La plupart des hébergeurs proposent une console accessible depuis le navigateur, qui se comporte comme un écran et un clavier branchés sur la machine. Elle ne dépend ni du réseau du serveur ni de SSH. Observez ce qui s’affiche :
- une invite de connexion : le système tourne, le problème est réseau ou pare-feu ;
- un message
Kernel panicou un écran figé : le noyau a planté ; - un
emergency modeouGive root password for maintenance: un système de fichiers n’a pas pu être monté, souvent à cause d’une ligne de/etc/fstabou d’un disque plein ou endommagé ; - un écran noir : relevez l’heure et passez à l’étape suivante.
Redémarrer le serveur depuis l’espace client
Si la console reste figée, utilisez d’abord le redémarrage logiciel de l’espace client, puis le redémarrage forcé en dernier recours : une coupure brutale peut laisser des fichiers ou des tables de base de données incohérents. Notez l’heure exacte de l’opération, elle servira pour lire les journaux. Une fois le serveur revenu, relevez immédiatement la charge et l’espace libre avec uptime et df -h.
Tester le réseau, l’adresse et le pare-feu
Depuis la console, connecté en root ou avec sudo, vérifiez que l’interface a bien son adresse avec ip -br a et sa route par défaut avec ip route. Testez la sortie avec ping -c 3 1.1.1.1. Depuis l’extérieur, mtr -rwc 20 adresse-ip (ou traceroute adresse-ip) montre où les paquets s’arrêtent : un arrêt chez l’hébergeur dépasse votre périmètre, un arrêt sur le dernier saut indique un filtrage local. Contrôlez ensuite le pare-feu avec ufw status verbose ou nft list ruleset. Une règle ajoutée récemment, un port fermé par erreur ou une politique DROP appliquée par un outil de sécurité expliquent beaucoup de coupures. Corrigez la règle fautive plutôt que de désactiver le pare-feu.
Relire les journaux du démarrage précédent
Après un redémarrage, les messages utiles se trouvent dans le boot d’avant. journalctl --list-boots liste les démarrages connus, journalctl -b -1 -p err affiche les erreurs du précédent, et journalctl -b -1 -e ouvre la fin de son journal, c’est-à-dire les dernières minutes avant la coupure. Si la commande ne trouve rien, le journal n’est pas conservé après redémarrage : créez le dossier /var/log/journal puis lancez systemctl restart systemd-journald, ce qui rendra le prochain diagnostic possible.
Chercher une saturation de mémoire (OOM)
Quand la mémoire est épuisée, le noyau tue des processus, souvent la base de données ou PHP, et le serveur peut devenir inutilisable. Recherchez la trace avec journalctl -k -b -1 | grep -i -E "out of memory|oom" ou dmesg -T | grep -i "killed process". Si elle apparaît, comparez avec free -h et suivez le guide sur un serveur surchargé pour trouver le processus en cause.
Passer en mode rescue si le système ne démarre plus
Le mode rescue de l’hébergeur démarre la machine sur un système temporaire, en laissant votre disque intact. Montez la partition avec mount /dev/sda1 /mnt (adaptez le nom avec lsblk), lisez /mnt/var/log/syslog et /mnt/etc/fstab, puis corrigez la ligne fautive. Un système de fichiers endommagé se vérifie avec fsck -f /dev/sda1, uniquement quand la partition n’est pas montée. Faites une copie des données importantes avant toute réparation, puis quittez le mode rescue et redémarrez normalement.
Questions fréquentes
Pourquoi mon serveur ne répond plus au ping ?
Le serveur peut être arrêté, bloqué, privé de réseau, ou configuré pour ignorer le ping : certains hébergeurs et pare-feu filtrent ces paquets. Testez aussi le port SSH ou HTTPS avec nc -vz, puis ouvrez la console de secours pour savoir si la machine tourne réellement.
Mon site est tombé mais SSH fonctionne, que faire ?
Le serveur est vivant, seul un service est en cause. Vérifiez systemctl status nginx ou systemctl status apache2, puis la base de données et PHP-FPM. Regardez aussi df -h : un disque plein arrête souvent les services web sans couper SSH.
Comment savoir pourquoi mon serveur a redémarré tout seul ?
Lancez journalctl --list-boots puis journalctl -b -1 -e pour lire les dernières lignes avant l’arrêt. Cherchez un kernel panic, un manque de mémoire ou une maintenance de l’hébergeur. La commande last -x reboot shutdown donne la chronologie des redémarrages.
Que faire si la console de secours n’affiche rien ?
Patientez, rafraîchissez la page, puis essayez un autre navigateur. Si l’écran reste noir, la machine est peut-être arrêtée : vérifiez son état et redémarrez-la depuis l’espace client. Sans réaction, ouvrez un ticket urgent chez l’hébergeur en précisant l’heure de la coupure.
Un serveur piraté peut-il cesser de répondre ?
C’est possible : un processus étranger peut saturer le processeur, le disque ou la bande passante, ou une attaque peut remplir les connexions. Si vous constatez des processus ou des connexions inconnus, consultez le guide sur un serveur piraté avant de redémarrer.