ERR_CONNECTION_RESET : signification et solutions

Qu'est-ce que ERR_CONNECTION_RESET ?

ERR_CONNECTION_RESET est l'erreur que Chrome, Edge, Brave et les autres navigateurs Chromium affichent lorsqu'une connexion à un site web était ouverte puis a été coupée de force. La page indique « Ce site est inaccessible. La connexion a été réinitialisée. » Dans Chromium, il s'agit de l'erreur réseau -101, que le code source décrit en une ligne : une connexion a été réinitialisée, « correspondant à un TCP RST ».

Un TCP reset (RST), c'est le bouton « raccrocher » du réseau. Une connexion normale se termine poliment par un paquet FIN une fois les données livrées. Un reset y met fin instantanément, sans au revoir, et tout ce qui était à moitié chargé est jeté. Votre navigateur est bien allé jusqu'au serveur : le DNS a fonctionné et la connexion a été établie. Puis quelque chose sur le trajet a décidé de la tuer.

Tout le problème est de savoir quel est ce « quelque chose ». Il peut s'agir de votre propre ordinateur (antivirus, VPN, pile réseau endommagée), de votre routeur ou de votre FAI, d'un pare-feu placé devant le site, ou du processus du serveur web lui-même. Les solutions ci-dessous sont classées pour le découvrir, de la plus rapide à la plus poussée.

À quoi ressemble cette erreur dans les autres navigateurs

La formulation change d'un navigateur à l'autre, mais tous signalent le même TCP reset.

Si Firefox affiche plutôt PR_CONNECT_RESET_ERROR sur une page « Échec de la connexion sécurisée », le reset s'est produit pendant la négociation HTTPS. Les causes recoupent largement celles de ce guide, en particulier l'analyse HTTPS des antivirus et le filtrage réseau.

Quelles sont les causes de ERR_CONNECTION_RESET ?

Chaque reset a un expéditeur. Savoir qui l'a envoyé vous indique qui peut corriger le problème.

Les cinq premières causes sont de votre côté et se corrigent généralement en quelques minutes. Les deux dernières sont du côté du site : vider le cache n'y changera rien, et la seule solution est que le propriétaire règle le problème, ou que vous attendiez.

Étape 1 : le problème vient-il de vous ou du site ?

Prenez 60 secondes pour vérifier ce point avant de modifier le moindre paramètre. Cela vous dit quelle moitié de ce guide vous concerne.

• Essayez un autre réseau. Désactivez le Wi-Fi de votre téléphone et ouvrez la même page en données mobiles. Si elle se charge, le reset se produit sur votre appareil ou sur votre réseau domestique ou professionnel.

• Essayez un autre site. Si tous les sites HTTPS sont réinitialisés, soupçonnez votre VPN, votre proxy ou votre antivirus. Si un seul site l'est, soupçonnez un filtrage ou le serveur de ce site.

• Testez le serveur depuis l'extérieur. Le Vérificateur de ports de DNS Robot se connecte au port 443 du site depuis nos serveurs. Si le port est ouvert pour nous mais réinitialisé pour vous, le problème se situe entre vous et le site.

• Tracez la route. Un traceroute affiche chaque saut réseau entre DNS Robot et le serveur, ce qui vous aide à distinguer un serveur hors service d'un trajet défaillant.

Solution 1 : recharger, puis essayer une fenêtre de navigation privée

Un reset isolé est souvent ponctuel : un routeur qui redémarre, un serveur relancé pendant un déploiement, un passage d'une borne Wi-Fi à une autre. Appuyez sur Ctrl + R (Mac : Cmd + R) après quelques secondes.

Si l'erreur persiste, ouvrez la page dans une fenêtre de navigation privée (Ctrl + Shift + N, Mac Cmd + Shift + N). La navigation privée fonctionne sans vos extensions et sans cookies enregistrés. Si la page s'y charge, une extension ou un cookie corrompu est en cause : désactivez les extensions une par une, ou effacez les données de ce site via l'icône à gauche de la barre d'adresse → Paramètres des sites → Supprimer les données.

Solution 2 : couper le VPN et vérifier les paramètres de proxy

Les VPN et les proxys se placent au milieu de chaque connexion, et quand leur serveur est surchargé, bloqué ou doté d'un délai d'inactivité trop court, ils réinitialisent les connexions. Déconnectez complètement le VPN (ne vous contentez pas de changer de serveur) et rechargez la page.

• Windows 11 : Paramètres → Réseau et Internet → Proxy. Laissez Détecter automatiquement les paramètres activé, puis sous Configuration manuelle du proxy, cliquez sur Configurer (ou Modifier) et désactivez Utiliser un serveur proxy.

• macOS : Réglages Système → Réseau → sélectionnez Wi-Fi ou Ethernet → Détails… → Proxys. Désactivez tous les proxys que vous n'avez pas configurés volontairement.

• Chrome lui-même utilise le proxy du système : il n'y a donc rien de distinct à modifier dans le navigateur.

# Windows dispose aussi d'un proxy distinct pour les services système (WinHTTP).
# À exécuter dans une invite de commandes ou un PowerShell en mode administrateur :
netsh winhttp show proxy
netsh winhttp reset proxy

Solution 3 : suspendre l'analyse HTTPS de l'antivirus ou le pare-feu

De nombreuses suites antivirus déchiffrent et inspectent votre trafic HTTPS. Cette fonction porte des noms comme Analyse HTTPS, Agent Web (Web Shield), Filtrage des protocoles SSL/TLS ou Analyser les connexions chiffrées. Quand l'analyseur ne parvient pas à gérer le certificat ou le protocole d'un site, il réinitialise la connexion plutôt que de la laisser passer.

Pour tester, désactivez l'option d'analyse HTTPS, pas l'antivirus entier, et rechargez. Si la page se charge, laissez l'analyse désactivée pour ce site (la plupart des produits permettent une exclusion) ou mettez l'antivirus à jour. Les pare-feu tiers peuvent faire de même : testez aussi en les mettant en pause.

Solution 4 : réinitialiser la pile réseau de Windows (Winsock)

Windows tient un catalogue de composants réseau appelé Winsock. Les clients VPN, les anciens antivirus et certains malwares y ajoutent des entrées, et un catalogue endommagé provoque des resets sur tous les sites. Réinitialiser Winsock et la pile TCP/IP les remet tous deux à leurs valeurs par défaut. Ouvrez l'invite de commandes en tant qu'administrateur et exécutez :

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

:: Redémarrez ensuite le PC. La réinitialisation de Winsock ne s'applique qu'après un redémarrage.

Windows 11 propose aussi une version en un clic : Paramètres → Réseau et Internet → Paramètres réseau avancés → Réinitialisation du réseau. Elle supprime puis réinstalle toutes les cartes réseau et redémarre le PC : vous devrez ensuite vous reconnecter au Wi-Fi et réinstaller votre éventuel VPN.

Solution 5 : vider le DNS et essayer un autre résolveur DNS

Le DNS n'envoie pas lui-même de resets, mais certains résolveurs de FAI ou d'entreprise redirigent les domaines bloqués vers un serveur de filtrage qui réinitialise la connexion. Une adresse obsolète en cache peut aussi vous envoyer vers un serveur qui n'héberge plus le site. Videz d'abord le cache. Notre guide pour vider le cache DNS donne la commande pour chaque système :

# Windows
ipconfig /flushdns

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

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

Comparez ensuite ce que renvoie votre réseau avec une réponse neutre. Passez le domaine dans la Recherche DNS de DNS Robot : si les adresses IP affichées diffèrent de celles que résout votre ordinateur (nslookup example.com), votre résolveur vous redirige. Passez à un résolveur public comme Cloudflare (1.1.1.1) ou Google (8.8.8.8). Notre Test de vitesse DNS indique lequel est le plus rapide depuis chez vous.

Solution 6 : réduire la MTU si les grosses pages échouent et les petites passent

Un scénario classique : les pages simples se chargent, mais les grosses pages, les téléchargements de fichiers ou les connexions à un compte sont réinitialisés. Cela désigne un problème de MTU. Les paquets sont trop gros pour l'un des liens du trajet (fréquent avec les VPN, l'ADSL en PPPoE et certains partages de connexion mobile), et un équipement qui devrait signaler le problème les abandonne silencieusement : la connexion se bloque, puis échoue.

Trouvez le plus gros paquet qui passe sans fragmentation. 1472 octets de données plus 28 octets d'en-têtes donnent la MTU standard de 1500 :

:: Windows : -f = ne pas fragmenter, -l = taille de la charge utile
ping example.com -f -l 1472
:: "Packet needs to be fragmented but DF set" = trop gros. Réduisez jusqu'à obtenir des réponses.

:: Puis réglez MTU = (plus grande taille qui passe + 28), par ex. 1400 :
netsh interface ipv4 show subinterfaces
netsh interface ipv4 set subinterface "Wi-Fi" mtu=1400 store=persistent

# macOS : -D = ne pas fragmenter, -s = taille de la charge utile
ping -D -s 1472 example.com

Solution 7 : vider les pools de sockets de Chrome et réinitialiser Chrome

Chrome réutilise les connexions ouvertes pour charger les pages plus vite. Si l'une de ces connexions mises en commun est devenue obsolète, par exemple après un changement de réseau ou une coupure du VPN, Chrome peut la réessayer et se faire réinitialiser. Ouvrez chrome://net-internals/#sockets et cliquez sur Flush socket pools, puis rechargez.

L'erreur persiste uniquement dans Chrome alors que Firefox fonctionne ? Allez sur chrome://settings/reset → Restaurer les paramètres par défaut. Cela désactive les extensions et efface les données temporaires, mais conserve les favoris, l'historique et les mots de passe enregistrés.

Corriger ERR_CONNECTION_RESET sur Android et iPhone

Les téléphones rencontrent cette erreur pour les mêmes raisons, plus une : un réglage DNS privé sur Android qui pointe vers un serveur de filtrage ou injoignable.

• Android, DNS privé : Paramètres → Réseau et Internet → DNS privé → réglez-le sur Automatique (sur Samsung : Paramètres → Connexions → Autres paramètres de connexion → DNS privé). Notre guide sur le DNS privé sous Android explique à quoi sert chaque option.

• Android, réinitialiser les paramètres réseau : Paramètres → Système → Options de réinitialisation → Réinitialiser le Bluetooth et le Wi-Fi, plus Réinitialiser les paramètres du réseau mobile si les données mobiles sont touchées (sur Samsung : Paramètres → Gestion globale → Réinitialisation → Réinitialiser les paramètres Wi-Fi et Bluetooth (Reset Wi-Fi and Bluetooth settings)).

• iPhone et iPad : Réglages → Général → Transférer ou réinitialiser l'iPhone → Réinitialiser → Réinitialiser les réglages réseau. Cela efface les réseaux Wi-Fi et mots de passe enregistrés, et supprime les réglages VPN qui n'ont pas été installés par un profil de configuration.

• Les deux : désactivez toute application VPN ou de blocage de publicités (beaucoup fonctionnent comme un VPN local), alternez entre Wi-Fi et données mobiles, et mettez à jour l'application du navigateur.

Pour les propriétaires de sites : trouver ce qui réinitialise vos visiteurs

Si des visiteurs signalent ERR_CONNECTION_RESET et que votre site échoue depuis plusieurs réseaux, le reset vient de votre infrastructure. Procédez de l'extérieur vers l'intérieur :

• Reproduisez l'erreur depuis l'extérieur. Lancez curl -v https://yourdomain.com depuis une machine hors de votre réseau, ou testez le port 443 avec le Vérificateur de ports. Notez si le reset survient avant la négociation TLS, pendant celle-ci, ou après l'envoi de la requête.

• Vérifiez votre couche de sécurité. Les limiteurs de débit, fail2ban, CrowdSec et les WAF cloud peuvent rejeter les IP bannies par un TCP reset (par exemple une règle iptables REJECT --reject-with tcp-reset). Vérifiez avant tout si l'IP de l'utilisateur qui signale le problème est bannie.

• Cherchez les plantages et redémarrages. Un processus qui meurt en pleine requête emporte ses connexions ouvertes avec lui. Consultez journalctl -u your-service, pm2 logs, ou dmesg -T | grep -i "killed process" pour repérer l'OOM killer de Linux (manque de mémoire).

• Vérifiez le TLS. Servez TLS 1.2 et 1.3 avec une chaîne de certificats complète. D'anciens réglages de protocole ou une chaîne incomplète peuvent interrompre brutalement la négociation chez certains clients. Le Vérificateur SSL affiche votre chaîne de certificats et sa date d'expiration, et En-têtes HTTP montre ce que reçoit une vraie requête.

• Vérifiez le CDN. Si vous êtes derrière Cloudflare ou un autre CDN, consultez son journal d'événements de sécurité pour l'IP ou le pays du visiteur avant de toucher au serveur d'origine.

# L'IP du visiteur est-elle bannie par fail2ban ?
sudo fail2ban-client status              # liste des jails
sudo fail2ban-client status sshd         # IP bannies dans une jail
sudo fail2ban-client set sshd unbanip 203.0.113.7

# L'OOM killer a-t-il arrêté votre application ?
dmesg -T | grep -i "killed process"

ERR_CONNECTION_RESET, REFUSED, TIMED_OUT ou CLOSED : les différences

Ces quatre erreurs se ressemblent à l'écran mais décrivent des situations différentes sur le réseau, et chacune oriente vers une solution différente. Les codes sont les numéros d'erreur réseau propres à Chromium.

Guides complets pour les erreurs voisines : ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUT et ERR_CONNECTION_CLOSED. Si votre réseau bloque aussi le DNS sécurisé, consultez ce réseau bloque le trafic DNS chiffré.