Pourquoi je n’arrive pas à joindre mon port ?

Tu as configuré un site web, une appli, une base de données, et depuis ton ordinateur portable, impossible d’y accéder. Le navigateur reste bloqué. curl finit en timeout. Tu regardes le serveur et tout semble correct à l’intérieur — le processus tourne, les logs indiquent "listening on port 8080" — mais depuis l’extérieur, c’est comme si le serveur n’existait pas.

C’est l’un des blocages les plus fréquents. Et si c’est frustrant, c’est parce que trois problèmes complètement différents ont exactement la même apparence depuis l’extérieur. Tant que tu ne sais pas lequel te concerne, tu ne peux pas le corriger.

Cet article passe en revue les trois couches, dans l’ordre où il faut les vérifier, et montre comment Server Manager détecte et corrige chacune d’elles.

Les trois couches, dans l’ordre

Entre ton navigateur et le programme qui tourne sur ton serveur, il y a trois endroits où le trafic peut être bloqué. Depuis l’extérieur, les trois donnent le même résultat — "je n’arrive pas à y accéder". À l’intérieur, ce sont des problèmes très différents, avec des corrections très différentes.

Les trois couches :

1. Pare-feu du fournisseur cloud — il fonctionne en dehors de ton serveur, chez ton fournisseur (Hetzner, Oracle, AWS, etc.). Il jette les paquets avant même qu’ils n’atteignent le serveur.
2. Pare-feu du serveur — il fonctionne sur ton serveur. Il jette les paquets à leur arrivée, avant qu’un service puisse les voir.
3. Ton service — le programme lui-même (Caddy, ton appli, ta base de données). Soit il ne tourne pas, soit il n’écoute qu’en local.

Imagine un bâtiment avec trois postes de sécurité. Le paquet doit passer les trois pour arriver jusqu’à toi. Si n’importe lequel le bloque, tu n’es pas joignable — et depuis l’extérieur, tu ne peux pas savoir quel poste l’a arrêté.

Couche 3 — Ton service écoute-t-il vraiment ?

C’est la cause la plus simple et la plus fréquente. Avant de te préoccuper des pare-feu, vérifie qu’un programme écoute activement sur le port attendu sur le serveur.

Les deux façons classiques dont ça casse :

• Rien n’écoute. Le conteneur a planté. Le service systemd n’a pas démarré. L’appli s’est arrêtée au démarrage. Depuis l’extérieur, ça ressemble exactement à un blocage par pare-feu — le paquet arrive, mais personne n’est là pour répondre.
• Le service écoute seulement sur localhost. Celle-ci est sournoise. Beaucoup de programmes utilisent par défaut "loopback only" (127.0.0.1), ce qui veut dire que le programme tourne bien et accepte des connexions — mais uniquement depuis le serveur lui-même. Les connexions venant de l’extérieur ne peuvent pas l’atteindre, même si tous les pare-feu sont grands ouverts. Coupables fréquents : PostgreSQL par défaut, MySQL/MariaDB, Redis, notebooks Jupyter, serveurs de développement, tout ce qui dit "for security, we only bind to localhost by default."

Comment Server Manager t’aide :

• L’onglet Détails du serveur → Pare-feu peut répondre à "est-ce que le pare-feu de mon serveur le bloque ?", mais pour la couche 3, le chat est plus adapté — demande à Faro : "Est-ce que quelque chose écoute vraiment sur le port 8080 ?" et il lancera ss -tlnp puis te répondra.
• Si tu cliques sur Diagnostiquer l’inaccessibilité dans l’onglet Pare-feu, le diagnostic vérifie les trois couches — y compris celle-ci — et t’indique laquelle est en cause.

Couche 2 — Le pare-feu du serveur (sur le serveur)

La couche suivante à vérifier est le pare-feu qui tourne sur le serveur lui-même. Sur Ubuntu/Debian, c’est généralement ufw ; sur Fedora/Rocky, c’est firewalld ; derrière les deux, on retrouve les règles brutes iptables. Quelle que soit l’interface utilisée, le rôle est le même : jeter les paquets entrants qui ne sont pas explicitement autorisés.

Trois choses à savoir sur cette couche :

• La plupart des serveurs neufs sont en "autoriser par défaut" — tous les ports sont joignables à travers le pare-feu du serveur, soit parce que le pare-feu n’est pas installé, soit parce qu’il n’applique aucune règle. Server Manager l’indique clairement : l’onglet Pare-feu affiche une bannière jaune "Autoriser par défaut" dans ce cas.
• Un serveur "renforcé" est en "refuser par défaut" — le trafic entrant est bloqué par défaut ; seuls les ports explicitement autorisés passent. SSH (port 22) reste toujours ouvert, ainsi que les ports que tu as confirmés pendant la configuration.
• La plupart des hébergeurs n’activent pas de pare-feu serveur pour toi. Soit ton serveur est en autoriser par défaut (tous les ports sont ouverts à cette couche), soit tu en configures un toi-même.

Comment Server Manager t’aide :

• Détails du serveur → onglet Pare-feu te montre l’état actuel en un coup d’œil : backend (ufw / iptables / firewalld / none), actif ou en autoriser par défaut, et la liste des ports explicitement autorisés avec des libellés en langage clair.
• Ouvrir un port te permet d’autoriser un seul port à travers le pare-feu du serveur en un clic (le champ Port + le sélecteur de protocole en haut de l’onglet). Le chat te guide pour le faire de manière sûre et persistante.
• Renforcer le pare-feu de ce serveur fait passer un serveur en autoriser par défaut vers refuser par défaut, en toute sécurité. Une fenêtre liste chaque service qui écoute actuellement et te laisse choisir lesquels doivent rester publics. SSH est toujours conservé (la protection refuse de te bloquer dehors). Docker est détecté automatiquement et un mode compatible Docker est utilisé pour que les conteneurs continuent de fonctionner.
• Diagnostiquer l’inaccessibilité vérifie cette couche (et les autres) et indique laquelle bloque ton port.

Important : activer un pare-feu serveur avec Docker est délicat. Un simple ufw enable sur un hôte Docker peut casser le réseau des conteneurs — Docker gère ses propres règles de pare-feu via une chaîne séparée (DOCKER-USER), et ufw ne la connaît pas. Si tu laisses Server Manager gérer le renforcement, il détecte Docker et utilise automatiquement une méthode compatible Docker. Le faire à la main sans cette intégration est une façon courante de perdre la connectivité vers tes conteneurs.

Couche 1 — Le pare-feu du fournisseur cloud (hors du serveur)

C’est la couche la plus piégeuse. Ton hébergeur exécute un pare-feu devant ton serveur — les paquets sont filtrés avant même d’atteindre ta VM. Server Manager ne peut pas voir directement ce pare-feu, parce qu’il n’est pas sur ton serveur ; seule la console web de ton fournisseur peut le modifier.

Les noms et les comportements varient énormément :

Le point à bien retenir : le pare-feu du serveur et le pare-feu cloud sont deux pare-feu séparés. Les deux peuvent bloquer. Les deux peuvent laisser passer. Tu peux ouvrir un port côté serveur et rester bloqué côté cloud (très fréquent). Tu peux n’avoir aucun blocage côté serveur mais être bloqué côté cloud (fréquent aussi).

Comment Server Manager t’aide :

• Server Manager ne peut pas modifier directement les règles du pare-feu cloud (il lui faudrait des clés API pour chaque fournisseur), mais Faro connaît les étapes clic par clic pour tous les grands fournisseurs et te guide. Après avoir ouvert un port côté serveur, Faro te demande "tu veux que je te guide aussi pour l’ouvrir côté cloud ?" et te donne les instructions exactes pour la console web de ton fournisseur.
• Quand tu lances Diagnostiquer l’inaccessibilité dans l’onglet Pare-feu, le diagnostic identifie si le pare-feu cloud est le blocage et génère automatiquement le guide adapté au fournisseur.
• Quand tu utilises Renforcer le pare-feu de ce serveur, Faro te rappelle de resserrer aussi le pare-feu côté cloud pour qu’il corresponde (sinon tu as une configuration asymétrique — stricte sur le serveur, permissive dans le cloud).

Comment Server Manager vérifie les trois couches pour toi

Par le chat : ouvre Faro et dis "pourquoi je n’arrive pas à joindre le port 8080 ?" L’agent sonde les trois couches dans l’ordre — service à l’écoute, pare-feu du serveur, pare-feu cloud — et t’indique laquelle est en cause. Ensuite, il propose de la corriger.

Par l’interface : Détails du serveur → onglet Pare-feu → Diagnostiquer l’inaccessibilité. Saisis le port, clique sur le bouton. Même sonde en trois couches, même diagnostic, même proposition de correction.

Le résultat nomme toujours une couche précise comme cause, plus une seule correction proposée sous forme de question oui/non. Pas de longues checklists génériques sur plusieurs pages.

Scénarios courants

"J’ai déployé une base de données et je n’arrive pas à m’y connecter depuis mon ordinateur portable"

C’est presque sûrement la couche 3 — la base de données **écoute seulement sur 127.0.0.1**. PostgreSQL, MySQL, MariaDB et Redis utilisent tous localhost par défaut. Ils fonctionnent correctement, mais tu ne peux simplement pas les joindre depuis l’extérieur.

La bonne correction dépend de ce que tu veux faire :

• Pour "appli → base de données" sur le même serveur (le cas normal) — c’est exactement comme ça que ça doit être. Connecte ton appli à localhost:5432 (ou au port concerné) et c’est terminé. Aucun changement de pare-feu nécessaire. Dans Server Manager : rien à faire — Faro déploie les bases de données comme ça par défaut.
• Pour "mon ordinateur portable → base de données" en administration distante — ouvre un tunnel : ssh -L 5432:localhost:5432 user@server depuis ton ordinateur portable, puis connecte ton client DB à localhost:5432 en local. C’est plus sûr que d’exposer la base de données à internet. Dans Server Manager : demande à Faro la commande de tunnel exacte — il connaît l’utilisateur et l’hôte de ton serveur.
• Pour "je veux vraiment que cette base de données soit joignable publiquement" — change l’adresse d’écoute dans la configuration de la DB en 0.0.0.0, redémarre la DB, puis ouvre le port à la fois dans le pare-feu du serveur ET dans le pare-feu cloud. Assure-toi absolument d’avoir défini un mot de passe robuste avant ; exposer une DB sur l’internet public sans authentification solide est une façon courante de se faire compromettre. Dans Server Manager : demande à Faro de faire les trois étapes (changer l’adresse d’écoute de la DB, ouvrir le port du pare-feu serveur via l’onglet Pare-feu, te guider pour la règle du fournisseur cloud). Demande d’abord à Faro de générer un mot de passe robuste si tu n’en as pas encore défini.

"J’ai ouvert le port dans ufw et je n’arrive toujours pas à l’atteindre"

Couche 1 — le pare-feu du fournisseur cloud n’a pas été configuré. Côté serveur, ufw allow 8080/tcp ouvre la couche 2 ; le paquet doit encore passer la couche 1 avant d’atteindre ton serveur. Ouvre la règle correspondante dans la console de ton fournisseur cloud.

Dans Server Manager : demande à Faro de te guider pour créer la règle côté cloud chez ton fournisseur — il te donnera les étapes clic par clic pour Hetzner / AWS / Oracle / etc., sans que tu aies à chercher l’organisation du tableau de bord.

"Ça marchait hier, plus aujourd’hui"

Quelques causes fréquentes :

• Ton IP a changé — si ton pare-feu cloud est limité à "mon IP uniquement" et que ta connexion internet domestique a reçu une nouvelle IP pendant la nuit (très courant chez la plupart des FAI grand public), la nouvelle IP est maintenant bloquée. Élargis temporairement à 0.0.0.0/0, connecte-toi, puis resserre à nouveau.
• Le service a planté — un problème de couche 3 déguisé. Vérifie systemctl status <service> ou docker ps.
• Le serveur a été renforcé récemment — si quelqu’un a activé le pare-feu du serveur sans inclure le port qui t’intéresse, ce port est maintenant bloqué à la couche 2. Ouvre l’onglet Pare-feu pour voir les règles actuelles.

Dans Server Manager : saisis le port concerné dans l’onglet Pare-feu et clique sur Diagnostiquer l’inaccessibilité — Faro sonde les trois couches et te dit laquelle a régressé. C’est plus rapide que de deviner.

"Je peux faire un curl depuis le serveur, mais pas depuis l’extérieur"

C’est la ligne de séparation du diagnostic : cela te dit que le service va bien et que la couche 3 n’est pas le problème. Il reste soit la couche 2 (pare-feu du serveur), soit la couche 1 (pare-feu cloud). Utilise Diagnostiquer l’inaccessibilité pour préciser.

Dans Server Manager : le bouton Diagnostiquer l’inaccessibilité de l’onglet Pare-feu est l’outil prévu exactement pour ce cas — il saute la couche 3 (puisque tu as déjà prouvé qu’elle fonctionne) et te dit laquelle des deux couches de pare-feu jette le paquet.

Questions fréquentes

Ai-je besoin d’un pare-feu serveur si mon fournisseur cloud en a déjà un ?

Oui et non, selon ton modèle de menace. Un pare-feu cloud couvre le cas le plus courant. Un pare-feu serveur est utile quand :

• Tu utilises Docker — dans certaines configurations, les conteneurs peuvent ouvrir leurs propres accès qui contournent le pare-feu cloud. Un pare-feu serveur rattrape les sorties des conteneurs.
• Tu oublies de supprimer des règles temporaires du pare-feu cloud — le pare-feu serveur sert de filet de sécurité.
• Tu veux filtrer le trafic sortant — les pare-feu cloud se concentrent généralement sur l’entrant ; les pare-feu serveur peuvent faire les deux.

Si aucun de ces cas ne s’applique, un seul pare-feu cloud bien configuré suffit pour la plupart des installations.

Server Manager fonctionne-t-il sans pare-feu serveur ?

Oui. Server Manager n’a besoin d’aucune configuration de pare-feu pour fonctionner. L’onglet Pare-feu sert à ta sécurité, pas à la connexion à Server Manager lui-même (Server Manager a seulement besoin de SSH, port 22).

Pourquoi l’onglet Pare-feu m’indique-t-il "Autoriser par défaut" alors que je n’ai jamais rien configuré ?

Parce que c’est l’état réel. La plupart des serveurs neufs n’ont pas de pare-feu serveur configuré — tous les ports sont joignables à cette couche. Le fait qu’un paquet atteigne réellement ton service dépend de la couche 1 (pare-feu cloud) et de la couche 3 (le service écoute-t-il ?). La bannière jaune t’avertit que tu pourrais vouloir le renforcer.

Est-ce que je devrais parfois fermer "Ouvrir le port 22 / SSH" ?

Non. Server Manager communique avec ton serveur uniquement via SSH. Fermer le port 22 déconnecte Server Manager et t’obligerait à passer par la console du fournisseur pour récupérer l’accès (voir Récupérer l’accès quand SSH ne fonctionne plus). C’est pour cette raison que l’onglet Pare-feu ne propose pas de bouton Fermer sur la ligne SSH, et que la fenêtre de renforcement verrouille la ligne SSH sur "toujours garder ouvert".

Ce qui n’est PAS couvert ici

• Problèmes de trafic sortant (ton serveur ne peut pas accéder à internet) — c’est une autre configuration : généralement NAT, DNS ou réseau sortant du fournisseur. Demande à Faro de diagnostiquer.
• Erreurs HTTPS / TLS — dans ce cas, l’accès réseau fonctionne, mais la négociation de chiffrement échoue. C’est un autre sujet ; consulte la section domaines, HTTPS et e-mail.
• Problèmes DNS ("mon domaine ne pointe pas vers le serveur") — couverts dans Faire pointer un domaine ici. Le paquet n’en est même pas encore à la question des pare-feu — il ne sait pas où se trouve le serveur.
• Configuration spécifique d’une appli (quelle variable d’environnement définir pour que ton appli écoute sur 0.0.0.0 au lieu de 127.0.0.1) — cela varie selon l’appli. Demande à Faro : il connaît les cas courants.