PuTTY « Network error: Connection timed out » : 7 étapes

Temps de lecture : 13 min

Vous cliquez sur Ouvrir, la fenêtre reste vide une vingtaine de secondes, puis le message tombe : « Network error: Connection timed out ». Avant de toucher au moindre réglage dans PuTTY, savez-vous ce que le client est en train de vous dire exactement ?

Je vois passer cette question chaque semaine, et presque toujours avec la même intuition de départ : « ça doit être mon identifiant ». Non. Une connexion SSH qui expire avant l’invite n’a jamais atteint le serveur. Le blocage se situe quelque part sur le chemin, entre votre carte réseau et le démon distant.

Dans ce guide, je vous propose un ordre de vérification reproductible, du poste client jusqu’au pare-feu du serveur, avec les commandes exactes et les cas concrets que je rencontre sur le terrain. Pas de tâtonnement, pas de relance de PuTTY « pour voir ». Comme on dit chez nous en Bretagne : mieux vaut un bon chemin qu’un grand détour.

Pourquoi PuTTY affiche « Network error: Connection timed out »

PuTTY affiche « Network error: Connection timed out » lorsqu’il envoie des paquets vers une adresse et un port sans recevoir la moindre réponse avant expiration du délai, soit une vingtaine de secondes. Le blocage se situe entre votre poste et le serveur : filtrage, mauvaise route ou hôte injoignable. L’authentification n’est jamais atteinte.

Ce que je veux que vous reteniez ici, c’est le mécanisme. PuTTY ne dit pas « le serveur a refusé ». Il dit « le délai est dépassé ». Ce sont deux phrases différentes, produites par deux couches réseau différentes, et qui n’appellent pas du tout les mêmes vérifications.

Ce que fait réellement PuTTY au moment où vous cliquez sur Ouvrir

Derrière le bouton Ouvrir, il n’y a aucune magie. PuTTY construit un segment TCP à destination de l’adresse saisie, sur le port cible — le port 22 par défaut. Il émet un premier paquet de synchronisation, le fameux SYN qui ouvre la poignée de main TCP, puis il attend le SYN-ACK en retour.

Si la réponse arrive, la poignée de main se termine, la bannière SSH s’affiche et vous obtenez votre invite de connexion. Si rien ne revient, le système d’exploitation retente à intervalles réguliers, sans succès. Après une vingtaine de secondes, PuTTY abandonne et affiche son message d’erreur.

Autrement dit : votre poste a parlé dans le vide. Personne ne lui a répondu, ni oui ni non. C’est précisément pour cette raison que le mot de passe ne peut pas être en cause. L’authentification se déroule après la poignée de main, sur un canal déjà établi. Si PuTTY n’atteint jamais la bannière SSH, il n’a jamais eu l’occasion de demander un identifiant.

Selon SSH Workbench, dans un guide mis à jour le 22 août 2026, le message survient effectivement après environ vingt secondes pendant lesquelles le client retente sans jamais recevoir de réponse. Une vidéo de dépannage consacrée à cette erreur, publiée le 19 septembre 2023 sur la chaîne HackHunt, cumule 87 311 vues pour 361 mentions d’appréciation (2023) — le sujet touche donc bien plus que quelques administrateurs isolés.

Trois causes dominantes : filtrage, mauvaise route, hôte injoignable

Quand aucun paquet ne revient, il n’existe que trois familles d’explications possibles. Les reconnaître tôt évite de perdre une heure :

• Un filtrage silencieux : un pare-feu, un groupe de sécurité cloud ou une règle de routeur supprime les paquets sans daigner répondre. C’est le cas le plus fréquent, et le plus déroutant.
• Une mauvaise route : votre machine envoie les paquets vers une passerelle qui ne sait pas où les livrer. La table de routage désigne alors un chemin inexistant.
• Un hôte réellement injoignable : machine éteinte, en veille, adresse IP attribuée à un autre équipement, ou adresse qui n’existe plus sur le réseau.

Encadré définition — deux silences très différents. Un dépassement de délai signifie qu’aucun paquet n’est revenu : ni acceptation, ni refus, rien du tout. Un refus de connexion signifie au contraire que la machine a été atteinte et qu’elle a répondu explicitement par un paquet RST, du type « ce port n’écoute pas ». Le premier message est une absence de preuve d’atteinte, le second est une preuve d’atteinte. Toute la suite du diagnostic découle de cette distinction.

Message affiché par PuTTY	Ce qu’il prouve techniquement	Premier réflexe de vérification
Connection timed out	Aucun paquet retour reçu dans le délai : filtrage, route absente ou hôte muet	Tester le port 22 depuis un autre réseau
Connection refused	La machine répond, mais rien n’écoute sur le port demandé	Vérifier que le démon SSH tourne et le port réel d’écoute
No route to host	Un équipement intermédiaire signale l’absence de chemin vers la cible	Contrôler la passerelle et la table de routage

Voilà pour le mécanisme. Reste à savoir dans quelle branche vous vous trouvez — et ça, seul le libellé exact de votre message peut le dire.

SECTION_IMAGE_1

Timed out ou refused : distinguer les deux erreurs en 30 secondes

Sur le terrain, je constate une confusion tenace entre putty connection refused et le dépassement de délai. Les deux empêchent la connexion SSH, mais ils désignent deux mondes différents. Un refus, c’est une porte fermée sur laquelle on a frappé et où quelqu’un a répondu « non ». Un dépassement de délai, c’est une porte au bout d’un couloir dont personne n’a entendu les coups.

Les quatre messages d’erreur réseau de PuTTY et leur signification

• Connection timed out : aucune réponse dans le délai imparti. Le paquet est parti, personne ne l’a acquitté.
• Connection refused : la cible est joignable, mais le port est fermé ou le service arrêté. Vérifiez si SSH écoute ailleurs, par exemple sur un port personnalisé.
• No route to host : un routeur intermédiaire indique qu’il ne connaît aucun chemin vers cette adresse. Typique d’un réseau mal segmenté ou d’une passerelle absente.
• Network is unreachable : votre propre machine n’a pas de route par défaut utilisable. Souvent après une bascule Wi-Fi ou la coupure d’un VPN.

Pourquoi la durée avant le message varie d’un équipement à l’autre

La vingtaine de secondes n’est pas une constante universelle. Certains équipements appliquent un délai d’attente plus court et renvoient le message bien plus vite : c’est notamment ce qui ressort d’une discussion r/networking sur Reddit où des administrateurs comparent le comportement de commutateurs Cisco SG avec d’autres matériels qui, eux, ne définissent aucun délai particulier (2022). Résultat : le même blocage peut produire un message en trois secondes sur un réseau et en vingt-deux sur un autre.

Conséquence pratique : ne comparez jamais deux chronos pour en déduire une cause. Comparez des libellés.

Avertissement. Je vois régulièrement des internautes augmenter le délai d’attente dans les réglages de PuTTY, en espérant que « ça finisse par passer ». Ça ne passe pas. Si les paquets sont perdus, attendre plus longtemps ne crée pas de réponse : vous retomberez sur le même message, deux minutes plus tard, avec deux minutes de perdues. Le réglage ne corrige rien, il masque.

Maintenant que la branche est identifiée, attaquons les vérifications concrètes. On commence par le plus rapide à corriger, côté client.

Étape 1 et 2 : vérifier l’adresse, le port 22 et la résolution de nom

Avant d’accuser le serveur, accusez votre saisie. Ça paraît bête, ça règle pourtant un dossier sur trois. Une session enregistrée dans PuTTY conserve une adresse qui a pu changer depuis six mois, un nom d’hôte tapé de travers ou un port laissé sur une valeur héritée d’un ancien serveur.

Contrôler le nom d’hôte et l’adresse IP dans la session enregistrée

Ouvrez les propriétés de la session et relisez trois champs : le nom d’hôte, le port, et le type de connexion. Ce dernier point est un classique : une session configurée en Telnet ou en Raw sur le port 23 produira exactement le même silence si rien n’écoute. Vérifiez que SSH est bien sélectionné et que le port correspond à celui du serveur.

Un cas que je rencontre souvent : un nom d’hôte local qui ne se résout pas. Vous tapez raspberrypi.local ou monserveur.lan, et PuTTY cherche en vain. Si la résolution de nom échoue ou retourne une adresse obsolète, la connexion part vers une cible fantôme. Le remède est simple : utilisez l’adresse IP directe pour trancher, puis corrigez la résolution ensuite (fichier hosts, DNS local, ou résolution mDNS selon votre environnement).

Tester l’accessibilité du port 22 avant de toucher au serveur

C’est le geste que je conseille systématiquement en premier : tester le port 22 depuis un poste extérieur au réseau concerné, avec un outil de test de port en ligne ou depuis une autre machine hors du segment. Si le port reste fermé vu de l’extérieur, la cause est l’adresse ou un filtrage — pas PuTTY. Vous venez d’économiser une heure de réglages inutiles.

Depuis un poste Linux ou macOS du même réseau, un simple test de socket suffit pour voir si le port répond localement. Depuis Windows, la commande Test-NetConnection de PowerShell avec le paramètre de port rend le même service. L’important n’est pas l’outil, c’est la logique : on teste le port, pas seulement la machine.

Reconnaître une adresse privée mal routée

Les adresses privées se ressemblent d’un réseau à l’autre, et c’est le piège. Deux machines chez deux clients différents peuvent afficher 192.168.1.20 sans avoir le moindre rapport. Si vous basculez d’un contexte à l’autre, vérifiez à quel réseau appartient réellement l’adresse visée.

Plage d’adresses privées	Contexte d’utilisation typique
192.168.0.0 à 192.168.255.255	Box domestiques, petits réseaux de bureau, réseaux internes de machines virtuelles
10.0.0.0 à 10.255.255.255	Réseaux d’entreprise, clouds privés, interconnexions VPN
172.16.0.0 à 172.31.255.255	Environnements virtualisés, laboratoires, réseaux d’hébergeurs

Checklist côté client, à dérouler en deux minutes :

• Nom d’hôte ou adresse IP relus et à jour
• Port cohérent avec la configuration du serveur
• Type de connexion réglé sur SSH, pas sur Telnet ou Raw
• Résolution de nom testée avec l’adresse IP en secours
• Port 22 testé depuis un poste externe au réseau

Si tout cela est propre et que le silence persiste, le problème n’est plus chez vous. Il est temps de passer côté serveur.

Étape 3 et 4 : le serveur ne répond pas (démon SSH, machine éteinte, pare-feu serveur)

Un serveur allumé n’est pas un serveur disponible. C’est une distinction que j’ai apprise à mes dépens, et elle explique une bonne moitié des ssh désactivé sur le serveur que l’on me signale. La machine répond au ping, elle est bien sur le réseau, et pourtant rien n’écoute sur le port 22.

Vérifier que le démon SSH est actif

Il faut un accès console, physique ou via l’interface de l’hébergeur. Une fois devant la machine, trois commandes suffisent sur une distribution classique : vérifier l’état du service, vérifier qu’il écoute réellement sur le port attendu, et vérifier qu’il démarre au boot.

• systemctl status ssh indique si le service est actif ou en échec
• ss -tlnp montre les ports réellement en écoute, avec le nom du processus
• systemctl is-enabled ssh confirme le démarrage automatique au prochain boot

Ouvrir le port 22 dans le pare-feu du serveur

Sur une machine équipée d’UFW, ouvrir le port ne suffit pas si la règle n’est pas rechargée. La séquence correcte tient en deux commandes, puis une vérification :

• sudo ufw allow 22/tcp pour créer la règle d’autorisation
• sudo ufw reload pour appliquer la configuration
• sudo ufw status verbose pour confirmer que la règle est bien active

Attention à l’ordre : activer un pare-feu sans avoir autorisé SSH au préalable vous coupe l’accès distant. C’est une erreur que je vois encore, et elle coûte cher quand la machine est à trois cents kilomètres.

Hébergement cloud : le groupe de sécurité compte autant que la machine

Sur un serveur cloud, il existe souvent deux pare-feux superposés : celui de la machine et celui du fournisseur, appelé groupe de sécurité ou pare-feu réseau. Ouvrir le port 22 dans UFW ne sert à rien si la règle équivalente n’existe pas côté console de l’hébergeur. Vérifiez les deux, dans cet ordre : périmètre d’abord, machine ensuite.

Encadré conseil — l’ordre de vérification côté serveur. Un service actif ne suffit pas. Déroulez toujours : le service tourne-t-il ? écoute-t-il sur la bonne adresse et le bon port ? une règle de pare-feu local l’autorise-t-elle ? le pare-feu périmétrique l’autorise-t-il aussi ? et enfin, le service a-t-il été redémarré depuis le dernier changement ? Sauter une de ces étapes, c’est garantir un aller-retour supplémentaire.

Là, je vais vous raconter une histoire qui m’est arrivée. Une machine de laboratoire redémarre après une mise à jour de noyau un mardi matin. Elle répond au ping, l’équipe est rassurée, « le serveur est debout ». Sauf que le service SSH ne s’était pas relancé automatiquement : il avait été installé à la main, jamais activé au boot. Trois personnes ont cherché côté réseau pendant quarante minutes avant que quelqu’un pense à regarder l’état du service. Depuis, je vérifie toujours is-enabled avant status.

Si le service tourne, écoute et que les pare-feux autorisent, il reste un maillon à isoler : celui qui se trouve entre vous et le serveur. Et là, votre poste Windows a son mot à dire.

SECTION_IMAGE_2

Étape 5 : pare-feu Windows, antivirus et box — isoler le point de blocage

Un pare-feu Windows bloquant SSH ne se signale pas toujours. Selon le profil actif — réseau public ou privé — les règles sortantes et le comportement des suites de sécurité tierces changent. Une mise à jour d’antivirus qui reclasse votre réseau domestique en « public » suffit à faire tomber la connexion sans le moindre message.

La méthode de segmentation en trois tests

Plutôt que de désactiver des protections au hasard, segmentez. Trois tests, dans cet ordre, et vous saurez où se situe le filtrage.

Test réalisé	Résultat observé	Conclusion sur le point de blocage
Connexion depuis un autre poste du même réseau local	Échec identique	Le blocage est côté serveur ou sur le réseau, pas sur votre poste
Connexion depuis un autre poste du même réseau local	Succès	Le blocage est sur votre poste : pare-feu local, antivirus, ou configuration PuTTY
Connexion depuis un réseau totalement différent (partage mobile, par exemple)	Échec persistant	Le filtrage est périmétrique ou côté serveur : escaladez vers l’administrateur

Réglages de la box et filtrage du routeur : le réflexe des changements récents

Question récurrente dans les fils d’entraide : « un changement sur ma box peut-il provoquer ça ? » Oui, très souvent. Un filtrage parental activé, une plage d’adresses modifiée, une redirection de port supprimée, un mode « invité » enclenché par erreur, et le port 22 devient muet sans que rien ne le signale.

Ma règle : cherchez toujours ce qui a changé dans les 48 heures. Nouveau matériel, nouvelle version d’un antivirus, nouvelle box, nouveau profil de pare-feu. Le silence réseau a presque toujours une date de début, et cette date pointe vers une modification.

Reste la famille de cas où tout est correct sur le papier et où la connexion échoue quand même : machines virtuelles, changements de réseau et VPN.

Cas particuliers : machine virtuelle, réseau local, Wi-Fi et VPN

Quand PuTTY ne se connecte pas à la machine virtuelle, l’erreur revient neuf fois sur dix pour une raison d’adressage. Le mode réseau de la carte virtuelle décide de la visibilité de la machine sur votre réseau, et donc de l’adresse que PuTTY doit viser.

Mode NAT, mode ponté : quelle adresse PuTTY doit-il viser

Encadré définition. En mode NAT, la machine virtuelle sort vers Internet à travers l’hôte, mais elle n’est pas visible depuis le reste du réseau : son adresse privée n’existe que dans le réseau interne de l’hyperviseur. En mode ponté, elle obtient une adresse du même réseau que votre poste et devient joignable comme n’importe quelle machine physique. Confondre les deux, c’est chercher une machine invisible.

Cas concret que je croise régulièrement : une machine VirtualBox en mode NAT avec une adresse en 192.168.x.x, injoignable depuis PuTTY. Deux issues. Soit vous restez en NAT et vous configurez une redirection de port sur l’hyperviseur pour joindre la machine via l’adresse de l’hôte. Soit vous basculez la carte en mode ponté, et la machine devient directement accessible — à condition que le réseau autorise le pontage, ce qui n’est pas garanti en Wi-Fi d’entreprise.

Deuxième réflexe : l’adresse a peut-être changé. Un bail DHCP expiré, un redémarrage de la machine virtuelle, et l’adresse n’est plus la même. Vérifiez l’adresse actuelle dans la console de la machine avant de relancer PuTTY.

Changement de réseau et perte de route vers le serveur

Vous étiez en filaire, vous passez en Wi-Fi : la route par défaut change, et parfois une route spécifique vers le réseau interne disparaît. Même effet avec un VPN mal configuré. Un tunnel qui capture tout le trafic envoie vos paquets SSH vers une passerelle distante qui ne connaît pas votre 192.168.1.50 local.

Le test est simple : coupez le VPN, retentez. Si ça passe, le problème est un routage, pas une authentification ni un service. Vous pouvez ensuite ajuster la configuration du tunnel pour exclure les plages locales.

En résumé sur ces cas particuliers : la machine visée doit être visible sur le même plan d’adressage que vous, ou joignable via une règle explicite. Tout le reste n’est que conséquence.

Checklist finale : la séquence de dépannage en 7 étapes

Voici la network error connection timed out solution dans l’ordre que j’applique moi-même, du moins coûteux au plus coûteux. Chaque étape a un critère de sortie : tant qu’il n’est pas rempli, inutile de descendre.

Les 7 étapes dans l’ordre

• Étape 1 — Relire le libellé exact. Critère : je sais si je suis en timed out, refused, no route ou unreachable.
• Étape 2 — Vérifier l’adresse, le port et le type de connexion. Critère : la session vise la bonne machine, sur le bon port, en SSH.
• Étape 3 — Tester le port 22 depuis un poste externe. Critère : le port répond ou ne répond pas — je le sais, c’est factuel.
• Étape 4 — Segmenter avec un test depuis un autre poste du réseau. Critère : je sais si le blocage est sur mon poste ou ailleurs.
• Étape 5 — Vérifier le démon SSH et le port en écoute côté serveur. Critère : le service est actif et écoute sur le port attendu.
• Étape 6 — Vérifier les deux pare-feux : local et périmétrique. Critère : une règle explicite autorise le port 22 des deux côtés, et la configuration est rechargée.
• Étape 7 — Tester depuis un réseau totalement différent. Critère : si l’échec persiste, le blocage est en dehors de mon périmètre et j’escalade.

Les informations à fournir à votre administrateur

Le moment de l’escalade est clair : dès que l’étape 7 échoue, ou dès que vous n’avez pas d’accès console au serveur. Continuer à bricoler côté PuTTY ne produit plus rien d’utile.

Pour accélérer la résolution, transmettez quatre éléments : le libellé exact du message, l’adresse et le port visés, l’horodatage précis de la tentative, et le résultat du test de port depuis l’extérieur. Avec ça, un administrateur système ou réseau situe le problème en quelques minutes au lieu de vous rappeler trois fois.

Et si vous administrez un parc, distinguez toujours les deux responsabilités : le dépannage du poste client s’arrête au test de port. Au-delà, c’est le serveur ou le réseau, et ce n’est plus le même métier.

Questions fréquentes

Pourquoi PuTTY affiche-t-il « Network error: Connection timed out » alors que le ping fonctionne ?

Le ping teste une autre couche et un autre protocole : une machine peut très bien répondre à l’ICMP tout en filtrant le port 22. Il faut tester le port lui-même, pas seulement la joignabilité de l’hôte.

Est-ce que le mot de passe ou l’identifiant peuvent causer cette erreur ?

Non. Le message apparaît avant l’invite d’authentification, donc avant toute vérification des identifiants. Le problème est réseau, en amont de la connexion SSH.

Faut-il augmenter le délai d’attente dans les réglages de PuTTY ?

Non, cela retarde seulement l’affichage du même message. Si les paquets sont perdus, attendre plus longtemps ne crée pas de réponse : le blocage reste entier.

Comment tester rapidement si le port 22 est accessible ?

Utilisez un test de port depuis un poste externe au réseau concerné. Si le port reste fermé vu de l’extérieur, la cause est l’adresse ou un filtrage, pas PuTTY.

Combien de temps PuTTY attend-il avant d’afficher l’erreur ?

Une vingtaine de secondes en général, le temps que le client retente sans réponse. Certains équipements configurés avec un délai plus court renvoient le message bien plus vite.

Cette erreur peut-elle venir de mon fournisseur d’accès ou de mon entreprise ?

Oui. Un filtrage périmétrique ou une règle de sécurité réseau produit exactement le même silence. Un test depuis un autre réseau permet de trancher immédiatement.

En résumé : interpréter le silence plutôt que le subir

Reprenons les quatre points qui comptent. Le message signale une absence de réponse, jamais un problème d’identifiants : votre mot de passe n’a pas eu l’occasion d’être testé. La distinction entre dépassement de délai et connexion refusée oriente tout le diagnostic, et c’est la première chose à lire. L’ordre des vérifications, du client vers le serveur, évite les impasses et fait gagner un temps considérable. Enfin, le délai d’attente n’est pas un réglage à augmenter mais un indice à interpréter : vingt secondes de silence, c’est vingt secondes d’information.

Je termine par ce que je répète à chaque intervention : un diagnostic réseau n’est pas une collection de correctifs essayés au hasard, c’est une succession de questions dont on connaît la réponse avant de passer à la suivante. Le druide ne lance pas ses sorts en espérant ; il observe le ciel d’abord.

Alors, la prochaine fois, plutôt que de relancer PuTTY une troisième fois en croisant les doigts, pourquoi ne pas commencer par un simple test du port 22 ?