VPS inaccessible : diagnostic réseau en 30 secondes

Un VPS qui ne répond plus ne signifie pas forcément que le serveur est hors service. Le problème peut venir de votre connexion, d’un port filtré, d’un service arrêté ou de la configuration réseau du système. Ce diagnostic rapide aide à isoler la cause sans redémarrer au hasard.

Ce qu’est un VPS et pourquoi l’accès diffère d’un hébergement mutualisé

Un VPS (serveur privé virtuel) repose sur une couche de virtualisation qui isole vos ressources CPU, RAM et espace disque de celles des autres clients de l’hébergeur, contrairement à un hébergement mutualisé où l’accès système reste restreint. Cette isolation vous donne un accès root complet, ce qui est un avantage pour l’administration au quotidien, mais signifie aussi que la configuration réseau (pare-feu, services actifs, interfaces) reste entièrement sous votre responsabilité. C’est justement cette configuration qu’il faut vérifier en premier lorsqu’un serveur virtuel semble injoignable.

1. Vérifier si la panne vient de votre connexion

Commencez par tester un autre site ou une autre connexion réseau. Si plusieurs services sont inaccessibles, le VPS n’est peut-être pas en cause. Depuis un terminal, vérifiez ensuite la résolution DNS du nom de domaine avec nslookup ou dig. Comparez le résultat avec l’adresse IP affichée dans votre espace de gestion.

Testez l’IP directement. Une réponse au ping n’est pas obligatoire, car certains pare-feu bloquent ICMP, mais l’absence de réponse ne suffit donc pas à conclure à une panne.

2. Tester le port du service

Un serveur peut être joignable alors que SSH, RDP ou le port de votre application est fermé. Testez le port concerné depuis votre poste : nc -vz ADRESSE_IP 22 pour SSH, ou le port réellement utilisé par votre service. Pour un VPS Windows, vérifiez de la même manière le port RDP, généralement 3389, sans supposer qu’il est resté inchangé.

Un VPS peut aussi héberger un serveur Web, une base de données ou un service d’emails : si le port SMTP, HTTP ou celui de votre base de données semble bloqué, testez-le exactement comme les autres services plutôt que de le supposer en cause sans vérification.

Si le test indique un délai d’attente, contrôlez d’abord le pare-feu local et les règles réseau de votre fournisseur. Si la connexion est refusée, la machine répond probablement mais aucun service n’écoute sur ce port, ou le service rejette la demande.

3. Distinguer service arrêté et VPS hors ligne

Consultez la console ou le statut du VPS dans l’espace client. Un état allumé ne garantit pas que le service applicatif fonctionne, tandis qu’une console inaccessible peut signaler un incident plus bas niveau. Si SSH fonctionne, connectez-vous en root et contrôlez le service avec le gestionnaire de votre distribution (Ubuntu, Debian et la plupart des systèmes Linux utilisent systemctl status nom-du-service).

Évitez de relancer plusieurs fois la machine avant d’avoir noté les symptômes : heure du dernier accès, ports touchés, message affiché et dernière modification effectuée. Ces éléments accélèrent le support et évitent de masquer la cause.

4. Contrôler le pare-feu et la configuration réseau

Après une modification récente, inspectez les règles de ufw, nftables ou du pare-feu (firewall) installé sur le système. Vérifiez aussi que le service écoute sur la bonne interface et le bon port avec ss -lntup. Une application liée à 127.0.0.1 n’acceptera pas les connexions externes, même si le processus est actif.

Sur Windows, vérifiez les règles entrantes du pare-feu et le profil réseau associé. Ne désactivez pas durablement le pare-feu pour tester : créez plutôt une règle limitée au port et au protocole nécessaires.

5. Vérifier les ressources et les logs

Un disque plein, de la RAM saturée ou un processus qui consomme tout le CPU peut rendre l’administration très lente, même sur un espace de stockage SSD rapide. Sur Linux, utilisez df -h pour l’espace disque, free -h pour la RAM et top ou htop pour le CPU. Consultez les journaux autour de l’heure du problème avec journalctl. Un redémarrage peut rétablir l’accès, mais il ne corrige ni un disque rempli ni une règle réseau incorrecte.

Un pic de bande passante inhabituel peut aussi ralentir un service sans rendre le VPS totalement injoignable : si les lenteurs touchent uniquement certaines connexions, pensez à vérifier le trafic réseau avant de conclure à une panne complète.

Pour un serveur de jeu, la charge peut aussi venir du logiciel, d’un mod ou d’une ressource récemment ajoutée. Les guides d’optimisation des performances d’un serveur FiveM et d’hébergement d’un serveur Minecraft aident à replacer le diagnostic dans le contexte de l’application.

Quand contacter le support

Contactez le support si la console confirme un problème, si plusieurs ports restent injoignables après vérification, ou si l’incident touche le réseau amont. Transmettez l’adresse IP ou l’identifiant du VPS, l’heure de début, les tests réalisés et les messages d’erreur. Ne partagez jamais votre mot de passe ni une clé privée.

Si vous gérez plusieurs serveurs virtuels ou plusieurs sites web hébergés, précisez lequel est concerné : la plupart des hébergeurs traitent plus vite un ticket qui identifie clairement la machine et le service touchés.

Si vous devez repartir sur une architecture mieux dimensionnée, comparez un serveur dédié et un VPS, appliquez les premiers réglages de sécurité et mettez en place des sauvegardes adaptées.

Checklist de diagnostic en 30 secondes

• Tester un autre site et vérifier la résolution DNS.
• Tester l’IP puis le port du service concerné (Web, base de données, emails…).
• Consulter le statut et la console du VPS.
• Contrôler le pare-feu, l’écoute du service et l’interface réseau.
• Vérifier RAM, CPU, espace disque et journaux avant tout redémarrage.
• Rassembler les horaires et résultats pour le support.

Cette méthode permet de séparer rapidement panne locale, port filtré, service arrêté et incident d’infrastructure. Elle est également utile avant une migration : le guide sur la migration d’un serveur FiveM détaille les précautions à prendre pour limiter les interruptions.