DOC
Accueil/ Projets/ VPS Hostinger - Stack ENGWE/ 08 - Erreurs connues et solutions (retour d'expérience)

08 - Erreurs connues et solutions (retour d'expérience)

Ce document recense les erreurs réellement rencontrées lors d'une installation VPS Hostinger + Coolify (parcours A), avec leur cause exacte et le fix appliqué. Sert de référence rapide si les mêmes symptômes reviennent plus tard (après un redeploy, une mise à jour Coolify, un nouveau service). Les docs 01 et 06 intègrent déjà la plupart de ces fixes directement dans leurs étapes - ce document sert de table des matières + détail pour retrouver vite le bon paragraphe.

Phase 1 - Durcissement serveur

"REMOTE HOST IDENTIFICATION HAS CHANGED" en SSH

Symptôme : ssh root@IP refuse de se connecter avec un avertissement "POSSIBLE MAN-IN-THE-MIDDLE ATTACK".

Cause : le VPS a été réinstallé (reset depuis hPanel) → nouvelle empreinte de clé d'hôte SSH. Normal, pas une attaque, si tu viens toi-même de faire la réinstallation.

Fix :

ssh-keygen -R IP_DU_VPS
ssh root@IP_DU_VPS   # accepte la nouvelle empreinte (yes)

Pare-feu hPanel bloque un port pourtant ouvert dans UFW

Symptôme : sudo ufw status montre un port ALLOW, mais rien ne répond depuis l'extérieur (ex. Coolify injoignable sur IP:8000).

Cause : Hostinger propose un pare-feu cloud séparé d'UFW (hPanel → VPS → Firewall), appliqué devant le serveur. S'il est attaché avec des règles restrictives, un port peut être ouvert côté UFW et bloqué avant même d'arriver dessus.

Fix : voir 01-serveur-initial.md §1bis. Vérifier qu'aucun pare-feu hPanel n'est attaché, ou qu'il autorise les mêmes ports qu'UFW (22, 80, 443, temporairement 8000).

Phase 2 - Installation et onboarding Coolify

Coolify injoignable sur IP:8000

Checklist complète (pare-feu hPanel, install pas terminée, UFW, mauvaise URL, cache navigateur, VPN) : 06-coolify.md §Dépannage.

"You can't use this server until it is validated" / Validate Server échoue

Cause : le serveur "localhost" (celui où tourne Coolify) doit être connecté en root - Coolify gère /data/coolify en supposant un accès root complet. Sur un VPS durci à l'ancienne (root SSH totalement désactivé), la validation échoue toujours.

Fix : depuis la version à jour de scripts/01-bootstrap.sh, root reste joignable par clé uniquement (jamais par mot de passe) - voir 06-coolify.md §3bis. Si ton VPS a été bootstrappé avec une ancienne version du script, adapte /etc/ssh/sshd_config.d/99-hardening.conf (PermitRootLogin prohibit-password) et /root/.ssh/authorized_keys à la main.

Start Proxy : Permission denied sur /data/coolify/proxy/ ou sur

/var/www/html/storage/app/ssh/keys

Cause : mauvais UID propriétaire sur le dossier concerné. /data/coolify n'appartient pas à un seul et même utilisateur partout : le proxy/Traefik attend root, mais l'app Coolify elle-même tourne en interne avec l'UID 9999 (www-data) et a besoin que /data/coolify/ssh lui appartienne spécifiquement.

Fix : ne jamais faire un chown -R global sur tout /data/coolify. Identifier l'UID exact du conteneur concerné (docker exec <conteneur> id) et ne corriger que le dossier nommé dans l'erreur :

sudo chown -R 9999:9999 /data/coolify/ssh     # ex. pour l'app Coolify (www-data)
sudo chown -R root:root /data/coolify/proxy   # ex. pour le proxy

Détails : 06-coolify.md §3bis.

Start Proxy reste bloqué sur "Waiting for the process to start..."

Cause : l'action UI ne déclenche pas toujours réellement la commande Docker (bug d'affichage/état bloqué côté Coolify).

Fix : vérifier docker ps -a | grep -i proxy. S'il n'existe pas du tout, démarrer à la main :

cd /data/coolify/proxy
docker compose up -d

Puis rafraîchir la page Coolify.

Phase 3 - Déploiement des services (doc 06 §5)

n8n : There was an error initializing DB / getaddrinfo EAI_AGAIN <host>

Deux causes possibles, à vérifier dans l'ordre :

1. Mauvais nom d'hôte dans DB_POSTGRESDB_HOST (deviné plutôt que vérifié, ex. postgres générique). Vérifie le vrai nom du conteneur :

docker ps --format "{{.Names}}"

2. Bon nom d'hôte, mais toujours EAI_AGAIN → les deux conteneurs ne sont pas sur le même réseau Docker. C'est le cas le plus piégeux : une ressource "Service" du catalogue (n8n + son "Task Runners" est un bundle multi-conteneurs) obtient son propre réseau Docker isolé, différent du réseau coolify partagé où vivent les ressources "Database" standalone (PostgreSQL, MongoDB) - même si tout est dans le même projet/environnement Coolify. Être "dans le même projet" ne garantit pas un réseau commun dès qu'un des deux est un Service catalogue.

Vérifie avec :

docker inspect <conteneur_db> --format '{{json .NetworkSettings.Networks}}'
docker inspect <conteneur_n8n> --format '{{json .NetworkSettings.Networks}}'

Si les noms de réseaux affichés diffèrent, connecte manuellement les conteneurs du Service au réseau coolify (où vit la base) :

docker network connect coolify <conteneur_n8n>
docker network connect coolify <conteneur_task-runners>
docker restart <conteneur_n8n>

⚠️ Cette connexion manuelle peut sauter si Coolify recrée le conteneur lors d'un futur redeploy - si l'erreur revient après une mise à jour/redeploy, relance les mêmes commandes.

Nuance importante : ce n'est PAS systématique. Une ressource "Application" standalone déployée manuellement (ex. Mongo Express via Docker Image, voir plus bas) atterrit en général directement sur le réseau coolify sans manip supplémentaire. Le problème de réseau isolé concerne spécifiquement les "Service" du catalogue en bundle multi-conteneurs (n8n + Task Runners, etc.). Dans le doute : vérifie avec docker inspect (réflexe de fin de document) avant de supposer qu'il faut connecter les réseaux à la main - ça peut déjà marcher tout seul.

NocoDB : je ne vois pas les bases "n8n"/"nocodb" dans l'interface

Cause : ce n'est pas un bug. La base nocodb (celle du NC_DB) est le stockage interne de NocoDB (workspaces, users, config) - pas une "Base" à parcourir, comme /data/coolify pour Coolify. NocoDB n'importe jamais automatiquement les bases existantes du serveur Postgres.

Fix : dans le Workspace NocoDB, onglet "Bases" (pas "Settings") → Create New → connecter une base Postgres externe en donnant host/port/ user/password/nom de base. ⚠️ Évite de connecter/éditer la base interne d'une autre appli (ex. n8n) - risque de casser son fonctionnement ; NocoDB est plutôt fait pour tes propres données, dans une base dédiée créée exprès.

Mongo Express absent du catalogue de Services Coolify

Cause : pas présent dans le catalogue de cette version de Coolify (v4.1.2).

Fix : déployer en Application → Docker Image :

  • Image : mongo-express:1.0.2
  • Ports Exposes : mets 8081 (le port réel où écoute mongo-express) - Coolify préremplit souvent ce champ à 80 par défaut, ce qui provoque un 502 Bad Gateway si tu ne le corriges pas, même si le conteneur tourne bien et que le Domain contient déjà :8081.
  • Domain : https://mongo-it.engwe-france.fr:8081
  • Environment Variables :
    ME_CONFIG_MONGODB_URL=mongodb://<user>:<password>@<host_mongo>:27017/?directConnection=true
ME_CONFIG_BASICAUTH_USERNAME=<identifiant>
ME_CONFIG_BASICAUTH_PASSWORD=<mot_de_passe_fort>
    Les deux variables BASICAUTH protègent l'interface web elle-même - sans elles, n'importe qui avec le lien accède à la base sans rien demander.

Le sous-service "Task Runners" (ou tout worker interne d'un Service

catalogue) a un champ Domain public rempli

Cause : un worker interne (pas de serveur HTTP public à exposer) n'a pas besoin de domaine - souvent un champ dupliqué par erreur en configurant le Service parent.

Fix : vide le champ Domain de ce sous-composant, Save. Seul le composant qui sert vraiment du HTTP (ex. n8n lui-même) garde son Domain.

"Custom Docker Options" pré-rempli avec des options bizarres

(--cap-add SYS_ADMIN --device=/dev/fuse ...)

Cause : c'est du texte placeholder (exemple de syntaxe), pas une valeur réellement appliquée - Coolify l'affiche en grisé pour illustrer le format attendu. Si la ressource démarre "healthy" malgré ce texte visible, c'est confirmé : rien n'est réellement appliqué, ignore-le.

Réflexe général de diagnostic

Face à une ressource Coolify qui ne démarre pas ou ne se connecte pas à une autre :

  1. docker ps -a | grep <nom> - le conteneur existe-t-il, tourne-t-il ?
  2. docker logs <conteneur> --tail 50 - l'erreur exacte, jamais deviner.
  3. docker inspect <conteneur> --format '{{json .NetworkSettings.Networks}}'
    • sur quel(s) réseau(x) est-il, partage-t-il celui de l'autre conteneur ?
  4. docker exec <conteneur> id - quel UID tourne dedans, si un souci de permission sur un volume est suspecté.

Ces 4 commandes ont résolu 100 % des blocages rencontrés jusqu'ici - plus fiable que de deviner depuis l'UI seule.