ERR_CONNECTION_REFUSED: Ce que cela signifie et comment le corriger complètement

L’erreur ERR_CONNECTION_REFUSED signifie que votre navigateur a envoyé une demande de connexion à un serveur web, et ce serveur l’a activement rejetée — non pas ignorée, mais explicitement refusée lors de la poignée de main TCP. C’est un mode de défaillance fondamentalement différent d’un délai d’expiration (ERR_CONNECTION_TIMED_OUT) ou d’une défaillance DNS (ERR_NAME_NOT_RESOLVED), et cette distinction est extrêmement importante lors du diagnostic de la cause racine.

En termes pratiques, lorsque Chrome affiche « Ce site est inaccessible. ERR_CONNECTION_REFUSED », cela signifie l’une de trois choses : le serveur cible n’écoute pas sur le port demandé, un pare-feu ou une couche de sécurité envoie un paquet TCP RST (réinitialisation) à votre client, ou votre pile réseau locale est mal configurée et achemine la demande de manière incorrecte avant qu’elle n’atteigne le serveur. Identifier laquelle de ces trois catégories s’applique à votre situation est le chemin le plus rapide vers une solution.

Comprendre la mécanique au niveau TCP

La plupart des guides de dépannage des navigateurs traitent ERR_CONNECTION_REFUSED comme un vague « problème réseau ». Ce n’est pas le cas. Au niveau TCP, une connexion refusée signifie que le serveur (ou un intermédiaire) a renvoyé un paquet RST/ACK en réponse au paquet SYN de votre navigateur. C’est un rejet explicite, pas une perte silencieuse.

Cette distinction a une implication pratique de diagnostic : si la connexion était silencieusement abandonnée par un pare-feu, vous verriez ERR_CONNECTION_TIMED_OUT. Une connexion refusée signifie que quelque chose répond activement — ce qui signifie que l’hôte est accessible au niveau réseau, mais le service sur le port cible est indisponible ou bloqué.

Les causes courantes au niveau du port incluent :

• Le processus du serveur web (Apache, Nginx, Node.js) s’est arrêté ou a échoué
• Le serveur écoute sur un port non standard et l’URL ne le spécifie pas
• Un pare-feu basé sur l’hôte (iptables, ufw, Windows Defender Firewall) rejette les connexions sur le port 80 ou 443
• Un proxy inverse (HAProxy, Nginx, Cloudflare) est configuré incorrectement et renvoie des paquets RST en amont
• L’application derrière le proxy s’est arrêtée, laissant le proxy sans backend vers lequel transférer

Causes Racines : Analyse Structurée

Causes Côté Client

Causes Côté Serveur

Guide de diagnostic et de correction étape par étape

Étape 1 : Déterminer si le problème est global ou local

Avant de modifier les paramètres locaux, établissez si le site est inaccessible pour tout le monde ou seulement pour vous. Utilisez ces outils :

• downforeveryoneorjustme.com — vérification simple de disponibilité
• isitdownrightnow.com — inclut l’historique des temps de réponse
• ping.pe — effectue des pings sur la cible depuis plusieurs emplacements mondiaux simultanément

Si le site est accessible depuis des nœuds externes mais pas depuis votre machine, le problème est local. S’il est inaccessible mondialement, le problème est côté serveur et hors de votre contrôle — contactez l’administrateur du site ou attendez.

Pour les administrateurs de serveurs gérant leur propre infrastructure, un site mondialement inaccessible justifie une investigation immédiate du processus du serveur web, des règles de pare-feu et du réseau en amont. Si vous exécutez un environnement VPS Hosting, vérifiez d’abord la liste des processus de votre serveur et la configuration du pare-feu.

Étape 2 : Vérifier que le serveur écoute réellement (pour les administrateurs de serveurs)

Si vous administrez le serveur en question, connectez-vous via SSH et exécutez la commande suivante pour confirmer ce qui écoute sur quels ports :

sudo ss -tlnp | grep -E ':80|:443'

Si la sortie est vide pour le port 80 ou 443, votre processus de serveur web n’est pas en cours d’exécution. Redémarrez-le :

# For Nginx
sudo systemctl restart nginx

# For Apache
sudo systemctl restart apache2

# Check status
sudo systemctl status nginx

Vérifiez également que votre pare-feu ne bloque pas les connexions entrantes :

# Check iptables rules
sudo iptables -L INPUT -n -v

# If using ufw
sudo ufw status verbose

Si le port 443 est bloqué, autorisez-le :

sudo ufw allow 443/tcp
sudo ufw allow 80/tcp
sudo ufw reload

Pour les administrateurs exécutant des Serveurs dédiés, vérifiez également si le pare-feu en amont de votre fournisseur d’hébergement ou les règles du groupe de sécurité bloquent le port au périmètre du réseau — ceci est distinct du pare-feu au niveau du système d’exploitation.

Étape 3 : Redémarrer votre routeur et vider l’état du réseau local

Pour les problèmes côté client, un redémarrage du routeur efface les tables NAT, les baux DHCP et tout échec de routage transitoire. Débranchez le routeur pendant 30 secondes, puis reconnectez-le. Ceci est particulièrement efficace quand l’erreur est apparue soudainement sans aucun changement de configuration.

Étape 4 : Vider le cache DNS

Une entrée de cache DNS obsolète pointant vers une ancienne adresse IP ou une adresse IP désaffectée est l’une des causes les plus courantes de ERR_CONNECTION_REFUSED côté client. Le serveur à l’adresse IP en cache peut ne plus exécuter le site cible.

• Sur Windows :

ipconfig /flushdns

• Sur macOS (Ventura, Sonoma et la plupart des versions modernes) :

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

• Sur Linux (systemd-resolved) :

sudo systemd-resolve --flush-caches

Après le vidage, vérifiez à quelle adresse IP le domaine se résout maintenant :

nslookup example.com
# or
dig +short example.com

Comparez ceci avec l’adresse IP connue du site. S’ils diffèrent, la propagation DNS peut encore être en cours.

Étape 5 : Effacer le cache et les cookies du navigateur

Dans Google Chrome, accédez à chrome://settings/clearBrowserData ou utilisez le raccourci clavier :

• Windows/Linux : Ctrl + Maj + Suppr
• macOS : Cmd + Maj + Suppr

Définissez la plage de temps sur Toute la période, cochez Images et fichiers en cache et Cookies et autres données de site, puis cliquez sur Effacer les données. Redémarrez complètement Chrome (pas seulement l’onglet) avant de retester.

Pour un test plus rapide sans effacer les données, ouvrez une fenêtre Incognito (Ctrl + Maj + N). Si le site se charge en Incognito mais pas dans une fenêtre normale, une ressource en cache ou une extension de navigateur est le coupable.

Étape 6 : Auditer et désactiver les paramètres de proxy

Un serveur proxy mal configuré ou inactif est une cause fréquente de ERR_CONNECTION_REFUSED sur tous les sites web simultanément. Chrome utilise les paramètres de proxy du système par défaut.

• Sur Windows :

Accédez à Paramètres > Système > Proxy et désactivez « Utiliser un serveur proxy » s’il est activé à votre insu. Vous pouvez également exécuter ceci depuis une invite de commandes élevée :

netsh winhttp reset proxy

• Sur macOS

Allez à Paramètres système > Réseau, sélectionnez votre interface active, cliquez sur Détails, puis l’onglet Proxies, et décochez tous les protocoles de proxy actifs.

Après avoir désactivé le proxy, testez le site. S’il se charge, votre configuration de proxy était la cause. Soit reconfigurez-la correctement, soit supprimez-la entièrement.

Étape 7 : Changer votre résolveur DNS

Le résolveur DNS par défaut de votre FAI peut retourner des résultats incorrects, connaître une panne ou bloquer activement certains domaines. Passer à un résolveur public élimine cette variable.

Résolveurs DNS publics recommandés :

• Sur Windows (via PowerShell) :

Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1","1.0.0.1")

• Sur macOS :

Allez à Paramètres système > Réseau > [Votre interface] > Détails > DNS, supprimez les entrées existantes, et ajoutez 1.1.1.1 et 1.0.0.1.

• Sur Linux (systemd-resolved) :

Modifiez /etc/systemd/resolved.conf :

[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4

Puis redémarrez le résolveur :

sudo systemctl restart systemd-resolved

Étape 8 : Désactiver temporairement le pare-feu et l’antivirus

Certains produits antivirus et pare-feu basés sur l’hôte interceptent le trafic HTTPS via un proxy local et peuvent émettre des paquets RST quand leur moteur d’inspection échoue ou quand le domaine cible est sur une liste de blocage. Les désactiver temporairement (à des fins de diagnostic uniquement) confirme s’ils sont la cause.

Si la désactivation du logiciel de sécurité résout l’erreur, ajoutez une exception spécifique pour le domaine cible plutôt que de laisser le logiciel désactivé. Réactivez-le immédiatement après le test.

Étape 9 : Tester avec un navigateur et un réseau différents

Testez l’URL dans Firefox, Edge ou Safari. Si elle se charge dans un autre navigateur, le problème est spécifique à Chrome — probablement un profil corrompu, une extension défectueuse ou un paramètre de proxy spécifique à Chrome. Essayez de créer un nouveau profil Chrome pour isoler le problème.

Si le site échoue dans tous les navigateurs, basculez vers un point d’accès mobile. S’il se charge sur les données mobiles, votre FAI ou votre routeur domestique est la source du problème.

Étape 10 : Vérifier les problèmes de configuration SSL/TLS (administrateurs de serveurs)

Un certificat SSL mal configuré peut faire planter le serveur ou refuser les connexions TLS, ce que Chrome signale comme ERR_CONNECTION_REFUSED plutôt qu’une erreur de certificat dans certains cas limites. Utilisez ce qui suit pour tester depuis la ligne de commande :

curl -vI https://yourdomain.com

Recherchez l’étape de poignée de main TLS dans la sortie détaillée. Un échec ici indique un problème de certificat ou de suite de chiffrement. Vous pouvez également tester avec :

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

Si votre certificat SSL a expiré ou est mal configuré, le renouveler ou le remplacer résout le problème. Assurez-vous que vos Certificats SSL sont valides, correctement chaînés et installés sur l’interface serveur correcte.

ERR_CONNECTION_REFUSED vs. Erreurs de navigateur similaires

Comprendre comment cette erreur diffère des erreurs connexes prévient les diagnostics erronés :

Cas limites avancés et pièges

1) Conflits de résolution IPv6 vs. IPv4 :

Si un domaine se résout en adresse IPv6 mais que votre réseau ne supporte pas correctement IPv6, Chrome peut tenter une connexion IPv6 qui est refusée, puis échouer à basculer vers IPv4 rapidement. Désactiver temporairement IPv6 sur l’adaptateur réseau peut confirmer cela. Sur Linux, vous pouvez forcer IPv4 avec curl -4 https://example.com.

2) Mise en cache Cloudflare ou CDN avec erreurs d’origine obsolètes :

Si un site utilise Cloudflare et que le serveur d’origine tombe en panne, Cloudflare peut servir une version en cache pendant un certain temps, puis commencer à retourner des erreurs 521 (origin refused connection) ou 522, que Chrome peut afficher comme ERR_CONNECTION_REFUSED selon la façon dont l’erreur est proxifiée.

3) Environnements de développement Localhost :

Les développeurs voient fréquemment ERR_CONNECTION_REFUSED lors de l’accès à localhost:3000 ou similaire. La cause est presque toujours que le processus du serveur de développement n’est pas en cours d’exécution, a planté, ou est lié à 127.0.0.1 sur un port différent de celui attendu. Exécutez ss -tlnp | grep node (ou le processus pertinent) pour confirmer ce qui écoute réellement.

4) Conflits de ports de serveur de messagerie :

Si vous exécutez Email Hosting sur le même serveur que votre application web, assurez-vous que les conflits de ports entre SMTP (25, 587), IMAP (993) et HTTP/HTTPS (80, 443) ne causent pas l’échec de la liaison du serveur web.

5) Limitations de l’hébergement mutualisé :

Sur les environnements Shared Web Hosting, un refus de connexion peut indiquer que le serveur du fournisseur d’hébergement est surchargé, que le compte a été suspendu, ou que le DNS du domaine ne pointe pas encore vers la bonne IP partagée. Vérifiez le statut de votre compte et la configuration DNS dans le panneau de contrôle de votre hébergement.

Matrice de décision pratique : Quel correctif appliquer en premier

Utilisez cette checklist pour un triage efficace :

• L’erreur apparaît sur tous les sites web simultanément — Vérifiez d’abord les paramètres proxy et la configuration VPN/firewall
• L’erreur apparaît uniquement sur un domaine spécifique — Vérifiez si le site est globalement hors ligne ; puis videz le cache DNS
• L’erreur apparaît uniquement dans Chrome, pas dans les autres navigateurs — Videz le cache Chrome, désactivez les extensions, ou créez un nouveau profil Chrome
• L’erreur apparaît uniquement sur votre réseau, pas sur les données mobiles — Redémarrez le routeur ; vérifiez le DNS au niveau du FAI ou le firewall
• L’erreur apparaît après une modification de configuration du serveur — Vérifiez l’état du processus du serveur web, les liaisons de ports et les règles firewall sur le serveur
• L’erreur apparaît par intermittence sous charge — Enquêtez sur l’épuisement des ressources (descripteurs de fichiers, mémoire, limites de connexion) sur le serveur
• L’erreur apparaît uniquement sur HTTPS, pas sur HTTP — Enquêtez sur la validité du certificat SSL et la configuration TLS
• L’erreur est apparue après modification des paramètres DNS — Annulez les modifications DNS et videz le cache ; vérifiez que le nouveau résolveur est accessible

FAQ

1) Quelle est la différence entre ERR_CONNECTION_REFUSED et ERR_CONNECTION_TIMED_OUT ?

ERR_CONNECTION_REFUSED signifie que le serveur (ou un pare-feu) a activement envoyé un paquet de réinitialisation TCP, rejetant la connexion immédiatement. ERR_CONNECTION_TIMED_OUT signifie qu’aucune réponse n’a été reçue dans le délai imparti — les paquets ont été silencieusement abandonnés. Une connexion refusée apparaît plus rapidement et indique un rejet actif, tandis qu’un délai d’expiration suggère une règle de routage ou de pare-feu DROP.

2) ERR_CONNECTION_REFUSED peut-il être causé par un certificat SSL expiré ?

Indirectement, oui. Dans certaines configurations de serveur, un certificat SSL expiré ou mal configuré provoque l’échec du processus du serveur web au démarrage ou son arrêt lors du traitement des connexions TLS, ce qui entraîne l’absence d’écouteur sur le port 443. Chrome signale alors ERR_CONNECTION_REFUSED car rien n’écoute, même si la cause sous-jacente est un problème de certificat.

3) Pourquoi ERR_CONNECTION_REFUSED apparaît-il uniquement sur un site web spécifique ?

Si l’erreur est isolée à un seul domaine, les causes les plus probables sont : le service web du serveur cible a planté, le pare-feu du serveur bloque votre plage d’adresses IP, les enregistrements DNS du domaine pointent vers une ancienne adresse IP où aucun service n’est en cours d’exécution, ou le site a été fermé. Utilisez curl -v https://thatdomain.com depuis un réseau ou un serveur différent pour isoler la cause.

4) Comment corriger ERR_CONNECTION_REFUSED sur localhost ?

Le serveur d’application n’est pas en cours d’exécution ou est lié à un port différent de celui que vous demandez. Confirmez ce qui écoute avec ss -tlnp sur Linux/macOS ou netstat -ano | findstr :PORT sur Windows. Démarrez le processus du serveur d’application et assurez-vous qu’il est lié à 0.0.0.0 ou 127.0.0.1 sur le port attendu.

5) Le vidage du DNS corrige-t-il toujours ERR_CONNECTION_REFUSED ?

Uniquement lorsque la cause première est une entrée de cache DNS obsolète pointant vers une adresse IP où le service n’est plus en cours d’exécution. Si le serveur est arrêté, le pare-feu bloque la connexion, ou le proxy est mal configuré, le vidage du DNS n’aura aucun effet. Utilisez dig ou nslookup pour vérifier la résolution DNS avant et après le vidage pour confirmer si DNS était réellement le problème.