CyberSDF

Reprenez la main sur votre numérique

Rédigé par Rédaction CyberSDF / / mis à jour

Connection refused : les six causes sous Linux

Connection refused signifie que le noyau a refusé la connexion TCP avant qu’un service ne la lise. Le client tente de se connecter à une adresse IP et un port ; le serveur répond 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 se vérifient dans l’ordre, en commençant par la plus simple.

Sommaire
  1. Cause 1 : le service n’est pas démarré
  2. Cause 2 : le service écoute sur un autre port
  3. Cause 3 : le service n’écoute 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 démarré

La première cause à vérifier est aussi la plus simple : le service n’écoute pas. Vérifiez son état 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 démarré ou il a été arrêté. La commande ss -tlnp montre les ports en écoute : si le port 80 n’apparaît pas, nginx n’écoute pas. Le journal indique la cause de l’arrêt (erreur de configuration, port déjà utilisé, dépendance manquante). Pour comprendre le cycle de vie d’un service, consultez services et journaux systemd.

Cause 2 : le service écoute sur un autre port

Un service peut être actif mais écouter sur un port différent de celui attendu. Par défaut, nginx écoute sur le port 80, mais un fichier de configuration peut le déplacer vers 8080 ou 8443. La commande ss -tlnp affiche le port réel ; comparez-le au port que le client tente d’atteindre. Si le port correspond, passez à la cause suivante.

Cause 3 : le service n’écoute que sur localhost

Certains services n’écoutent que sur 127.0.0.1 (localhost) par défaut. 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 refusée parce que le service n’accepte que les connexions locales. La correction dépend 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 réseau peut bloquer le paquet SYN avant qu’il n’atteigne le service. Deux vérifications :

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

Si ufw est actif et qu’aucune règle n’autorise le port, la connexion est refusée. Ajoutez une règle avec sudo ufw allow 80/tcp ou sudo ufw allow 443/tcp. Pour Docker, le filtrage est différent : Docker écrit ses règles dans la chaîne DOCKER-USER d’iptables, avant les chaînes qu’ufw contrôle. La page ufw et Docker explique cette incompatibilité et la résolution en cinq étapes.

Cause 5 : l’adresse de liaison est incorrecte

Un service configuré pour écouter sur 192.168.1.100 refuse les connexions vers 192.168.1.101. Vérifiez l’adresse de liaison avec ss -tlnp et comparez-la à l’adresse que le client utilise. Si le service écoute sur 0.0.0.0, il accepte les connexions sur toutes les interfaces. Si le service écoute sur une adresse spécifique, seule cette adresse est joignable.

Cause 6 : le nombre maximum de connexions est atteint

Certains services limitent le nombre de connexions simultanées. Quand la limite est atteinte, les nouvelles connexions sont refusées. Vérifiez 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 où la limite vient du système, pas du service.

Diagnostic rapide en trois commandes

Résumé 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 ?

Si les trois sont normales, le problème est réseau (route, DNS, pare-feu distant) ou logiciel (le service accepte la connexion mais la ferme immédiatement). La page diagnostiquer une connexion détaille les étapes réseau.

Repères pour aller plus loin