Tester son débit Internet sous Linux en ligne de commande

Tester un débit Internet sous Linux en ligne de commande sert surtout à obtenir une mesure rapide, reproductible et exploitable sur une machine sans interface graphique. C’est utile sur un serveur, un PC de jeu sous Linux, un mini-lab, une VM ou une connexion qui semble instable à certaines heures.

Le bon outil dépend du besoin. Pour comparer votre ligne avec un service public de test, utilisez un client Speedtest. Pour tester un lien interne, un VPN ou un réseau local, préférez iperf3. Pour vérifier seulement le téléchargement réel d’un fichier, un simple curl ou wget peut déjà donner un signal utile.

Quelle commande utiliser pour tester son débit sous Linux ?

Pour un test simple depuis le terminal, la commande la plus directe reste speedtest, installée depuis le client officiel Ookla ou un paquet disponible selon la distribution. Elle donne généralement le ping, le débit descendant, le débit montant et le serveur utilisé. Pour un diagnostic plus sérieux, complétez avec iperf3 ou un téléchargement contrôlé.

Un résultat propre commence par un objectif de mesure clair, avant même de choisir la commande ou le serveur de test.

Préparer un test qui veut dire quelque chose

Avant de lancer une commande, stabilisez l’environnement. Fermez les téléchargements, suspendez les sauvegardes cloud, évitez les mises à jour en arrière-plan et testez si possible en câble Ethernet. Sur un PC portable, désactivez temporairement le VPN si vous voulez mesurer la ligne elle-même. Sur un serveur, vérifiez qu’un job de backup ne monopolise pas déjà la bande passante.

La mesure la plus utile est celle que vous pourrez refaire. Notez donc l’heure, le type de connexion, le serveur de test, l’outil utilisé et le symptôme observé. Si votre problème concerne le jeu en ligne, ajoutez la latence et la stabilité. Si votre souci concerne une sauvegarde, regardez aussi l’upload, pas seulement le download.

• Ethernet d’abord : pour séparer la ligne Internet d’un problème Wi-Fi.
• Même serveur : pour comparer deux mesures sans changer de référence.
• Même créneau : pour repérer une saturation du soir ou du week-end.
• Contexte noté : VPN actif, routeur redémarré, téléchargement en cours, usage gaming.

Installer et lancer un test Speedtest

Commencez par une mesure manuelle, observez le résultat, puis automatisez seulement si le problème revient vraiment dans les mêmes conditions.

Pour approfondir ce point, consultez tester sa connexion internet facilement et efficacement, qui traite plus précisément de comment tester sa connexion internet facilement et efficacement.

Selon votre distribution, vous pouvez installer un client Speedtest depuis les dépôts disponibles ou depuis la documentation officielle du fournisseur choisi. Le principe reste le même : installez l’outil, lancez la commande, puis notez le serveur, l’heure et le type de connexion. Sans ce contexte, le chiffre brut est difficile à interpréter, surtout si vous comparez un test Wi-Fi du soir avec un test Ethernet réalisé le lendemain matin.

speedtest
speedtest --accept-license
speedtest --format=json

Le mode JSON est pratique si vous voulez exploiter les résultats dans un script. Il évite de parser une sortie texte fragile. En revanche, ne lancez pas un test toutes les minutes sur une petite connexion : un speedtest consomme réellement de la bande passante et peut gêner les autres usages.

Client officiel, paquet distro ou alternative ?

Sur Linux, le nom d’une commande ne suffit pas toujours à savoir ce que vous utilisez. Selon les distributions, un paquet peut installer le client officiel, un wrapper communautaire ou une ancienne variante. Avant d’automatiser une mesure, lancez speedtest --version, regardez les options disponibles et vérifiez si la sortie correspond bien à ce que votre script attend.

• Usage personnel : installation simple, test manuel, lecture directe du résultat.
• Serveur distant : sortie machine-readable, faible dépendance, exécution ponctuelle.
• Monitoring : version documentée, fréquence maîtrisée, stockage homogène.
• Dossier support : méthode répétable, conditions notées, test Ethernet prioritaire.

Utiliser iperf3 pour un vrai diagnostic réseau

iperf3 ne teste pas directement votre abonnement Internet. Il mesure le débit entre deux machines que vous contrôlez. C’est précisément ce qui le rend utile pour isoler une cause : câble Ethernet fatigué, Wi-Fi saturé, VLAN mal configuré, tunnel VPN limité ou serveur local qui plafonne. Si le problème est interne, un speedtest externe peut donner une impression rassurante tout en laissant la vraie panne intacte.

# Sur la machine qui reçoit le test
iperf3 -s

# Sur la machine cliente
iperf3 -c 192.168.1.20

Si iperf3 montre un réseau local sain mais que Speedtest reste mauvais, le problème se situe plus probablement côté accès Internet, routeur, DNS, peering ou serveur de test. Si iperf3 plafonne déjà en local, commencez par le câble, le port, le Wi-Fi, le switch ou la carte réseau.

Ping, jitter et stabilité : le débit ne dit pas tout

Un débit élevé peut masquer une connexion pénible à utiliser. Pour le jeu en ligne, le cloud gaming, la visio ou le SSH, la latence et sa régularité comptent autant que le nombre de mégabits. Un ping bas mais instable provoque des micro-coupures; un upload saturé peut dégrader une visioconférence alors que le download reste correct.

• Ping vers le routeur : repère un souci Wi-Fi, LAN, câble ou carte réseau.
• Ping vers l’extérieur : observe le chemin Internet et la stabilité au-delà de la box.
• Speedtest ponctuel : donne une photo du débit à un instant précis.
• iperf3 : vérifie un lien interne entre deux machines contrôlées.

ping -c 20 192.168.1.1
ping -c 20 1.1.1.1

Interprétez toujours ces commandes avec prudence. Certaines destinations limitent les réponses ICMP, et un routeur peut prioriser son trafic utile plutôt que les réponses au ping. Ce n’est pas grave : l’objectif est de repérer une tendance, pas de transformer un seul chiffre en verdict définitif.

Tester un téléchargement avec curl ou wget

• Fichier connu : choisissez une source stable, pas un serveur douteux ou surchargé.
• Sortie vers /dev/null : vous mesurez le transfert sans conserver le fichier.
• Comparaison utile : testez plusieurs sources si un miroir Linux semble lent.
• Lecture prudente : ce résultat décrit un chemin précis, pas toute la ligne.

curl -L -o /dev/null https://exemple.org/fichier-test.iso
wget -O /dev/null https://exemple.org/fichier-test.iso

Ce test doit rester prudent : le serveur distant peut être lent, limité ou éloigné. Il ne faut donc pas conclure trop vite que votre accès Internet est en cause. La bonne lecture consiste à comparer plusieurs sources fiables, à noter l’heure et à vérifier si le phénomène se reproduit.

Automatiser sans transformer le test en bruit

Automatiser un test de débit peut aider à documenter une panne intermittente. C’est particulièrement utile si la connexion chute le soir, si un routeur redémarre, si un lien 4G/5G de secours varie beaucoup ou si vous devez fournir des éléments factuels à un support technique. L’automatisation doit rester raisonnable : un test trop fréquent consomme du débit, perturbe parfois les usages que vous essayez d’observer et finit par produire un historique difficile à relire. Mieux vaut quelques mesures bien annotées qu’une masse de chiffres sans contexte.

Un fichier CSV quotidien suffit souvent. Pour un serveur ou un homelab, vous pouvez ensuite afficher les résultats dans Grafana, Prometheus ou un simple tableau. L’objectif n’est pas de produire de jolies courbes, mais de repérer une dégradation répétable.

Un exemple de journal minimal

Un journal simple suffit souvent, à condition qu’il reste lisible plusieurs jours plus tard et utile pour expliquer le contexte.

Pour documenter une panne, mieux vaut un fichier compréhensible qu’un script ambitieux que personne ne maintient. Vous pouvez écrire une ligne par mesure avec la date, l’outil, le contexte et un commentaire. Même sans automatisation complète, cette trace aide à discuter avec un support, un hébergeur ou un administrateur réseau.

date -Is >> debit.log
speedtest --format=json >> debit.log
echo "ethernet, routeur salon, backup arrêté" >> debit.log

Gardez ce journal lisible. Si vous devez l’expliquer trois semaines plus tard, vous devez comprendre rapidement quelles mesures ont été faites en Wi-Fi, en Ethernet, avec VPN ou pendant une panne. La qualité des notes compte presque autant que la commande utilisée.

Les erreurs qui faussent les mesures

• Tester en Wi-Fi faible puis accuser directement la fibre.
• Comparer deux serveurs différents comme s’ils étaient identiques.
• Lancer un test pendant une sauvegarde, un téléchargement ou une mise à jour.
• Ignorer l’upload alors que le problème touche visio, cloud ou streaming.
• Oublier la latence pour le jeu en ligne, le cloud gaming et le SSH.
• Multiplier les tests sans noter les conditions exactes.

Un speedtest parfait ne garantit pas une expérience parfaite. Un jeu peut souffrir de latence instable, une visio peut dépendre de l’upload, et un téléchargement peut être limité par le serveur distant. Le chiffre de débit est un indice, pas un verdict complet.

Le bon réflexe selon votre situation

• PC Linux de bureau : lancez speedtest en Ethernet, puis comparez avec le Wi-Fi.
• Serveur distant : utilisez un test sobre et ponctuel pour ne pas perturber les services.
• Réseau local : passez à iperf3 entre deux machines fiables.
• Dossier FAI : gardez des mesures datées, répétées et prises dans des conditions comparables.

Si vous cherchez à documenter un problème auprès d’un FAI, gardez des mesures propres : date, heure, connexion filaire, outil utilisé, serveur et symptômes constatés. Un dossier simple, répété sur plusieurs créneaux, vaut mieux qu’une capture isolée prise au pire moment. Il permet aussi de distinguer une panne réelle de ligne, une saturation Wi-Fi, un serveur distant lent ou une mauvaise fenêtre de test. C’est cette régularité qui transforme une commande Linux en diagnostic crédible, pas le nombre de tests lancés.

Pour approfondir ce point, consultez Realme Watch 5 : une smartwatch complète, qui traite plus précisément de realme watch 5 : une smartwatch complète sous les 50 € qui séduit avec son style.