CyberSDF

Reprenez la main sur votre numérique

Rédigé par Rédaction CyberSDF /

Connection refused : les six causes sous Linux

Connection refused signifie que le noyau a refuse la connexion TCP avant qu’un service ne la lise. Le client tente de se connecter a une adresse IP et un port ; le serveur repond par un RST (reset) ou le pare-feu rejette le paquet SYN. L’erreur ne dit pas pourquoi le service refuse : elle dit que la connexion n’a pas abouti. Les six causes les plus courantes se verifient dans l’ordre, en commencant par la plus simple.

Sommaire
  1. Cause 1 : le service n’est pas demarre
  2. Cause 2 : le service ecoute sur un autre port
  3. Cause 3 : le service n’ecoute que sur localhost
  4. Cause 4 : un pare-feu rejette la connexion
  5. Cause 5 : l’adresse de liaison est incorrecte
  6. Cause 6 : le nombre maximum de connexions est atteint
  7. Diagnostic rapide en trois commandes
  8. Repères pour aller plus loin

Cause 1 : le service n’est pas demarre

La cause la plus frequencee est aussi la plus simple : le service n’ecoute pas. Verifiez son etat avant de chercher plus loin :

systemctl status nginx
ss -tlnp | grep :80
journalctl -u nginx --since "5 min ago"

Si systemctl status affiche inactive (dead), le service n’a jamais demarre ou il a ete arrete. La commande ss -tlnp montre les ports en ecoute : si le port 80 n’apparait pas, nginx n’ecoute pas. Le journal indique la cause de l’arret (erreur de configuration, port deja utilise, dependance manquante). Pour comprendre le cycle de vie d’un service, consultez services et journaux systemd.

Cause 2 : le service ecoute sur un autre port

Un service peut etre actif mais ecouter sur un port different de celui attendu. Par defaut, nginx ecoute sur le port 80, mais un fichier de configuration peut le deplacer vers 8080 ou 8443. La commande ss -tlnp affiche le port reel ; comparez-le au port que le client tente d’atteindre. Si le port correspond, passez a la cause suivante.

Cause 3 : le service n’ecoute que sur localhost

Certains services n’ecoutent que sur 127.0.0.1 (localhost) par defaut. La ligne ss -tlnp affiche 127.0.0.1:8080 au lieu de 0.0.0.0:8080. Depuis une autre machine, la connexion est refusee parce que le service n’accepte que les connexions locales. La correction depend du service : dans nginx, c’est la directive listen ; dans PostgreSQL, c’est listen_addresses dans postgresql.conf.

Cause 4 : un pare-feu rejette la connexion

Le pare-feu local (ufw, firewalld, iptables) ou le pare-feu reseau peut bloquer le paquet SYN avant qu’il n’atteigne le service. Deux verifications :

sudo ufw status
sudo iptables -L INPUT -n | head -20

Si ufw est actif et qu’aucune regle n’autorise le port, la connexion est refusee. Ajoutez une regle avec sudo ufw allow 80/tcp ou sudo ufw allow 443/tcp. Pour Docker, le filtrage est different : Docker ecrit ses regles dans la chaine DOCKER-USER d’iptables, avant les chaines qu’ufw controle. La page ufw et Docker explique cette incompatibilite et la resolution en cinq etapes.

Cause 5 : l’adresse de liaison est incorrecte

Un service configure pour ecouter sur 192.168.1.100 refuse les connexions vers 192.168.1.101. Verifiez l’adresse de liaison avec ss -tlnp et comparez-la a l’adresse que le client utilise. Si le service ecoute sur 0.0.0.0, il accepte les connexions sur toutes les interfaces. Si le service ecoute sur une adresse specifique, seule cette adresse est joignable.

Cause 6 : le nombre maximum de connexions est atteint

Certains services limitent le nombre de connexions simultanees. Quand la limite est atteinte, les nouvelles connexions sont refusees. Verifiez la file d’attente avec :

ss -s
netstat -an | grep :80 | wc -l

Si le compteur est proche de la limite, augmentez-la dans la configuration du service. Pour nginx, c’est worker_connections ; pour Apache, c’est MaxClients. La page sur too many open files traite le cas ou la limite vient du systeme, pas du service.

Diagnostic rapide en trois commandes

Resume en trois commandes :

systemctl status {service}          # le service tourne ?
ss -tlnp | grep {port}              # il ecoute sur le bon port ?
sudo iptables -L INPUT -n | head   # le pare-feu bloque ?

Ces trois verifications couvrent 90 % des cas. Si les trois sont normales, le probleme est reseau (route, DNS, pare-feu distant) ou logiciel (le service accepte la connexion mais la ferme immediatement). La page diagnostiquer une connexion detaille les etapes reseau.

Repères pour aller plus loin