ERR_CONNECTION_REFUSED

Ce que signifie cette erreur et comment la reconnaître

• Chrome, Edge ou un autre navigateur basé sur Chromium affiche « Impossible d’accéder à ce site — ERR_CONNECTION_REFUSED ».
• L’erreur apparaît rapidement plutôt qu’après une longue attente. Un délai prolongé correspond davantage à un timeout tel que ERR_CONNECTION_TIMED_OUT.
• Un site qui fonctionnait auparavant cesse de répondre après un redémarrage du serveur, un déploiement, une modification DNS, une mise à jour de configuration ou un changement du pare-feu.
• SSH ou un autre port applicatif sur la même machine peut rester accessible tandis que le port web refuse les connexions.
• Les requêtes effectuées sur le serveur peuvent réussir alors que celles provenant de l’extérieur échouent lorsque le service écoute uniquement sur localhost ou qu’un pare-feu externe bloque le port.

Causes principales, classées par probabilité

1. Le serveur web ou le processus applicatif est arrêté — Nginx, Apache ou le serveur d’application peut avoir subi un crash, avoir été arrêté ou avoir échoué lors de son démarrage.
2. Aucun processus n’écoute sur le port demandé — le service utilise peut-être un autre port, tandis que la requête est envoyée vers le port 80 ou 443.
3. Le service est lié à la mauvaise interface — un processus en écoute sur 127.0.0.1 accepte les requêtes locales, mais pas les connexions externes directes.
4. Un pare-feu hôte ou cloud rejette le trafic — le pare-feu du système d’exploitation, un security group, une network ACL ou le pare-feu du fournisseur a peut-être été modifié.
5. Le DNS pointe vers la mauvaise destination — le domaine peut résoudre vers un ancien serveur, un serveur reconstruit ou un serveur qui n’est pas configuré. Un enregistrement AAAA peut également diriger certains visiteurs vers une adresse IPv6 sans processus web fonctionnel en écoute.

Comment corriger le problème

1. Confirmer l’adresse de destination

Vérifiez les enregistrements A et AAAA du domaine et comparez les adresses résolues avec le serveur qui doit recevoir la requête. Si le domaine pointe vers un ancien serveur, un serveur décommissionné ou un serveur récemment reconstruit, corrigez le DNS avant de modifier la configuration du service web. Si des enregistrements IPv4 et IPv6 existent, vérifiez que le service et le pare-feu prennent en charge les deux chemins.

2. Vérifier que le service fonctionne

À l’aide d’une méthode d’administration autorisée telle que SSH, vérifiez le service concerné. Par exemple, examinez Nginx avec systemctl status nginx ; utilisez le nom de service équivalent pour Apache ou le serveur d’application.

Si le service est arrêté ou en échec, examinez son état et ses journaux avant de le démarrer. Une erreur de configuration introduite par une modification récente est une cause fréquente d’échec au démarrage. Validez la configuration avec nginx -t pour Nginx ou apachectl configtest pour Apache. Ce n’est qu’une fois le test réussi, et si vous êtes autorisé à modifier le service, que vous devez le redémarrer ou le recharger. Un redémarrage peut interrompre les requêtes actives et peut ne pas être approprié pendant un pic de production.

3. Vérifier le port et l’interface en écoute

Sur le serveur, examinez les processus en écoute avec ss -tlnp ou l’équivalent de la plateforme. Confirmez que le processus attendu écoute sur le port demandé, généralement :80 ou :443.

Vérifiez l’adresse de liaison ainsi que le port :

• 0.0.0.0:80 ou 0.0.0.0:443 écoute généralement sur les interfaces IPv4 disponibles.
• Une adresse spécifique du serveur indique que le service est lié à cette interface.
• 127.0.0.1:80 ou 127.0.0.1:443 accepte uniquement les requêtes locales.

Si l’application est volontairement privée sur localhost, confirmez que le reverse proxy exposé publiquement fonctionne et lui transmet les requêtes. Sinon, modifiez la configuration du service afin qu’il écoute sur l’interface prévue, dans le cadre d’une opération de maintenance ou d’un déploiement approuvé.

4. Vérifier les règles des pare-feu hôte et cloud

Examinez le pare-feu du serveur avec ufw status, iptables -L ou la commande équivalente du système d’exploitation. Inspectez ensuite le security group cloud, la network ACL ou le pare-feu du fournisseur associé au serveur attendu.

Confirmez que le trafic entrant est autorisé sur le port requis depuis les sources appropriées. Un site web public peut nécessiter un accès depuis Internet, tandis qu’un service interne doit utiliser une plage approuvée plus restrictive. Vérifiez séparément les règles IPv4 et IPv6 lorsque les deux types d’enregistrements sont publiés. N’élargissez pas l’accès au-delà du nécessaire et ne modifiez les règles du pare-feu qu’avec une autorisation appropriée.

5. Effectuer des tests locaux et externes

Depuis le serveur, testez séparément le processus local en écoute et le nom d’hôte configuré. Un succès local confirme uniquement qu’un élément répond sur la machine ; il ne prouve pas que les clients externes peuvent atteindre le port.

Après avoir corrigé le DNS, le service, la liaison ou le pare-feu, exécutez une requête curl -v détaillée vers le nom d’hôte concerné depuis un autre réseau ou une machine externe. Confirmez que la requête atteint l’adresse et le port attendus et que le refus a disparu.

6. Comparer les modifications récentes

Si l’échec a commencé après un déploiement, un redémarrage, une reconstruction du serveur, une mise à jour DNS ou une modification du pare-feu, comparez la configuration actuelle avec la dernière version connue comme fonctionnelle. Recherchez notamment un port modifié, un échec au démarrage du service, une liaison limitée à localhost, une règle associée au mauvais serveur ou une configuration IPv6 incomplète.

Prévention et vérification du correctif

• Utilisez un gestionnaire de services ou un superviseur de processus afin que le service web puisse récupérer après une défaillance inattendue.
• Faites de la validation de configuration, comme nginx -t ou apachectl configtest, une étape obligatoire du déploiement avant tout rechargement ou redémarrage.
• Documentez les ports, adresses de liaison, règles de pare-feu, security groups et enregistrements DNS prévus comme référence connue pour fonctionner.
• Surveillez le service depuis l’extérieur du serveur au lieu de vous fier uniquement aux contrôles d’état locaux.
• Vérifiez les processus en écoute et les règles de pare-feu IPv4 et IPv6 chaque fois qu’un domaine possède des enregistrements A et AAAA.
• Consignez les modifications de l’infrastructure afin de pouvoir corréler un nouveau refus avec un déploiement, une reconstruction, une mise à jour DNS ou une modification du pare-feu.

Questions fréquentes