ERR_CONNECTION_RESET : causes et corrections

Ce que signifie ERR_CONNECTION_RESET

Contrairement à ERR_CONNECTION_REFUSED, qui se déclenche avant que la moindre donnée ne circule, une réinitialisation se produit après que le handshake TCP a réussi et que la connexion échangeait déjà des données. Quelque chose sur le chemin, ou l'un des points d'extrémité lui-même, envoie alors un paquet RST qui termine la connexion sans la séquence de fermeture habituelle. Le navigateur n'a aucun moyen de dire si le RST vient du serveur, d'un équipement intermédiaire comme un pare-feu ou un équilibreur de charge, ou de la pile réseau propre du client, donc le message reste générique quelle que soit la cause.

Une fermeture TCP normale implique un échange FIN dans les deux sens, ce qui laisse chaque côté finir d'envoyer ce qu'il avait déjà mis en file. Un RST saute complètement cette étape : tout ce qui était en transit est abandonné, et toute donnée que le serveur avait déjà commencé à écrire mais que le client n'avait pas encore reçue est perdue. C'est pourquoi une réinitialisation en cours de téléchargement d'un gros fichier ou d'une longue réponse d'API laisse souvent un résultat visiblement tronqué plutôt qu'un échec net avant que quoi que ce soit ne se soit chargé.

Comment l'erreur apparaît

Chrome affiche « This site can't be reached ... ERR_CONNECTION_RESET » en cours de chargement, parfois après qu'une partie de la page s'est déjà affichée. curl la rapporte directement :

curl -v https://example.com/api/report
* TLSv1.2 (IN), TLS alert, close notify
* OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) Recv failure: Connection reset by peer

Côté serveur, nginx journalise une ligne correspondante pour le même événement : readv() failed (104: Connection reset by peer) while reading upstream. Une réinitialisation qui se produit systématiquement au même nombre d'octets ou au même nombre de secondes dans une requête pointe vers une limite de taille ou de délai quelque part sur le chemin, plutôt qu'un incident réseau aléatoire.

Ce qui provoque ERR_CONNECTION_RESET

• Un pare-feu, un IDS, ou un WAF coupe la connexion en plein flux. Une règle qui correspond en cours de requête ou de réponse, plutôt qu'au moment de la connexion, produit une réinitialisation au lieu d'un refus immédiat.
• Des problèmes de MTU ou de fragmentation de paquets. Un chemin avec un MTU plus petit que ce qu'attend l'un ou l'autre point d'extrémité peut corrompre les gros paquets, et certains routeurs mal configurés répondent en réinitialisant la connexion au lieu de fragmenter correctement.
• L'inspection TLS par un logiciel antivirus ou un proxy d'entreprise. Une interception qui échoue en plein handshake ou en pleine réponse réinitialise souvent la connexion plutôt que d'échouer proprement.
• Un processus worker du serveur plante en pleine requête. Une erreur applicative, une extinction pour manque de mémoire, ou un redémarrage de worker pendant un déploiement laissent tous une connexion ouverte sans plus rien pour y répondre.
• Une incompatibilité de délai keep-alive entre le client et le serveur ou le proxy. Si le délai d'inactivité d'un équilibreur de charge est plus court que celui du backend, il peut réinitialiser une connexion que le backend considère encore active.
• Une interférence ou un façonnage de trafic par le FAI. Certains FAI réinitialisent les connexions longues ou à haut débit, en particulier pour le streaming ou les gros téléchargements, comme forme de gestion du trafic.

Comment savoir de qui vient la faute

Testez la même requête depuis un second réseau, comme des données mobiles au lieu du Wi-Fi du bureau. Si cela fonctionne là-bas, un pare-feu local, un antivirus, ou un proxy intercepte la connexion. Si la réinitialisation se produit à l'identique partout, la cause se situe côté serveur ou dans une règle WAF devant lui. Une vérification HTTP lancée depuis plusieurs emplacements à la fois montre si la réinitialisation est universelle ou limitée à un réseau, sans que vous ayez besoin d'un second appareil pour tester.

Comment corriger ERR_CONNECTION_RESET

Si vous êtes visiteur

1. Redémarrez votre routeur ou modem. Une entrée de table NAT bloquée ou un état de connexion périmé sur des routeurs grand public est une cause courante et facile à éliminer.
2. Désactivez tout VPN ou proxy et rechargez. Si la réinitialisation s'arrête, le VPN ou le proxy intercepte ou gère mal la connexion.
3. Désactivez le scan HTTPS dans votre antivirus, généralement listé sous « protection web » ou « scan SSL/TLS », et réessayez. Si cela corrige le problème, ajoutez le site à une liste d'exclusions plutôt que de laisser le scan désactivé.
4. Vérifiez un réglage de MTU inhabituellement bas si vous êtes sur un VPN ou un point d'accès mobile ; l'abaisser légèrement côté client peut résoudre des réinitialisations liées à la fragmentation.

Si vous gérez le site

1. Vérifiez les journaux applicatifs et système à la recherche d'un plantage ou d'une extinction pour manque de mémoire autour du moment de la réinitialisation. Un processus worker qui meurt en pleine requête est l'une des causes les plus courantes.
2. Passez en revue les règles WAF et IDS et leurs journaux. Une règle qui réinitialise les connexions correspondant à certaines charges utiles ou débits peut ressembler en tout point à une panne réseau aléatoire tant que vous ne vérifiez pas le journal de sécurité spécifiquement.
3. Alignez les délais keep-alive à travers la pile. Sur nginx, réglez le délai côté proxy pour qu'il corresponde à celui du backend ou le dépasse :

   keepalive_timeout 65s;
   proxy_read_timeout 65s;

   Une incompatibilité ici est une cause fréquente de réinitialisations sous charge, quand le frontend ferme une connexion que le backend s'attend encore à utiliser.
4. Surveillez les messages de réinitialisation en amont dans le journal du reverse proxy, comme upstream prematurely closed connection while reading response header from upstream, qui pointe directement vers l'application backend plutôt que vers le réseau.
5. Rechargez après tout changement plutôt que d'éditer en place : nginx -t && systemctl reload nginx valide la configuration avant qu'elle ne prenne effet.

Comment prévenir ERR_CONNECTION_RESET

Une réinitialisation qui n'apparaît que sous charge, ou seulement pour de grosses réponses, se montre rarement lors d'une vérification manuelle rapide, puisqu'elle dépend de seuils de temporisation ou de taille qu'une seule requête peut ne pas atteindre. Une surveillance HTTP continue qui vérifie le code de statut et le contenu du corps selon un calendrier depuis plus de 300 points de contrôle dans 158 villes détecte un schéma de réinitialisation intermittent qu'un test ponctuel manquerait, et alerte par e-mail, SMS, appel vocal, Slack, Telegram et bien plus dès que cela commence.

Erreurs associées

• ERR_CONNECTION_REFUSED se produit quand la connexion ne s'établit jamais du tout.
• ERR_CONNECTION_TIMED_OUT se produit quand rien ne répond à la tentative de connexion du tout.
• This site can't be reached couvre l'ensemble complet des erreurs de connexion que Chrome regroupe sous un seul titre.

Questions fréquentes

ERR_CONNECTION_RESET signifie-t-il que j'ai été piraté ?

Non. Cela pointe presque toujours vers un équipement réseau, une règle de pare-feu, une interception antivirus, ou un plantage côté serveur, pas vers une attaque sur votre appareil.

Pourquoi cela n'arrive-t-il qu'avec de gros téléchargements de fichiers ?

Les gros transferts sont plus susceptibles de rencontrer une incompatibilité de MTU, un délai de proxy, ou une limite de taille configurée sur un pare-feu ou un équilibreur de charge, tout cela pouvant terminer une connexion en plein flux qu'une petite requête finirait avant de déclencher.

Mon propre antivirus peut-il causer cela ?

Oui. Les fonctionnalités de scan HTTPS qui interceptent et rechiffrent le trafic TLS échouent parfois sur des sites spécifiques ou de grosses réponses et réinitialisent la connexion au lieu de la laisser passer.

Une réinitialisation est-elle pire qu'un délai dépassé ?

Pas intrinsèquement. Une réinitialisation signifie que quelque chose a activement terminé la connexion, ce qui est souvent plus facile à diagnostiquer qu'un délai dépassé, où rien ne se passe et vous ne pouvez pas savoir si le paquet est jamais arrivé.

Pourquoi la réinitialisation se produit-elle au même point à chaque fois ?

Un nombre d'octets ou un temps écoulé constant avant la réinitialisation pointe généralement vers une limite fixe, comme un délai de proxy, une taille de réponse maximale, ou un réglage keep-alive, plutôt qu'une faute aléatoire.

Un opérateur mobile peut-il réinitialiser mes connexions ?

Certains opérateurs réinitialisent effectivement les connexions longues dans le cadre de la gestion du réseau, en particulier sur des cellules congestionnées ou pour des transferts à haut débit comme le streaming vidéo. Si la même requête fonctionne de façon fiable en Wi-Fi mais se réinitialise en données mobiles, une interférence au niveau de l'opérateur est une explication raisonnable.