ERR_CONNECTION_REFUSED : ce que ça signifie et comment le corriger

Ce que signifie ERR_CONNECTION_REFUSED

Une connexion TCP commence par un handshake : le client envoie un paquet SYN, et le serveur répond par SYN-ACK si un processus est lié à ce port. Quand aucun processus n'écoute, la pile réseau du système d'exploitation renvoie plutôt un paquet RST, fermant la tentative immédiatement. Ce RST est ce qui produit ERR_CONNECTION_REFUSED dans Chrome et ses équivalents dans les autres navigateurs. La connexion a atteint la machine cible et a reçu un non clair, ce qui distingue cette erreur d'un délai dépassé, où rien ne répond du tout.

La réponse RST vient de la pile TCP du noyau, pas d'un quelconque code applicatif, ce qui explique qu'elle arrive en quelques millisecondes au lieu d'après plusieurs secondes d'attente. Cela signifie aussi que la machine elle-même est en ligne et répond au trafic réseau ; elle n'a simplement rien lié au port précis que la requête visait. Cette distinction compte quand vient le moment de décider où regarder en premier : une connexion refusée pointe vers le port et le processus derrière lui, pas vers l'alimentation du serveur ou sa liaison réseau.

Comment l'erreur apparaît

Chrome affiche une simple page « This site can't be reached ... ERR_CONNECTION_REFUSED » sans autre détail. Firefox rapporte « Unable to connect » et nomme l'hôte et le port qu'il a tentés. La ligne de commande donne un tableau plus précis :

curl -v https://example.com:8443/
* Trying 203.0.113.10:8443...
* connect to 203.0.113.10 port 8443 failed: Connection refused
* Failed to connect to example.com port 8443 after 2 ms: Connection refused

Le message nomme le port exact que curl a tenté et rapporte le refus en quelques millisecondes, assez vite pour exclure un délai dépassé. telnet host port ou nc -zv host port renvoient la même ligne « Connection refused ».

Ce qui provoque ERR_CONNECTION_REFUSED

• Rien n'écoute sur ce port. Le serveur web, l'application, ou le proxy qui devrait être lié au port ne fonctionne pas.
• Le service s'est arrêté ou a planté. Un processus qui s'est terminé, a été tué pour consommation excessive de mémoire, ou a été arrêté pour maintenance laisse le port délié.
• Une règle de pare-feu rejette la connexion d'emblée. Une règle REJECT renvoie le même RST qu'un port fermé, donc de l'extérieur cela paraît identique à l'absence de tout.
• Le mauvais port se trouve dans l'URL. Une faute de frappe, un vieux favori d'avant un changement de port, ou un service qui a déménagé vers un autre port produisent tous cette erreur contre l'ancien port.
• Un serveur de développement local n'est pas en cours d'exécution. localhost:3000 refusé signifie presque toujours que le serveur de dev a été arrêté ou n'a jamais été démarré dans cette session de terminal.
• Un proxy ou un VPN est mal configuré. Un proxy pointant vers un backend en panne, ou un client VPN réécrivant les requêtes vers un port que rien ne sert, refuse la connexion pour son propre compte.
• Le mappage de port d'un conteneur ne correspond pas à l'application qu'il contient. Un service Docker ou Kubernetes dont le port publié diffère du port que l'application lie réellement produit cette erreur même si le processus lui-même fonctionne normalement.

Comment savoir de qui vient la faute

Si le site se charge pour d'autres personnes en ce moment, ou s'est chargé pour vous il y a une minute, le problème est plus probablement local : un VPN, un réglage de proxy, ou une règle de pare-feu sur votre propre machine ou réseau. S'il échoue de la même façon depuis un téléphone en données mobiles, le côté serveur refuse les connexions pour tout le monde. Lancer une vérification HTTP ou de port depuis plusieurs emplacements à la fois règle cela en une seule requête ; si des points de contrôle dans plusieurs pays rapportent tous la connexion refusée, la cause est le serveur ou son pare-feu, pas votre réseau.

Comment corriger ERR_CONNECTION_REFUSED

Si vous êtes visiteur

1. Confirmez l'URL et le port. Cherchez une faute de frappe, un vieux favori, ou un lien qui pointe encore vers un port mis hors service.
2. Désactivez votre VPN ou votre proxy et rechargez. Si le site se charge ensuite, la configuration du VPN ou du proxy est la cause ; vérifiez ses réglages ou contactez qui le gère.
3. Essayez un autre réseau, comme les données mobiles au lieu du Wi-Fi, pour écarter un pare-feu local ou une règle de routeur.
4. Attendez et réessayez. Si l'opérateur du site est en plein déploiement ou redémarre un service, le port peut n'être délié que pendant quelques secondes.

Si vous gérez le site

1. Confirmez que le processus est en cours d'exécution et lié au port attendu :

   ss -ltnp | grep :443
   netstat -tlnp | grep :443

   Un résultat vide signifie que rien n'écoute ; démarrez le service ou corrigez son port configuré.
2. Vérifiez le statut du service et ses journaux :

   systemctl status nginx
   journalctl -u nginx -n 50

   Une unité qui a planté ou échoué apparaît ici, souvent avec la raison de sa sortie.
3. Vérifiez si le pare-feu a une règle REJECT sur le port :

   iptables -L -n | grep REJECT
   ufw status verbose

   Une règle REJECT paraît identique à un port fermé vue de l'extérieur, donc cette étape est facile à manquer.
4. Confirmez que le service écoute sur la bonne interface. Un serveur lié à 127.0.0.1 au lieu de 0.0.0.0 refuse chaque connexion qui arrive depuis l'extérieur de la machine, même s'il fonctionne bien depuis un shell local.
5. Redémarrez le service une fois la configuration corrigée, et confirmez que le port est de nouveau lié avec la même commande ss avant de considérer le problème résolu.

Comment prévenir ERR_CONNECTION_REFUSED

Un service qui plante ou une règle de pare-feu accidentelle apparaissent généralement d'abord comme des connexions refusées plutôt que comme une alerte venant du serveur lui-même, puisqu'un processus qui ne fonctionne pas ne peut pas signaler sa propre panne. Une surveillance de port régulière détecte cela en quelques minutes en se connectant depuis l'extérieur du réseau de la même façon qu'un visiteur le ferait, et envoie une alerte par e-mail, SMS, appel vocal, Slack, Telegram et d'autres canaux dès qu'une vérification échoue.

Erreurs associées

• ERR_CONNECTION_TIMED_OUT se produit quand rien ne répond à la tentative de connexion du tout, plutôt que de la refuser activement.
• ERR_CONNECTION_RESET se produit quand une connexion a été acceptée puis coupée en cours de route.
• 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_REFUSED est-il la même chose qu'un pare-feu qui me bloque ?

Cela peut l'être. Une règle de pare-feu REJECT produit la même réponse RST qu'un port fermé, donc les deux paraissent identiques depuis le navigateur. Une règle DROP se comporte différemment et produit un délai dépassé à la place.

Pourquoi cela n'arrive-t-il que sur localhost ?

Presque toujours parce que le serveur de dev local ne fonctionne pas dans ce terminal, a été arrêté, ou a planté au démarrage à cause d'une erreur de code ou de configuration. Vérifiez le terminal où vous le démarrez habituellement à la recherche d'un message d'erreur.

Un VPN peut-il causer ERR_CONNECTION_REFUSED ?

Oui. Un VPN qui route le trafic à travers un proxy ou une passerelle peut refuser des connexions pour le compte de la passerelle si son propre backend est en panne, même si le vrai serveur de destination fonctionne bien.

ERR_CONNECTION_REFUSED signifie-t-il que le site est en panne pour tout le monde ?

Pas nécessairement. Testez depuis un second réseau ou lancez une vérification depuis plusieurs emplacements avant de conclure cela. Une seule règle de pare-feu mal configurée ou un VPN local peuvent produire la même erreur tandis que le site fonctionne bien pour tout le monde.

Quelle est la différence entre refusé et réinitialisé ?

Refusé signifie que la tentative de connexion n'a jamais abouti ; la cible l'a rejetée immédiatement. Réinitialisé signifie que la connexion avait été établie et fonctionnait, puis a été coupée en cours de route, généralement par quelque chose plus loin sur le chemin.

Comment savoir quel processus devrait écouter ?

Vérifiez les propres journaux de démarrage de l'application et sa configuration pour le port qu'elle s'attend à lier. Si le processus fonctionne mais est lié à un port différent de celui que l'URL utilise, mettez à jour l'URL ou la configuration pour que les deux concordent, puis confirmez avec ss -ltnp que le port est maintenant lié comme attendu.