Aller au contenu principal

Dépannage de l’auto-hébergement

Commencez par les journaux : docker compose logs --tail=200 app. Augmentez le niveau de détail avec LOG_LEVEL=debug (et remettez-le ensuite).

L’application ne démarre pas​

  • Le journal mentionne une variable d’environnement : une variable obligatoire manque ou est trop courte : APP_URL (une URL complète), DATABASE_URL, AUTH_SECRET (16 caractères ou plus), APP_ENCRYPTION_KEY (32 caractères ou plus). Voir Configuration.
  • Base de données injoignable : vérifiez docker compose ps (le service db doit être healthy) et que POSTGRES_PASSWORD n’a pas changé depuis la création de la base (le mot de passe n’est défini qu’au premier démarrage sur un volume vide).
  • Une migration échoue : ne modifiez pas la base de données à la main. Restaurez la sauvegarde d’avant la mise à niveau, puis signalez l’erreur avec les lignes du journal.

Vérifiez la disponibilité avec curl -fsS http://127.0.0.1:3000/api/ready.

Problèmes de connexion​

  • Redirection vers la mauvaise adresse, ou cookies non conservés : APP_URL doit être exactement l’adresse HTTPS publique, et le proxy doit transmettre X-Forwarded-Proto (Reverse proxy et TLS).
  • « Trop de tentatives » pour tout le monde : toutes les requêtes semblent venir d’une seule adresse. Corrigez la gestion de X-Forwarded-For par le proxy et TRUST_PROXY_HOPS (Adresses IP des clients).
  • L’authentification unique échoue après la page du fournisseur : l’URI de redirection enregistrée auprès du fournisseur doit correspondre exactement à celle affichée dans Admin → Authentification ; utilisez Tester la connexion pour vérifier l’émetteur.
  • Les clés d’accès ne fonctionnent plus : le domaine de APP_URL a changé. Chacun doit ajouter à nouveau ses clés d’accès.
  • Accès perdu à tous les comptes admin : créez ou promouvez un Propriétaire en ligne de commande (Installation).

Les e-mails n’arrivent pas​

  • MAIL_DRIVER doit valoir smtp ; avec log, les messages apparaissent seulement dans le journal de l’application.
  • Cherchez les erreurs d’envoi dans le journal (échec d’authentification, connexion refusée, erreurs TLS). Le port 465 nécessite SMTP_SECURE=true ; le port 587 nécessite false.
  • E-mails reçus mais classés en spam : configurez SPF, DKIM et DMARC pour le domaine expéditeur (E-mail).
  • Nouveaux comptes bloqués sur Consultez vos e-mails : ils ont besoin de l’e-mail de confirmation. Réparez l’envoi, ou désactivez Exiger la confirmation de l’e-mail dans Admin → Authentification (Confirmation de l’e-mail).

Les envois de fichiers échouent​

  • Échec immédiat pour les fichiers plus gros : la limite de corps du proxy est inférieure à la taille des blocs (1 Mo par défaut pour nginx). Voir Reverse proxy et TLS.
  • « Ce fichier dépasse la limite de … » : augmentez la taille maximale de fichier dans Admin → Général → Envoi de fichiers. Un admin de l’espace peut définir une limite plus basse pour son espace.
  • S3 : les envois fonctionnent, pas les téléchargements : les navigateurs doivent pouvoir joindre l’adresse du bucket ; définissez S3_PUBLIC_ENDPOINT (Stockage).
  • S3 : taille des blocs refusée : S3 exige des blocs d’au moins 5 Mo.

Les webhooks ne sont pas livrés​

  • L’instance ou l’espace de travail a désactivé les webhooks (Admin → Général → API, ou les paramètres de l’espace).
  • La cible se trouve sur un réseau privé : ce n’est autorisé qu’avec Autoriser les webhooks vers des adresses réseau privées.
  • Un webhook qui a échoué 20 fois de suite se désactive tout seul ; réactivez-le après avoir corrigé le destinataire. Voir Webhooks.

Toujours bloqué ?​

Rassemblez la version (SOL2FLOW_VERSION), les lignes de journal pertinentes (retirez les secrets et les données personnelles) et les étapes pour reproduire le problème, puis contactez votre canal de support sol2flow.