ERR_CONNECTION_TIMED_OUT

Ce que signifie cette erreur et comment la reconnaître

• Le navigateur affiche un message tel que « Ce site est inaccessible » avec ERR_CONNECTION_TIMED_OUT.
• L’échec survient après une attente notable plutôt qu’immédiatement.
• Le nom d’hôte fonctionne depuis un réseau, mais le délai de connexion expire depuis un autre.
• Les requêtes vers l’adresse publique du serveur peuvent également expirer alors que la console d’hébergement indique toujours que l’instance est en cours d’exécution.
• Le problème affecte de nombreux visiteurs lorsque l’hôte, l’interface réseau, la route ou le réseau en amont est indisponible.
• Un serveur soumis à une forte pression sur le processeur, la mémoire, les processus ou les connexions peut rester allumé sans parvenir à terminer rapidement les nouvelles connexions.
• Un CDN, un reverse proxy ou un load balancer peut être accessible alors que sa connexion vers l’origine expire.

Causes principales, classées par probabilité

1. L’hôte ou l’interface réseau est inaccessible — le serveur, la VM, l’interface réseau, la route ou le réseau en amont peut être indisponible.
2. Un pare-feu ou un groupe de sécurité bloque silencieusement le trafic — une règle de rejet silencieux provoque généralement un délai d’attente, tandis qu’un rejet explicite échoue en général plus rapidement.
3. Le serveur est surchargé — l’épuisement des ressources, les limites de processus ou un trop grand nombre de connexions ouvertes peuvent empêcher la négociation TCP ou la réponse de l’application d’aboutir.
4. Le DNS pointe vers la mauvaise destination — le nom d’hôte peut résoudre vers une ancienne adresse, une adresse inaccessible ou une infrastructure qui ne fournit plus le site.
5. Le chemin réseau du visiteur est défaillant — un problème de routage du FAI, un VPN, un proxy, un pare-feu local ou un équipement de filtrage peut bloquer l’accès depuis un réseau.
6. IPv6 est mal configuré — un enregistrement AAAA inutilisable peut provoquer des échecs pour les réseaux qui privilégient IPv6, même lorsque le service IPv4 fonctionne.
7. Un CDN, un reverse proxy, un load balancer ou une couche de protection en amont est mal configuré — le frontal peut être incapable d’atteindre l’origine alors que celle-ci fonctionne.

Comment corriger le problème

1. Testez depuis un deuxième réseau

Ouvrez le site via les données mobiles ou une autre connexion sans lien avec la première. Si un VPN ou un proxy est actif, testez sans celui-ci lorsque cela est autorisé.

• Fonctionne sur le deuxième réseau : examinez le Wi-Fi d’origine, la route du FAI, le pare-feu local, le VPN, le proxy ou l’équipement de filtrage.
• Expire partout : poursuivez avec les vérifications du DNS, du serveur, du pare-feu et du fournisseur d’hébergement.

Ne supposez pas qu’un seul test réussi prouve que le site fonctionne pour tous les utilisateurs ; les problèmes de routage et de famille d’adresses peuvent n’affecter que certains réseaux.

2. Vérifiez le DNS et les deux familles d’adresses

Utilisez un outil de résolution DNS tel que nslookup ou dig pour identifier les adresses IPv4 et IPv6 renvoyées pour le nom d’hôte. Comparez chaque adresse renvoyée avec le serveur, le load balancer, le CDN ou l’autre service qui doit recevoir le trafic.

Recherchez une ancienne adresse, un enregistrement inattendu ou une destination IPv6 qui n’est pas configurée. Si le DNS a été récemment modifié, vérifiez les enregistrements faisant autorité et tenez compte de la période de mise en cache configurée avant d’évaluer la modification depuis un seul réseau.

3. Testez le service sans dépendre du navigateur

Depuis un réseau qui devrait pouvoir atteindre le site, exécutez une requête en lecture seule telle que :

curl -v --connect-timeout 10 https://[your hostname]

La sortie détaillée permet de déterminer si l’échec survient lors de la résolution du nom d’hôte, de l’établissement de la connexion TCP ou de la négociation HTTPS. Testez le port et le protocole réellement utilisés par le service. Un échec de ping seul n’est pas concluant, car ICMP peut être bloqué.

Si vous administrez le service, comparez séparément le comportement des connexions IPv4 et IPv6 à l’aide de tests appropriés en lecture seule. Un échec sur une seule famille d’adresses oriente l’enquête vers cette route, ce listener, cette règle de pare-feu ou cet enregistrement DNS.

4. Vérifiez la console du fournisseur d’hébergement

Utilisez le tableau de bord du fournisseur ou une console hors bande plutôt que de vous appuyer sur SSH lorsque l’accès réseau est défaillant. Vérifiez que l’instance est en cours d’exécution, que l’interface réseau est attachée, que l’adresse publique est correcte et que les contrôles d’état du fournisseur ne signalent aucun échec.

Si la console indique que l’hôte ne répond pas, utilisez une procédure de récupération autorisée. Un redémarrage ou un cycle d’alimentation constitue une modification opérationnelle : vérifiez les autorisations, comprenez l’impact sur les utilisateurs actifs et le travail non enregistré, puis suivez la procédure de récupération documentée par le fournisseur.

5. Examinez les règles des pare-feu cloud et de l’hôte

Vérifiez les groupes de sécurité, les ACL réseau et les règles de pare-feu du fournisseur pour le port de service entrant attendu, généralement HTTP ou HTTPS selon la configuration. Examinez ensuite le pare-feu du système d’exploitation, tel que ufw ou iptables, si vous disposez d’un accès à la console.

Recherchez les règles ajoutées lors d’un renforcement de la sécurité, d’un déploiement, d’une modification d’adresse ou d’une migration. Vérifiez que le trafic est autorisé depuis les plages sources pertinentes et que la règle s’applique à la bonne interface et à la bonne famille d’adresses. Ne désactivez pas largement les protections ; effectuez uniquement la modification autorisée la plus limitée et documentez-la.

6. Recherchez un épuisement des ressources

Depuis la console du fournisseur ou une session administrative existante, examinez le processeur, la mémoire, la pression sur le disque, les limites de processus, les sockets en écoute et le nombre de connexions. Une machine peut sembler allumée tout en étant trop saturée pour accepter de nouvelles connexions.

Comparez les mesures actuelles aux niveaux habituels et examinez les journaux autour du premier échec. Si un service est à court de ressources, suivez la procédure approuvée de capacité ou de récupération plutôt que de le redémarrer à répétition. Un redémarrage peut interrompre le trafic actif et masquer le problème de charge sous-jacent.

7. Vérifiez le proxy, le CDN ou le load balancer

Si le DNS pointe vers un CDN, un reverse proxy ou un load balancer, vérifiez que le frontal peut atteindre l’origine sur le port configuré. Contrôlez l’adresse de l’origine, l’état des contrôles de santé, les paramètres TLS, la route réseau et les listes d’autorisation.

Une origine saine n’exclut pas une règle ou une route défaillante entre le frontal et l’origine. À l’inverse, un frontal sain ne prouve pas que l’origine accepte les connexions.

8. Transmettez des éléments utiles lors de l’escalade

Notez le nom d’hôte concerné, l’heure approximative et le fuseau horaire, le réseau client, les adresses IPv4 et IPv6 résolues, le comportement de chaque famille d’adresses, la sortie détaillée des connexions et l’état de santé affiché dans la console du fournisseur. Ces éléments permettent de distinguer les défaillances DNS, de routage, de filtrage, d’hôte et d’intermédiaire.

Prévention et vérification du correctif

• Surveillez le site depuis plusieurs emplacements externes et déclenchez des alertes sur les délais de connexion séparément des échecs de statut HTTP.
• Documentez les enregistrements DNS, les adresses publiques, les origines CDN et la configuration IPv4/IPv6, puis vérifiez-les après les migrations.
• Testez les modifications des pare-feu et des groupes de sécurité via un processus contrôlé prévoyant une procédure de récupération par la console du fournisseur.
• Conservez une marge suffisante au niveau du processeur, de la mémoire, des descripteurs de fichiers, des processus et des connexions afin que les pics de trafic n’empêchent pas les nouvelles connexions.
• Surveillez séparément l’état de santé de l’origine et celui du CDN ou du load balancer.
• Intégrez les tests depuis un deuxième réseau et les éléments liés aux délais de connexion à la checklist d’incident.
• Utilisez un comportement de pare-feu clair et intentionnel pour les ports de service légitimes tout en préservant la politique de sécurité requise par l’environnement.

Questions fréquentes