Diagnostiquer une lenteur réseau
ping, mtr et traceroute : mesurer au bon endroit, lire une perte de paquets sans se tromper, et savoir quoi nous transmettre.
« Le serveur rame » peut vouloir dire deux choses très différentes : la machine est occupée, ou le chemin réseau est mauvais. Les distinguer prend une minute et évite de chercher au mauvais endroit pendant une heure.
D'abord, écarter la machine
Connectez-vous en SSH et regardez la charge. Si la machine est calme et que le site reste lent depuis chez vous, le problème est sur le chemin. Le guide sur la surveillance détaille cette étape.
ping : la latence de base
ping -c 20 203.0.113.10Depuis la France vers Paris, comptez 5 à 30 ms selon votre opérateur. Ce qui compte n'est pas tant la moyenne que l'écart : des temps qui sautent de 12 à 300 ms trahissent une saturation quelque part.
Un ping qui ne répond pas ne veut rien dire
Beaucoup d'équipements limitent ou ignorent l'ICMP, et lui donnent la plus basse priorité. Un routeur intermédiaire qui affiche 200 ms dans un traceroute peut très bien acheminer votre trafic parfaitement : il répond aux pings quand il a le temps.
mtr : l'outil qui répond vraiment
sudo apt install mtr-tiny
mtr -rwzbc 100 203.0.113.10mtr combine ping et traceroute et fait cent mesures par saut. C'est ce qu'il faut nous envoyer : un traceroute simple ne montre qu'un instantané, mtr montre le comportement dans la durée.
Lire une perte de paquets
C'est là que presque tout le monde se trompe. Une perte affichée sur un saut intermédiaire, qui disparaît sur les suivants, n'est pas une perte : c'est le routeur qui a mieux à faire que de répondre. Seule la perte qui commence à un saut et se poursuit jusqu'à la destination compte.
| Ce que montre mtr | Interprétation |
|---|---|
| 30 % au saut 5, 0 % ensuite | Un routeur qui déprioritise l'ICMP — rien à signaler |
| 0 %, puis 12 % au saut 7 et jusqu'au bout | Perte réelle à partir du saut 7 |
| Latence qui bondit et reste haute | Saturation d'un lien à partir de ce point |
| Le dernier saut ne répond pas | Le pare-feu de la destination ignore l'ICMP, c'est courant |
Mesurer dans les deux sens
Internet n'est pas symétrique : l'aller et le retour empruntent souvent des chemins différents, et le problème peut n'être que sur l'un des deux. Lancez donc un mtr depuis votre poste vers le serveur, et un autre depuis le serveur vers votre adresse.
Ce qu'il faut nous envoyer
Un ticket avec les deux mtr en texte — pas en capture d'écran, on ne peut rien y chercher — votre adresse IP publique, l'heure précise du problème et ce que vous constatez côté application. Avec ça, on peut regarder nos propres mesures au même instant. Sans ça, on ne peut que demander la même chose.
Vérifier le débit, pas seulement la latence
sudo apt install iperf3
# Sur le serveur :
iperf3 -s
# Depuis votre poste :
iperf3 -c 203.0.113.10 -t 20Un débit très inférieur à ce que vous payez, avec une latence normale, oriente vers un problème de fenêtre TCP ou de MTU plutôt que vers une saturation.
Bloqué malgré tout ? Ouvrez un ticket : on répond en français, et on regarde votre machine si besoin.
Ouvrir un ticket