Méthodologie de diagnostic réseau

Un message d'erreur réseau ne nomme jamais sa cause : il nomme ce que la pile réseau du noyau a constaté. Connection refused sort aussi bien d'un service arrêté que d'un pare-feu qui rejette proprement. No route to host s'affiche alors que la route existe. Ce guide donne la correspondance mesurée entre chaque message et l'ensemble des causes qui le produisent, puis la méthode pour les départager. Il s'adresse à qui administre des serveurs Linux et veut arrêter de chercher au mauvais endroit.

Ce que vous allez apprendre

• Traduire un message d'erreur en liste complète de causes, jamais en cause unique.
• Distinguer les codes d'erreur du noyau : ECONNREFUSED, ETIMEDOUT, EHOSTUNREACH, ENETUNREACH.
• Suivre une méthode de diagnostic, du plus proche au plus loin, qui teste le protocole réellement en panne.
• Lire les quatre échecs DNS et savoir lequel désigne quoi.
• Reproduire ces mesures vous-même, dans une machine virtuelle, sans rien casser.

Prérequis

• Avoir suivi les modules précédents (IP, DNS, TCP/UDP, ICMP, HTTP)
• Un terminal Linux, macOS ou WSL
• Connaissance des commandes ip, ping, dig, nc, curl, ss

Ce guide est une synthèse

Vous n'avez pas besoin de maîtriser parfaitement chaque outil. L'important est de savoir quel outil utiliser pour quel symptôme, et de ne jamais tirer d'un message d'erreur plus que ce qu'il dit.

Que renvoie vraiment le noyau selon la panne ?

Toutes les mesures de cette page viennent d'une même série, rejouée sur Debian 13 (noyau 6.12.107, nftables 1.1.3, iproute2 6.15.0), dans des espaces de noms réseau isolés. Un petit programme tente un connect() TCP et affiche le numéro d'erreur rendu par le noyau, sans l'interpréter. C'est la seule façon de séparer ce qu'on croit de ce que la pile répond.

Le tableau ci-dessous est le cœur du guide. Lisez-le dans le sens qui compte : une même erreur apparaît sur plusieurs lignes.

Situation réelle	Code	Nom	Message affiché
Aucun service n'écoute sur le port	111	ECONNREFUSED	Connection refused
Pare-feu nft ... reject	111	ECONNREFUSED	Connection refused
Pare-feu nft ... drop	110	ETIMEDOUT	Connection timed out
Pare-feu reject with icmpx type admin-prohibited	113	EHOSTUNREACH	No route to host
Route de type unreachable	113	EHOSTUNREACH	No route to host
Route de type prohibit	13	EACCES	Permission denied
Route de type blackhole	22	EINVAL	Invalid argument
Aucune route vers la destination	101	ENETUNREACH	Network is unreachable

Glissez pour voir

Trois enseignements en sortent, et ils contredisent les raccourcis les plus répandus. Deux causes opposées donnent le même ECONNREFUSED. No route to host s'affiche sans qu'aucune route ne manque. Et le vrai cas « pas de route » produit un message que personne ne cite, Network is unreachable. La page ICMP et ping détaille les messages du protocole qui portent ces refus.

Où lire la liste officielle

Ces codes ne sont pas une convention de distribution : ils sont normalisés par la page de manuel connect(2), section ERRORS. La commande errno 111 du paquet moreutils traduit un numéro en nom, et perror fait de même dans un programme.

« Connection refused » veut-il dire que rien n'écoute ?

Non. ECONNREFUSED signifie exactement une chose : une réponse négative est revenue tout de suite. Qui a répondu, et pourquoi, reste entier. Trois situations produisent ce message, et la première est seulement la plus fréquente.

• Aucun processus n'écoute sur ce couple adresse/port. Le noyau de la machine distante répond lui-même.
• Un pare-feu rejette la demande. Le service peut tourner, écouter, et fonctionner parfaitement pour d'autres adresses.
• Un équipement intermédiaire (répartiteur de charge, proxy, garde-barrière) répond par un reset à la place de la destination.

La différence se voit sur le fil, et elle surprend. La capture relève la réponse dans les trois cas où l'appelant reçoit le même ECONNREFUSED :

Cause	Ce qui revient réellement
Port fermé, aucun filtrage	TCP RST
nft ... reject sans clause with	ICMP port unreachable
nft ... reject with tcp reset	TCP RST

Glissez pour voir

Un pare-feu nftables en famille inet répond par défaut en ICMP, pas par un reset TCP. Qui lance tcpdump en cherchant un Flags [R] ne verra donc rien dans le cas du milieu, et conclura à tort au silence, donc au drop. Le réflexe correct est de capturer icmp or tcp port <numéro>, jamais le seul TCP.

Comment trancher entre service arrêté et pare-feu

La méthode tient en deux commandes, et elle demande un accès à la machine cible. ss répond sur l'écoute, nft sur le filtrage. Aucune des deux ne se déduit de l'autre.

# Sur la machine qui héberge le service : quelqu'un écoute-t-il ?
ss -tlnp | grep ':8080'

# Et si oui, une règle rejette-t-elle malgré tout ?
sudo nft list ruleset | grep -A5 '8080'

Une sortie vide sur ss désigne un service arrêté. Une ligne LISTEN accompagnée d'une règle reject désigne un filtrage, et c'est le cas que le message d'erreur seul ne permet pas de voir. Le guide Pare-feu, qui peut parler à qui couvre l'écriture de ces règles.

« Connection timed out » veut-il dire qu'un pare-feu jette les paquets ?

Non, et c'est l'équivalence la plus coûteuse en temps perdu. ETIMEDOUT dit uniquement que la connexion n'a pas abouti avant l'expiration du délai. Rien n'est revenu, ni refus ni acceptation. Ce silence a beaucoup de sources possibles.

• Un pare-feu en drop, effectivement, sur l'aller ou sur le retour.
• Une perte de paquets sur le chemin, sans intention de filtrer.
• Un routage asymétrique : la demande arrive, la réponse part ailleurs.
• Un serveur saturé dont la file d'attente d'acceptation déborde.
• Une route de type blackhole en amont, qui jette sans prévenir.

Le point commun de ces causes est qu'aucune ne se distingue depuis le client. Un traceroute situe le dernier équipement qui répond, ce qui aide, mais un routeur muet en ICMP n'est pas forcément celui qui bloque. La mesure croisée depuis une autre machine, ou depuis un autre réseau, reste la façon la plus rapide de séparer un blocage global d'un blocage propre à votre position.

Le délai lui-même est une information

Un refus arrive en quelques millisecondes ; un drop fait attendre le client jusqu'à son délai, souvent plusieurs secondes. Chronométrer avec time nc -zv <hôte> <port> distingue donc les deux familles avant même de lire le message.

« No route to host » veut-il dire que la route manque ?

Non, dans les deux sens. Ce message correspond à EHOSTUNREACH, et la mesure montre qu'il apparaît sans aucune route manquante, tandis que l'absence réelle de route en produit un autre. La table de routage connaît quatre états pour une destination, et chacun a son erreur.

État de la destination	Commande qui le crée	Code	Message
Aucune route ne correspond	(table vide)	ENETUNREACH	Network is unreachable
Route unreachable	ip route add unreachable 198.51.100.0/24	EHOSTUNREACH	No route to host
Route prohibit	ip route add prohibit 198.51.100.0/24	EACCES	Permission denied
Route blackhole	ip route add blackhole 198.51.100.0/24	EINVAL	Invalid argument

Glissez pour voir

La ligne blackhole est la plus déroutante : Invalid argument ne suggère aucun problème de réseau, et c'est pourtant la table de routage qui le produit. Un développeur qui voit cette erreur remontée par sa bibliothèque HTTP ira chercher un bug dans son code, jamais une route.

Quant à EHOSTUNREACH, il sort également d'un ICMP unreachable renvoyé par un routeur ou un pare-feu. Une règle nft ... reject with icmpx type admin-prohibited produit très exactement « No route to host » alors que la route existe, que le paquet est arrivé, et que la machine distante est allumée. Le message décrit ce que le client a appris, pas l'état du réseau. Le module Le routage explique comment lire la table qui produit ces états.

# La question à poser à la table de routage, plutôt que de la lire en entier
ip route get 198.51.100.10

Cette commande affiche la décision que le noyau prendrait, y compris le type de route et l'interface de sortie. Sur une destination sans route, elle répond directement unreachable, ce qui tranche en une ligne.

Pourquoi ping ne prouve pas qu'une machine est joignable

Parce que ICMP et TCP se filtrent séparément. La mesure le montre sans ambiguïté : avec une règle qui jette les seules demandes d'écho, ping rend un code de retour 1 pendant qu'une connexion TCP vers le même hôte aboutit normalement. Conclure « la machine ne répond pas » sur un ping en échec est donc une erreur de raisonnement, pas une approximation.

L'inverse existe aussi : un ping qui passe ne garantit ni que le port applicatif est ouvert, ni que le service répond, ni que TLS négocie. ICMP renseigne sur la couche 3 et sur elle seule.

La règle pratique tient en une phrase : tester le protocole réellement en panne. Si c'est HTTPS qui échoue, c'est HTTPS qu'il faut tester.

# Le protocole en panne, pas son voisin
curl -I --connect-timeout 3 https://blog.stephane-robert.info/
nc -zv blog.stephane-robert.info 443

# ICMP en complément, jamais à la place
ping -c 2 blog.stephane-robert.info

Gardez ping pour ce qu'il fait bien : mesurer une latence, repérer une perte de paquets avec ping -c 100, vérifier qu'une machine du même réseau local répond. Le guide netcat, tester des ports et des flux détaille la vérification par port.

Quels sont les quatre échecs DNS, et que désigne chacun ?

Le DNS n'a pas un mode d'échec mais quatre, et dig les distingue tous. Les confondre sous « le DNS ne marche pas » revient à jeter l'information qui désigne le coupable. Voici ce que la mesure rend, en interrogeant successivement un nom inexistant, un serveur en panne, un port fermé et un serveur muet.

Réponse de dig	Ce qui s'est passé	Où chercher
status: NXDOMAIN	Le serveur affirme que le nom n'existe pas	L'orthographe du nom, la zone interrogée
status: SERVFAIL	Le serveur a reçu la question et ne peut pas répondre	Le serveur amont, une validation DNSSEC en échec
connection refused	Rien n'écoute sur le port 53 de ce serveur	Le service de résolution sur cette machine
no servers could be reached	Aucune réponse n'est revenue	Un filtrage, ou une mauvaise adresse de serveur

Glissez pour voir

La distinction porte parce qu'elle oriente ailleurs à chaque fois. Un NXDOMAIN renvoie à la zone et à ce qu'elle contient ; un SERVFAIL renvoie au serveur interrogé ; un refus renvoie au service qui devrait tourner ; un silence renvoie au chemin réseau. La page Comprendre le DNS reprend ces codes en détail.

Interroger le bon serveur, et pas celui qu'on suppose

Le piège vient avant le diagnostic. Sur une machine moderne gérée par systemd-resolved, /etc/resolv.conf contient nameserver 127.0.0.53, l'adresse d'un relais local, et non celle du serveur qui résout vraiment. Interroger 127.0.0.1 par habitude donne « no servers could be reached » dans tous les cas, ce qui efface la distinction que le tableau ci-dessus rend possible.

# Quel relais local, et quels serveurs derrière lui ?
resolvectl status | grep -A3 'DNS Servers'

# Interroger le relais du système
dig exemple.interne @127.0.0.53

# Puis le serveur amont réel, pour savoir lequel des deux échoue
dig exemple.interne @10.0.0.53

Cette comparaison entre relais et amont tranche une ambiguïté fréquente : un cache local qui répond mal ressemble en tout point à un serveur d'entreprise indisponible.

Ajouter un DNS public ne répare rien

Le réflexe d'écrire nameserver 8.8.8.8 dans /etc/resolv.conf échoue deux fois. Ce fichier est régénéré par NetworkManager ou systemd-resolved, donc la modification disparaît au prochain événement réseau. Et un résolveur public ne connaît pas vos zones internes : il répondra NXDOMAIN sur un nom qui existe bel et bien dans votre entreprise. Le réglage durable passe par resolvectl dns <interface> <adresse>.

La méthode en 5 étapes

La démarche reste la bonne : du plus proche au plus loin. On vérifie la machine locale, puis la passerelle, puis un service distant, puis la résolution de noms, puis le service visé. Chaque étape ajoute une inconnue ; la première qui échoue borne la zone à examiner.

Une seule correction par rapport à la version répandue de cette méthode : l'étape « Internet » ne se teste pas au ping, pour la raison exposée plus haut.

1. Vérifier la connectivité locale

   La machine a-t-elle une adresse, et l'interface est-elle active ?

   ip -brief addr show
   ip -brief link show

   En cas d'échec : interface DOWN, aucune adresse obtenue, bail DHCP non renouvelé.

2. Vérifier la passerelle

   La route par défaut existe-t-elle, et le routeur répond-il ?

   ip route | grep default
   ping -c 2 "$(ip route | awk '/^default/ {print $3; exit}')"

   En cas d'échec : route absente, passerelle éteinte, lien physique coupé. Un ping sans réponse n'exclut pas un routeur qui filtre ICMP.

3. Vérifier la sortie vers Internet

   Une destination publique répond-elle sur le protocole qui vous intéresse ?

   curl -sS -o /dev/null -w '%{http_code}\n' --connect-timeout 3 https://blog.stephane-robert.info/

   En cas d'échec : filtrage sortant, routage cassé, proxy obligatoire non configuré.

4. Vérifier la résolution de noms

   La résolution aboutit-elle, et par quel serveur ?

   resolvectl status | grep 'DNS Servers'
   dig blog.stephane-robert.info +short

   En cas d'échec : lisez le statut renvoyé par dig, il désigne la zone à examiner.

5. Vérifier le service distant

   Le port est-il ouvert, et le service répond-il ?

   nc -zv <hôte> <port>
   curl -I https://<hôte>/

   En cas d'échec : service arrêté, pare-feu applicatif, erreur applicative. Le message exact tranche, selon le tableau de correspondance de cette page.

Les questions clés à se poser

Avant de lancer la moindre commande, quatre questions réduisent le champ de recherche plus vite que n'importe quel outil. Elles portent sur le contexte, que la machine ne connaît pas et que vous êtes seul à pouvoir apporter.

Question	Ce qu'elle élimine
Est-ce que ça marchait avant ?	Si oui, la cause est un changement récent, pas une erreur de conception
Est-ce que ça marche en local ?	Sépare un problème réseau d'un problème applicatif
Est-ce que ça marche depuis une autre machine ?	Sépare un problème client d'un problème serveur
D'autres services sont-ils touchés ?	Sépare une panne globale d'une panne isolée

Glissez pour voir

Le réflexe du « qu'est-ce qui a changé ? »

Un problème réseau qui « fonctionnait avant » vient presque toujours d'un changement récent : mise à jour, modification de configuration, nouvelle règle de pare-feu, bascule DNS. Commencer par l'historique des changements coûte deux minutes et évite souvent une heure de recherche à l'aveugle. Les journaux répondent vite : journalctl -u <service> --since '2 hours ago'.

Checklist de diagnostic rapide

Ce script enchaîne les cinq étapes et affiche, pour chacune, un résultat lisible. Il ne conclut rien à votre place : il collecte, et c'est vous qui lisez. Gardez-le sous la main, il fait gagner du temps sur une machine que vous découvrez.

#!/usr/bin/env bash
# Collecte de diagnostic réseau. Ne corrige rien, n'interprète rien.
set -u

CIBLE="${1:-blog.stephane-robert.info}"
PORT="${2:-443}"

echo "=== 1. Interfaces et adresses ==="
ip -brief addr show

echo -e "\n=== 2. Route par défaut ==="
ip route | grep '^default' || echo "AUCUNE route par défaut"

echo -e "\n=== 3. Passerelle ==="
GATEWAY="$(ip route | awk '/^default/ {print $3; exit}')"
if [ -n "$GATEWAY" ]; then
  ping -c 2 -W 2 "$GATEWAY" || echo "Pas de réponse ICMP (le routeur peut filtrer)"
fi

echo -e "\n=== 4. Résolution de noms ==="
resolvectl status 2>/dev/null | grep -A2 'DNS Servers' || cat /etc/resolv.conf
dig "$CIBLE" +short || true

echo -e "\n=== 5. Service distant, sur son propre protocole ==="
nc -zv "$CIBLE" "$PORT"
curl -sS -o /dev/null -w 'code HTTP : %{http_code}, temps : %{time_total}s\n' \
  --connect-timeout 3 "https://$CIBLE/" || true

Comment le lire : la première étape qui échoue borne la zone du problème, et le message exact de cet échec désigne la cause dans le tableau de correspondance. Notez ce qui réussit autant que ce qui échoue : une étape 3 qui passe alors que l'étape 2 semble muette indique un routeur qui filtre ICMP, pas une passerelle en panne.

Quel outil pour quel symptôme ?

Chaque outil répond à une question précise, et se tait sur les autres. Le tableau ci-dessous évite l'erreur classique qui consiste à demander à ping une réponse qu'il ne détient pas.

Symptôme	Outils	Ce qu'on cherche
Pas d'adresse IP	ip -brief addr, journalctl -u NetworkManager	Interface active, bail DHCP obtenu
Pas de route	ip route get <ip>, traceroute	Décision du noyau, dernier saut qui répond
Résolution en échec	dig, resolvectl status	Statut exact, serveur réellement interrogé
Port fermé ou filtré	nc -zv, ss -tlnp, nmap	Écoute côté serveur, nature du refus
Latence élevée	mtr, ping	Temps aller-retour, saut responsable
Paquets perdus	ping -c 100, mtr	Taux de perte, localisation
Erreur HTTP	curl -v, journaux du serveur	Code de statut, message applicatif
Certificat TLS	openssl s_client -connect <hôte>:443	Validité, chaîne de confiance
Nature d'un refus	tcpdump -ni <interface> 'icmp or tcp port <n>'	TCP RST contre ICMP unreachable

Glissez pour voir

La dernière ligne est celle qu'on oublie. Capturer icmp or tcp, et non le seul TCP, est ce qui permet de voir un reject nftables au lieu de conclure au silence.

Cas pratiques de diagnostic

Trois situations réelles, avec le raisonnement complet. Chacune part d'un message d'erreur et montre comment on remonte à la cause sans sauter d'étape.

Cas 1 : un curl qui expire

Un curl https://api.interne.exemple/health ne rend rien pendant plusieurs secondes, puis expire.

1. Vérifier que le nom résout

   dig api.interne.exemple +short

   Résultat : 203.0.113.42. La résolution fonctionne, le DNS est hors de cause.

2. Chronométrer la tentative de connexion

   time nc -zv 203.0.113.42 443

   Résultat : l'échec survient après 3 secondes d'attente. Ce délai oriente vers un silence, donc un drop, une perte ou une route noire, et écarte le refus immédiat.

3. Vérifier la décision de routage locale

   ip route get 203.0.113.42

   Résultat : une route existe, via la passerelle habituelle. Le problème n'est donc pas sur cette machine.

4. Situer le dernier équipement qui répond

   mtr -rwc 20 203.0.113.42

   Résultat : le chemin s'arrête après le routeur de sortie. Les sauts suivants ne répondent plus.

5. Conclure et transmettre

   Le blocage est en amont de la machine, après le routeur de sortie. Transmettez au responsable réseau le triplet source, destination, port, le délai constaté et la sortie mtr : ces trois éléments évitent l'aller-retour habituel.

Cas 2 : un « Connection refused » sur un service qui tourne

Un curl http://10.0.2.15:8080/api répond Connection refused, alors que l'équipe affirme que le service est démarré.

1. Vérifier l'écoute, sur la machine cible

   ss -tlnp | grep ':8080'

   Résultat : LISTEN 0 4096 0.0.0.0:8080. Le service écoute bien, et sur toutes les adresses.

2. Ne pas s'arrêter là

   Le message d'erreur ne suffit plus à conclure : ECONNREFUSED couvre aussi le rejet par un pare-feu. La suite consiste à chercher ce rejet.

   sudo nft list ruleset | grep -B3 -A3 '8080'

   Résultat : une règle tcp dport 8080 reject dans la chaîne input.

3. Confirmer par la capture

   sudo tcpdump -ni any 'icmp or tcp port 8080'

   Résultat : un paquet ICMP port unreachable revient, et non un Flags [R]. La signature confirme le pare-feu plutôt qu'un port fermé.

4. Corriger au bon endroit

   La correction porte sur la règle de filtrage, pas sur le service. Redémarrer l'application n'aurait rien changé, et aurait coûté une interruption.

Cas 3 : une résolution interne qui échoue

Un curl https://git.interne.exemple/ échoue avec Could not resolve host.

1. Obtenir le statut exact, pas seulement l'absence de réponse

   dig git.interne.exemple

   Résultat : status: SERVFAIL. Le serveur a reçu la question, ce qui écarte d'emblée un problème de joignabilité.

2. Identifier le serveur réellement interrogé

   resolvectl status | grep -A3 'DNS Servers'

   Résultat : Current DNS Server: 10.0.0.53, derrière le relais local 127.0.0.53.

3. Interroger l'amont directement

   dig git.interne.exemple @10.0.0.53

   Résultat : SERVFAIL également. L'échec vient donc bien du serveur d'entreprise, pas du relais local ni du cache.

4. Vérifier que la machine, elle, va bien

   dig blog.stephane-robert.info @10.0.0.53 +short

   Résultat : une adresse revient. Le serveur fonctionne mais échoue sur cette zone précise, ce qui pointe la zone interne ou sa validation, et non la résolution en général.

5. Conclure

   Le constat à transmettre est précis : le serveur 10.0.0.53 rend SERVFAIL sur la zone interne.exemple tout en résolvant correctement le reste. Ajouter un DNS public n'aurait rien réparé, puisque la zone n'y existe pas.

Reproduire ces mesures vous-même

Ces correspondances se vérifient en quelques minutes, et le faire une fois vaut mieux que de retenir un tableau. Tout se joue dans un espace de noms réseau, qui isole le filtrage du reste de la machine : une règle drop posée là ne peut pas couper votre propre session SSH.

Dans une machine virtuelle, jamais sur un poste de travail

Les commandes ci-dessous modifient la table de routage et les règles de filtrage. Elles s'exécutent dans une machine virtuelle jetable, jamais sur un poste de travail ni sur un serveur en service. La page Homelab réseau explique comment en monter une.

# Un espace de noms « cible », relié à l'hôte par une paire veth
sudo ip netns add cible
sudo ip link add veth-h type veth peer name veth-c
sudo ip link set veth-c netns cible
sudo ip addr add 10.99.0.1/24 dev veth-h && sudo ip link set veth-h up
sudo ip netns exec cible ip addr add 10.99.0.2/24 dev veth-c
sudo ip netns exec cible ip link set veth-c up
sudo ip netns exec cible ip link set lo up

# Un service qui écoute, pour disposer d'un témoin positif
sudo ip netns exec cible python3 -m http.server 8080 --bind 10.99.0.2 &

# Témoin positif : sans règle, la connexion doit aboutir
nc -w 3 -zv 10.99.0.2 8080   # succeeded!

Le terrain est prêt. Chaque règle ci-dessous se pose, se teste, puis se remplace par la suivante. Comparez le message et le délai à chaque fois.

# 1. Rejet : réponse négative immédiate
sudo ip netns exec cible nft -f - <<'EOF'
table inet f {
  chain input {
    type filter hook input priority 0; policy accept;
    tcp dport 8080 reject
  }
}
EOF
nc -zv 10.99.0.2 8080        # Connection refused, immédiat

# 2. Rejet déguisé en problème de routage
sudo ip netns exec cible nft flush ruleset
sudo ip netns exec cible nft -f - <<'EOF'
table inet f {
  chain input {
    type filter hook input priority 0; policy accept;
    tcp dport 8080 reject with icmpx type admin-prohibited
  }
}
EOF
nc -zv 10.99.0.2 8080        # No route to host, alors que la route existe

# 3. Silence : le client attend son délai
sudo ip netns exec cible nft flush ruleset
sudo ip netns exec cible nft -f - <<'EOF'
table inet f {
  chain input {
    type filter hook input priority 0; policy accept;
    tcp dport 8080 drop
  }
}
EOF
time nc -w 3 -zv 10.99.0.2 8080   # timed out, après 3 secondes

Le nettoyage demande trois commandes, et la troisième n'est pas facultative : supprimer un espace de noms ne tue pas les processus qu'il contient. Vérifié en machine virtuelle, le serveur de test survit à ip netns del et garde le port occupé.

sudo pkill -f 'http.server 8080'
sudo ip netns del cible
sudo ip link del veth-h 2>/dev/null || true

Bonnes pratiques de diagnostic

Un diagnostic se conduit comme une expérience : une hypothèse, une mesure, une conclusion. Les deux colonnes ci-dessous résument ce qui accélère et ce qui fait perdre du temps.

À faire

• Noter le message d'erreur exact, mot pour mot, avant toute action
• Chronométrer l'échec : immédiat ou après délai, l'information est gratuite
• Tester le protocole en panne, pas son voisin
• Changer une seule variable à la fois
• Comparer avec une machine qui fonctionne
• Consulter les journaux : journalctl -u <service>, /var/log/

À éviter

• Conclure « rien n'écoute » sur un Connection refused
• Conclure « la route manque » sur un No route to host
• Traiter un ping en échec comme une machine éteinte
• Écrire un DNS public dans /etc/resolv.conf comme correctif
• Redémarrer avant d'avoir collecté l'état
• Changer plusieurs réglages en même temps

Le piège du redémarrage

Redémarrer un service efface l'état qui aurait désigné la cause : connexions en cours, descripteurs ouverts, journaux en mémoire. Collectez d'abord (ss -tanp, journalctl, nft list ruleset), redémarrez ensuite. Un problème qui disparaît au redémarrage sans être compris reviendra, et souvent au pire moment.

Dépannage rapide

Cette table condense la page en une entrée par message. Elle donne la première commande à lancer et, surtout, rappelle que chaque message couvre plusieurs causes.

Message reçu	Première commande	Causes à départager
Connection refused	ss -tlnp | grep <port> sur la cible	Service arrêté, reject d'un pare-feu, reset d'un intermédiaire
Connection timed out	time nc -zv <hôte> <port>	drop, perte, route noire, serveur saturé, retour asymétrique
No route to host	ip route get <ip>	Route unreachable, ICMP admin-prohibited d'un pare-feu
Network is unreachable	ip route	Aucune route, y compris pas de route par défaut
Permission denied	ip route get <ip>	Route prohibit, ou politique locale
Invalid argument	ip route get <ip>	Route blackhole
NXDOMAIN	dig <nom> @<serveur>	Nom absent de la zone, zone interne absente du serveur public
SERVFAIL	dig <nom> @<amont>	Serveur amont en panne, validation DNSSEC en échec
Certificat invalide	openssl s_client -connect <hôte>:443	Date, nom, chaîne de confiance

Glissez pour voir

À retenir

• Un message d'erreur nomme un constat, pas une cause. Chaque message de cette page couvre au moins deux situations distinctes.
• Connection refused (111) signifie « réponse négative immédiate » : service arrêté, reject d'un pare-feu, ou reset d'un intermédiaire.
• Connection timed out (110) signifie « rien n'est revenu » : drop, perte, route noire, saturation, retour asymétrique.
• No route to host (113) vient aussi d'un pare-feu en admin-prohibited. L'absence réelle de route donne Network is unreachable (101).
• Les routes blackhole, prohibit et unreachable rendent trois erreurs sans ressemblance entre elles, dont un Invalid argument qui n'évoque rien de réseau.
• ping ne teste qu'ICMP. Un ping en échec avec un port ouvert est un cas mesuré, pas une curiosité.
• Le DNS a quatre échecs distincts, et chacun désigne un endroit différent : NXDOMAIN, SERVFAIL, refus de connexion, absence de réponse.
• Le délai est une information gratuite : immédiat signale un refus, plusieurs secondes signalent un silence.

Testez vos connaissances

Douze questions portent sur les correspondances mesurées de cette page : ce que chaque code d'erreur prouve, et surtout ce qu'il ne prouve pas. Le seuil est fixé à 80 %, parce qu'une erreur d'interprétation sur un message de diagnostic coûte du temps à chaque incident.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

10 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

FAQ : questions fréquentes sur le diagnostic réseau

Comment diagnostiquer un problème réseau méthodiquement ?

On diagnostique du plus proche au plus loin : interface et adresse locale, passerelle, sortie vers Internet testée sur le protocole concerné (curl, pas ping, car ICMP se filtre à part), résolveur DNS, puis service distant. La première étape qui échoue borne la zone.

Quelle différence entre « connection refused » et « connection timed out » ?

Refused signifie qu'une réponse négative immédiate est revenue : port fermé, mais aussi pare-feu en reject alors que le service écoute. Timed out signifie que rien n'est revenu : drop, perte, saturation ou route blackhole. Le délai distingue les deux familles.

NXDOMAIN, SERVFAIL ou timeout : que signifie chaque échec DNS ?

NXDOMAIN : le nom n'existe pas dans la zone. SERVFAIL : le serveur a reçu la question mais ne peut pas répondre. Connection refused : rien n'écoute sur le port 53. No servers could be reached : aucune réponse, donc filtrage ou mauvaise adresse de serveur.

Comment savoir si le problème vient du réseau ou de l'application ?

On teste en local d'abord : si curl localhost ou ss montrent le service qui écoute et répond, le réseau est hors de cause. On teste ensuite depuis une autre machine pour distinguer client et serveur. Si d'autres services sont touchés, c'est un problème réseau global, pas applicatif.

Quels outils utiliser selon le symptôme réseau ?

Pas d'IP : ip addr. Pas de route : ip route, traceroute. DNS KO : dig, resolvectl. Port fermé ou filtré : nc -zv, ss -tuln. Latence ou pertes : ping, mtr. Erreur HTTP : curl -v. Problème TLS : openssl s_client. Les outils ip, ss, dig remplacent les anciens ifconfig, netstat et nslookup.

Pourquoi ne faut-il pas redémarrer en premier réflexe ?

Le redémarrage masque la cause sans la corriger : le problème reviendra, et vous perdez l'état (connexions, logs, processus) qui permettait de comprendre. Avant de redémarrer, collectez les informations de diagnostic. Le redémarrage est la solution de dernier recours, pas le premier geste.

Prochaines étapes

Diagnostiquer un problème réseau sous Linux La déclinaison outil par outil sur une machine Linux : ip, ss, dig, mtr.

Pare-feu, qui peut parler à qui ? Écrire les règles nftables qui produisent reject, drop et admin-prohibited.

ICMP et ping Les messages d'erreur ICMP derrière No route to host et Host unreachable.

Homelab réseau Monter les machines virtuelles où rejouer ces mesures sans risque.

×

📖 Voir la documentation →