ERR_CONNECTION_CLOSED : signification et solutions

Qu'est-ce que ERR_CONNECTION_CLOSED ?

ERR_CONNECTION_CLOSED est l'erreur de Chrome et d'Edge qui indique « Ce site est inaccessible. example.com a fermé la connexion de manière inattendue. » Dans Chromium, il s'agit de l'erreur réseau -100, définie comme « une connexion a été fermée (correspondant à un TCP FIN) ».

Un FIN est la manière polie de terminer une connexion TCP. C'est l'inverse d'un reset : rien n'a planté ni été tué, l'un des côtés a simplement dit « j'ai terminé » et a raccroché. Le problème, c'est le moment choisi. L'autre côté a raccroché avant que le navigateur ne reçoive la page : il n'y avait donc rien à afficher.

Quelque chose a choisi de mettre fin à votre connexion trop tôt. Il peut s'agir du serveur du site web, d'un CDN placé devant lui, d'un filtre sur votre réseau ou d'un logiciel sur votre propre ordinateur. Les solutions ci-dessous vous indiquent lequel.

Où se produit la fermeture : généralement pendant la négociation HTTPS

Le code réseau de Chromium nous indique où chercher. Quand une connexion se termine pendant la négociation TLS (HTTPS), la couche de chiffrement transforme cette fin de connexion en ERR_CONNECTION_CLOSED. Quand une nouvelle connexion parvient à transmettre sa requête et que le serveur ferme ensuite sans répondre, Chrome signale plutôt ERR_EMPTY_RESPONSE.

Chrome relance aussi automatiquement une requête quand une ancienne connexion réutilisée se ferme sous ses pieds : vous voyez donc rarement l'erreur pour cette raison. En conséquence, une page ERR_CONNECTION_CLOSED sur un site HTTPS signifie généralement que quelque chose a raccroché pendant l'établissement de la connexion sécurisée. Cela désigne tout ce qui gère le TLS sur le trajet : l'analyseur HTTPS de votre antivirus, un VPN ou un proxy, un équipement de filtrage sur votre réseau, le CDN du site, ou la configuration TLS du serveur web.

Quelles sont les causes de ERR_CONNECTION_CLOSED ?

Solution 1 : essayer un autre réseau pour trouver le coupable

Ouvrez la page sur votre téléphone en données mobiles (Wi-Fi désactivé), ou sur un autre ordinateur connecté à un autre réseau.

• Cela fonctionne ailleurs : la fermeture vient de votre appareil ou de votre réseau. Poursuivez avec les solutions 2 à 6.

• Cela échoue partout : c'est le serveur ou le CDN du site qui raccroche. Seul le propriétaire peut corriger cela. S'il s'agit de votre site, passez directement à la section pour les propriétaires de sites ci-dessous.

• Vérifiez le certificat depuis l'extérieur : le Vérificateur SSL de DNS Robot se connecte au site depuis nos serveurs et indique si la négociation HTTPS réussit et quel certificat est servi.

Solution 2 : désactiver le VPN et le proxy

Les serveurs VPN et les proxys gèrent chacune de vos connexions, et quand ils sont surchargés ou bloqués, ils mettent souvent fin aux connexions pendant la négociation. Déconnectez complètement le VPN, puis vérifiez la présence d'un proxy :

• Windows 11 : Paramètres → Réseau et Internet → Proxy → sous Configuration manuelle du proxy, désactivez Utiliser un serveur proxy.

• macOS : Réglages Système → Réseau → votre connexion → Détails… → Proxys → désactivez-les.

• Les extensions de navigateur qui font office de VPN ou de proxy comptent aussi. Testez dans une fenêtre de navigation privée, où les extensions sont désactivées par défaut.

Solution 3 : suspendre l'analyse HTTPS de l'antivirus

Les suites de sécurité qui inspectent le trafic chiffré s'insèrent au milieu de chaque négociation HTTPS. Si l'analyseur ne parvient pas à négocier avec un site, par exemple à cause d'une fonction TLS plus récente ou d'un certificat inhabituel, il se contente souvent de fermer la connexion.

Cherchez une option nommée Analyse HTTPS, Agent Web (Web Shield), Filtrage des protocoles SSL/TLS ou Analyser les connexions chiffrées, désactivez uniquement celle-ci, et rechargez. Si la page se charge, ajoutez le site en exclusion et réactivez l'analyse. Mettre à jour l'antivirus règle souvent le problème définitivement.

Solution 4 : changer de DNS pour écarter un filtrage

Certains FAI et filtres réseau bloquent des sites en faisant pointer le domaine vers leur propre serveur, qui raccroche ensuite les connexions HTTPS qu'il ne peut pas servir. Si la Recherche DNS de DNS Robot renvoie pour le site des adresses IP différentes de celles de votre ordinateur (nslookup example.com), votre résolveur vous redirige.

Passez à un résolveur public comme Cloudflare (1.1.1.1), Google (8.8.8.8) ou Quad9 (9.9.9.9), puis videz votre cache DNS et réessayez. Si votre réseau bloque aussi le DNS chiffré, consultez ce réseau bloque le trafic DNS chiffré.

Solution 5 : effacer l'état SSL, les pools de sockets et les données du navigateur

• Pools de sockets de Chrome : ouvrez chrome://net-internals/#sockets et cliquez sur Flush socket pools, pour que Chrome cesse de réutiliser des connexions potentiellement obsolètes.

• État SSL de Windows : appuyez sur Win + R, tapez inetcpl.cpl, ouvrez l'onglet Contenu et cliquez sur Effacer l'état SSL.

• Données du site : cliquez sur l'icône à gauche de la barre d'adresse → Paramètres des sites → Supprimer les données, pour que les cookies et les données en cache de ce site repartent de zéro.

• Mettez à jour le navigateur : allez sur chrome://settings/help. Les anciennes versions peuvent échouer à négocier avec des serveurs qui utilisent des fonctions TLS plus récentes.

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

Si plusieurs sites échouent sur un seul appareil, réinitialisez sa configuration réseau. Redémarrez aussi le routeur, ce qui vide sa table de connexions. Sous Windows, exécutez ces commandes dans une invite de commandes administrateur, puis redémarrez :

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

Windows 11 propose aussi Paramètres → Réseau et Internet → Paramètres réseau avancés → Réinitialisation du réseau, qui réinstalle les cartes réseau. Sur Mac, supprimez le réseau Wi-Fi dans Réglages Système → Wi-Fi, puis reconnectez-vous.

Corriger ERR_CONNECTION_CLOSED sur Android et iPhone

• Changez de réseau : passez du Wi-Fi aux données mobiles ou l'inverse, pour savoir si un filtre réseau est en cause.

• Désactivez les applications VPN, de blocage de publicités et de « sécurité ». Beaucoup font passer le trafic par un VPN local et l'inspectent.

• DNS privé sur Android : Paramètres → Réseau et Internet → DNS privé → Automatique. Consultez le guide du DNS privé pour savoir à quoi sert chaque option.

• Mettez à jour Chrome ou Safari via la boutique d'applications, et mettez à jour le système d'exploitation s'il a plusieurs versions de retard.

• 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 votre serveur raccroche

Si des visiteurs sur de nombreux réseaux obtiennent ERR_CONNECTION_CLOSED, testez vous-même la négociation TLS depuis une machine hors de votre réseau. openssl s_client montre précisément où elle s'arrête :

• SNI et certificats : chaque nom d'hôte qu'utilisent les visiteurs, example.com comme www.example.com, doit avoir une entrée server_name et un certificat qui le couvre. Les noms d'hôte qui aboutissent sur un bloc server par défaut sans certificat voient souvent leur négociation fermée.

• Protocoles : servez TLSv1.2 et TLSv1.3. Les très anciennes configurations qui ne proposent que TLS 1.0/1.1, ou des listes de chiffrements inhabituelles, échouent avec les navigateurs actuels. Le Vérificateur SSL affiche le certificat et la chaîne que reçoivent les visiteurs.

• Limites de connexions : si nginx journalise worker_connections are not enough, ou si une règle de pare-feu connlimit ou anti-DDoS se déclenche, les nouvelles connexions sont abandonnées ou fermées sous forte charge. Relevez les limites ou trouvez la source du trafic.

• CDN et WAF : consultez les événements de sécurité du CDN pour les visiteurs concernés. Les règles de protection anti-bots et de géoblocage peuvent fermer les connexions de régions entières.

• Journaux : cherchez dans le journal d'erreurs du serveur web des lignes SSL_do_handshake() failed aux heures des signalements. nginx journalise la plupart des échecs de négociation côté client au niveau info : avec le niveau error par défaut, vous risquez de ne rien voir. Définissez brièvement error_log /var/log/nginx/error.log info; le temps de l'enquête.

# Négociation complète avec SNI (le nom d'hôte qu'utilisent les visiteurs)
openssl s_client -connect example.com:443 -servername example.com </dev/null

# Bon : chaîne de certificats, "Verify return code: 0 (ok)", une ligne de protocole TLSv1.3 ou TLSv1.2
# Mauvais : "unexpected eof while reading" ou "no peer certificate available"
#      = le serveur (ou ce qui est placé devant lui) a fermé la négociation

# Tester une version de protocole précise
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null

Vérifiez ensuite ces points, dans l'ordre :

ERR_CONNECTION_CLOSED, RESET, EMPTY_RESPONSE et erreurs SSL : les différences

Nos guides associés : ERR_CONNECTION_RESET, ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH et ERR_CONNECTION_REFUSED.