ERR_CONNECTION_TIMED_OUT : Pourquoi cela se produit et comment y remédier

ERR_CONNECTION_TIMED_OUT apparaît lorsque votre navigateur envoie une requête et ne reçoit tout simplement jamais de réponse – pas une réponse d’erreur, pas une redirection, rien. Après environ 30 secondes de silence, il abandonne et vous montre cette page. Ce silence est l’indice clé : contrairement à une erreur DNS ou à un avertissement SSL, la connexion n’a jamais eu la chance de démarrer correctement.

Qu’est-ce qui est différent avec un timeout

La plupart des erreurs de connexion se produisent parce que quelque chose a répondu et a dit « non » : un mauvais certificat, un enregistrement DNS manquant, un 404. Un délai d’attente est le contraire : rien ne répond. Cela place les causes probables à un endroit différent de celui habituel : quelque part le long du chemin réseau ou sur un serveur surchargé, plutôt que dans une erreur de configuration spécifique.

Étape 1 : Déterminez la portée

Avant de changer quoi que ce soit, précisez où se produit le silence :

• Essayez d’autres sites. Si rien ne se charge, le problème vient de votre réseau ou de votre appareil, et non d’un seul site.
• Essayez le même site avec les données mobiles, Wi-Fi désactivé. Cela permute l’intégralité de votre chemin réseau. S’il se charge instantanément sur les données mobiles, votre réseau d’origine (routeur, FAI ou portail captif) constitue le goulot d’étranglement.
• Exécutez-le via un vérificateur côté serveur. Cela envoie la requête depuis un réseau entièrement différent sans relation avec le vôtre. Si la vérification indépendante réussit, le délai d’attente est local pour vous. S’il expire également, le serveur lui-même est le problème.

Étape 2 : Si c’est local pour vous

Redémarrez votre routeur et votre modem. Éteignez-les, attendez environ 30 secondes, puis rallumez-les. Cela élimine un nombre surprenant de problèmes de routage et de DHCP qui produisent exactement ce symptôme.

Recherchez un VPN ou un proxy. Ceux-ci ajoutent un saut qui peut lui-même être lent ou inaccessible. Désactivez temporairement et réessayez.

Désactivez les extensions de navigateur, en particulier les bloqueurs de publicités ou les extensions de confidentialité, une par une. Certaines interceptent de manière agressive les requêtes de manière à produire un délai d’attente au lieu d’un bloc propre.

Videz le cache de votre navigateur. Une entrée de cache corrompue pour un site entraîne parfois le blocage des requêtes plutôt que leur échec propre.

Vérifiez votre pare-feu ou votre antivirus. Les logiciels de sécurité maintiennent parfois les connexions ouvertes pendant qu’ils les inspectent, suffisamment longtemps pour déclencher un délai d’attente sur les connexions plus lentes.

Étape 3 : Si c’est du côté du serveur

Si une vérification indépendante expire également, le serveur ne répond à personne, pas seulement à vous. Causes courantes, de la plus courante à la moins courante :

• Le serveur est surchargé. Un pic de trafic, un processus gourmand en ressources ou tout simplement trop de demandes simultanées pour les ressources du plan d’hébergement — ceci est particulièrement courant sur l’hébergement mutualisé, où un voisin occupé peut ralentir tout le monde.
• Un pare-feu ou une règle de sécurité interrompt silencieusement la connexion. Contrairement à un rejet approprié, un paquet abandonné produit exactement ce symptôme « aucune réponse du tout » au lieu d’une erreur propre.
• Le processus du serveur est tombé en panne ou s’est bloqué, et plus rien n’écoute sur le port.
• Un enregistrement DNS mal configuré pointe le domaine vers un serveur ou une IP qui n’existe plus ou ne répond plus sur ce port.

S’il s’agit de votre propre serveur : vérifiez les graphiques de ressources de votre hôte pour détecter les pics de CPU/mémoire au moment de la panne, vérifiez que le processus du serveur Web (nginx, Apache, etc.) est réellement en cours d’exécution et examinez les règles du pare-feu/groupe de sécurité pour tout ce qui pourrait interrompre les connexions entrantes.

Le diagnostic rapide

Le moyen le plus rapide de résoudre cette erreur est le même test en une seule question que chaque problème de connexion réduit à : un serveur indépendant l’atteint-il ? Un vérification d’état en direct répond qu’en quelques secondes - accessible là-bas mais pas pour vous signifie qu’il est local (étape 2) ; inaccessible là aussi signifie que le serveur a besoin d’attention (étape 3). Sauter cette question, c’est comment les gens finissent par redémarrer leur routeur pour un problème qui n’a jamais été le leur, ou d’attendre sur un site qui fonctionnait depuis le début.

Pour la version DNS de « impossible de se connecter », voir DNS_PROBE_FINISHED_NXDOMAIN; pour la version avec certificat, voir “Votre connexion n’est pas privée”.