Où voir combien de trafic mon serveur a consommé ?

L'onglet Métriques du tableau de bord montre les débits réseau de la dernière heure, du dernier jour et de la dernière semaine. Pour des totaux par jour ou par mois, installez vnStat dans le serveur ; il compte à partir de son installation.

Existe-t-il une limite de trafic que je pourrais atteindre ?

Non. Aucun plan n'a de quota de trafic mensuel. La limite, c'est la vitesse du port : 1 Gbit/s sur les plans Linux, 150 Mbit/s sur Windows, partagée équitablement quand la ligne est chargée.

Mon test affiche 200 Mbit/s. Il y a un problème ?

C'est généralement le test. Un seul flux pendant 10 secondes vers un serveur public chargé montre rarement le vrai débit. Recommencez avec iperf3, 4 flux parallèles et 30 secondes vers un serveur que vous contrôlez.

Puis-je faire tourner un serveur iperf3 sur un serveur NAT ?

Il ne sera pas joignable de l'extérieur, car un serveur NAT n'accepte les connexions entrantes que sur son port SSH. Lancez le serveur iperf3 sur l'autre machine et utilisez le serveur NAT comme client, avec -R pour tester le sens téléchargement.

Vérifier débit et trafic du VPS en 7 commandes

Lisez les graphiques réseau du tableau de bord, comptez le trafic mensuel avec vnStat, trouvez le processus qui mange votre bande passante et faites un test de débit qui donne de vrais chiffres. Sept étapes avec les commandes exactes.

« Le serveur est lent » peut vouloir dire trois choses différentes : le réseau est chargé, quelque chose sur le serveur consomme la bande passante, ou le test lui-même est faux. Ces sept étapes permettent de les distinguer. Les commandes sont pour Linux ; les noms de paquets valent pour les systèmes qui utilisent apt.

1. Regarder les graphiques du tableau de bord

Ouvrez le serveur dans le tableau de bord et allez dans l'onglet Métriques. Le graphique réseau montre le trafic entrant et sortant par seconde pour la dernière heure, le dernier jour ou la dernière semaine. Les données viennent de la couche de virtualisation, elles sont donc là même si l'OS du serveur est bloqué.

Deux choses n'y figurent pas : les totaux en gigaoctets et le programme à l'origine du trafic. C'est le rôle des étapes suivantes.

Les mêmes données sont disponibles via l'API, y compris le dernier mois :

curl -s "https://api.eqvps.com/api/v1/eqvps/services/SERVICE_ID/metrics?timeframe=month" \
  -H "Authorization: Bearer $EQVPS_API_KEY"

2. Trouver votre interface réseau

La plupart des commandes ci-dessous ont besoin du nom de l'interface :

ip -br addr

C'est l'interface qui porte votre adresse publique (ou privée, sur les serveurs NAT), souvent eth0 ou ens18. Remplacez eth0 ci-dessous si la vôtre diffère.

3. Compter le trafic par jour et par mois avec vnStat

apt install -y vnstat
vnstat -l -i eth0          # live rate, Ctrl+C to stop
vnstat -d                  # per day
vnstat -m                  # per month

vnStat lit les compteurs d'interface du noyau, survit aux redémarrages et ne consomme presque rien. Il commence à compter à son installation, installez-le donc avant d'avoir besoin des chiffres.

4. Voir quel processus utilise la bande passante

apt install -y nethogs
nethogs eth0

nethogs liste les processus avec leurs débits d'envoi et de réception actuels. Si vous voyez un processus inconnu qui pousse du trafic, regardez-le de près : un gros émetteur inattendu peut signaler un serveur compromis.

Pour voir les connexions elles-mêmes :

ss -tunap | head -30

5. Faire un test de débit qui veut dire quelque chose

La méthode fiable, c'est iperf3 entre deux machines que vous contrôlez. Sur l'autre machine, lancez le serveur :

iperf3 -s

Sur votre serveur, testez les deux sens avec 4 flux pendant 30 secondes :

iperf3 -c OTHER_HOST -P 4 -t 30        # upload from this server
iperf3 -c OTHER_HOST -P 4 -t 30 -R     # download to this server

Un serveur NAT n'accepte les connexions entrantes que sur son port SSH : lancez donc iperf3 -s sur l'autre machine et gardez le serveur NAT comme client, comme ci-dessus.

Pas de seconde machine ? Téléchargez un gros fichier depuis un miroir rapide proche de vous et lisez la moyenne :

curl -o /dev/null -w "%{speed_download}\n" https://mirror.example.net/1GB.bin

Le résultat est en octets par seconde. Multipliez par 8 pour obtenir des bits par seconde : 110000000 correspond à environ 880 Mbit/s.

6. Vérifier la latence et la perte de paquets

Un faible débit sur de longues distances est souvent un problème de latence ou de perte, pas de bande passante :

apt install -y mtr-tiny
mtr -rwc 100 example.com

Regardez la colonne Loss% de la dernière ligne. Une perte qui apparaît sur un saut au milieu puis disparaît ensuite signifie le plus souvent que ce routeur traite les réponses ping en basse priorité, pas une vraie perte.

7. Comparer avec ce qu'on peut attendre

Plan	Port	Résultat typique sur 4 flux, ligne calme
VPS Linux	1 Gbit/s	environ 900–940 Mbit/s dans chaque sens
VPS Windows	150 Mbit/s	environ 140 Mbit/s

Quand plusieurs serveurs de la même machine physique sont chargés en même temps, le lien montant est partagé à parts égales entre eux : un chiffre plus bas à un moment chargé est donc normal. Aucun plan n'a de quota de trafic. Le partage est expliqué dans Trafic et débit réseau.

Sur un serveur Windows, le Gestionnaire des tâches → Performances → Ethernet affiche le débit en direct, et le Moniteur de ressources → Réseau le trafic par processus.

Si les chiffres sont vraiment bas

Refaites l'étape 5 vers deux serveurs de test différents, notez l'heure et ouvrez un ticket avec les commandes et leur sortie. Avec cela, nous pouvons vérifier le lien montant à ce moment précis.

Voir aussi

Trafic et débit réseau : vitesses des ports, partage équitable, ports du courrier sortant.
Réseau et ports : redirection NAT et ports ouverts.
Libérer de l'espace disque, si vnStat ou les journaux remplissent le disque.

Comment vérifier le débit de votre serveur et sa consommation de trafic