Réseau lent : 7 commandes pour isoler le goulot

Il y a des pannes réseau qui crient tout de suite. Une interface down, une route manquante, un DNS mort. Et puis il y a le pire. Le réseau « marche », mais tout est lent. Les pages chargent, mais ça mouline. Le SSH répond, mais avec une seconde de retard. Le SaaS est « utilisable », mais tout le monde se plaint.

Et là, si tu es SysAdmin, ou juste la personne qu’on appelle dès que « ça rame », tu as besoin d’un plan simple. Pas d’un audit de 3 jours. Juste : isoler le goulot. Est ce que c’est le Wi-Fi ? Le DNS ? La latence ? La MTU ? La saturation ? Une perte de paquets ? Un routeur qui a décidé de mourir lentement ?

Je te propose 7 commandes très concrètes, celles que je lance quasiment par réflexe. Tu peux les enchaîner en 10 minutes et obtenir une hypothèse solide.

Petit rappel au passage, parce que je le répète souvent sur Le Blog Tech Pro de Samyn-Antoy ABASSE (https://monblog-sa-abasse.blogspot.com) : quand tu diagnostiques, tu veux des mesures. Même simples. Même « moches ». Mais des mesures.

1) ip a, ip r : vérifier les bases sans s’endormir

On commence basique, mais pas optionnel. Parce que tu peux perdre 30 minutes à ping un serveur… alors que tu es sur la mauvaise IP, ou que ta route par défaut n’est pas celle que tu crois.

bash ip a ip r

Ce que tu cherches :

• l’interface réellement utilisée (eth0 ? wlan0 ? tun0 ? docker0 qui pollue ?)
• une IP correcte, le bon masque
• la route par défaut (default via … dev …)
• des routes bizarres apparues via VPN, overlay, ou un vieux script réseau

Astuce rapide : si tu es sur un poste avec plusieurs interfaces, la lenteur peut venir d’un mauvais choix de route. Exemple typique : le trafic part sur un VPN split-tunnel mal fichu, ou sur une interface Wi-Fi faible alors que l’Ethernet est branché.

Tu peux aussi vérifier rapidement « comment je sors vers internet » :

bash ip route get 1.1.1.1

Ça te dit l’interface, la passerelle, et l’IP source choisie.

Dans certains cas, le tunnel de vente parfait pourrait être la solution à envisager pour optimiser certaines connexions réseau.

De plus, si vous êtes dans un environnement mixte avec des utilisateurs utilisant à la fois Linux et Windows, il pourrait être utile de comprendre les différences clés entre ces deux systèmes d'exploitation afin d'optim

2) ping : mesurer la latence et détecter la perte, sans interpréter n’importe comment

Oui, ping est vieux. Oui, ça reste utile. Mais il faut savoir quoi ping.

Je fais souvent ce trio :

bash ping -c 20 <ta_passerelle> ping -c 20 1.1.1.1 ping -c 20 google.com

Lecture rapide :

• si la passerelle est déjà haute en latence ou avec perte : problème local (Wi-Fi, câble, switch, NIC, CPU routeur local)
• si passerelle OK mais 1.1.1.1 mauvais : problème FAI ou routage amont
• si 1.1.1.1 OK mais google.com lent : suspect DNS (ou filtrage, ou proxy)

Un point important : la latence moyenne ne suffit pas. Regarde aussi :

• le min/avg/max/mdev
• les pics (max très haut)
• la perte (même 1 % peut casser du TCP de manière bien visible)

Tu peux ajouter un intervalle plus agressif pour voir une instabilité :

bash ping -i 0.2 -c 50 1.1.1.1

Et si ping est bloqué chez toi (ça arrive), passe directement à curl plus bas.

3) mtr : le mix parfait entre traceroute et ping

Quand j’ai une seule commande à garder pour « réseau lent », c’est souvent mtr.

Installe si besoin :

bash sudo apt-get install -y mtr-tiny

ou bash sudo dnf install -y mtr

Puis :

bash mtr -rwzbc 100 1.1.1.1

Options utiles :

• -r mode rapport
• -w format large
• -z éviter de spammer avec des DNS inverses
• -b affiche l’IP et le nom si dispo
• -c 100 100 probes

Ce que tu veux voir :

• à quel saut la latence explose
• si la perte apparaît à un saut précis

Attention, nuance importante : certains routeurs « limitent » les réponses ICMP et affichent de la perte dans mtr, alors que le trafic traverse bien. Le signal le plus fiable : la perte et la latence sur le dernier saut, ou à partir d’un point et qui continue sur les sauts suivants.

Si tu vois 0 % au dernier saut mais 30 % au milieu, ça peut être juste du rate-limit ICMP. Ne panique pas trop vite.

Pour optimiser ton utilisation de ces outils, il serait bénéfique d'intégrer certaines compétences en prompt engineering qui pourraient t'aider à formuler des requêtes plus efficaces.

En outre,

4) dig : diagnostiquer un DNS lent (le faux coupable numéro 1)

Le DNS lent est sournois. Parce qu’on a l’impression que « internet est lent », alors que ce sont juste les résolutions qui prennent 800 ms. Et ça ruine tout : navigation, connexions API, packages, etc.

Commande :

bash dig google.com

Mais surtout, mesure le temps :

bash dig google.com | grep "Query time"

Fais pareil sur plusieurs domaines, et compare.

Test très parlant : interroger un résolveur différent.

bash dig @1.1.1.1 google.com dig @8.8.8.8 google.com dig @9.9.9.9 google.com

Si ton DNS local est lent et les autres sont rapides, tu tiens un suspect.

Autre test, vérifier la chaîne de résolution. Exemple : si tu as un systemd-resolved local, un DNS d’entreprise, un DoH dans le navigateur… tu peux avoir des chemins différents selon les applis. Et donc une lenteur « bizarre » qui n’apparaît pas partout.

Sur Linux, j’aime bien regarder :

bash resolvectl status

Ou si tu es sur une distro plus classique :

bash cat /etc/resolv.conf

5) curl : mesurer le temps de connexion, TLS, et première réponse (TTFB)

Quand on me dit « le site est lent », je veux découper le temps : DNS, connexion TCP, handshake TLS, TTFB, téléchargement.

curl le fait très bien.

bash curl -o /dev/null -s -w
"namelookup:%{time_namelookup}\nconnect:%{time_connect}\nappconnect:%{time_appconnect}\nstarttransfer:%{time_starttransfer}\ntotal:%{time_total}\n"
https://example.com

Interprétation rapide :

• time_namelookup haut : DNS
• time_connect haut : latence réseau, firewall, SYN retransmits, saturation
• time_appconnect haut : TLS lent (CPU, inspection SSL, proxy)
• time_starttransfer haut : serveur lent ou congestion côté serveur, ou paquet perdu qui retarde la fenêtre TCP
• total haut mais starttransfer faible : téléchargement lent (débit)

Et là tu peux tester un endpoint externe fiable pour comparer, par exemple un gros CDN. Si tout est lent partout, c’est réseau. Si seulement ton service est lent, c’est app ou infra.

Tu peux aussi faire un test HTTP sans TLS pour isoler l’étape :

bash curl -I http://example.com curl -I https://example.com

Différence énorme entre les deux ? TLS/proxy/inspection.

Pour une compréhension plus approfondie des problèmes de lenteur de serveur et des solutions potentielles à ces problèmes, je te recommande de lire cet article sur l'autopsie d'un serveur lent.

Si tu souhaites explorer davantage les distributions Linux et leurs caractéristiques respectives pour mieux diagnostiquer ces problèmes de lenteur du DNS ou du serveur en général, cet article sur [les 7 distributions Linux à suivre

6) ss et iperf3 : voir si c’est la saturation, et si TCP souffre

Quand c’est « lent », c’est parfois juste… saturé. Un backup qui tourne. Une sync cloud. Un poste qui upload en continu. Une VM qui cause.

Voir les connexions et l’état TCP

Utiliser la commande bash ss -s te donne un résumé (established, timewait, etc). Pour des infos TCP utiles, tu peux exécuter ss -ti. Parfois tu vois des retransmissions ou une congestion.

Sur certaines machines, tu peux repérer vite des symptômes : beaucoup de retransmits, des fenêtres réduites, des connexions qui stagnent.

Mesurer le débit brut avec iperf3

Si tu as la main sur deux machines (client et serveur) sur le même réseau, iperf3 est incroyable pour isoler : « le lien peut il faire 900 Mbps ou pas ? ».

Sur le serveur :

bash iperf3 -s

Sur le client :

bash iperf3 -c <ip_du_serveur> -P 4

• -P 4 lance plusieurs flux, souvent plus représentatif
• tu peux tester l’upload aussi :

bash iperf3 -c <ip_du_serveur> -R

Si tu obtiens un débit très bas sur LAN, ce n’est pas ton FAI. C’est local : câble, duplex, switch, driver, VM host surchargé, QoS foireuse, Wi-Fi en pls.

Et si le LAN est bon mais internet est mauvais, tu remontes plus haut : routeur, modem, FAI, peering.

7) tcpdump : capturer 30 secondes et arrêter de deviner

Je sais. tcpdump fait peur. Mais pour un réseau lent, tu n’as pas besoin d’être un expert Wireshark tout de suite. Tu veux juste confirmer un truc : pertes, retransmissions, DNS qui traîne, handshake qui recommence.

Exemples simples.

Pour aller plus loin dans l'analyse de tes commandes Linux utilisées pour diagnostiquer ces problèmes réseau, je te recommande de consulter cet article sur 25 commandes Linux qui sauvent.

Si tu es intéressé par l'automatisation des processus business à travers l'IA en 2026 ou les frameworks comme AARRR en 2025, je te suggère de jeter un œil à ces articles respectifs sur le framework AARRR en 2025 et business automatisé par IA en 2026.

Capturer un test ping ou un flux vers un hôte

bash sudo tcpdump -i eth0 host 1.1.1.1

Capturer DNS

bash sudo tcpdump -i eth0 port 53

Tu lances, tu refais ton test (un dig, un curl), tu observes.

Signaux utiles même en brut :

• répétition de requêtes DNS (le client redemande car pas de réponse)
• retransmissions TCP (tu verras des séquences qui reviennent)
• SYN envoyés plusieurs fois (connexions qui peinent à s’établir)

Tu peux enregistrer un fichier et l’analyser après :

bash sudo tcpdump -i eth0 -w capture.pcap

Puis tu ouvres dans Wireshark si tu veux aller plus loin.

Comment enchaîner ces 7 commandes en 10 minutes (ordre conseillé)

Parce que le vrai problème, ce n’est pas les commandes. C’est l’ordre. Tu ne veux pas partir dans tous les sens.

1. ip a et ip r : suis je sur la bonne interface, bonne route, bon gateway ?
2. ping gateway puis ping 1.1.1.1 : local vs internet.
3. dig et test sur résolveurs publics : DNS ou pas DNS.
4. curl -w : quelle étape est lente exactement.
5. mtr vers une IP fiable : où ça se dégrade dans le chemin.
6. ss puis iperf3 si possible : saturation, santé TCP, débit réel.
7. tcpdump : preuve rapide quand tu dois escalader, ou quand tu as un doute.

Ce workflow évite le piège classique : « ça rame » donc on redémarre le routeur. Parfois ça marche, oui. Mais tu n’as rien appris, et ça reviendra.

En parlant d'apprentissage et d'amélioration continue, il est intéressant de noter que les approches de développement logiciel évoluent également avec le temps, comme le montre cette analyse sur la transition entre no-code et low-code prévue pour 2026.

Deux pièges fréquents (et franchement énervants)

Piège 1 : la MTU

Symptôme typique : certains sites marchent, d’autres pas. Ou ça charge, puis ça bloque sur des gros transferts. VPN et PPPoE adorent créer ça.

Tu peux tester un ping avec taille et DF (ne pas fragmenter) :

bash ping -M do -s 1472 -c 3 1.1.1.1

Si ça échoue, baisse progressivement (1464, 1452, etc). Si tu découvres que ta MTU effective est plus basse que prévu, tu as une piste solide.

Piège 2 : le Wi-Fi « presque bon »

Le Wi-Fi peut te donner 200 Mbps en speedtest et pourtant être horrible pour la latence et la stabilité. Micro coupures, roaming, interférences, power saving.

Si tu suspectes le Wi-Fi : teste en Ethernet. Même 5 minutes. Juste pour trancher.

Petit mot de fin

L’intérêt de ces 7 commandes, ce n’est pas de faire « hacker ». C’est de te donner une histoire claire : où ça ralentit, à partir de quand, et quel composant est probablement responsable.

Si tu veux, je peux aussi faire une fiche plus orientée « checklist production » à coller dans un runbook, avec un modèle de rapport d’incident (quoi copier, quoi screenshot). Je poste ce genre de ressources sur Le Blog Tech Pro de Samyn-Antoy ABASSE (https://monblog-sa-abasse.blogspot.com), donc garde le lien sous la main si tu reviens souvent sur ces sujets.

Et la prochaine fois qu’on te dit « le réseau est lent », au moins tu ne pars pas à l’aveugle. Tu mesures. Puis tu coupes le problème en morceaux. C’est tout.

Questions fréquemment posées

Quelles sont les premières commandes à utiliser pour diagnostiquer un réseau lent ?

Pour commencer un diagnostic rapide d'un réseau lent, il est essentiel d'utiliser les commandes basiques comme ip a et ip r pour vérifier les interfaces réseau, les adresses IP et les routes par défaut. Cela permet de s'assurer que vous êtes sur la bonne interface avec une configuration correcte avant d'aller plus loin.

Comment interpréter efficacement les résultats de la commande ping lors d'un problème de lenteur réseau ?

Il faut pinguer plusieurs cibles : la passerelle locale, une IP publique fiable (comme 1.1.1.1), puis un nom de domaine (comme google.com). Une latence élevée ou perte de paquets à la passerelle indique un problème local, tandis qu'une latence sur 1.1.1.1 signale un souci chez le FAI ou en amont. Si 1.1.1.1 est bon mais google.com lent, suspectez le DNS ou filtrage. Analysez aussi min/avg/max/mdev et pertes même faibles.

Pourquoi utiliser la commande mtr pour diagnostiquer un réseau lent ?

mtr combine les fonctionnalités de traceroute et ping en fournissant un rapport détaillé sur chaque saut du chemin réseau avec des statistiques de latence et perte de paquets. C'est l'outil idéal pour identifier précisément où se situe le goulot dans la chaîne réseau lorsqu'une lenteur est constatée.

Comment savoir si le Wi-Fi est responsable d'une lenteur réseau ?

En utilisant ping vers la passerelle locale, si vous constatez une latence élevée ou une perte de paquets dès ce stade, cela indique souvent un problème local comme le Wi-Fi faible, un câble défectueux ou un switch défaillant. Vérifier aussi avec ip a quelle interface est utilisée peut révéler que le trafic passe par une interface Wi-Fi faible au lieu d'Ethernet.

Que faire si la commande ping est bloquée dans mon environnement ?

Si ping est bloqué par un pare-feu ou une politique réseau, il est conseillé d'utiliser des commandes alternatives comme curl pour tester la connectivité HTTP/HTTPS vers des serveurs externes afin d'évaluer la latence et la qualité du réseau sans dépendre du protocole ICMP utilisé par ping.

Pourquoi est-il important de prendre des mesures même simples lors du diagnostic réseau ?

Lors du diagnostic d'un problème réseau, obtenir des mesures concrètes – même simples ou imparfaites – permet de baser l'analyse sur des faits objectifs plutôt que sur des suppositions. Cela aide à isoler rapidement le goulot d'étranglement et à formuler une hypothèse solide sans perdre de temps dans des audits complexes.