ERR_CONNECTION_REFUSED : ce que signifie l'erreur et comment la corriger

Qu'est-ce que ERR_CONNECTION_REFUSED ?

ERR_CONNECTION_REFUSED est une erreur de Chrome qui apparaît lorsque votre navigateur atteint le serveur du site web mais que le serveur refuse activement la connexion. Au niveau du réseau, votre ordinateur a envoyé une demande de connexion TCP (SYN) à l'adresse IP et au port du serveur, et au lieu de l'accepter, le serveur — ou un pare-feu placé devant lui — a répondu par un paquet de réinitialisation (RST) qui dit « rien ici ne vous parlera ».

Cela rend ERR_CONNECTION_REFUSED fondamentalement différente des erreurs DNS comme DNS_PROBE_FINISHED_NXDOMAIN. Avec une erreur DNS, le nom de domaine ne s'est jamais résolu en adresse IP. Avec ERR_CONNECTION_REFUSED, le DNS a parfaitement fonctionné — votre navigateur sait exactement où se trouve le serveur — mais la machine à cette adresse a refusé d'ouvrir la porte.

Le refus signifie généralement l'une de ces trois choses : aucun service n'écoute sur ce port (le serveur web est arrêté ou a planté), un pare-feu rejette le trafic vers ce port, ou votre appareil se connecte à une adresse IP totalement erronée — par exemple à cause d'un cache DNS obsolète ou d'un proxy défaillant.

À quoi ressemble cette erreur dans les autres navigateurs

Chaque navigateur signale une connexion refusée différemment, mais le rejet TCP sous-jacent est identique.

Les navigateurs basés sur Chromium (Chrome, Edge, Brave, Opera) affichent tous le code brut ERR_CONNECTION_REFUSED. Firefox et Safari le formulent en langage courant, mais la cause et les solutions sont exactement les mêmes.

Causes courantes de ERR_CONNECTION_REFUSED

Environ la moitié du temps, le problème se situe côté serveur, et l'autre moitié du temps, quelque chose sur votre appareil ou votre réseau interfère. Voici les causes les plus courantes, de la plus fréquente à la moins fréquente.

• Le serveur du site web est hors service — Le service web (nginx, Apache, Node.js) a planté, redémarre ou a été arrêté. La machine est en ligne mais rien ne répond sur le port 80/443.

• Un pare-feu bloque le port — Un pare-feu sur le serveur, votre réseau ou votre appareil rejette les connexions vers ce port.

• Paramètres de proxy mal configurés — Votre système fait transiter le trafic par un serveur proxy hors ligne ou injoignable. C'est l'une des causes côté client les plus courantes.

• Cache DNS obsolète — Le site a migré vers un nouveau serveur, mais votre entrée DNS en cache pointe toujours vers l'ancienne adresse IP où plus rien n'écoute.

• Interférence du VPN ou de l'antivirus — Le logiciel de sécurité intercepte la connexion et la rejette, ou le serveur de sortie du VPN ne peut pas atteindre le site.

• Interférence d'une extension de navigateur — Les bloqueurs de publicité, les extensions de confidentialité ou les extensions infectées par un malware peuvent bloquer les connexions vers certains hôtes.

• Substitution dans le fichier hosts — Le domaine est associé à une mauvaise IP (souvent 127.0.0.1) dans votre fichier hosts, donc votre navigateur se connecte à votre propre machine, qui refuse.

• Rien n'écoute sur localhost — Pour les développeurs : le serveur de développement local ne tourne pas, a planté ou est lié à un autre port que celui que vous avez ouvert.

• Problème de routeur — Un routeur ou un modem défaillant altère les connexions jusqu'à ce qu'il soit redémarré.

Solution 1 : vérifier si le site est hors ligne pour tout le monde

Avant de modifier quoi que ce soit sur votre appareil, déterminez si le problème se situe côté serveur — si le site est hors ligne pour tout le monde, aucune solution locale n'y changera rien.

La façon la plus propre de tester est de passer par un chemin réseau différent. Ouvrez le site sur votre téléphone en utilisant les données mobiles (Wi-Fi désactivé). S'il échoue là aussi, le serveur lui-même refuse les connexions et il ne vous reste qu'à attendre que le propriétaire du site corrige le problème.

Vous pouvez aussi tester le serveur directement avec ces outils DNS Robot :

• [Vérificateur de ports](/port-checker) — Saisissez le domaine du site et testez le port 443 (HTTPS) et le port 80 (HTTP). Si les deux apparaissent fermés, le serveur web est hors service ou bloqué par un pare-feu pour tout le monde, pas seulement pour vous.

• [Test Ping](/ping) — Vérifie si la machine serveur répond tout court. Si le ping fonctionne mais que les ports sont fermés, la machine est en ligne mais le service web est mort.

• [Vérificateur d'en-têtes HTTP](/http-headers) — Envoie une véritable requête HTTP depuis les serveurs de DNS Robot. S'il obtient une réponse alors que votre navigateur n'en obtient pas, le problème est local à votre appareil ou à votre réseau.

Solution 2 : redémarrer votre routeur et votre appareil

Le grand classique du premier réflexe, et pour cause : un redémarrage efface la table de connexions du routeur, son cache DNS et tout état NAT défaillant susceptible de provoquer des connexions refusées.

Débranchez votre routeur (et le modem, s'il est séparé) de l'alimentation, attendez 30 secondes, rebranchez-le et laissez-lui 2 à 3 minutes pour se reconnecter complètement. Redémarrez aussi votre ordinateur ou votre téléphone pour réinitialiser sa pile réseau, puis réessayez le site.

Solution 3 : vider le cache et les cookies de votre navigateur

Chrome peut avoir mis en cache une redirection cassée, une ancienne entrée HSTS ou des cookies qui vous dirigent vers un serveur mort. Les effacer force une connexion entièrement nouvelle.

• Ouvrez Chrome → cliquez sur le menu à trois points → Supprimer les données de navigation

• Période → sélectionnez Toutes les périodes

• Cochez « Cookies et autres données des sites » et « Images et fichiers en cache »

• Cliquez sur Supprimer les données, redémarrez Chrome et réessayez le site

Solution 4 : désactiver les paramètres de proxy

Un proxy mal configuré ou mort est l'une des causes les plus courantes de ERR_CONNECTION_REFUSED sur tous les sites web à la fois. Lorsque votre système est configuré pour faire transiter le trafic par un proxy qui n'existe plus — souvent un vestige d'un ancien VPN, d'une configuration scolaire/professionnelle ou d'un malware — chaque connexion est refusée.

Windows : ouvrez Paramètres → Réseau et Internet → Proxy. Désactivez « Utiliser un serveur proxy » sous Configuration manuelle du proxy, et désactivez « Détecter automatiquement les paramètres » si vous n'utilisez pas de proxy d'entreprise.

macOS : ouvrez Réglages Système → Réseau → Wi-Fi → Détails → Proxys. Décochez chaque protocole de la liste (proxy web HTTP, proxy web sécurisé HTTPS, proxy SOCKS) sauf si votre organisation en exige un, puis cliquez sur OK.

Chrome utilise les paramètres de proxy du système d'exploitation ; après les avoir modifiés, redémarrez donc le navigateur et testez à nouveau.

Solution 5 : vider votre cache DNS

Si le site web a récemment migré vers un nouveau serveur, votre entrée DNS en cache peut encore pointer vers l'ancienne adresse IP — où plus rien n'écoute, donc la connexion est refusée. Vider le cache force votre appareil à rechercher l'adresse actuelle.

# Windows (Command Prompt as Administrator)
ipconfig /flushdns

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

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Also clear Chrome's internal DNS cache:
# chrome://net-internals/#dns → Clear host cache

Après le vidage, effacez aussi le cache DNS propre à Chrome sur chrome://net-internals/#dns et videz les pools de sockets sur chrome://net-internals/#sockets — Chrome conserve les deux séparément du système d'exploitation. Pour la marche à suivre complète, consultez notre guide sur comment vider le DNS sur chaque OS.

Vous pouvez confirmer vers quelle IP le domaine se résout actuellement avec la recherche DNS de DNS Robot — si le nslookup de votre terminal affiche une IP différente du résultat global, votre cache était le problème.

Solution 6 : passer à un serveur DNS public

Si le serveur DNS de votre FAI renvoie des enregistrements obsolètes, vider le cache ne servira à rien — vous récupérerez simplement la même IP périmée. Passer à un résolveur public rapide vous garantit des enregistrements à jour et accélère souvent la navigation dans son ensemble.

Windows : Paramètres → Réseau et Internet → votre connexion → Modifier l'attribution du serveur DNS → Manuel → IPv4 activé → saisissez 1.1.1.1 et 1.0.0.1 → Enregistrez.

macOS : Réglages Système → Réseau → Wi-Fi → Détails → DNS → ajoutez 1.1.1.1 et 1.0.0.1, supprimez les anciennes entrées → OK.

Vous ne savez pas quel résolveur est le plus rapide depuis chez vous ? Lancez le Test de vitesse DNS de DNS Robot — il évalue Cloudflare, Google, Quad9 et d'autres depuis votre propre connexion en quelques secondes.

Solution 7 : désactiver temporairement VPN, antivirus et pare-feu

Les VPN, les boucliers web des antivirus et les pare-feu se placent tous entre votre navigateur et Internet, et chacun peut rejeter des connexions. Les fonctions d'analyse HTTPS des antivirus sont des coupables fréquents : elles font transiter votre trafic sécurisé par un service local, et quand ce service se dérègle, chaque site HTTPS est refusé.

Testez dans cet ordre : déconnectez le VPN et rechargez. Puis désactivez le module de protection web de l'antivirus pendant une minute et rechargez. Enfin, coupez brièvement le pare-feu (Pare-feu Windows Defender, ou le coupe-feu de macOS) et rechargez.

Si le site se charge après la désactivation de l'un d'eux, réactivez-le et ajoutez une exception pour le site — ou changez d'emplacement de serveur VPN — plutôt que de laisser la protection désactivée.

Solution 8 : tester les extensions en navigation privée

Les bloqueurs de publicité, les outils de confidentialité et les extensions VPN peuvent bloquer silencieusement les connexions vers certains hôtes. Le test rapide : ouvrez le site dans une fenêtre de navigation privée (Ctrl+Shift+N / Cmd+Shift+N), où la plupart des extensions sont désactivées par défaut.

Si le site se charge en navigation privée, une extension est en cause. Allez sur chrome://extensions, désactivez-les toutes, puis réactivez-les une par une jusqu'à ce que l'erreur revienne — voilà votre coupable. Supprimez-la ou excluez le site de ses filtres.

Solution 9 : vérifier votre fichier hosts

Votre fichier hosts a priorité sur le DNS pour certains domaines. Si le site y est associé à 127.0.0.1, 0.0.0.0 ou à une ancienne IP de serveur, votre navigateur se connecte à cette adresse à la place — et se fait refuser. Les entrées de développement oubliées et les listes hosts de blocage de publicités sont les suspects habituels.

# Windows — open as Administrator:
notepad C:\Windows\System32\drivers\etc\hosts

# macOS / Linux:
sudo nano /etc/hosts

# Look for lines containing the domain, e.g.:
# 127.0.0.1   example.com   ← forces the connection to your own PC
# 203.0.113.7 example.com   ← forces an old server IP

# Delete the offending line, save, then flush DNS.

Localhost refuse la connexion (pour les développeurs)

Voir localhost refused to connect ou ERR_CONNECTION_REFUSED sur 127.0.0.1 est un rite de passage pour tout développeur. Cela signifie que rien sur votre machine n'accepte de connexions sur le port demandé. Les raisons habituelles :

• Le serveur de développement ne tourne pas — Vous ne l'avez jamais démarré, ou il a planté. Vérifiez le terminal où npm run dev, rails s ou python manage.py runserver devrait être en cours d'exécution.

• Mauvais port — Le serveur a démarré sur un autre port (par ex. 3001 parce que 3000 était occupé) et vous ouvrez l'ancien. Lisez la ligne du journal de démarrage qui indique le port utilisé.

• Lié à une autre interface — Le serveur s'est lié à 0.0.0.0 ou à l'IP interne d'un conteneur, mais vous interrogez localhost — ou inversement. Les mappages de ports Docker (-p 3000:3000) doivent correspondre au port sur lequel l'application écoute à l'intérieur du conteneur.

• Pare-feu ou logiciel de sécurité — Les pare-feu locaux peuvent bloquer même les ports de loopback ; c'est courant sur les machines d'entreprise.

• HTTPS vs HTTP — Vous ouvrez https://localhost:3000 mais le serveur de développement ne parle que du HTTP simple. Essayez explicitement http://.

# Which process is listening on port 3000?
# macOS / Linux:
lsof -i :3000

# Windows (PowerShell):
netstat -ano | findstr :3000

# No output = nothing is listening = connection refused.
# Start your dev server, or kill the stale process and restart it.

Si vous devez vérifier qu'un port de votre serveur public est joignable depuis Internet (et pas seulement depuis la machine elle-même), utilisez le Vérificateur de ports de DNS Robot — il teste la connexion depuis l'extérieur de votre réseau, c'est-à-dire ce que vivent réellement vos visiteurs.

Pour les propriétaires de sites : votre site refuse les connexions

Si des visiteurs signalent ERR_CONNECTION_REFUSED sur votre propre site web, le serveur est en ligne (le DNS se résout, la machine répond probablement au ping) mais le service web n'accepte pas les connexions. Passez en revue cette liste de contrôle :

• Le processus du serveur web tourne-t-il ? Connectez-vous en SSH et vérifiez : systemctl status nginx (ou apache2, caddy). Un processus qui a planté après un rechargement raté ou une extinction par manque de mémoire est la cause n°1. Redémarrez-le : sudo systemctl restart nginx.

• Écoute-t-il sur les bons ports ? Exécutez ss -tlnp | grep -E ':80|:443'. Si rien n'écoute sur le 443, votre configuration TLS n'a pas pu se charger — vérifiez les erreurs de configuration avec nginx -t.

• Le pare-feu est-il ouvert ? Vérifiez ufw status ou le groupe de sécurité de votre fournisseur cloud. Les ports 80 et 443 doivent autoriser le TCP entrant depuis 0.0.0.0/0.

• Votre IP de serveur a-t-elle changé ? Comparez votre enregistrement DNS A avec l'IP réelle du serveur à l'aide de la recherche DNS. Après une migration, un ancien enregistrement A envoie les visiteurs vers la machine précédente.

• Testez depuis l'extérieur — Utilisez le Vérificateur de ports sur les ports 80 et 443, et le Vérificateur d'en-têtes HTTP pour confirmer que votre serveur répond à de vraies requêtes depuis l'Internet public.

Comment vérifier que la solution a fonctionné

Après chaque solution, confirmez la connexion au niveau du réseau plutôt que de simplement recharger la page — cela vous indique si le port s'est réellement ouvert.

# Test the TCP connection directly (Mac/Linux):
nc -zv example.com 443
# "succeeded" = port open, "refused" = still rejected

# Windows (PowerShell):
Test-NetConnection example.com -Port 443
# TcpTestSucceeded : True = fixed

# Then confirm what IP you're actually connecting to:
nslookup example.com

Ou évitez le terminal : saisissez le domaine et le port dans le Vérificateur de ports de DNS Robot pour une réponse ouvert/fermé instantanée depuis un réseau externe. Si le port est ouvert de l'extérieur mais que votre navigateur affiche toujours ERR_CONNECTION_REFUSED, le blocage se situe sur votre appareil — reprenez les solutions proxy, VPN, antivirus et fichier hosts ci-dessus.