TL;DRLe navigateur tourne dans le vide pendant de longues secondes, puis Chrome affiche ERR_CONNECTION_TIMED_OUT. Ici, personne n'a dit non : personne n'a répondu du tout. Ce silence est votre meilleur indice, car il pointe vers un pare-feu, une adresse ou un chemin réseau plutôt que vers le service lui-même.

Ce que dit vraiment ERR_CONNECTION_TIMED_OUT#

Pour ouvrir une page, votre navigateur envoie d'abord un paquet SYN au serveur et attend un SYN-ACK. La liste des erreurs réseau de Chromium définit ERR_CONNECTION_TIMED_OUT (code -118) comme « une tentative de connexion a expiré ». Ici, le SYN part, mais rien ne revient : ni SYN-ACK, ni RST. Le navigateur réémet, patiente, puis renonce.

La page de manuel de connect(2) décrit l'erreur ETIMEDOUT comme un dépassement de délai pendant la tentative de connexion, et précise que ce délai peut être très long lorsque les syncookies sont activés côté serveur. Le RFC 9293 rappelle de son côté que, faute d'accusé de réception, la connexion est abandonnée après le délai utilisateur (user timeout), sans imposer de valeur précise. C'est pourquoi l'erreur se fait attendre. Si l'échec était immédiat, il s'agirait plutôt d'un refus : voir le guide dédié à ERR_CONNECTION_REFUSED.

Les causes d'un silence complet#

  • Un pare-feu qui ignore les paquets (règle DROP) : comportement volontairement discret de la plupart des configurations « fermées par défaut ».
  • Un groupe de sécurité cloud ou une règle du fournisseur qui bloque le port avant même que le paquet n'atteigne la machine.
  • Une adresse IP obsolète : l'enregistrement DNS pointe vers une machine qui n'existe plus ou n'est plus la vôtre.
  • Un hôte éteint ou une route réseau interrompue.
  • Un serveur saturé qui n'accepte plus de nouvelles connexions.
  • Un proxy, un VPN ou un réseau d'entreprise qui filtre certaines destinations, côté visiteur.

Chromium distingue aussi ERR_ADDRESS_UNREACHABLE (-109), qui indique l'absence de route vers l'hôte ou le réseau : proche cousin, mais détecté plus tôt.

Diagnostic côté visiteur, dans l'ordre#

  1. Testez un autre réseau. Passez en 4G/5G depuis votre téléphone. Si le site s'ouvre, le problème vient de votre réseau local, de votre fournisseur d'accès ou de votre poste. S'il échoue partout, il vient du serveur : inutile de continuer à bricoler chez vous.
  2. Videz le cache DNS. Sous Windows, ipconfig /flushdns ; sous macOS, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder ; sous Linux avec systemd-resolved, resolvectl flush-caches. Une ancienne IP en cache est une cause classique de timeout, comme l'explique notre article sur le choix d'un serveur DNS.
  3. Contrôlez le fichier hosts. Une ligne oubliée (C:\Windows\System32\drivers\etc\hosts sous Windows, /etc/hosts sous Linux et macOS) force le domaine vers une adresse qui ne répond plus.
  4. Désactivez temporairement proxy et VPN, et vérifiez les paramètres proxy du système.
  5. Suspendez antivirus et pare-feu logiciel quelques minutes pour tester, puis réactivez-les.
  6. Redémarrez la box ou changez de DNS (par exemple ceux de votre fournisseur d'accès contre un résolveur public) si tous les sites lents à répondre sont concernés.

Diagnostic côté administrateur#

Travaillez de l'intérieur vers l'extérieur : d'abord la machine, puis son pare-feu, puis le réseau du fournisseur.

1. Le service répond-il en local ?#

sudo ss -tlnp
curl -v --connect-timeout 10 http://localhost/

Selon la page de manuel de ss, -t affiche les sockets TCP, -l ceux en écoute, -n évite la résolution des noms et -p indique le processus. Si le service écoute et répond en local, la machine va bien : le silence vient de plus loin.

2. Tester depuis l'extérieur#

nc -vz exemple.fr 443
curl -v --connect-timeout 10 https://exemple.fr/

Un blocage prolongé suivi de « timed out » confirme le silence, alors que « Connection refused » signalerait un RST. L'option --connect-timeout de curl limite la phase de connexion, et son code de sortie 28 correspond à un dépassement de délai. Pour tester une IP précise en contournant le DNS, utilisez --resolve exemple.fr:443:203.0.113.10 (adresse de documentation, à remplacer par la vôtre).

3. Le pare-feu de la machine#

Sur Ubuntu, ufw bloque les connexions entrantes par défaut sauf autorisation :

sudo ufw status numbered
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Avec firewalld, sudo firewall-cmd --list-all ; avec iptables, sudo iptables -L -n -v. Repérez une règle DROP sur le port concerné : c'est elle qui produit le silence côté client.

4. Le pare-feu du fournisseur#

Un port ouvert dans ufw peut rester bloqué en amont par un groupe de sécurité ou un pare-feu réseau de l'hébergeur. Si ss montre le service en écoute, que le test local réussit mais que l'extérieur reste en timeout, c'est la première piste à explorer dans la console du fournisseur.

5. DNS et adresse IP#

Comparez la réponse DNS avec l'IP réelle du serveur : dig +short exemple.fr depuis plusieurs résolveurs. Un enregistrement A ou AAAA obsolète envoie les visiteurs vers une machine muette. Attention à l'IPv6 : un enregistrement AAAA sans écoute IPv6 côté serveur pénalise seulement une partie des visiteurs, ce qui donne des pannes « intermittentes » difficiles à reproduire.

6. Le serveur est-il saturé ?#

Un serveur qui n'accepte plus de nouvelles connexions (file d'attente pleine, processus bloqués, mémoire épuisée) produit aussi des timeouts. Consultez la charge (uptime, top), la mémoire (free -h) et les journaux du serveur web. Si la connexion TCP réussit mais que la réponse traîne, vous êtes plutôt dans le cas d'une erreur 503 ou d'un timeout applicatif.

Quatre scénarios types#

Ces situations sont des illustrations courantes, pas des retours d'expérience chiffrés.

Nouveau serveur qui ne répond pas de l'extérieur#

nginx tourne, curl localhost répond depuis la machine, mais l'extérieur attend indéfiniment. Suspects : ufw, ou le groupe de sécurité du fournisseur qui n'autorise pas les ports 80 et 443. Comparez nc -vz IP 80 depuis l'extérieur avec le test local.

Migration et DNS pas encore à jour#

Après un changement d'hébergeur, certains visiteurs arrivent encore sur l'ancienne IP, où la machine est éteinte : timeout. Le délai de propagation dépend du TTL de l'enregistrement. Comparez les réponses de plusieurs résolveurs et videz votre cache local.

Un seul poste touché#

Le site s'ouvre depuis un téléphone en 4G mais pas depuis un poste précis : vérifiez proxy, VPN, fichier hosts et antivirus de ce poste. Si le blocage vient d'une politique de sécurité de l'entreprise, seul l'administrateur du réseau peut la modifier.

Le site est lent puis tombe en timeout aux heures de pointe#

Le serveur sature quand le trafic monte. Regardez la charge et la mémoire au moment de la panne, puis dimensionnez ou optimisez en conséquence. Une supervision externe des ports 80 et 443 vous prévient avant vos visiteurs.

Arbre de décision rapide#

  1. Le site s'ouvre-t-il en 4G ? Oui : problème local (DNS, hosts, proxy, VPN, antivirus). Non : passez à la suite.
  2. Le service répond-il en local sur le serveur ? Non : il est arrêté ou planté, voyez ERR_CONNECTION_REFUSED. Oui : passez à la suite.
  3. Le test nc -vz depuis l'extérieur échoue-t-il ? Oui : pare-feu de la machine, puis pare-feu du fournisseur.
  4. Le DNS pointe-t-il vers la bonne IP ? Non : corrigez l'enregistrement et patientez le temps du TTL.

Prévenir plutôt que subir#

Supervisez les ports 80 et 443 depuis l'extérieur, documentez vos règles de pare-feu et de groupes de sécurité, vérifiez les enregistrements DNS avant et après toute migration, et gardez un œil sur la charge du serveur. Si vous préférez déléguer cette surveillance, l'équipe de Websource, à Aix-en-Provence, propose de l'hébergement et de l'infogérance de serveurs.

Questions fréquentes#

Que signifie ERR_CONNECTION_TIMED_OUT ?#

Le navigateur a envoyé sa demande de connexion mais n'a reçu aucune réponse dans le délai imparti. La machine est éteinte, injoignable, ou un pare-feu ignore silencieusement les paquets.

ERR_CONNECTION_TIMED_OUT : que faire en premier ?#

Testez le site depuis un autre réseau, par exemple la 4G. S'il s'ouvre, videz le cache DNS, contrôlez le fichier hosts, le proxy et le VPN. S'il échoue partout et que le site est le vôtre, vérifiez le pare-feu du serveur et les groupes de sécurité du fournisseur.

Pourquoi le message met-il si longtemps à apparaître ?#

Tant qu'aucune réponse ne revient, le navigateur réémet sa demande et patiente avant d'abandonner. La page de manuel de connect(2) précise que ce délai peut être très long, notamment quand les syncookies sont activés côté serveur.

Un pare-feu peut-il provoquer un timeout ?#

Oui, c'est l'une des causes les plus courantes. Une règle qui ignore les paquets (DROP) laisse le client dans le silence, alors qu'une règle qui les rejette (REJECT) donne un refus immédiat. Vérifiez aussi le pare-feu ou le groupe de sécurité de votre hébergeur.

Comment savoir si un port est ouvert depuis l'extérieur ?#

Depuis une machine extérieure au serveur, la commande nc -vz nom-du-serveur 443 teste la connexion TCP. Un blocage prolongé suivi de « timed out » indique un silence réseau ; « Connection refused » indique un refus.

Article rédigé le 29/09/2026 par l'équipe Websource à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.