ERR_CONNECTION_REFUSED : « n'autorise pas la connexion »

Qu'est-ce que ERR_CONNECTION_REFUSED ?

ERR_CONNECTION_REFUSED signifie que votre navigateur a trouvé l'adresse IP du site web, mais que la machine située à cette adresse a refusé la connexion. Chrome affiche « Ce site est inaccessible » avec « example.com n'autorise pas la connexion. » et le code ERR_CONNECTION_REFUSED, l'erreur -102 de la liste de Chromium (net_error_list.h).

Votre appareil a envoyé une demande de connexion TCP à l'adresse IP et au port du serveur (443 pour HTTPS, 80 pour HTTP) et a reçu un refus immédiat, soit une réinitialisation TCP, soit un message « port unreachable » (port inaccessible) d'un pare-feu : aucun programme n'acceptait de connexions sur ce port, ou un pare-feu a rejeté la demande. Le DNS a fonctionné ; la connexion, non.

Autrement dit, c'est une réponse, pas un silence. Si personne ne répond, Chrome attend et affiche ERR_CONNECTION_TIMED_OUT. Si la connexion s'ouvre puis est coupée, c'est ERR_CONNECTION_RESET ; si le serveur raccroche avant d'envoyer la page, c'est ERR_CONNECTION_CLOSED.

À quoi ressemble cette erreur dans les autres navigateurs et applications

Une connexion refusée est le même événement partout ; seule la formulation change. Les navigateurs basés sur Chromium (Chrome, Edge, Brave, Opera) affichent le code ERR_CONNECTION_REFUSED, et les applications signalent l'erreur propre au système d'exploitation :

Les solutions ci-dessous valent quelle que soit la formulation : quelque chose, à cette adresse et sur ce port, a dit non.

Causes courantes de ERR_CONNECTION_REFUSED

Les causes, du côté du site web jusqu'au vôtre :

• Le serveur du site web est en panne — le serveur 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 ou 443.
• Un pare-feu configuré pour rejeter — un pare-feu sur le serveur, sur votre réseau ou sur votre appareil qui rejette (au lieu d'abandonner sans rien dire) les connexions vers ce port.
• Le site bloque votre réseau — certains sites rejettent des plages d'adresses entières, comme les serveurs de sortie d'un VPN ou tout un pays.
• Un logiciel de sécurité ou un VPN — un bouclier web d'antivirus ou un VPN qui fait passer votre trafic par lui-même et refuse la connexion. (Un pare-feu de votre propre appareil qui bloque Chrome affiche une autre page, « Votre accès à Internet est bloqué », ERR_NETWORK_ACCESS_DENIED.)
• Une mauvaise adresse IP — un cache DNS obsolète ou une entrée du fichier hosts vous envoie vers un ancien serveur, ou vers votre propre ordinateur (127.0.0.1), où rien n'écoute.
• Une redirection ou une règle HTTPS mémorisée — Chrome a gardé en mémoire une redirection, ou la règle HSTS du site, et continue de vous envoyer vers un port que le site ne sert plus.
• Rien n'écoute sur localhost — pour les développeurs : le serveur local ne tourne pas, a planté, ou utilise un autre port ou une autre adresse que celui que vous avez ouvert.

Un site, tous les sites ou tous les navigateurs ?

L'endroit où l'erreur apparaît vous dit où chercher, avant de rien modifier :

« Dans tous les navigateurs » compte : Edge, Firefox et Safari ne partagent ni le cache ni les extensions de Chrome ; un refus dans tous les navigateurs pointe donc sous le navigateur, vers votre appareil, votre réseau ou le site lui-même.

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 site refuse tout le monde. Si c'est le cas, aucune solution de votre côté n'aidera.

Le test le plus rapide consiste à passer par un autre chemin réseau : ouvrez le site sur votre téléphone en données mobiles (Wi-Fi désactivé). Testez ensuite le serveur depuis l'extérieur avec ces outils DNS Robot :

• Vérificateur de site en panne — ouvre le site depuis 11 endroits et depuis votre propre navigateur. En panne partout : c'est le site ; accessible partout sauf chez vous : le problème est de votre côté.
• Vérificateur de ports — saisissez le site avec le port 443 (ou example.com:443). Fermé signifie que le serveur a aussi refusé notre connexion ; ouvert, qu'il accepte les connexions et que le refus est local.
• Test de Ping — se connecte au site sur le port 443 depuis 11 villes, plus un ping classique depuis une seule. Refusé depuis toutes les villes : la machine est allumée mais rien n'écoute sur ce port ; l'absence de réponse au ping classique ne prouve rien, car beaucoup de serveurs l'ignorent.

Solution 2 : redémarrer votre routeur et votre appareil

La première suggestion de Chrome, « Vérifier la connexion », dit de redémarrer « votre routeur, votre modem ou tout autre périphérique réseau utilisé ». Cela efface tout l'état accumulé par le routeur, y compris son cache DNS.

Débranchez votre routeur (et le modem, s'il est séparé), 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 : effacer les redirections et règles HTTPS mémorisées par Chrome

Chrome mémorise les redirections permanentes et la règle HSTS de chaque site (« toujours utiliser HTTPS »). Si le site a déménagé, ou a cessé de servir HTTPS sur le port 443, Chrome continue de vous envoyer vers une adresse ou un port où rien n'écoute.

• Ouvrez Chrome → menu à trois points → Supprimer les données de navigation
• Période → Depuis le début, cochez Images et fichiers en cache (les cookies peuvent rester)
• Cliquez sur Supprimer les données (ou Supprimer de cet appareil si vous n'êtes pas connecté à Chrome), puis réessayez le site
• Toujours refusé ? Ouvrez chrome://net-internals/#hsts, saisissez le domaine sous Delete domain security policies et cliquez sur Delete. Cela ne fonctionne que pour les règles définies par le site lui-même, pas pour les domaines intégrés à la liste de préchargement HSTS de Chrome.

Un changement de 2026 : Chrome 154 (octobre 2026) active par défaut « Toujours utiliser une connexion sécurisée » ; Chrome demande donc votre autorisation avant la première visite d'un site public sans HTTPS, au lieu d'essayer en silence (Google Security Blog).

Solution 4 : vérifier vos paramètres de proxy

La page d'erreur de Chrome mentionne le proxy ; vérifiez-le donc, mais sachez à quoi vous attendre. Quand Chrome ne peut pas joindre un serveur proxy, il affiche une page intitulée « Aucun accès à Internet » avec ERR_PROXY_CONNECTION_FAILED (« Le serveur proxy présente une erreur, ou l'adresse est incorrecte ») plutôt qu'ERR_CONNECTION_REFUSED. Si c'est cette page que vous voyez, voici votre solution.

Windows : Paramètres → Réseau et Internet → Proxy. Sous Configuration manuelle du proxy, cliquez sur Modifier à côté de « Utiliser un serveur proxy », désactivez-le et cliquez sur Enregistrer. Désactivez aussi « Utiliser le script d'installation » si vous ne reconnaissez pas l'adresse. Laissez « Détecter automatiquement les paramètres » activé, sauf si vous savez que votre réseau ne l'utilise pas.

macOS : Réglages Système → Réseau → Wi-Fi → Détails → Proxys. Désactivez tous les proxys que votre organisation n'a pas mis en place, puis cliquez sur OK.

Chrome utilise les paramètres de proxy du système, et Firefox aussi par défaut (« Utiliser les paramètres proxy du système »), si bien qu'un seul proxy périmé casse tous les navigateurs à la fois. Sur un appareil d'école ou de travail, c'est l'administrateur qui définit le proxy et vous ne pouvez pas le modifier.

Solution 5 : vider votre cache DNS

Si le site a migré vers un nouveau serveur, une réponse DNS en cache peut encore pointer vers l'ancienne adresse IP, où plus rien n'écoute. Vider le cache oblige 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.

Pour voir l'adresse que votre ordinateur utilise réellement (fichier hosts et cache compris), exécutez ping example.com, ou Resolve-DnsName example.com dans PowerShell, et comparez avec la Recherche DNS. N'utilisez pas nslookup pour cela : il interroge directement le serveur DNS et ignore les deux.

Solution 6 : passer à un serveur DNS public

Si le résolveur de votre FAI continue de renvoyer une ancienne adresse après le vidage du cache, passez à un résolveur public pour obtenir une réponse à jour.

Windows : Paramètres → Réseau et Internet → Wi-Fi → « Gérer les réseaux connus » → votre réseau (Ethernet → votre réseau) → Modifier à côté de « Attribution du serveur DNS » → Manuel → IPv4 activé → DNS préféré 1.1.1.1, Autre DNS 1.0.0.1 → Enregistrer.

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 compare 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 entre votre navigateur et Internet, et chacun peut refuser une connexion. Les boucliers qui analysent le HTTPS font transiter votre trafic par un service local ; si ce service tombe en panne, les sites HTTPS peuvent échouer dans tous les navigateurs à la fois. Et certains sites rejettent purement et simplement les adresses de VPN.

Testez-les un par un : déconnectez le VPN et rechargez. Ensuite, mettez en pause la protection web de l'antivirus pendant une minute et rechargez. Enfin, mettez en pause tout pare-feu tiers, souvent intégré à une suite antivirus. (Le pare-feu de macOS ne filtre que les connexions entrantes, et le Pare-feu Windows Defender autorise le trafic sortant sauf si quelqu'un a ajouté une règle. Si Chrome affiche « Votre accès à Internet est bloqué », la cause est un pare-feu de votre appareil.)

Si le site se charge avec l'un d'eux désactivé, réactivez-le et ajoutez une exception pour le site, ou choisissez un autre serveur VPN, plutôt que de laisser la protection désactivée.

Solution 8 : tester les extensions en navigation privée

Les extensions causent rarement ce code : une extension qui bloque un site affiche ERR_BLOCKED_BY_CLIENT. Mais une fenêtre de navigation privée (Ctrl+Maj+N, ou Cmd+Maj+N sur Mac) est un test de dix secondes qui écarte à la fois les extensions et les données en cache, car les extensions y sont désactivées sauf si vous les avez autorisées.

Si le site se charge en navigation privée, allez sur chrome://extensions, désactivez-les toutes, puis réactivez-les une par une jusqu'au retour de l'erreur. S'il échoue encore en navigation privée, la cause est en dehors de Chrome.

Solution 9 : vérifier votre fichier hosts

Votre fichier hosts a priorité sur le DNS pour les noms qu'il contient. Si le site y est associé à 127.0.0.1 ou à l'IP d'un ancien serveur, votre navigateur se connecte là et se fait refuser. Les entrées de développement oubliées et les listes hosts de blocage de publicités sont les coupables habituels, et le fichier touche tous les navigateurs.

# 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.

Solution 10 : sur Android ou iPhone

Les téléphones refusent des connexions pour les mêmes raisons, avec d'autres interrupteurs :

• Changez de réseau : chargez le site en données mobiles, puis en Wi-Fi. Si un seul des deux refuse, le problème vient de ce réseau, pas du téléphone.
• Désactivez les applications VPN, y compris les bloqueurs de publicités et pare-feu qui fonctionnent comme un VPN (ils affichent une clé ou une icône VPN dans la barre d'état).
• Supprimez un proxy Wi-Fi : sur Android, ouvrez les paramètres du réseau Wi-Fi → icône en forme de crayon (Modifier) → Options avancées → Proxy → Aucun (le libellé varie selon le fabricant). Sur iPhone : Réglages → Wi-Fi → ⓘ à côté du réseau → Configurer le proxy → « Off » (désactivé).
• Effacez les données de Chrome : Chrome → Paramètres → Confidentialité et sécurité → Supprimer les données de navigation → Images et fichiers en cache.
• Vous testez votre propre serveur ? Sur un téléphone, localhost désigne le téléphone lui-même. Utilisez plutôt l'adresse IP locale de votre ordinateur (voir la section suivante).

Localhost refuse la connexion (pour les développeurs)

Voir localhost refused to connect (« localhost n'autorise pas la connexion ») ou ERR_CONNECTION_REFUSED sur 127.0.0.1 signifie que rien sur votre machine n'accepte de connexions sur l'adresse et le port que vous avez ouverts. 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 s'exécuter.
• Mauvais port — le serveur a démarré sur un autre port (3001 parce que 3000 était occupé, par exemple). Copiez l'adresse affichée à son démarrage.
• Pas de port dans l'adresse — http://localhost va au port 80, alors que les serveurs de développement utilisent le leur (3000, 5173, 8000, 8080).
• 127.0.0.1 ou [::1] — les navigateurs essaient les deux adresses pour localhost, mais un serveur peut n'écouter que sur l'une d'elles. Ouvrir directement l'autre adresse (http://127.0.0.1:3000 ou http://[::1]:3000), ou se connecter depuis un outil qui n'en essaie qu'une, est refusé.
• Dans Docker — l'application doit écouter sur 0.0.0.0 dans le conteneur, et le port doit être publié (-p 3000:3000). Une application liée à 127.0.0.1 dans un conteneur n'est pas joignable depuis votre machine (vous pouvez voir ERR_EMPTY_RESPONSE à la place).
• Depuis un téléphone ou un émulateur — là, localhost désigne l'appareil lui-même. Utilisez l'IP LAN de votre ordinateur et démarrez le serveur de développement sur toutes les interfaces (Vite : --host), ou 10.0.2.2 depuis l'émulateur Android, son alias pour le localhost de votre ordinateur.

# What is listening on port 3000?
# macOS / Linux:
lsof -nP -iTCP:3000 -sTCP:LISTEN

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

# No output = nothing is listening = connection refused.
# 127.0.0.1:3000 in the output = IPv4 only; [::1]:3000 = IPv6 only.

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 vos visiteurs.

« N'autorise pas la connexion » dans une page intégrée

Si « example.com n'autorise pas la connexion. » apparaît dans un cadre d'une autre page (un formulaire, un rapport, une carte ou une connexion intégrés), ce n'est en général pas un problème de réseau. Chrome affiche la même phrase quand le site intégré interdit d'être affiché dans les pages d'autres sites au moyen d'un en-tête X-Frame-Options ou Content-Security-Policy: frame-ancestors. En interne, c'est ERR_BLOCKED_BY_RESPONSE, erreur -27 (net_error_list.h).

En tant que visiteur, ouvrez le lien intégré dans son propre onglet ; il s'y chargera. En tant que propriétaire du site, autorisez la page qui vous intègre avec Content-Security-Policy: frame-ancestors 'self' https://parent.example. X-Frame-Options ne peut dire que DENY ou SAMEORIGIN, et les navigateurs actuels suivent frame-ancestors quand une page envoie les deux. Voyez ce que votre site envoie avec le Vérificateur d'en-têtes HTTP, et notre guide X-Frame-Options donne les en-têtes exacts.

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

Si des visiteurs signalent ERR_CONNECTION_REFUSED sur votre site, leurs paquets atteignent une machine à votre IP, mais rien n'y accepte la connexion. Parcourez cette liste de contrôle :

• Le serveur web tourne-t-il ? Connectez-vous en SSH et vérifiez systemctl status nginx (ou apache2, caddy). Un serveur qui n'a pas démarré après un redémarrage à cause d'une configuration cassée, ou qui a été tué par manque de mémoire, ne laisse rien à l'écoute. Redémarrez-le avec sudo systemctl restart nginx.
• Écoute-t-il sur les bons ports et les bonnes adresses ? Exécutez ss -tlnp | grep -E ':(80|443) '. Un serveur qui n'écoute que sur 127.0.0.1 refuse tout le monde à l'extérieur ; rien sur le 443 signifie qu'aucun bloc serveur n'y écoute (HTTPS n'a jamais été configuré, ou le fichier du site n'est pas activé). nginx -T affiche la configuration réellement chargée.
• Un pare-feu rejette-t-il ? Une règle configurée pour rejeter (iptables REJECT, ufw reject) envoie des refus. Le deny par défaut d'ufw et les pare-feu cloud comme les groupes de sécurité AWS abandonnent les paquets en silence, ce que les visiteurs voient comme ERR_CONNECTION_TIMED_OUT.
• fail2ban a-t-il banni quelqu'un ? Son bannissement par défaut rejette l'adresse bannie : ce visiteur (ou vous, après quelques échecs de connexion SSH) reçoit ERR_CONNECTION_REFUSED pendant que tous les autres entrent. Vérifiez sudo fail2ban-client status.
• L'IP de votre serveur a-t-elle changé ? Comparez votre enregistrement 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.
• Derrière Cloudflare ? Pour les enregistrements en mode proxy (nuage orange), les visiteurs se connectent à Cloudflare, pas à vous, et ne verront donc pas ce code. Quand votre origine refuse les connexions de Cloudflare, Cloudflare affiche sa propre Error 521: Web server is down.
• Testez depuis l'extérieur : le Vérificateur de ports sur les ports 80 et 443, et le Vérificateur d'en-têtes HTTP pour une vraie requête depuis l'Internet public.

Comment vérifier que la solution a fonctionné

Après chaque correction, vérifiez 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 -w 5 example.com 443
# "succeeded" = port open, "refused" = still rejected

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

# Then confirm the address your computer actually uses:
ping -c 1 example.com          # Mac/Linux
Resolve-DnsName example.com    # Windows PowerShell

Ou évitez le terminal : passez le domaine et le port dans le Vérificateur de ports de DNS Robot pour une réponse ouvert/fermé depuis l'extérieur de votre réseau. Si le port est ouvert de l'extérieur mais que votre navigateur affiche toujours ERR_CONNECTION_REFUSED, le blocage se trouve sur votre appareil ou votre réseau : reprenez les solutions VPN, logiciel de sécurité et fichier hosts.