ERR_CONNECTION_REFUSED : le diagnostic complet

ERR_CONNECTION_REFUSED : le serveur claque la porte

Ce matin, sur un site hébergé chez un petit hébergeur mutualisé, impossible d’ouvrir la moindre page : le navigateur affiche en boucle ERR_CONNECTION_REFUSED. Pas de page blanche, pas de message d’erreur du serveur, juste un refus sec. C’est le message le plus frustrant de tous, car il ne vient même pas de ton site : il signifie que la machine en face a refusé la connexion avant même de pouvoir parler à WordPress ou à ton code.

Bonne nouvelle : ce message est en réalité très précis. Contrairement à un ERR_CONNECTION_TIMED_OUT (où personne ne répond du tout), ici quelqu’un répond activement “non”. Ça veut dire qu’on peut localiser le coupable assez vite : service arrêté, mauvais port, pare-feu trop strict, ou DNS qui pointe vers la mauvaise adresse. Suis la checklist dans l’ordre, tu élimines les hypothèses une par une.

Pourquoi ça arrive : ce qui pèse sur la connexion

• Le service web est arrêté : Apache ou Nginx a planté ou a été stoppé côté serveur (redémarrage, mise à jour système, crash mémoire).
• Le mauvais port est visé : ton navigateur tente le port 443 (HTTPS) ou 80 (HTTP), mais rien n’écoute derrière — souvent après une migration bâclée ou une config SSL cassée.
• Un pare-feu bloque le port : côté serveur (iptables, ufw, pare-feu applicatif) ou côté réseau (box internet, proxy d’entreprise, VPN).
• Le DNS pointe vers une IP morte : le domaine a été redirigé vers une ancienne adresse serveur qui n’existe plus.
• L’hébergement a suspendu le compte : impayé, dépassement de quota, signalement d’abus — certains hébergeurs coupent le service au lieu d’afficher une page d’attente.
• Un souci réseau local : antivirus, VPN d’entreprise, réseau Wi-Fi restrictif qui bloque certains ports en sortie.
• Cloudflare ou un proxy devant le serveur ne parvient pas à joindre l’origine et referme la connexion sèchement.

L’objectif de la checklist qui suit : trancher vite entre “ça vient de toi / de ton réseau” et “ça vient du serveur”.

1. Élimine d’abord ton propre réseau

Avant de toucher au serveur, vérifie que le problème n’est pas local :

• Teste depuis un autre appareil, un autre réseau (4G du téléphone par exemple).
• Utilise un outil de vérification externe type “site down for everyone or just me” pour savoir si d’autres visiteurs ont le même souci.
• Désactive temporairement VPN, proxy d’entreprise ou antivirus agressif : certains bloquent des ports spécifiques en sortie.

Si le site fonctionne ailleurs, le problème est réseau local, pas serveur — inutile d’aller plus loin dans cet article.

2. Vérifie où pointe réellement le domaine (DNS)

Un DNS mal réglé envoie parfois les visiteurs vers une IP qui ne répond plus (ancien serveur éteint, migration incomplète). Vérifie l’enregistrement A ou AAAA de ton domaine avec un outil whois/dig en ligne, et compare avec l’IP réelle de ton hébergement actuel.

Si tu viens de changer d’hébergeur, consulte la checklist après migration et le guide pour migrer WordPress proprement. Si les DNS ne se sont pas encore propagés ou pointent au mauvais endroit, direction le diagnostic DNS complet, avec les guides pratiques par hébergeur : OVH, Hostinger, IONOS.

3. Teste la connexion réseau brute (sans navigateur)

Le navigateur cache parfois des détails utiles. Ouvre un terminal et teste directement :

ping tonsite.fr
telnet tonsite.fr 443
curl -v https://tonsite.fr

• Si ping répond mais telnet sur le port 443 échoue avec “connection refused” : le serveur est joignable, mais rien n’écoute sur ce port — service arrêté ou mal configuré.
• Si ping échoue aussi : le problème est plus en amont, souvent DNS ou réseau (retour à l’étape 2).

Cette distinction est cruciale : elle sépare “le serveur existe mais dort” de “le serveur n’est même pas trouvé”.

4. Vérifie que le service web tourne côté serveur

Si tu as un accès SSH (VPS, serveur dédié, certains mutualisés avancés), connecte-toi et vérifie l’état du service :

sudo systemctl status nginx
sudo systemctl status apache2

Si le service est “inactive” ou “failed”, relance-le :

sudo systemctl restart nginx

Regarde ensuite les logs d’erreur (/var/log/nginx/error.log ou /var/log/apache2/error.log) pour comprendre pourquoi il s’est arrêté : plantage mémoire, conflit de configuration, port déjà utilisé par un autre processus. Si tu n’as jamais utilisé le terminal, les guides SSH sur OVH, SSH sur Gandi ou SSH sur Plesk t’expliquent la connexion pas à pas.

Sur un mutualisé classique sans accès SSH, contacte directement le support hébergeur : c’est souvent la façon la plus rapide de savoir si le service a été coupé côté eux (maintenance, incident, suspension).

5. Vérifie le pare-feu et les ports ouverts

Si le service tourne mais que la connexion est quand même refusée de l’extérieur, un pare-feu bloque probablement le port. Vérifie les règles actives :

sudo ufw status
sudo iptables -L

Assure-toi que les ports 80 (HTTP) et 443 (HTTPS) sont bien ouverts en entrée. Un pare-feu trop strict, ajouté après un audit sécurité ou une tentative de blocage d’attaque, peut malheureusement bloquer aussi les visiteurs légitimes.

6. Vérifie que le compte d’hébergement n’est pas suspendu

Certains hébergeurs coupent purement et simplement le service en cas d’impayé, de dépassement de quota disque, ou de signalement d’abus (souvent après un piratage). Dans ce cas, tu ne verras même pas de page d’attente, juste ce refus de connexion. Connecte-toi à l’espace client de l’hébergeur pour vérifier l’état du compte et les factures en attente. Si le site a été compromis, le guide site WordPress piraté t’aide à nettoyer avant la remise en ligne.

7. Cas particulier : Cloudflare ou un proxy devant le serveur

Si ton domaine passe par Cloudflare (ou un autre CDN/proxy), le refus de connexion peut venir de l’incapacité du proxy à joindre ton serveur d’origine. Les symptômes sont proches d’une erreur 520 Cloudflare ou d’une erreur 523 Origin Is Unreachable. Vérifie que l’IP d’origine renseignée dans Cloudflare est correcte et que le pare-feu du serveur autorise bien les IP de Cloudflare à se connecter.

Tableau récapitulatif

FAQ

Quand passer la main à un pro

Si tu as accès SSH et que tu es à l’aise avec un terminal, les étapes 3 à 5 se résolvent en 15-20 minutes. Mais dès que le diagnostic touche à la configuration réseau du serveur, aux règles de pare-feu système, ou à un proxy comme Cloudflare mal réglé entre le domaine et l’origine, une mauvaise manipulation peut couper l’accès encore plus durablement — y compris ton propre accès SSH.

Si le prestataire qui gérait ce serveur ne répond plus, ou si tu ne sais même plus quels accès existent, le guide prestataire web disparu : récupérer son site t’aide à reprendre la main proprement avant d’aller plus loin dans le diagnostic serveur.