Diagnostiquer un VPS Linux injoignable

« Mon serveur ne répond plus » recouvre une dizaine de situations très différentes. La méthode ci-dessous les sépare en quelques minutes, et vous évite d’attendre une réponse alors que la solution est à portée de clic.

1. Comment vérifier l’état de mon VPS dans l’espace client ?

Ouvrez Mes services puis votre VPS. La fiche indique l’état de la machine.

• Arrêtée : cliquez sur Démarrer. Un arrêt peut résulter d’un shutdown lancé par erreur, d’un noyau planté ou d’une action précédente.
• En cours d’installation : rien à faire, attendez la fin.
• Suspendue ou expirée : vérifiez vos factures dans l’espace client. Un service impayé est suspendu.

2. Où voir les dernières actions effectuées sur mon VPS ?

L’onglet Historique liste les actions effectuées sur le VPS, leur auteur — Système, Utilisateur ou Administrateur — et leur date. Une réinstallation, un changement de mot de passe ou un arrêt oublié y apparaissent noir sur blanc. C’est souvent là que se trouve l’explication.

3. Que montrent les graphiques de mon VPS ?

L’onglet Graphiques montre le CPU, la mémoire, le réseau et les entrées-sorties disque. Trois lectures utiles :

• tout à zéro depuis une heure précise : la machine est arrêtée ou bloquée ;
• CPU au plafond en continu : un processus est parti en boucle, ou la machine est utilisée par quelqu’un d’autre que vous ;
• trafic sortant inhabituel : envisagez sérieusement une compromission.

4. Comment voir ce qui se passe sur la machine avec la console ?

C’est l’étape décisive. La console affiche l’écran de la machine sans passer par le réseau.

• Vous voyez l’invite de connexion : le système tourne, le problème est réseau ou SSH. Passez à l’étape 5.
• Vous voyez des messages d’erreur au démarrage : notez la dernière ligne avant le blocage, c’est elle qui compte.
• L’écran est noir et ne répond pas : redémarrez la machine depuis la fiche de service, puis regardez le démarrage dans la console.

5. Comment vérifier le réseau et SSH depuis la console ?

Quelques commandes suffisent : l’adresse et la route par défaut, un ping vers une IP publique puis vers un nom de domaine, l’état du service SSH, et un éventuel bannissement de votre adresse par fail2ban.

Connectez-vous dans la console avec root :

ip -4 addr          # l'adresse est-elle bien présente ?
ip route            # la route par défaut existe-t-elle ?
ping -c3 9.9.9.9    # la couche IP fonctionne-t-elle ?
ping -c3 debian.org # le DNS résout-il ?

Si 9.9.9.9 répond mais pas un nom de domaine, corrigez la résolution DNS. Si rien ne répond, comparez votre configuration avec ce qu’affiche l’onglet Réseau de l’espace client.

Puis SSH et le pare-feu :

systemctl status ssh          # ou sshd
ss -tulpn | grep :22
ufw status                    # ou firewall-cmd --list-all
fail2ban-client status sshd   # votre IP est-elle bannie ?

Une adresse bannie par fail2ban après plusieurs erreurs de mot de passe est une cause très fréquente d’un serveur « injoignable » qui va parfaitement bien. Débannissez-la avec fail2ban-client set sshd unbanip VOTRE_IP.

6. Comment savoir si le disque de mon VPS est plein ?

Avec df -h pour l’espace et df -i pour les inodes : un disque saturé empêche les services de démarrer et les journaux de s’écrire.

df -h
df -i
journalctl --disk-usage

Un disque plein à 100 % — ou à court d’inodes, ce que df -h ne montre pas — empêche les services de démarrer et les journaux de s’écrire. Libérez de l’espace, puis redémarrez les services concernés.

7. Comment repérer un service en échec sur mon VPS ?

Avec systemctl list-units --failed, puis le journal du service concerné : la cause y est presque toujours écrite en clair.

systemctl list-units --failed
journalctl -p err -b --no-pager | tail -50
systemctl status NOM_DU_SERVICE

Un service en échec après une mise à jour est presque toujours expliqué en clair dans son journal.

Que faut-il joindre à mon ticket au support ?

Si vous ouvrez un ticket au Service Technique, ces éléments évitent plusieurs allers-retours :

• l’identifiant du service concerné ;
• l’heure exacte du début du problème, avec le fuseau ;
• ce qui a changé juste avant : mise à jour, modification du pare-feu, du réseau, de SSH ;
• les résultats des commandes ci-dessus, copiés en texte ;
• le message d’erreur exact, et non un résumé ;
• ce que la console affiche.

Ne transmettez jamais de mot de passe, de clé privée ni de jeton : le support n’en a pas besoin, et un ticket est archivé.