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 que ce serveur l’a activement rejetée — non pas ignorée, mais explicitement refusée lors de la négociation TCP. Il s’agit d’un mode d’échec fondamentalement différent d’un délai d’attente (ERR_CONNECTION_TIMED_OUT) ou d’un échec DNS (ERR_NAME_NOT_RESOLVED), et cette distinction est extrêmement importante lors du diagnostic de la cause racine.

En pratique, lorsque Chrome affiche « Ce site est inaccessible. ERR_CONNECTION_REFUSED », cela signifie l’une des trois choses suivantes : 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 requête incorrectement avant qu’elle n’atteigne le serveur. Identifier laquelle de ces trois catégories s’applique à votre situation est le moyen le plus rapide de trouver une solution.

Comprendre les mécanismes au niveau TCP

La plupart des guides de dépannage de navigateur traitent ERR_CONNECTION_REFUSED comme un vague « problème réseau ». Ce n’est pas le cas. Au niveau de la couche 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. Il s’agit d’un rejet explicite, et non d’un abandon silencieux.

Cette distinction a une implication pratique pour le 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 que le service sur le port cible est indisponible ou bloqué.

Les causes courantes au niveau des ports incluent :

• Le processus du serveur web (Apache, Nginx, Node.js) a planté ou s’est arrêté
• 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 mal configuré et renvoie des paquets RST en amont
• L’application derrière le proxy a planté, laissant le proxy sans backend vers lequel transférer

Causes racines : une 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 des paramètres locaux, déterminez si le site est inaccessible pour tout le monde ou uniquement 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 un ping vers 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 globalement, le problème est côté serveur et hors de votre contrôle — contactez l’administrateur du site ou patientez.

Pour les administrateurs de serveurs gérant leur propre infrastructure, un site globalement 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 exploitez 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 ne fonctionne pas. 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 exploitant des Dedicated Servers, vérifiez également si le pare-feu en amont de votre hébergeur ou les règles de groupe de sécurité bloquent le port au périmètre réseau — cela 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 toute défaillance de routage transitoire. Débranchez le routeur pendant 30 secondes, puis reconnectez-le. Cela est particulièrement efficace lorsque l’erreur est apparue soudainement sans aucune modification de configuration.

Étape 4 : Vider le cache DNS

Une entrée de cache DNS obsolète pointant vers une ancienne adresse IP ou une IP désaffectée est l’une des causes les plus courantes de ERR_CONNECTION_REFUSED côté client. Le serveur à l’IP mise en cache peut ne plus héberger 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 avoir vidé le cache, vérifiez vers quelle IP le domaine se résout maintenant :

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

Comparez cela avec l’IP connue du site. Si elles diffèrent, la propagation DNS est peut-être encore en cours.

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

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

• Windows/Linux : Ctrl + Shift + Delete
• macOS : Cmd + Shift + Delete

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

Pour un test rapide sans effacer les données, ouvrez une fenêtre de navigation privée (Ctrl + Shift + N). Si le site se charge en navigation privée mais pas dans une fenêtre normale, une ressource mise en cache ou une extension de navigateur est en cause.

Étape 6 : Vérifier 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 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 avec élévation de privilèges :

netsh winhttp reset proxy

Sur macOS :

Allez dans Réglages Système > Réseau, sélectionnez votre interface active, cliquez sur Détails, puis sur 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. Reconfigurez-le correctement ou supprimez-le entièrement.

Étape 7 : Changer votre résolveur DNS

Le résolveur DNS par défaut de votre FAI peut renvoyer des résultats incorrects, subir 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 dans Réglages 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-feux basés sur l’hôte interceptent le trafic HTTPS via un proxy local et peuvent émettre des paquets RST lorsque leur moteur d’inspection échoue ou lorsque le domaine cible figure sur une liste de blocage. Les désactiver temporairement (à des fins de diagnostic uniquement) permet de confirmer 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 les tests.

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

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éfaillante ou un paramètre de proxy propre à Chrome. Essayez de créer un nouveau profil Chrome pour isoler le problème.

Si le site échoue dans tous les navigateurs, passez à un point d’accès mobile. S’il se charge via 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 provoquer le plantage du serveur ou le refus des connexions TLS, que Chrome signale comme ERR_CONNECTION_REFUSED plutôt que comme une erreur de certificat dans certains cas particuliers. Utilisez la commande suivante pour tester depuis la ligne de commande :

curl -vI https://yourdomain.com

Recherchez l’étape de négociation TLS dans la sortie détaillée. Un échec à ce stade 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é, son renouvellement ou son remplacement résout le problème. Assurez-vous que vos SSL Certificates sont valides, correctement chaînés et installés sur la bonne interface serveur.

ERR_CONNECTION_REFUSED vs. erreurs de navigateur similaires

Comprendre en quoi cette erreur diffère des erreurs connexes permet d’éviter les mauvais diagnostics :

Cas limites avancés et pièges

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

Cloudflare ou CDN mettant en cache des erreurs d’origine obsolètes : Si un site utilise Cloudflare et que le serveur d’origine tombe en panne, Cloudflare peut servir une version mise en cache pendant un certain temps, puis commencer à renvoyer des erreurs 521 (connexion refusée par l’origine) ou 522, que Chrome peut afficher comme ERR_CONNECTION_REFUSED selon la façon dont l’erreur est transmise par proxy.

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 ne fonctionne pas, 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 concerné) pour confirmer ce qui écoute réellement.

Conflits de ports de serveur de messagerie : Si vous exploitez un 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 provoquent pas l’échec de liaison du serveur web.

Limitations de l’hébergement mutualisé : Dans les environnements d’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 l’état de votre compte et la configuration DNS dans votre panneau de contrôle d’hébergement.

Matrice de décision pratique : quelle correction appliquer en premier

Utilisez cette liste de contrôle pour trier efficacement :

• L’erreur apparaît sur tous les sites web simultanément — Vérifiez d’abord les paramètres de proxy et la configuration VPN/pare-feu
• L’erreur apparaît uniquement sur un domaine spécifique — Vérifiez si le site est globalement inaccessible ; 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 via les données mobiles — Redémarrez le routeur ; vérifiez le DNS ou le pare-feu au niveau du FAI
• 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 de pare-feu sur le serveur
• L’erreur apparaît de façon intermittente sous charge — Examinez 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 — Examinez la validité du certificat SSL et la configuration TLS
• L’erreur est apparue après avoir modifié les paramètres DNS — Annulez les modifications DNS et videz le cache ; vérifiez que le nouveau résolveur est accessible

FAQ

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’attente suggère une règle DROP de routage ou de pare-feu.

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 démarrage du processus du serveur web ou son plantage 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.

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 IP, les enregistrements DNS du domaine pointent vers une ancienne adresse IP où aucun service ne fonctionne, ou le site a été mis hors ligne. Utilisez curl -v https://thatdomain.com depuis un réseau ou un serveur différent pour isoler la cause.

Comment corriger ERR_CONNECTION_REFUSED sur localhost ?

Le serveur d’application ne fonctionne pas 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.

Le vidage du DNS résout-il toujours ERR_CONNECTION_REFUSED ?

Uniquement lorsque la cause racine est une entrée de cache DNS obsolète pointant vers une adresse IP où le service ne fonctionne plus. Si le serveur est hors service, si le pare-feu bloque la connexion ou si 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 afin de confirmer si le DNS était réellement le problème.