Commandes réseau UNIX : ping, traceroute, curl, wget
« Le site ne répond pas. » Derrière cette phrase peuvent se cacher une dizaine de causes très différentes : une panne de réseau, un DNS mal configuré, un pare-feu, un serveur web arrêté, un certificat expiré. Les commandes réseau d’Unix servent précisément à trancher entre elles, dans l’ordre.
Ce guide suit cet ordre de diagnostic : la machine répond-elle, le nom se résout-il, le chemin est-il complet, le port est-il ouvert, le service répond-il correctement. À chaque étape, une commande — ping, nslookup, traceroute, curl, wget — et la façon de lire sa réponse.
ping : la machine est-elle joignable ?
ping envoie de petits paquets ICMP et mesure le temps de réponse. C’est le premier test, celui qui distingue un problème de connectivité de tout le reste.
ping richer-solution.com
ping -c 4 8.8.8.8
Sous Linux, ping tourne indéfiniment : l’option -c limite le nombre d’envois, ce qui est presque toujours souhaitable dans un script.
Trois informations dans la réponse :
- le temps, en millisecondes : quelques dizaines sur Internet, moins d’une sur un réseau local ;
- la perte de paquets : au-delà de quelques pourcents, la liaison est dégradée ;
- le TTL, qui donne une indication sur le nombre de routeurs traversés.
Un piège classique mérite d’être connu : l’absence de réponse ne prouve pas que la machine est éteinte. Beaucoup de serveurs et de pare-feu bloquent l’ICMP par principe. Un ping qui échoue sur un site web dont les pages s’affichent normalement n’est pas une anomalie.
Deux options utiles pour aller plus loin :
ping -c 100 -i 0.2 serveur.local
ping -s 1400 serveur.local
La première teste la stabilité sur une centaine d’envois rapprochés — c’est ainsi qu’on met en évidence une perte intermittente. La seconde envoie des paquets plus gros, et révèle parfois un problème de MTU : tout passe en petits paquets, rien ne passe en gros.
nslookup et dig : le nom se résout-il ?
Si le ping échoue avec « nom ou service inconnu », le problème n’est pas le réseau mais le DNS.
nslookup richer-solution.com
dig richer-solution.com
dig +short richer-solution.com
dig est plus précis et plus lisible pour qui travaille régulièrement sur le DNS ; nslookup est présent partout, y compris sous Windows. L’option +short ne renvoie que la réponse, sans l’appareil de diagnostic — pratique dans un script.
Pour interroger un serveur DNS particulier plutôt que celui du système :
dig @8.8.8.8 richer-solution.com
dig @ns1.vps.richer-solution.com richer-solution.com
C’est la manœuvre décisive lors d’un changement d’enregistrement : interroger le serveur faisant autorité donne la valeur réelle, immédiatement, tandis qu’un serveur public peut encore servir l’ancienne valeur pendant la durée de propagation.
Les types d’enregistrement se demandent explicitement :
dig richer-solution.com MX
dig richer-solution.com TXT
dig richer-solution.com NS
dig -x 8.8.8.8
La dernière forme fait la résolution inverse : d’une adresse IP vers un nom.
traceroute : où le chemin s’arrête-t-il ?
Quand la machine répond mal ou pas du tout, traceroute montre les routeurs traversés et celui où ça bloque.
traceroute richer-solution.com
tracepath richer-solution.com
Chaque ligne correspond à un saut. Trois mesures par saut donnent une idée de la stabilité.
La lecture demande une précaution : des étoiles au milieu du parcours ne signalent pas une panne. Beaucoup de routeurs intermédiaires refusent de répondre par politique, sans gêner le transit. Ce qui compte, c’est l’endroit où le parcours s’interrompt définitivement — et s’il atteint bien la destination.
Un saut où le temps bondit de 20 à 300 millisecondes indique une congestion à ce point du réseau, souvent hors de votre portée. mtr, s’il est installé, combine ping et traceroute en continu et rend ce diagnostic bien plus lisible :
mtr richer-solution.com
Le port est-il ouvert ?
Un serveur qui répond au ping mais pas à la requête a souvent un port fermé — pare-feu, ou service arrêté. Plusieurs outils répondent :
nc -zv richer-solution.com 443
telnet richer-solution.com 443
timeout 3 bash -c "</dev/tcp/richer-solution.com/443" && echo ouvert
La troisième forme n’exige aucune installation : elle utilise une fonctionnalité du shell bash lui-même, ce qui dépanne sur un serveur minimal où ni nc ni telnet ne sont présents.
Côté machine locale, pour savoir quels ports écoutent :
ss -ltnp
ss -ltnp | grep 443
ss remplace l’ancien netstat. L’option -p affiche le processus propriétaire, ce qui demande généralement les droits root.
curl : interroger un service
C’est l’outil le plus polyvalent de la liste. Pour un diagnostic, trois formes suffisent le plus souvent.
Les en-têtes seuls, sans télécharger la page :
curl -I https://richer-solution.com/
Vous y lisez le code de réponse — 200, 301, 404, 500 — et les en-têtes du serveur. Le détail de ces codes fait l’objet d’un article dédié sur les codes d’erreur HTTP.
Le code seul, pour un script ou une surveillance :
curl -s -o /dev/null -w "%{http_code}\n" https://richer-solution.com/
-s supprime la barre de progression, -o /dev/null jette le contenu, -w n’affiche que ce qu’on demande. C’est la commande de contrôle par excellence.
Le détail des temps, pour distinguer un DNS lent d’un serveur lent :
curl -s -o /dev/null -w "dns:%{time_namelookup} connexion:%{time_connect} tls:%{time_appconnect} total:%{time_total}\n" https://richer-solution.com/
Cette ligne répond seule à « pourquoi le site est lent » : si time_namelookup domine, c’est le DNS ; si time_appconnect domine, c’est la négociation TLS ; si l’écart se fait sur le total, c’est le serveur.
Pour suivre les redirections plutôt que de s’arrêter au premier 301 :
curl -IL https://richer-solution.com/mentions/
Et pour tester une API, avec méthode, en-têtes et corps :
curl -X POST https://api.exemple.fr/v1/objets \
-H "Content-Type: application/json" \
-H "Authorization: Bearer jeton" \
-d '{"nom":"essai"}'
Notre article sur les API et données publiques détaille ce type d’usage.
wget : télécharger
Là où curl interroge, wget télécharge — et insiste. Il reprend après coupure, suit les liens, et copie un site entier si on le lui demande.
wget https://exemple.fr/archive.tar.gz
wget -c https://exemple.fr/gros-fichier.iso
wget -O rapport.pdf https://exemple.fr/doc?id=42
L’option -c est celle qui justifie souvent le choix de wget : elle reprend un téléchargement interrompu au lieu de recommencer.
Pour récupérer une arborescence :
wget -r -np -k -p https://exemple.fr/documentation/
Les quatre options comptent : -r descend récursivement, -np interdit de remonter au-dessus du dossier de départ, -k réécrit les liens pour une consultation hors ligne, -p récupère images et feuilles de style.
Sur un site tiers, ajoutez une temporisation pour ne pas être pris pour une attaque :
wget -r -np --wait=1 --limit-rate=200k https://exemple.fr/docs/
Vérifier un certificat
Un certificat expiré produit des erreurs difficiles à interpréter côté navigateur. La vérification est directe :
echo | openssl s_client -connect richer-solution.com:443 2>/dev/null \
| openssl x509 -noout -dates -subject
Vous obtenez les dates de validité et le nom couvert. Un certificat valide mais délivré pour un autre nom de domaine est une cause fréquente d’alerte, et elle n’apparaît que par ce contrôle.
Une séquence de diagnostic
Dans l’ordre, chaque étape éliminant une famille de causes :
ping -c 3 exemple.fr # la machine répond-elle ?
dig +short exemple.fr # le nom se résout-il ?
traceroute exemple.fr # le chemin aboutit-il ?
nc -zv exemple.fr 443 # le port est-il ouvert ?
curl -I https://exemple.fr/ # le service répond-il ?
La première commande qui échoue désigne la couche fautive. C’est la valeur de cette séquence : elle évite de chercher une erreur de configuration applicative quand le problème est un enregistrement DNS, ou l’inverse.
Sur un poste plutôt qu’un serveur, les mêmes symptômes ont souvent des causes plus prosaïques — notre article sur les problèmes de connexion Wi-Fi les passe en revue.
En résumé
ping -c 4en premier, mais un ping sans réponse ne prouve rien : l’ICMP est souvent bloqué ;dig +shortpour la résolution,dig @serveurpour interroger l’autorité et contourner la propagation ;traceroutepour localiser la rupture — les étoiles au milieu sont normales ;nc -zvpour un port, ou la redirection/dev/tcpde bash quand rien n’est installé ;curl -Ipour les en-têtes,-w "%{http_code}"pour la surveillance,-wavec les temps pour diagnostiquer une lenteur ;wget -cpour reprendre un téléchargement,-r -nppour une arborescence ;openssl s_clientpour les dates d’un certificat ;- et surtout : suivre la séquence dans l’ordre, la première commande qui échoue désigne la cause.