Dépannage : mon VPS est inaccessible

Votre VPS ne répond plus : SSH reste bloqué, votre site affiche une erreur de connexion. Cette page donne une méthode de diagnostic à suivre de haut en bas : chaque étape élimine une famille de causes, et vous arriverez au support avec un diagnostic plutôt qu’avec une question.

Deux réflexes avant de commencer. Ouvrez status.cloudfive.xyz : si un incident est publié, l’information y est, et un ticket n’accélérera rien. Puis vérifiez que votre service est bien actif dans l’espace client — un service suspendu pour facture impayée est coupé et ressemble en tout point à une panne (Factures et paiements).

Vérifier si le serveur répond (ping, port SSH)

Ces trois tests se lancent depuis votre ordinateur, pas depuis le VPS. Remplacez 203.0.113.10 par l’adresse IP de votre machine.

macOS, Linux

ping -c 4 203.0.113.10
nc -vz 203.0.113.10 22
ssh -v root@203.0.113.10

Windows, PowerShell

Test-NetConnection 203.0.113.10 -Port 22

Et, pour savoir si le problème est sur le trajet plutôt que sur la machine :

mtr -r -c 10 203.0.113.10    # ou : traceroute 203.0.113.10

Note

Un ping sans réponse n’est pas une preuve de panne. Le filtrage anti-DDoS est permanent sur nos réseaux et peut écarter certaines sondes, et beaucoup de serveurs sont configurés pour ne pas répondre au ping. Le test qui compte vraiment est celui du port.

Interpréter le résultat des tests

C’est l’étape qui fait gagner le plus de temps. Le message d’erreur exact désigne presque toujours la cause.

Ce que vous observez	Cause la plus probable	Où aller ensuite
Rien ne répond, ni ping ni port	machine éteinte, bloquée au démarrage, ou service suspendu	la console, plus bas
Connection refused sur le port 22	la machine est en ligne, mais le service SSH est arrêté ou écoute ailleurs	la console, plus bas
Connection timed out sur le port 22	un pare-feu jette les paquets, souvent celui que vous venez de configurer	Configurer le pare-feu
Permission denied ou mot de passe refusé	authentification, pas de panne : clé absente, ou accès par mot de passe désactivé	Clé SSH, mot de passe root
La connexion s’ouvre puis se fige avant l’invite	disque plein, ou résolution DNS cassée sur le serveur	les causes fréquentes, plus bas
Le port 22 répond mais votre site non	la machine va bien, c’est le service web	les causes fréquentes, plus bas
mtr s’arrête loin de votre IP	incident réseau sur le trajet	status.cloudfive.xyz, puis ticket

Testez depuis un autre réseau

Refaites le test depuis un partage de connexion mobile. Si ça marche de là et pas de chez vous, c’est votre adresse IP qui est bloquée — par votre pare-feu, ou par un outil anti-intrusion qui a compté trop d’échecs. Le serveur, lui, va bien.

Vérifier l’état de la machine dans le panel

Ouvrez la fiche de votre VPS sur cloudfive.fr/manager (comment la retrouver). Vous y cherchez trois informations :

• Le statut du service. Un service suspendu est coupé volontairement ; la cause est presque toujours une facture en attente.
• L’état de la machine. Allumée ou éteinte, et depuis quand.
• Les graphiques de consommation. Ils sont relevés même quand votre VPS ne répond plus : un CPU à 100 % depuis mardi 2 h du matin est souvent le premier indice utile. Lecture détaillée dans Surveiller les ressources.

Si la machine est éteinte, redémarrez-la depuis cette fiche et attendez deux minutes avant de retester le port. Si elle est allumée et que rien ne répond, passez à la console.

Attention

Évitez les redémarrages en rafale. Chaque redémarrage interrompt les vérifications du système de fichiers en cours et peut aggraver un disque déjà en souffrance. Un redémarrage, puis on diagnostique.

Passer par la console pour diagnostiquer

La console vous donne l’écran de la machine. Elle ne passe ni par SSH, ni par votre pare-feu, ni par la configuration réseau du serveur : c’est l’outil qui marche quand plus rien ne marche. Procédure d’accès dans Utiliser la console VNC. Une fois connecté, dans cet ordre :

1. Lisez ce qui est affiché à l’écran avant de taper quoi que ce soit. Un système qui s’est arrêté sur une erreur l’affiche, et cela vous dispense de toute la suite.

2. Connectez-vous en root. Si le mot de passe est refusé, réinitialisez-le d’abord : Réinitialiser le mot de passe root.

3. Vérifiez l’espace disque. C’est la cause numéro un, loin devant les autres.

   df -h
   df -i

4. Vérifiez les services en échec.

   systemctl --failed

5. Vérifiez l’état et la configuration de SSH. La deuxième commande teste le fichier de configuration sans redémarrer le service : elle signale la faute de frappe qui empêche sshd de repartir.

   systemctl status ssh      # ou sshd selon la distribution
   sshd -t

6. Lisez les journaux du dernier démarrage, et cherchez les erreurs.

   journalctl -p err -b --no-pager | tail -40

7. Vérifiez que le réseau est bien monté et que la passerelle répond.

   ip a
   ip r
   ping -c 2 1.1.1.1

Les causes les plus fréquentes : disque plein, service planté, pare-feu

Le disque est plein. Le serveur reste joignable mais plus rien ne fonctionne : les sessions ne s’ouvrent pas, les bases refusent d’écrire. Faites de la place, puis redémarrez les services.

du -xh --max-depth=1 / | sort -h     # localiser
journalctl --vacuum-size=200M        # purger les journaux
apt clean                            # vider le cache de paquets (Debian, Ubuntu)

Un service a planté. Le port répond mais l’application non. Relisez son journal, puis relancez-le.

journalctl -u nom-du-service -n 50 --no-pager
systemctl restart nom-du-service

Le pare-feu s’est fermé sur vous. Le classique absolu : une règle activée sans autoriser SSH, et l’accès se coupe aussitôt. Depuis la console, ouvrez le port, puis relisez Configurer le pare-feu.

ufw allow 22/tcp && ufw status      # Debian, Ubuntu

Un outil anti-intrusion a banni votre IP. Après plusieurs échecs de connexion, votre adresse peut se retrouver bloquée. Depuis la console :

fail2ban-client status sshd
fail2ban-client set sshd unbanip 198.51.100.25

La mémoire a été saturée et le système a tué un processus. Le symptôme est une application qui disparaît sans explication.

dmesg -T | grep -i -E "killed process|out of memory"
free -h

La connexion s’établit mais les transferts se bloquent à mi-chemin. Un ssh qui marche et un gros scp qui gèle pointent vers un problème de taille de paquets (MTU), pas vers une panne. Signalez-le par ticket : la bonne valeur dépend de votre réseau, ne la devinez pas.

Le service est suspendu. Ni commande ni console n’y changeront quoi que ce soit. Réglez la facture en attente et le service repart : Factures et paiements.

Utiliser le mode rescue

Quand le système ne démarre plus du tout — erreur de montage, configuration corrompue, noyau cassé — il reste une étape avant la réinstallation. Le principe : la machine démarre sur un petit système indépendant de votre disque, puis vous montez ce disque pour corriger le fichier fautif ou récupérer vos données. De quoi réparer une entrée invalide dans /etc/fstab, une configuration SSH cassée, ou un service qui bloque le démarrage.

1. Cherchez l’option sur la fiche de votre service, dans la section des actions disponibles. Sa présence dépend de votre offre et de la technologie employée.

2. Si vous ne la trouvez pas, ouvrez un ticket avec l’identifiant du service et ce que vous cherchez à réparer. Le support est joignable 7 j/7 et peut rendre le disque accessible pour vous.

3. Montez votre disque dans un répertoire temporaire, corrigez le fichier identifié, puis démontez proprement avant de redémarrer en mode normal.

4. Si la réparation échoue, servez-vous du mode rescue pour sortir vos données avant toute réinstallation. C’est sa fonction la plus précieuse.

Danger

Ne lancez pas de réinstallation « pour voir ». Elle efface l’intégralité du disque, sans récupération possible. Le mode rescue, lui, ne détruit rien. Faites-le dans cet ordre : rescue, récupération des données, puis seulement réinstallation.

Les informations à fournir au support

Un ticket précis se traite en une réponse ; un ticket vague en cinq allers-retours. Rassemblez ceci avant d’écrire, puis ouvrez le ticket depuis cloudfive.fr/manager.

• L’identifiant du service et l’adresse IP concernée.
• La date et l’heure du début du problème, avec le fuseau.
• Ce qui a changé juste avant : mise à jour, règle de pare-feu, script ajouté, redémarrage.
• Le message d’erreur exact, copié, pas reformulé. « Ça ne marche pas » et Connection timed out n’envoient pas au même endroit.
• La sortie des tests de la première section, et votre IP publique si l’accès échoue seulement depuis certains réseaux.
• Ce que vous avez déjà tenté.

Attention

Ne communiquez jamais votre mot de passe root ni une clé privée dans un ticket, un message Discord ou un courriel. Le support n’en a pas besoin pour intervenir sur votre machine. Collez les journaux, pas les secrets.

Si l’accès ne revient toujours pas

Vous avez tout testé et la machine reste muette. Ouvrez un ticket avec les éléments ci-dessus. C’est le moment : vous avez un diagnostic, pas une question. Le Discord CloudFive sert à obtenir un deuxième regard, mais tout ce qui touche à votre compte ou à vos accès passe par un ticket, seul canal authentifié.

Le serveur redémarre et retombe en boucle. N’empilez pas les redémarrages. Laissez la machine éteinte et décrivez par ticket ce que montre la console pendant le démarrage : c’est l’information qui permet de trancher entre un disque, un noyau et un service.

Vous suspectez une compromission. Trafic sortant anormal, processus inconnus, fichiers modifiés. Coupez l’exposition des services concernés et ne nettoyez pas pour nettoyer : un serveur compromis se réinstalle (guide) après récupération des données. Si des abus partent de votre machine, l’adresse de signalement est abuse@cloudfive.xyz.

Vous voulez éviter la prochaine fois. Trois mesures suffisent : une sauvegarde automatique hors du VPS, une alerte sur l’espace disque, et une règle de pare-feu testée dans un second terminal avant d’être rendue permanente (guide).