Serveur inaccessible : comprendre pourquoi il ne répond plus et le rétablir
Un serveur inaccessible ne répond plus ni en SSH, ni en HTTP, ni parfois au ping. Tous les services qu'il héberge (sites, API, bases de données, e-mails) sont alors indisponibles en même temps. Les causes vont du simple disque plein à l'incident réseau chez l'hébergeur, en passant par une saturation mémoire, un pare-feu trop strict ou une attaque.
Le réflexe du redémarrage brutal règle parfois le symptôme mais peut aggraver la situation : corruption de base de données, perte de journaux qui auraient permis de comprendre l'origine, serveur qui retombe en panne quelques minutes plus tard. Il faut d'abord déterminer si le problème est réseau, système ou applicatif.
Cette page vous guide à travers les vérifications à effectuer depuis l'extérieur, depuis la console de secours de l'hébergeur et depuis le serveur lui-même, les causes les plus fréquentes, et les moments où l'intervention d'un professionnel évite une perte de données.
Symptômes typiques
- ssh: connect to host ... port 22: Connection timed out, ou Connection refused.
- Le ping ne répond pas, ou répond alors que tous les services sont muets.
- Tous les sites et applications hébergés sont tombés en même temps.
- La console VNC ou KVM de l'hébergeur affiche des messages « No space left on device », « Out of memory » ou un noyau en erreur (kernel panic).
- Le serveur répond de façon intermittente, avec des délais très longs entre deux réponses.
- Le tableau de bord de l'hébergeur montre une consommation CPU ou réseau à 100 % ou une alerte d'incident.
Causes possibles
Disque plein
Journaux qui grossissent, sauvegardes accumulées, fichiers temporaires ou base de données en expansion. Une fois le disque plein, les services ne peuvent plus écrire et se bloquent, y compris SSH.
Mémoire épuisée et OOM killer
Un processus (MySQL, PHP-FPM, Node, Java) consomme toute la mémoire ; le noyau tue des processus au hasard, parfois SSH ou la base de données, et le serveur devient inutilisable.
Pare-feu ou fail2ban qui bloque
Une règle iptables, ufw ou un groupe de sécurité cloud modifié, ou votre propre adresse IP bannie par fail2ban après des tentatives de connexion échouées.
Incident réseau ou matériel chez l'hébergeur
Panne de baie, d'hyperviseur, de routeur ou opération de maintenance : le serveur est sain mais injoignable.
Saturation CPU ou attaque
Boucle infinie, tâche cron qui s'empile, script de minage installé par un attaquant ou attaque par déni de service qui sature la bande passante.
Mise à jour système ou redémarrage mal terminé
Noyau non amorçable, système de fichiers à vérifier (fsck) au démarrage, service réseau non relancé ou configuration SSH invalide après une mise à jour.
Changement d'adresse IP ou de DNS
Adresse IP réattribuée après une recréation d'instance, IP flottante non rattachée, ou enregistrement DNS pointant vers une machine qui n'existe plus.
Contrôles à effectuer
- 1
Tester depuis l'extérieur
ping adresse-ip, puis nc -zv adresse-ip 22 et nc -zv adresse-ip 443 pour savoir si les ports répondent. traceroute ou mtr adresse-ip montrent où le trafic s'arrête. Testez depuis un autre réseau pour exclure un bannissement de votre IP.
- 2
Consulter la console et les graphiques de l'hébergeur
Les tableaux de bord affichent CPU, mémoire, disque et réseau : un plateau à 100 % ou une chute brutale datent l'incident. Vérifiez la page de statut du fournisseur pour un incident en cours.
- 3
Se connecter par la console de secours
La console VNC, KVM ou série de l'hébergeur permet d'accéder au serveur même si le réseau ou SSH est hors service. C'est là que les messages du noyau et l'invite de connexion apparaissent.
- 4
Vérifier le disque
df -h pour l'espace, df -i pour les inodes (un disque peut être « plein » d'inodes avec de l'espace libre). du -sh /var/log /var/lib/mysql /home/* pour trouver ce qui occupe l'espace.
- 5
Vérifier la mémoire et l'OOM killer
free -m pour l'état actuel, dmesg -T | grep -i 'out of memory' ou journalctl -k | grep -i oom pour savoir si le noyau a tué des processus, et quels processus.
- 6
Contrôler le pare-feu et fail2ban
iptables -L -n ou ufw status pour les règles locales, fail2ban-client status sshd pour voir les adresses IP bannies, et les groupes de sécurité ou règles réseau dans la console cloud.
- 7
Examiner la charge et les journaux
uptime et top montrent la charge et les processus gourmands ; journalctl -xe et /var/log/syslog ou /var/log/messages détaillent les erreurs système récentes ; last -x liste les redémarrages.
Solutions
Libérer de l'espace disque
Purger ou faire tourner les journaux (journalctl --vacuum-size, logrotate), supprimer les anciennes sauvegardes, vider les caches, puis relancer les services. Mettre en place une alerte sur l'espace disque.
Traiter la saturation mémoire
Identifier le processus responsable, ajuster sa configuration (innodb_buffer_pool_size, pm.max_children de PHP-FPM, heap Java), ajouter du swap comme filet de sécurité et, si nécessaire, redimensionner le serveur.
Corriger le pare-feu
Lever le bannissement de votre adresse (fail2ban-client set sshd unbanip), rétablir la règle qui autorise SSH et HTTP/HTTPS, corriger le groupe de sécurité cloud.
Redémarrer proprement
Depuis la console de secours, arrêter les services dans l'ordre (application, puis base de données), puis redémarrer. En cas de fsck au démarrage, laisser la vérification se terminer.
Contenir une attaque
Bloquer les adresses IP ou pays sources, activer la protection anti-DDoS du fournisseur, tuer les processus inconnus puis traiter la compromission avant remise en service.
Restaurer ou reconstruire
Si le système est irrécupérable, restaurer un instantané (snapshot) ou reconstruire le serveur depuis une sauvegarde, idéalement avec une configuration automatisée pour aller vite.
Quand contacter un professionnel ?
- Le serveur héberge des données de production (base de données, fichiers clients) et vous voulez éviter toute manipulation risquée.
- La console de secours affiche des erreurs de système de fichiers, de noyau ou « Out of memory » que vous ne savez pas interpréter.
- Le serveur retombe en panne après chaque redémarrage.
- Vous soupçonnez une intrusion : processus inconnus, charge anormale, connexions sortantes suspectes.
- Vous n'avez pas de sauvegarde récente ni de documentation de la configuration du serveur.
L'intervention proposée par Agencei
- 1
Diagnostic à distance
Tests réseau depuis plusieurs points, analyse via la console de secours de l'hébergeur, lecture des journaux système et du noyau pour dater et expliquer l'incident.
- 2
Remise en service
Libération des ressources, correction du pare-feu, relance ordonnée des services ou redémarrage contrôlé, restauration d'un instantané si nécessaire.
- 3
Correction de la cause
Réglage des services gourmands, rotation des journaux, mise à jour ou reconfiguration, nettoyage et durcissement en cas de compromission.
- 4
Vérification des données
Contrôle d'intégrité de la base de données et des fichiers après un arrêt brutal, réparation des tables si besoin.
- 5
Supervision et sauvegardes
Mise en place d'alertes sur le disque, la mémoire, la charge et la disponibilité, de sauvegardes automatiques testées et, si pertinent, d'une infrastructure plus résiliente.
Questions fréquentes
Dois-je redémarrer le serveur immédiatement ?
Pas avant d'avoir regardé la console de secours et, si possible, les journaux. Un redémarrage règle souvent le symptôme mais fait disparaître les indices, et un serveur avec le disque plein ou une base corrompue peut ne pas redémarrer correctement.
Le ping répond mais rien d'autre, que se passe-t-il ?
La machine et le réseau fonctionnent, mais les services ne répondent pas : pare-feu, services arrêtés, disque plein ou mémoire épuisée. La console de secours de l'hébergeur permet d'y voir clair.
Comment savoir si c'est un incident chez l'hébergeur ?
Consultez sa page de statut, ses e-mails et son espace client. Si le serveur est injoignable y compris depuis la console de secours et que le graphique de consommation s'arrête net, l'incident est probablement de son côté.
Mes données sont-elles perdues ?
Rarement à cause d'une simple panne. Un disque plein ou une saturation mémoire ne détruisent pas les données. Une base de données arrêtée brutalement peut nécessiter une réparation, d'où l'importance de sauvegardes régulières et testées.
Comment éviter que cela se reproduise ?
Supervision avec alertes (disque, mémoire, charge, disponibilité), rotation des journaux, dimensionnement adapté, mises à jour maîtrisées, pare-feu documenté et sauvegardes automatiques hors du serveur.
Services associés
Support informatique
Assistance applicative et serveurs, gestion des incidents et engagements de service clairs.
Voir ce serviceMigration de serveur
Transfert d'un serveur dédié ou VPS vers une nouvelle machine, avec mise à niveau d'OS et bascule contrôlée.
Voir ce serviceAccompagnement DevOps
Mise en place de la CI/CD, de l'infrastructure as code, de la supervision et des pratiques GitOps.
Voir ce serviceMaintenance informatique
Supervision, mises à jour, sauvegardes et amélioration continue de vos applications en production.
Voir ce serviceServices AWS
Conception, déploiement et optimisation de votre infrastructure AWS : calcul, données, stockage, coûts.
Voir ce serviceParlez-nous de votre projet
Décrivez votre besoin en quelques lignes : nous revenons vers vous avec une première analyse et les prochaines étapes.