ERR_CONNECTION_TIMED_OUT : pourquoi ça arrive et comment le corriger

2026-09-19

ERR_CONNECTION_TIMED_OUT signifie que le navigateur n'a jamais reçu aucune réponse à sa tentative de connexion dans la fenêtre de délai, contrairement à une connexion refusée, qui reçoit un rejet rapide et explicite. Quelque chose entre le client et le serveur abandonne silencieusement la requête.

Ce que signifie ERR_CONNECTION_TIMED_OUT

Quand un navigateur ouvre une connexion, il envoie un paquet SYN et attend un SYN-ACK en réponse. Un délai dépassé signifie qu'aucune réponse n'est arrivée du tout, ni acceptation ni rejet, avant que le client n'abandonne. Ce silence est la différence clé avec une connexion refusée : le refus est un non rapide et net venant de la machine cible, tandis qu'un délai dépassé signifie que le paquet n'a peut-être jamais atteint quoi que ce soit capable d'y répondre. Chrome attend généralement environ 30 secondes avant d'abandonner et d'afficher l'erreur.

Le système d'exploitation retente généralement le SYN plusieurs fois avant d'abandonner, espaçant les tentatives sur la fenêtre d'attente plutôt que d'envoyer une seule requête et d'attendre en silence. Ce comportement de nouvelle tentative explique en partie pourquoi un délai dépassé met sensiblement plus de temps à apparaître qu'un refus : le client continue d'essayer au cas où la première tentative aurait été perdue à cause d'une perte de paquets ordinaire, et ne signale l'erreur qu'une fois que chaque nouvelle tentative est également restée sans réponse.

Comment l'erreur apparaît

Chrome affiche « This site can't be reached ... ERR_CONNECTION_TIMED_OUT » seulement après l'attente complète, ce qui est le signe visuel le plus clair qui le distingue d'un échec rapide. Depuis la ligne de commande :

curl -v --max-time 10 https://example.com/
* Trying 203.0.113.10:443...
* Connection timed out after 10001 milliseconds
curl: (28) Connection timed out after 10001 milliseconds

Sans option --max-time, curl utilise le délai par défaut du système, qui peut dépasser largement une minute ; fixer l'option explicitement garde le diagnostic rapide.

Ce qui provoque ERR_CONNECTION_TIMED_OUT

L'hôte est en panne. Un serveur éteint, bloqué, ou injoignable au niveau réseau ne peut répondre à aucun paquet, pas même une réinitialisation.
Un pare-feu abandonne silencieusement le paquet. Une règle DROP jette le SYN sans rien renvoyer, ce qui est une posture de sécurité courante pour des ports qui ne devraient pas être joignables depuis internet.
Le DNS résout vers la mauvaise adresse IP ou une adresse obsolète. Le navigateur se connecte à une adresse réelle et joignable, simplement pas celle sur laquelle quoi que ce soit écoute réellement.
Un problème de routage existe quelque part sur le chemin. Une route mal configurée, un lien de peering cassé, ou une panne au niveau du FAI peuvent bloquer des paquets avant qu'ils n'atteignent jamais le réseau de destination.
Le serveur est surchargé et ne peut pas accepter de nouvelles connexions. Une file d'attente de connexions pleine ou un pool de workers épuisé laissent les paquets SYN entrants sans réponse même si la machine elle-même fonctionne.

Refusé, réinitialisé, ou délai dépassé

Erreur	Ce qui se passe	Cause typique
ERR_CONNECTION_REFUSED	Rejet rapide et explicite (RST)	Rien n'écoute sur le port, ou une règle de pare-feu REJECT
ERR_CONNECTION_RESET	La connexion fonctionnait, puis a été coupée	Pare-feu, plantage, ou interférence de proxy en cours de connexion
ERR_CONNECTION_TIMED_OUT	Aucune réponse du tout, attente complète avant d'abandonner	Hôte en panne, règle de pare-feu DROP, routage, ou mauvaise IP

Comment savoir de qui vient la faute

Essayez la même adresse depuis un autre réseau, comme des données mobiles. Si elle se connecte là-bas, le problème est local : votre routeur, votre FAI, ou un pare-feu sur votre propre réseau. Si le délai est dépassé partout, le serveur ou un segment de réseau proche de lui en est la cause. Lancer une vérification de port depuis plusieurs emplacements à la fois confirme cela en une seule étape et montre si le délai dépassé est constant à travers les régions ou limité à un seul chemin.

Comment corriger ERR_CONNECTION_TIMED_OUT

Si vous êtes visiteur

Essayez un autre réseau, comme des données mobiles, pour écarter un problème de routeur local ou de route du FAI.
Redémarrez votre routeur pour vider une entrée de routage ou de cache DNS bloquée.
Videz votre cache DNS local au cas où il conserverait une adresse IP obsolète et injoignable pour le domaine.
Désactivez temporairement un VPN s'il en existe un actif ; le propre nœud de sortie d'un VPN peut être ce qui est injoignable.

Si vous gérez le site

Confirmez que l'hôte est réellement en ligne et joignable depuis l'extérieur de son propre réseau, pas seulement depuis un shell local sur la même machine.
Vérifiez les groupes de sécurité cloud et les règles de pare-feu à la recherche d'une règle DROP sur le port en question ; une règle qui jette silencieusement le trafic est facile à négliger car elle ne produit aucune entrée de journal par défaut.
Tracez le chemin pour confirmer où les paquets s'arrêtent :
```
traceroute example.com
mtr example.com
```
Une trace qui s'arrête net à votre propre routeur de bordure pointe vers un pare-feu local ou de fournisseur cloud plutôt que vers l'internet au sens large.
Confirmez que le service écoute sur 0.0.0.0, pas seulement sur 127.0.0.1. Un service lié uniquement à l'adresse de bouclage est invisible pour tout ce qui se trouve à l'extérieur de la machine, ce qui ressemble en tout point à un abandon par pare-feu vu de l'extérieur.
Vérifiez un épuisement de la file d'attente de connexions sous charge ; une file d'attente pleine peut laisser de nouveaux paquets SYN sans réponse même pendant que les connexions existantes fonctionnent normalement.

Comment prévenir ERR_CONNECTION_TIMED_OUT

Un abandon silencieux ne produit aucun journal d'erreur sur le serveur, puisque rien n'a jamais reçu la requête à journaliser, ce qui rend ce mode d'échec facile à manquer sans vérifications actives. Une surveillance de port et HTTP régulière depuis l'extérieur du réseau détecte un hôte injoignable ou un port silencieusement abandonné dès que cela commence, et alerte par e-mail, SMS, appel vocal, Slack, Telegram et bien plus avant que les visiteurs ne le signalent eux-mêmes.

Erreurs associées

ERR_CONNECTION_REFUSED est un rejet rapide et explicite plutôt qu'un silence.
ERR_ADDRESS_UNREACHABLE signifie qu'il n'existe aucune route vers l'adresse du tout, plutôt qu'une tentative sans réponse sur une route valide.
This site can't be reached couvre l'ensemble complet des erreurs de connexion que Chrome regroupe sous un seul titre.

Questions fréquentes

Combien de temps Chrome attend-il avant d'afficher ERR_CONNECTION_TIMED_OUT ?

Environ 30 secondes, bien que le chiffre exact puisse varier selon la plateforme et les conditions réseau. Un échec systématiquement rapide bien en dessous de ce délai est plus probablement une connexion refusée qu'un délai dépassé.

Pourquoi le site se charge-t-il sur mon téléphone mais dépasse le délai sur mon ordinateur portable ?

Cela pointe généralement vers quelque chose de spécifique au chemin réseau de l'ordinateur portable : un pare-feu d'entreprise, un client VPN, ou une entrée DNS mise en cache localement pointant vers une adresse injoignable.

Un problème DNS peut-il causer ERR_CONNECTION_TIMED_OUT au lieu d'une erreur DNS ?

Oui, si le DNS résout avec succès mais renvoie une adresse IP sur laquelle rien n'est joignable, comme un vieux serveur qui a depuis été mis hors service. La résolution réussit, mais la tentative de connexion à cette adresse dépasse alors le délai.

ERR_CONNECTION_TIMED_OUT est-il le même sur tous les navigateurs ?

La cause sous-jacente est la même, mais le libellé diffère : Firefox affiche « The connection has timed out », et Safari affiche « This webpage is unable to load » après une attente similaire.

Un délai dépassé signifie-t-il toujours que le serveur est en panne ?

Non. Cela signifie que rien n'a répondu à la tentative de connexion, ce qui peut aussi signifier qu'un pare-feu l'a silencieusement abandonnée, qu'une route est cassée quelque part entre les deux, ou que le DNS pointe vers la mauvaise adresse alors que le vrai serveur va bien.

Pourquoi le même site dépasse-t-il le délai pour moi mais se charge pour un collègue sur le même réseau de bureau ?

Vérifiez un client VPN propre à l'appareil, une entrée DNS mise en cache localement, ou un réglage de proxy au niveau du navigateur que seule votre machine a configuré ; un problème réseau partagé affecte généralement tout le monde de façon égale, donc une différence entre deux appareils sur le même réseau pointe vers quelque chose de spécifique à l'un d'eux.