Localhost n’autorise pas la connexion : comment corriger

« Localhost n’autorise pas la connexion » (ERR_CONNECTION_REFUSED) signifie presque toujours que rien n’écoute là où le navigateur se connecte. Causes habituelles : le serveur local n’est pas lancé, il est sur un autre port, il écoute en IPv6 (::1) alors que vous atteignez l’IPv4 (127.0.0.1) ou l’inverse, l’entrée hosts de localhost manque, ou un pare-feu bloque le port. Suivez la checklist ci-dessous dans l’ordre et vous trouverez vite.

Corriger « localhost n’autorise pas la connexion » — checklist

1. Vérifiez que le serveur tourne vraiment. Cherchez une ligne « listening on port… » dans son terminal. Pas de serveur = refus garanti. Relancez-le. 2. Vérifiez le port. Le port de l’URL doit correspondre au serveur (localhost:3000, pas :8080). Un mauvais port est la cause la plus fréquente. 3. Essayez 127.0.0.1 directement. Si http://127.0.0.1:PORT fonctionne mais pas localhost, c’est un décalage IPv6/IPv4 — voir plus bas. À lire : 127.0.0.1 vs localhost. 4. Restaurez l’entrée hosts. Assurez-vous que 127.0.0.1 localhost et ::1 localhost existent ; une ligne supprimée casse toute la résolution. 5. Autorisez le port dans le pare-feu / antivirus. Les outils de sécurité bloquent parfois les ports locaux. 6. Videz le cache DNS du navigateur et rechargez dans un nouvel onglet — chrome://net-internals/#dns.

Cette erreur partage ses causes avec « Ce site est inaccessible » sur localhost — même checklist, formulation différente affichée par le navigateur.

Identifier ce qui écoute

Avant d’accuser le navigateur, vérifiez le port en ligne de commande :

# macOS / Linux
lsof -i :3000
# Windows (Invite de commandes)
netstat -ano | findstr :3000

• Rien ne s’affiche → le serveur n’écoute pas sur ce port. Corrigez l’appli, pas le navigateur.
• Un PID différent → un autre processus a pris le port ; arrêtez-le ou changez de port.

Le piège IPv6 vs IPv4 (127.0.0.1 marche, pas localhost)

Les systèmes modernes résolvent localhost d’abord en IPv6 ::1. Si votre serveur de dev n’écoute qu’en IPv4 127.0.0.1, la connexion IPv6 est refusée et le navigateur affiche « localhost n’autorise pas la connexion » — alors que http://127.0.0.1:PORT fonctionne.

Deux solutions :

• Liez le serveur à toutes les interfaces : 0.0.0.0 (IPv4) ou :: (double pile). Voir 0.0.0.0 vs 127.0.0.1.
• Ou utilisez simplement http://127.0.0.1:PORT dans le navigateur.

Quand le fichier hosts est en cause

Une ligne localhost supprimée ou commentée casse la résolution sur tout le système. Restaurez les deux entrées :

127.0.0.1 localhost
::1 localhost

Sur Mac, voir localhost ne fonctionne pas sur Mac. Pour éditer le fichier sans risque, voir comment modifier le fichier hosts.

Solutions par environnement

Chrome (et autres navigateurs)

Le texte de l’erreur vient du navigateur, mais la cause est le serveur/port/DNS — pas Chrome. Videz tout de même le cache hôte de Chrome (chrome://net-internals/#dns) et testez en navigation privée pour écarter une extension ou un cache périmé.

Windows 10 / 11

• Lancez le serveur de dev dans un terminal élevé s’il a besoin d’un port privilégié (< 1024).
• Vérifiez que le pare-feu Windows Defender ne bloque pas le port.
• Confirmez qu’aucun proxy n’est défini : Paramètres → Réseau et Internet → Proxy.

XAMPP / MAMP / WAMP

• Démarrez Apache (et MySQL) dans le panneau de contrôle — un service arrêté refuse toute connexion.
• Le port 80/443 est souvent pris par Skype, IIS ou un VPN. Changez le port d’Apache (ex. 8080) ou arrêtez l’appli en conflit.

VS Code / Node / serveurs Vite

• Lisez l’URL réellement affichée par le serveur — les frameworks choisissent un port libre (3000, 5173, 8000…) qui peut différer de ce que vous tapez.
• Sous WSL2 ou dans un conteneur, le port doit être redirigé vers l’hôte.

Docker

• Le port du conteneur doit être publié vers l’hôte : -p 3000:3000. Sans cela, localhost:3000 sur l’hôte est refusé.

Vérifier la correction

curl -I http://127.0.0.1:3000
curl -I http://localhost:3000

Si l’IP fonctionne mais pas le nom, revenez aux étapes IPv6/hosts. Si les deux échouent, le serveur n’écoute pas — corrigez d’abord le processus.

Éviter les pannes futures

Les modifications accidentelles de la ligne localhost sont une cause fréquente et difficile à repérer. Un gestionnaire de hosts comme Locahl garde les entrées localhost essentielles intactes, permet de basculer les domaines personnalisés sans risque, et vide le DNS automatiquement — pour que localhost réponde toujours.

_Dernier test : juin 2026 sur Windows 11, macOS 26 et Ubuntu 24.04._

Sources et ressources externes

• localhost et l’adresse de bouclage (Wikipédia)
• Le fichier hosts expliqué (Wikipédia)
• Comment fonctionne le DNS (Cloudflare Learning)