ERR_TIMED_OUT et ERR_CONNECTION_TIMED_OUT : solutions

Qu'est-ce que ERR_CONNECTION_TIMED_OUT ?

ERR_CONNECTION_TIMED_OUT est l'erreur que Chrome et les autres navigateurs Chromium affichent lorsqu'ils n'obtiennent aucune réponse du serveur d'un site web. La page indique « Ce site est inaccessible. example.com a mis trop de temps à répondre. » En interne, il s'agit de l'erreur réseau Chromium -118 : « une tentative de connexion a expiré » (net_error_list.h).

Pour ouvrir une connexion, votre ordinateur envoie au serveur une demande de connexion TCP, un paquet SYN, et attend une réponse. Normalement, celle-ci arrive en quelques millisecondes. Quand aucune réponse ne revient, le système d'exploitation renvoie le SYN plusieurs fois à intervalles croissants, puis abandonne ; la durée dépend du système (les notes de Chromium indiquent de 20 à 190 secondes). Sur notre Mac, une tentative de connexion vers une adresse où rien ne répond a abandonné au bout de 75 secondes.

Le silence est le détail clé. Un serveur en ligne sur lequel rien n'écoute répond immédiatement par un refus. Avec un délai dépassé, personne n'a répondu du tout : les paquets ont été abandonnés quelque part, ou envoyés à une adresse où rien n'existe.

ERR_CONNECTION_TIMED_OUT ou ERR_TIMED_OUT ?

Chrome a deux erreurs de délai d'apparence similaire, qui échouent à des étapes différentes :

• ERR_CONNECTION_TIMED_OUT (-118) : la connexion n'a jamais été établie, car le serveur n'a pas répondu au SYN initial. Examinez le trajet réseau, les pare-feu, le DNS et la disponibilité du serveur.
• ERR_TIMED_OUT (-7) : un délai dépassé plus général, déclenché par l'un des minuteurs propres à Chrome plutôt que par le système d'exploitation. La négociation HTTPS, par exemple, dispose de 30 secondes une fois la connexion TCP ouverte (Chromium), et une connexion qui s'ouvre puis cesse de recevoir des réponses peut se terminer de la même façon. Cela désigne généralement un serveur lent ou bloqué, ou un proxy qui se fige.

Les solutions ci-dessous s'appliquent aux deux. ERR_TIMED_OUT relève plus souvent d'un problème du site web, tandis que ERR_CONNECTION_TIMED_OUT relève plus souvent du trajet réseau ou d'un pare-feu.

Quelles sont les causes de ERR_CONNECTION_TIMED_OUT ?

Solution 1 : vérifier si le site est en ligne pour tout le monde

Si le serveur est hors service, rien de votre côté n'y changera quoi que ce soit : vérifiez donc ce point en premier :

• Ouvrez le site sur votre téléphone en données mobiles (Wi-Fi désactivé). S'il se charge, le problème vient de votre appareil ou de votre réseau.
• Vérifiez-le avec le Vérificateur de site en panne, qui ouvre la page depuis 11 endroits à la fois. Si tous expirent aussi, c'est le site qui est en cause.
• Lancez un Test Ping depuis 11 villes. Il mesure une connexion TCP vers le port 443 depuis chaque ville et ajoute un ping classique depuis notre serveur. Des réponses sur le port 443 signifient que le serveur web accepte les connexions ; si seul le ping classique répond, la machine est en ligne mais son port web ne l'est pas.
• Testez le port web avec le Vérificateur de ports. Vérifiez le port 443 (HTTPS) et le port 80 (HTTP). « Ouvert » pour nous alors que votre navigateur expire signifie que quelque chose entre vous et le site abandonne le trafic. « Filtré » (aucune réponse en 4 secondes) pour nous aussi signifie que le pare-feu du serveur ou le serveur lui-même est en cause.
• Lancez un traceroute depuis 8 villes en TCP 443 pour voir jusqu'où vont les paquets. Si tous les tracés TCP 443 s'arrêtent aux derniers sauts, le réseau de l'hébergeur du site abandonne le trafic ; avec des sondes ICMP, des derniers sauts silencieux sont normaux pour beaucoup de sites qui fonctionnent.

Solution 2 : vider votre cache DNS (et celui de Chrome)

Quand un site migre vers un nouveau serveur, votre ordinateur peut continuer à utiliser l'ancienne adresse IP jusqu'à l'expiration de son cache. Si l'ancien serveur est éteint ou protégé par un pare-feu, chaque tentative expire. Videz le cache du système d'exploitation et le cache d'hôtes propre à Chrome :

# Windows (invite de commandes)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux avec systemd-resolved
resolvectl flush-caches

# Chrome : ouvrez chrome://net-internals/#dns et cliquez sur "Clear host cache"

Pour vérifier si votre résolveur DNS sert un enregistrement périmé, comparez nslookup example.com (il interroge directement votre résolveur, sans passer par le cache local ni le fichier hosts) avec la Recherche DNS de DNS Robot ; les sites derrière un CDN peuvent légitimement renvoyer des adresses différentes. Le guide pour vider le cache DNS couvre chaque navigateur et système d'exploitation.

Solution 3 : vérifier le fichier hosts

Le fichier hosts a priorité sur le DNS pour tout nom qui y figure. Les développeurs, les bloqueurs de publicités et certains malwares y ajoutent des entrées, et une ligne oubliée qui associe le domaine à une IP ancienne ou privée expirera à chaque fois, sur cet ordinateur uniquement.

• Windows : ouvrez le Bloc-notes en tant qu'administrateur, puis ouvrez C:\Windows\System32\drivers\etc\hosts.
• macOS / Linux : exécutez sudo nano /etc/hosts dans le Terminal.

Cherchez une ligne contenant le domaine qui échoue. Supprimez-la, ou ajoutez # au début pour la désactiver, enregistrez, puis videz à nouveau le DNS.

Solution 4 : désactiver proxy, VPN et pare-feu pour tester

Si tous les sites expirent, un proxy ou un VPN qui ne fonctionne plus est une cause fréquente, car tout le trafic part vers une impasse.

• Proxy Windows 11 : Paramètres → Réseau et Internet → Proxy. Sous Configuration manuelle du proxy, sélectionnez Modifier (ou « Set up ») à côté de Utiliser un serveur proxy, désactivez Utiliser un serveur proxy puis sélectionnez Enregistrer. Si « Use setup script » est activé sous « Automatic proxy setup » et que vous ne l'avez pas configuré vous-même, désactivez-le aussi.
• Proxy macOS : Réglages Système → Réseau → votre connexion → Détails… → Proxys → désactivez-les.
• VPN : déconnectez-le complètement et rechargez. Si le site fonctionne sans le VPN, changez de serveur VPN ou contactez le fournisseur.
• Pare-feu / antivirus : mettez brièvement en pause le pare-feu tiers et rechargez. Si cela règle le problème, ajoutez une exception pour le navigateur au lieu de laisser le pare-feu désactivé.

Solution 5 : passer à un résolveur DNS public

Certains résolveurs de FAI tardent à se mettre à jour, et certains renvoient les domaines bloqués vers une adresse qui ne répond jamais. Passer à un résolveur public comme Cloudflare (1.1.1.1), Google (8.8.8.8) ou Quad9 (9.9.9.9) écarte cette hypothèse. Notre Test de vitesse DNS indique lequel est le plus rapide depuis chez vous.

Si c'est votre serveur DNS lui-même qui défaille, vous verrez peut-être d'autres erreurs, traitées dans le serveur DNS ne répond pas et serveur DNS indisponible.

Solution 6 : réinitialiser la pile réseau et redémarrer le routeur

Redémarrez le routeur et le modem : débranchez-les 30 secondes, puis laissez-leur deux ou trois minutes pour se reconnecter. Sous Windows, réinitialisez aussi la pile TCP/IP depuis une invite de commandes administrateur, puis redémarrez le PC pour terminer la réinitialisation :

netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

Sur Mac, désactivez puis réactivez le Wi-Fi, ou supprimez puis rajoutez le réseau dans Réglages Système → Réseau. Vous pouvez aussi lancer les Diagnostics réseau Windows (le lien sur la page d'erreur de Chrome) et laisser Windows réparer la carte réseau.

Solution 7 : tester le port depuis votre propre ordinateur

Ce test vous dit en moins d'une demi-minute si votre machine peut seulement ouvrir une connexion vers le site, sans passer par le navigateur :

# Windows PowerShell
Test-NetConnection example.com -Port 443
# TcpTestSucceeded : False  -> no connection from your network (dropped or refused)

# macOS (-G sets the connect timeout)
nc -vz -G 5 example.com 443
# Linux
nc -vz -w 5 example.com 443
# "timed out" -> dropped; "Connection refused" -> server rejected it

Si le test échoue depuis votre ordinateur alors que le Vérificateur de ports de DNS Robot affiche le port ouvert, quelque chose entre vous et le site le bloque : votre routeur, le pare-feu de l'entreprise, votre FAI, un filtre Wi-Fi d'hôtel ou d'école, ou le pare-feu du site lui-même qui bloque votre adresse IP ou votre pays. Essayez un autre réseau, ou contactez l'administrateur réseau. (Test-NetConnection est documenté par Microsoft.)

Corriger ERR_CONNECTION_TIMED_OUT sur Android et iPhone

• Changez de réseau : essayez les données mobiles au lieu du Wi-Fi, ou l'inverse. Les portails captifs des Wi-Fi publics font expirer les connexions tant que vous n'avez pas accepté leur page de connexion.
• DNS privé sur Android : Paramètres → Réseau et Internet → DNS privé → Automatique. Un nom d'hôte personnalisé injoignable fait échouer toutes les résolutions. Consultez notre guide du DNS privé.
• Désactivez les applications VPN et de blocage de publicités, car beaucoup fonctionnent comme un VPN local.
• Réinitialisez les paramètres réseau : sur iPhone, Réglages → Général → Transférer ou réinitialiser l'iPhone → Réinitialiser → Réinitialiser les réglages réseau. Sur Android, Paramètres → Système → Options de réinitialisation → Réinitialiser le Bluetooth et le Wi-Fi (et Réinitialiser les paramètres du réseau mobile si les données mobiles échouent aussi).

Pour les propriétaires de sites : pourquoi vos visiteurs expirent

Si votre site expire pour tout le monde, les paquets sont abandonnés avant d'atteindre votre serveur web. Vérifiez ces points dans l'ordre :

• Quelque chose écoute-t-il ? Sur le serveur, sudo ss -tlnp | grep -E ':(80|443) ' doit afficher nginx, Apache ou votre application. Si rien n'apparaît, démarrez le service. Notez qu'un service arrêté produit généralement un refus plutôt qu'un délai dépassé, sauf si un pare-feu abandonne les paquets avant.
• Le pare-feu autorise-t-il les ports 80 et 443 ? Lancez sudo ufw status verbose sur Ubuntu ou sudo firewall-cmd --list-all sur les systèmes de la famille RHEL. Le refus par défaut d'ufw abandonne les paquets, ce qui produit exactement des délais dépassés ; la zone par défaut de firewalld les rejette au contraire, ce que les visiteurs voient comme un refus ou une adresse injoignable.
• Les pare-feu cloud sont distincts. Les Security Groups AWS, les règles de pare-feu Google Cloud, les NSG Azure et les pare-feu des panneaux de nombreux hébergeurs VPS refusent le trafic entrant par défaut. Autorisez le TCP 80 et 443 depuis 0.0.0.0/0 (et ::/0 pour l'IPv6).
• Le DNS pointe-t-il vers ce serveur ? Après une migration, vérifiez les enregistrements A et AAAA avec la Recherche DNS. Un enregistrement AAAA pointant vers une adresse sur laquelle le serveur ne répond pas réellement peut provoquer des chargements lents ou des délais dépassés pour les visiteurs sur des réseaux IPv6.
• Le serveur est-il surchargé ? Si la file d'attente des connexions se remplit sous forte charge, les nouvelles tentatives de connexion sont abandonnées et expirent. Vérifiez le CPU, la mémoire et le nombre de connexions au moment où cela se produit.

# Ubuntu: allow web traffic through ufw
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status verbose

# Confirm from outside (another machine; on a Mac use -G 5 instead of -w 5):
nc -vz -w 5 yourdomain.com 443

Délai dépassé, refus ou reset : comment les distinguer

Un pare-feu configuré pour abandonner (drop) le trafic produit un délai dépassé ; un pare-feu configuré pour le rejeter (reject) répond aussitôt, le plus souvent par un refus, ou par ERR_ADDRESS_UNREACHABLE quand il rejette avec un message ICMP, comme le fait firewalld par défaut. Guides détaillés : ERR_CONNECTION_REFUSED, ERR_CONNECTION_RESET et ERR_NAME_NOT_RESOLVED.