ERR_CONNECTION_REFUSED, RESET, CLOSED et TIMED_OUT : ce que Chrome essaie de vous dire

Les quatre veulent dire la même chose au niveau qui compte : la conversation n’est jamais allée assez loin pour avoir un résultat. Chrome a essayé d’ouvrir une connexion vers un serveur, et la connexion a été refusée, coupée, fermée ou jamais honorée - il n’y a donc pas de page, pas de code de statut, et rien à lire du site.

C’est ce qui les sépare des erreurs auxquelles on les compare d’habitude. Un 404 ou un 504 veut dire qu’un serveur vous a répondu, en HTTP, avec quelque chose. Un ERR_CONNECTION_ quelconque veut dire que l’échange a échoué en dessous de HTTP, avant que rien de tout cela ne puisse arriver. Chrome invente ces noms lui-même, et c’est pour ça qu’ils ne ressemblent en rien à un code de statut.

Les quatre diffèrent par la façon dont ça a échoué, et cette différence est l’essentiel du diagnostic.

ERR_CONNECTION_REFUSED

Quelque chose a répondu, et ce qu’il a dit, c’est non.

La machine à cette adresse est joignable, et elle a activement rejeté la connexion sur ce port. Rien n’écoute là, ou un pare-feu renvoie la connexion immédiatement plutôt que de la laisser tomber en silence.

Les causes les plus fréquentes, dans l’ordre où il faut les vérifier : le serveur ne tourne pas ; il tourne sur un port autre que celui de l’adresse ; il est lié à 127.0.0.1 et n’accepte donc les connexions que depuis sa propre machine ; ou vous avez demandé https sur un port qui sert du http simple.

Si vous êtes développeur et que vous voyez ça contre localhost, c’est presque toujours l’une de ces quatre causes et presque jamais le navigateur.

ERR_CONNECTION_TIMED_OUT

Rien n’a répondu du tout.

Chrome a envoyé des paquets dans le noir et a attendu. C’est la signature de quelque chose qui jette le trafic en silence au lieu de le refuser : un pare-feu réglé sur « jeter » plutôt que sur « rejeter », une adresse qui ne mène plus nulle part, un VPN qui envoie votre trafic quelque part d’où la destination est injoignable.

Le signe, c’est l’attente. Un refus revient instantanément ; un délai dépassé prend tout le temps que dure la patience du navigateur.

ERR_CONNECTION_RESET

La connexion était ouverte, puis elle a été tuée en pleine phrase.

Quelque chose a envoyé un reset : le serveur, ou plus souvent quelque chose entre lui et vous. Des proxys d’entreprise qui inspectent le trafic, un logiciel de sécurité sur la machine, une liaison instable, ou un équipement réseau qui a décidé que la connexion n’était pas autorisée alors qu’elle avait déjà commencé.

C’est celle des quatre qui a le plus de chances d’être causée par autre chose que le site. Si elle arrive sur un réseau et pas sur un autre, vous avez votre réponse sans avoir touché au site.

ERR_CONNECTION_CLOSED

La même forme qu’un reset, terminée plus poliment : l’autre bout a fermé la connexion alors que le navigateur en attendait encore.

En pratique, cela désigne le serveur, ou quelque chose devant lui, qui abandonne à mi-chemin : un processus qui redémarre, un répartiteur de charge qui lâche une connexion inactive, un décalage de protocole. Vous verrez aussi ERR_CONNECTION_ABORTED dans cette famille, qui veut généralement dire que la requête a été annulée avant la fin, parfois par la page elle-même qui navigue ailleurs.

Quatre questions qui la situent en une minute environ

Quelle que soit celle des quatre que vous avez, le même triage la resserre. Posez-les dans l’ordre et arrêtez-vous dès que l’une répond.

• Les autres sites fonctionnent-ils ? Non, et le problème est votre connexion, pas le site.
• Est-ce que ça marche dans une fenêtre privée ? Oui, et c’est une extension, un cookie ou une ressource en cache plutôt que le réseau.
• Est-ce que ça marche sur un autre appareil du même réseau ? Oui, et c’est cette machine : son logiciel de sécurité, ses réglages de proxy, son VPN.
• Est-ce que ça marche en données mobiles plutôt qu’en wifi ? Oui, et c’est ce réseau-là, ce qui est l’explication habituelle d’un reset qu’une seule personne voit.

Deux de ces quatre questions écartent le site entièrement, ce qu’il vaut mieux savoir avant que quelqu’un passe un après-midi à lire des journaux serveur pour une panne qui n’a jamais atteint le serveur.

Pourquoi elles sont si mal rapportées

Une erreur de connexion ne produit aucun statut HTTP et souvent rien d’utile dans la console. Soit la page ne charge pas du tout, soit - bien plus difficile à diagnostiquer - elle charge très bien pendant qu’une requête à l’intérieur échoue de cette façon, si bien que le site paraît cassé d’une manière précise et inexplicable.

Ce deuxième cas est celui qui arrive sous la forme « le bouton enregistrer ne fait rien ». Aucune erreur à l’écran, aucun texte rouge, rien que la personne puisse vous citer. Dans le panneau réseau c’est évident et ça tient en une ligne : une requête en échec, pas de statut, et un hôte à côté.

Quel hôte, cela compte plus que tout le reste du rapport. Si les requêtes en échec nomment toutes votre propre domaine, c’est votre infrastructure ou la route qui y mène. Si elles nomment un prestataire de paiement, un service de cartes ou un hébergeur de polices, la page se comporte correctement et quelque chose dont elle dépend, non - et la personne qui lit peut aller voir la page d’état de ce prestataire plutôt que la vôtre.

Le journal réseau d’un rapport de bogue porte exactement cela, et c’est la différence entre cette classe de bogue reproductible et une histoire à propos de quelque chose qui est arrivé mardi.

La version courte

• Refused : quelque chose a dit non, immédiatement. En général rien n’écoute sur ce port.
• Timed out : rien n’a rien dit. En général quelque chose jette le trafic en silence.
• Reset : la connexion est morte en plein vol. En général le réseau intermédiaire, pas le site.
• Closed : l’autre bout a raccroché tôt. En général le serveur ou quelque chose devant lui.

Et aucune des quatre n’est une erreur HTTP, ce qui explique qu’aucun code de statut n’apparaisse à côté et que le serveur puisse n’avoir aucune trace de la tentative.