Erreur ERR_CONNECTION_TIMED_OUT : les solutions

Neuf fois sur dix, ERR_CONNECTION_TIMED_OUT ne vient pas du site mais de la couche réseau locale : la requête TCP part et personne ne répond dans le délai imparti. Chrome traduit littéralement le message par « la connexion à la page a pris trop de temps », et le code appartient à la phase de connexion, pas à la résolution de nom.

Points clés

• Dans la documentation Google, ERR_CONNECTION_TIMED_OUT et ERR_TIMED_OUT décrivent la même situation : la page a mis trop de temps à répondre, souvent parce que la connexion est trop lente ou que le serveur reçoit trop de connexions.
• Le code source de Chromium classe cette erreur dans la phase connection, sous le type tcp.timed_out : le nom de domaine a donc déjà été résolu.
• La liste complète des codes réseau du navigateur s’affiche dans chrome://network-errors/.
• 3 commandes réparent la majorité des cas côté Windows : ipconfig /flushdns, netsh winsock reset, netsh int ip reset.
• Un fichier hosts modifié bloque un domaine précis sans toucher au reste de la navigation.

Ce que le message signifie exactement

Charger une page se fait en trois temps : résolution DNS du nom de domaine, ouverture d’une connexion TCP vers l’adresse IP obtenue, puis échange HTTP. ERR_CONNECTION_TIMED_OUT arrive à la deuxième étape. Le navigateur a bien une adresse IP, il envoie sa demande d’ouverture de connexion, et il attend une réponse qui n’arrive jamais.

La nuance compte pour le diagnostic. Une panne DNS produit d’autres codes, comme DNS_PROBE_FINISHED_NXDOMAIN. Un serveur qui refuse explicitement la connexion renvoie ERR_CONNECTION_REFUSED. Une connexion coupée en cours de route donne ERR_CONNECTION_RESET. Ici, rien ne répond du tout : le silence est la signature d’un filtrage, d’un équipement saturé ou d’une route cassée.

Les causes réellement fréquentes

• Pare-feu ou antivirus local qui filtre le trafic sortant du navigateur. Google cite explicitement le pare-feu et l’antivirus parmi les causes des erreurs de connexion.
• Proxy ou VPN configuré mais injoignable. Le système envoie tout vers un intermédiaire qui ne répond plus.
• Fichier hosts contenant une entrée qui redirige le domaine vers une adresse morte, souvent un reliquat d’anciens logiciels de blocage.
• Équipement réseau à bout de souffle : box ou routeur avec une table de connexions pleine, ce qui fait échouer les nouvelles ouvertures pendant que les anciennes tiennent encore.
• Serveur du site surchargé ou en maintenance. Google mentionne l’indisponibilité du site parmi les causes possibles.

Solution 1 : isoler le problème en 60 secondes

Avant de toucher à un réglage, déterminez le périmètre de la panne. Ouvrez le même domaine dans une fenêtre de navigation privée, puis dans un autre navigateur, puis depuis un téléphone en données mobiles. Trois résultats possibles.

• Le site tombe partout, y compris en 4G : le problème est chez l’hébergeur, il n’y a rien à réparer sur votre poste.
• Le site tombe sur tous les appareils du réseau local mais passe en 4G : la cause est dans la box, le routeur ou le filtrage du fournisseur.
• Le site ne tombe que dans Chrome sur une seule machine : la cause est locale, logicielle, et les solutions suivantes s’appliquent.

Solution 2 : couper proxy, VPN et extensions

Dans Windows, ouvrez les paramètres de proxy et vérifiez qu’aucun serveur manuel n’est actif si vous n’en utilisez pas. Coupez ensuite le client VPN, y compris ceux intégrés à certaines suites de sécurité, et rechargez la page. Un tunnel dont le serveur est saturé produit exactement ce délai d’attente.

Testez aussi Chrome sans extension. Les bloqueurs de contenu et les extensions de sécurité ajoutent leurs propres règles de filtrage, et une liste de blocage mal mise à jour suffit à faire expirer une connexion. La fenêtre de navigation privée désactive par défaut la plupart des extensions, ce qui permet de trancher rapidement.

Solution 3 : vider les caches réseau de Windows

Ouvrez une invite de commandes en tant qu’administrateur, puis enchaînez ces commandes.

• ipconfig /flushdns vide le cache du résolveur DNS client. Microsoft documente précisément ce paramètre pour écarter les entrées négatives mises en cache.
• ipconfig /release puis ipconfig /renew redemandent un bail DHCP propre à la box.
• netsh winsock reset remet la couche Winsock à son état initial. La méthode complète et ce que ça implique sont détaillées dans notre article sur la réinitialisation de la pile réseau Windows.

Redémarrez ensuite le poste. Ces trois opérations ne suppriment aucune donnée personnelle, elles reconstruisent seulement des caches.

Solution 4 : vérifier le fichier hosts

Le fichier hosts se trouve dans C:\Windows\System32\drivers\etc, sans extension. Il est consulté avant le DNS : une ligne qui associe le domaine à une adresse inaccessible provoque un délai d’attente sur ce seul site, pendant que tout le reste fonctionne. Ouvrez-le avec le Bloc-notes lancé en administrateur, repérez les lignes qui ne commencent pas par # et qui mentionnent le domaine fautif.

Si le fichier est illisible ou visiblement rempli d’entrées douteuses, Microsoft publie la procédure officielle pour le rétablir à son contenu par défaut, en renommant l’ancien en hosts.old. Une modification du fichier hosts par un logiciel non désiré est un signal à prendre au sérieux : passez un contrôle antivirus complet derrière.

Solution 5 : réinitialiser la pile TCP/IP

Toujours en administrateur, la commande netsh int ip reset resetlog.txt réécrit les clés de registre utilisées par TCP/IP et produit un journal des actions effectuées. Microsoft précise que l’effet équivaut à supprimer puis réinstaller TCP/IP, et qu’un redémarrage est nécessaire pour que les valeurs par défaut s’appliquent.

Conséquence à connaître : les réglages personnalisés d’adresse IP fixe, de passerelle ou de serveurs DNS manuels disparaissent. Notez-les avant, surtout sur un poste configuré par un service informatique.

Solution 6 : tester la carte réseau et le matériel

Changez de support physique. Un poste en Wi-Fi passe en Ethernet, un poste en Ethernet essaie un autre port du switch et un autre câble. Redémarrez la box en la laissant hors tension une minute, le temps que la table de connexions se vide réellement.

Sur un réseau d’entreprise, le délai d’attente sur certains sites seulement pointe souvent vers le filtrage du proxy ou du pare-feu périmétrique. La demande à formuler à l’administrateur est précise : le domaine concerné est-il autorisé en sortie sur les ports 80 et 443 ?

Solution 7 : capturer le trafic avec net-export

Quand rien ne se dégage, Chrome sait enregistrer ses propres événements réseau. Ouvrez chrome://net-export/, cliquez sur le bouton de démarrage de l’enregistrement, reproduisez l’erreur dans un autre onglet, puis arrêtez l’enregistrement. L’onglet net-export doit rester ouvert, sinon la capture s’interrompt. Le fichier JSON obtenu se relit dans le visualiseur NetLog du projet Chromium.

Cette capture est l’outil qui distingue un blocage local d’un serveur muet : elle montre à quelle étape la tentative s’arrête et combien de fois le navigateur a réessayé. C’est aussi la pièce demandée par les développeurs Chromium lors d’un signalement de bug réseau.

Solution 8 : réinitialiser Chrome, puis le réinstaller

La réinitialisation des paramètres de Chrome remet les moteurs de recherche, la page de démarrage, les onglets épinglés et désactive les extensions, sans supprimer les favoris ni les mots de passe. Elle règle les cas où une politique ou un réglage résiduel force un proxy interne.

La réinstallation complète vient en dernier, après avoir vérifié que le problème ne touche qu’un seul navigateur. Google la place également en fin de parcours dans sa procédure de résolution des erreurs de connexion. Avant d’aller jusque là, un passage par la page de suppression du cache reste utile : voir notre méthode pour vider le cache de Chrome sans casser vos sessions.

Quand ça ne vient pas de votre poste

Si le domaine expire depuis plusieurs réseaux différents et plusieurs opérateurs, la panne est du côté du site. Rien de ce qui précède ne la corrigera. Reste alors à vérifier l’état du service auprès de son éditeur et à réessayer plus tard : le message de Google mentionne d’ailleurs le cas d’une page qui reçoit un trop grand nombre de connexions simultanées.

FAQ

ERR_CONNECTION_TIMED_OUT et ERR_TIMED_OUT, quelle différence ?

La page d’aide de Chrome regroupe les deux codes dans la même entrée, avec la même explication : la connexion à la page a pris trop de temps. Le traitement est identique.

Un VPN peut-il provoquer cette erreur ?

Oui. Tout le trafic transite par le serveur du VPN ; si ce serveur est saturé ou si le protocole utilisé est bloqué en sortie, les connexions expirent. Le test consiste à couper le VPN et à recharger la page.

Faut-il changer de serveur DNS ?

Pas pour ce code précis, puisque la résolution de nom a déjà réussi. Le changement de DNS a du sens sur les erreurs de résolution, comme celles décrites dans notre article sur le serveur DNS qui ne répond pas.

Où voir la liste des codes d’erreur du navigateur ?

Dans la barre d’adresse, chrome://network-errors/ affiche la liste complète des codes réseau reconnus par Chrome, comme l’indique la documentation Google.

La commande netsh int ip reset est-elle risquée ?

Elle ne touche pas aux fichiers personnels, mais elle efface les paramètres réseau personnalisés et exige un redémarrage. Sur un poste géré par une entreprise, prévenez l’administrateur avant.

_{Photo d’en-tête : commutateurs Ethernet et panneaux de brassage en baie 19 pouces, par Dsimic, CC BY-SA 4.0 via Wikimedia Commons. La photo illustre la couche réseau filaire, pas le message d’erreur lui-même.
Sources : Aide Google Chrome, messages d’erreur courants · Aide Google Chrome, résoudre les erreurs de connexion et de chargement · Microsoft Learn, ipconfig · Microsoft Learn, réinitialiser TCP/IP avec NetShell · Microsoft Support, rétablir le fichier hosts par défaut · Chromium, capturer un journal NetLog.}