ERR_CONNECTION_REFUSED sur localhost (XAMPP, Laragon, MAMP)

Ce que signifie cette erreur et comment la reconnaître

• Le navigateur affiche immédiatement ERR_CONNECTION_REFUSED pour localhost ou un nom d’hôte local.
• XAMPP, Laragon ou MAMP indique qu’Apache ou Nginx est arrêté, en échec ou ne fonctionne plus.
• Le serveur démarre puis s’arrête, parfois avec un message concernant un port, un fichier de configuration ou une erreur de syntaxe.
• Le problème apparaît après un redémarrage, une modification du système d’exploitation, l’installation d’un serveur local ou une modification de configuration.
• Les fichiers du projet sont présents sur l’ordinateur, mais le navigateur ne peut pas se connecter au serveur local.
• Un serveur configuré sur un port personnalisé peut fonctionner avec une adresse et échouer avec localhost seul, car le navigateur utilise le port HTTP par défaut.

Causes principales, classées par probabilité

1. Apache ou Nginx n’est pas démarré — Le service local n’a peut-être pas été lancé ou a échoué pendant son démarrage.
2. Un autre processus utilise le port configuré — IIS, une autre installation de XAMPP/Laragon/MAMP, Apache ou Nginx installé séparément, un logiciel de virtualisation ou une autre application écoute peut-être déjà sur le port 80 ou 443.
3. La configuration du serveur est invalide — Une erreur de syntaxe dans httpd.conf, un fichier de configuration Nginx, un fichier de virtual host ou un autre fichier serveur récemment modifié peut provoquer l’arrêt immédiat du service.
4. Le navigateur utilise le mauvais port — Une stack configurée sur le port 8080 ou un autre port personnalisé ne répondra normalement pas à localhost seul sur le port HTTP par défaut.
5. Le pare-feu ou l’antivirus interfère — Une modification récente du logiciel de sécurité peut bloquer le serveur local ou sa liaison réseau, même si cette cause est moins fréquente qu’un service arrêté ou qu’un conflit de ports.

Comment corriger le problème

1. Vérifier le serveur local et l’adresse

Ouvrez le XAMPP Control Panel, l’application Laragon ou MAMP et vérifiez qu’Apache ou Nginx est indiqué comme Running. S’il est arrêté, sélectionnez Start et notez le message exact en cas d’échec du démarrage.

Vérifiez quel port HTTP ou HTTPS la stack est configurée pour utiliser. Si elle utilise un port personnalisé, testez l’adresse correspondante — par exemple localhost:8080 — plutôt que de supposer que localhost seul est correct.

2. Identifier un conflit de ports

Si le message de démarrage indique qu’un port est déjà utilisé, vérifiez le port concerné. Sous Windows, ouvrez l’invite de commandes avec les droits d’administrateur si l’environnement l’exige, puis exécutez ces commandes en lecture seule :

netstat -ano | findstr :80
netstat -ano | findstr :443

Utilisez l’identifiant du processus indiqué pour identifier son propriétaire dans le Gestionnaire des tâches. Ne terminez pas un processus que vous ne connaissez pas. Si IIS utilise le port et que vous êtes autorisé à modifier la machine, désactivez ou arrêtez le service IIS concerné uniquement lorsqu’IIS n’est pas nécessaire. Sinon, configurez la stack locale pour utiliser un port disponible et utilisez ce port dans le navigateur.

Les commandes ci-dessus sont spécifiques à Windows. Sur un autre système d’exploitation, utilisez les outils réseau ou de gestion des processus intégrés, ou les informations de port fournies par le panneau de contrôle de la stack.

3. Consulter le journal d’erreurs du serveur

Si aucun processus évident n’utilise le port configuré, ouvrez le journal d’erreurs Apache ou Nginx depuis la stack locale ou son répertoire de journaux configuré. Recherchez la première erreur précise, notamment un chemin de fichier, une directive de configuration et un numéro de ligne.

Si l’échec a commencé après une modification de configuration, corrigez ou annulez cette modification. Vérifiez httpd.conf, les fichiers de configuration Nginx, les définitions de virtual hosts et tous les fichiers inclus. Modifiez un seul fichier à la fois afin de pouvoir identifier la cause.

4. Vérifier la présence de serveurs locaux en double

Recherchez une deuxième installation de XAMPP, Laragon, MAMP, WAMP, Apache ou Nginx autonome. Deux services ne peuvent normalement pas écouter sur la même adresse et le même port. Arrêtez un service inutilisé uniquement si vous savez que cette action est sûre et que vous y êtes autorisé, ou attribuez des ports distincts aux stacks que vous devez conserver.

5. Examiner les modifications des logiciels de sécurité

Si la configuration du serveur est valide et qu’aucun processus concurrent n’utilise le port, examinez les modifications récentes du pare-feu ou de l’antivirus. Utilisez les réglages habituels du produit de sécurité et créez une exception uniquement lorsque vous comprenez les accès qu’elle autorise. Évitez de désactiver largement la protection comme première étape de dépannage.

6. Vérifier la réparation

Attendez qu’Apache ou Nginx reste à l’état Running, puis ouvrez à nouveau l’adresse localhost configurée. Une page serveur par défaut ou le projet devrait se charger à la place de ERR_CONNECTION_REFUSED.

Si la page par défaut se charge, mais pas le projet, le problème de connexion est résolu. Poursuivez avec le dépannage de la racine documentaire, du routage, du virtual host ou de l’application plutôt que de modifier à nouveau les paramètres de port.

Prévention et vérification du correctif

• Notez les ports HTTP et HTTPS utilisés par chaque stack locale, en particulier lorsque plusieurs stacks sont installées.
• Évitez d’exécuter plusieurs serveurs locaux sur la même adresse et le même port ; attribuez des ports distincts lorsque les deux sont nécessaires.
• Conservez une note des modifications apportées aux fichiers de configuration Apache, Nginx et des virtual hosts.
• Après avoir modifié la configuration du serveur, démarrez le service et consultez son journal d’erreurs avant de supposer que le code du projet est défectueux.
• Utilisez le panneau de contrôle de la stack pour vérifier que le service reste actif, et pas seulement qu’il démarre une fois.
• Avant d’arrêter un processus ou un service, vérifiez qu’il n’est pas requis par IIS, un autre outil de développement ou une application sans rapport.

Questions fréquentes