Sommaire
Ce que signifie exactement ERR_CONNECTION_REFUSED
ERR_CONNECTION_REFUSED signifie une chose précise : la machine distante a bien été jointe sur le réseau, mais elle a refusé la connexion sur le port demandé. Autrement dit, la requête arrive jusqu’à l’hôte cible, puis celui-ci répond par un refus. Ce n’est ni un délai dépassé, ni un problème de nom de domaine, ni une panne générale d’Internet.
Cette distinction change tout dans le diagnostic. Si la connexion refusee, il faut chercher un blocage actif ou un service absent sur le chemin final : navigateur, proxy, pare-feu local, box, puis serveur. Quand un site refuse la connexion, le plus fréquent est un port ferme, un service web arrêté, un filtrage qui rejette la connexion, ou un proxy mal configuré.
Dans l’écosystème des Réseaux, ce message correspond en général à une réponse TCP négative, souvent un paquet RST, sur les ports web classiques 80 ou 443.
| Erreur | Message typique | Ce que cela implique | Où chercher |
|---|---|---|---|
| Connexion refusée | ERR_CONNECTION_REFUSED | La machine répond, mais n’accepte pas la session sur ce port | Service arrêté, port fermé, pare-feu en rejet, proxy |
| Délai dépassé | ERR_CONNECTION_TIMED_OUT | Aucune réponse dans le temps imparti | Filtrage silencieux, route, box, serveur injoignable |
| Nom introuvable | DNS_PROBE_FINISHED_NXDOMAIN | Le nom ne se résout pas en adresse IP | DNS, zone, cache, configuration du domaine |
Vérifier d’abord le navigateur et le proxy
La première cause locale d’erreur de connexion navigateur est un paramètre réseau dans le navigateur ou dans le système. Commencez par recharger la page, tester une navigation privée, puis essayer un autre navigateur. Si l’erreur n’apparaît que dans un seul logiciel, la piste locale se renforce.
Vérifiez aussi si un proxy manuel est activé. Un proxy erroné peut provoquer err_connection_refused alors que le site fonctionne. Sous Windows, la commande netsh winhttp show proxy affiche la configuration WinHTTP, par exemple Direct access (no proxy server) si aucun proxy n’est défini. Dans Chrome ou Edge, un proxy système mal renseigné peut suffire à bloquer l’accès.
- Tester l’URL en
http://puis enhttps:// - Essayer depuis un autre navigateur
- Contrôler les paramètres de proxy du système
- Vérifier si l’erreur touche un seul site ou plusieurs
Si seule la version HTTPS échoue, il peut être utile de vérifier si le port 443 est ouvert. Si le blocage concerne l’établissement TLS après connexion, consultez aussi les erreurs courantes liées au certificat SSL, qui relèvent toutefois d’un autre type de panne.
Contrôler le pare-feu local sans le désactiver
La seconde étape consiste à vérifier le filtrage sur la machine cliente. Un pare-feu peut refuser certaines connexions sortantes ou intercepter un logiciel précis. Le point clé ici : un refus n’est pas un silence. Quand un filtre rejette explicitement, le navigateur peut afficher une connexion refusee très vite.
Sur Windows, netstat -ano | findstr :443 affiche les connexions TCP liées au port 443 et peut montrer des états comme SYN_SENT ou ESTABLISHED. Si rien n’apparaît alors que vous tentez l’accès, le blocage peut se produire avant l’établissement de la session. Pour lire ces états, une page dédiée à netstat serait utile, mais ici l’objectif est surtout d’identifier si la requête part bien.
Ce contrôle élimine deux hypothèses : un blocage applicatif local et un rejet immédiat du système. Il ne faut pas désactiver le pare-feu comme méthode de test. Mieux vaut examiner ses journaux, ses règles sortantes et les exceptions par programme ou par port.
Tester la résolution DNS et purger le cache si besoin
Un refus de connexion n’est pas, par définition, un problème de nom. Pourtant, un DNS erroné peut vous envoyer vers une mauvaise adresse IP, qui elle refuse la connexion. Cette étape sert donc à vérifier que le domaine pointe vers la bonne machine.
La commande nslookup exemple.com affiche le serveur DNS interrogé puis l’adresse renvoyée, par exemple Name: exemple.com et Address: 93.184.216.34. Vous pouvez aussi tester la résolution DNS avec nslookup pour comparer les réponses selon les résolveurs.
Si la réponse DNS est correcte mais que le navigateur persiste à viser une ancienne IP, vider le cache DNS peut supprimer une entrée obsolète. Sous Windows, ipconfig /flushdns affiche Successfully flushed the DNS Resolver Cache.. Sous macOS, la commande dépend de la version, et sous Linux du résolveur utilisé.
Cette vérification élimine la confusion entre site refuse la connexion et domaine mal résolu. Elle permet aussi de confirmer que le navigateur tente bien d’atteindre le bon hôte.
Examiner la box, la redirection de port et l’accès au bon service
Si le site visé est un service auto-hébergé ou exposé depuis un réseau domestique, la box mérite un contrôle précis. Une redirection absente ou dirigée vers la mauvaise machine peut conduire à une réponse de refus. Le cas est fréquent quand un serveur web local écoute sur une IP privée différente de celle prévue.
Vérifiez l’adresse locale de la machine cible, le port publié et la règle NAT. Les ports standards du web sont 80 pour HTTP et 443 pour HTTPS. Si vous publiez un service sur un autre port, le client doit l’indiquer explicitement dans l’URL, par exemple http://203.0.113.10:8080.
Cette étape élimine les erreurs de chemin entre Internet et la machine finale. Elle recoupe souvent la notion d’adresse IP publique et privée, car une confusion entre les deux suffit à faire croire qu’un site refuse la connexion.
Vérifier côté serveur : port fermé, service arrêté ou rejet actif
Quand le réseau local et la résolution DNS sont corrects, il faut contrôler le serveur. Les causes principales sont connues : port ferme côté serveur, service web arrêté, application qui n’écoute que sur 127.0.0.1, ou pare-feu qui rejette explicitement les paquets au lieu de les ignorer.
Sur Linux, ss -ltn affiche les sockets TCP en écoute, par exemple LISTEN 0 511 0.0.0.0:443 si le serveur accepte les connexions HTTPS sur toutes les interfaces IPv4. Si vous obtenez seulement 127.0.0.1:443, le service écoute en local mais pas depuis l’extérieur. Avec systemd, systemctl status nginx ou systemctl status apache2 affiche si le service est active (running) ou arrêté.
Si un pare-feu serveur rejette la connexion, le client voit souvent un refus immédiat. S’il ignore les paquets, on bascule plutôt vers un délai dépassé. C’est la différence pratique entre rejet et silence. Dans les cas complexes, diagnostiquer un site avec des outils réseau aide à localiser le maillon qui répond négativement.
Tester dans l’ordre du chemin réseau, du plus proche au plus lointain
Le diagnostic le plus fiable suit l’ordre du trajet réel :
- Navigateur : autre navigateur, navigation privée, proxy, URL HTTP/HTTPS
- Machine locale : journaux et règles du pare-feu, connexions sortantes
- Résolveur DNS : comparaison des IP renvoyées, cache local
- Box ou routeur : NAT, redirection, bonne machine cible
- Serveur distant : service actif, écoute sur la bonne interface, filtre en rejet
Cet ordre évite de confondre plusieurs familles d’erreurs. Une panne DNS renvoie vers un autre chantier qu’un refus TCP. Un timeout oriente d’abord vers un filtrage silencieux ou une route cassée. Un err_connection_refused oriente au contraire vers une réponse négative explicite de l’hôte ou d’un équipement très proche de lui.
Cas particuliers souvent confondus avec ERR_CONNECTION_REFUSED
Certains scénarios reviennent souvent :
- Service arrêté : le serveur répond sur le réseau, mais aucun processus n’écoute sur le port demandé.
- Port fermé : le noyau ou le pare-feu refuse l’ouverture de session, typiquement sur
80ou443. - Pare-feu en rejet : il renvoie une erreur active, différente d’un simple filtrage silencieux.
- Proxy mal configuré : le navigateur envoie la requête au mauvais intermédiaire, qui refuse ou ne relaie rien.
- Mauvaise IP via DNS : le domaine résout vers un autre serveur, joignable mais non prévu pour ce site.
Le bon réflexe consiste à associer chaque test à ce qu’il élimine. Si nslookup renvoie la bonne IP, la piste DNS recule. Si le serveur écoute sur 0.0.0.0:443, le service n’est pas arrêté. Si la box redirige bien le port externe vers la bonne IP privée, le NAT n’est plus le suspect principal.
Questions fréquentes
Pourquoi un site refuse la connexion ?
Un site refuse la connexion quand la machine distante est joignable mais n’accepte pas la session sur le port demandé. La cause la plus fréquente est un service web arrêté ou un port fermé côté serveur. Un pare-feu configuré en rejet ou un proxy mal réglé peut produire le même résultat. Ce n’est pas la même chose qu’un nom de domaine introuvable ou qu’un délai dépassé.
Pourquoi Chrome me bloque l’accès de certains sites ?
Chrome peut afficher ce message si le proxy système est erroné, si une extension perturbe les connexions ou si le site visé refuse réellement l’accès réseau. Le navigateur peut aussi utiliser un cache DNS local obsolète. Un test en navigation privée et avec un autre navigateur permet de savoir si le problème vient de Chrome ou du chemin réseau. Si seul HTTPS échoue, le port 443 ou la couche TLS peuvent être en cause.
Comment résoudre le problème que votre site refuse la connexion ?
Il faut diagnostiquer dans l’ordre : navigateur, proxy, pare-feu local, DNS, box, puis serveur. Vérifiez d’abord la résolution du nom, puis si le service écoute réellement sur le port attendu, en général 80 ou 443. Contrôlez aussi les règles NAT si le site est auto-hébergé. Quand le service est arrêté ou limité à 127.0.0.1, l’erreur persiste tant que cette configuration n’est pas corrigée.
Quelle différence entre connexion refusée et délai dépassé ?
Une connexion refusée signifie que l’hôte cible répond et rejette activement l’ouverture de session. Un délai dépassé signifie qu’aucune réponse n’arrive avant la fin du temps d’attente. Dans le premier cas, on cherche surtout un port fermé, un service absent ou un filtrage en rejet. Dans le second, on examine plutôt un filtrage silencieux, une route cassée ou un serveur injoignable.
