Décrivez le problème/l’erreur/la question
Bonjour.
J’ai une instance N8N hébergée sur un compte Hostinger.
Quand j’essaie d’exécuter un nœud « When chat message received », il ne fait absolument rien. Pas de message d’erreur, pas de coche verte pour montrer qu’il a essayé… rien du tout. J’ai essayé d’ouvrir l’URL du chat dans mon navigateur, cela s’ouvre au moins, mais il n’y a pas non plus de réponses là-bas. J’ai créé une API sur Hostinger et l’ai configurée sur N8N, mais cela n’a pas résolu le problème.
Le truc, c’est que j’ai un autre compte N8N, en dehors de Hostinger, et cela fonctionne bien là-bas, même si cette version est complètement obsolète.
J’ai essayé de chercher des solutions en ligne, mais je n’ai toujours pas trouvé quelqu’un qui parle de ce problème en particulier. Est-ce que quelqu’un d’autre a eu ce problème ?
Quel est le message d’erreur (le cas échéant) ?
Veuillez partager votre workflow
C’est celui qui ne fonctionne pas (recréé à partir de celui qui fonctionne) :
C’est celui qui fonctionne.
Partagez la sortie renvoyée par le dernier nœud
Informations sur votre configuration n8n
- Version de n8n :
- Base de données (par défaut : SQLite) :
- Paramètre EXECUTIONS_PROCESS de n8n (par défaut : own, main) :
- Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) : Hostinger
- Système d’exploitation :
@Caike_Oliveira les logs ne montrent rien d’exécuté, donc le message de chat n’atteint pas réellement n8n pour déclencher le trigger, ce n’est pas le workflow. sur une box auto-hébergée comme hostinger c’est presque toujours WEBHOOK_URL qui ne correspond pas à votre vrai URL publique, donc la requête de chat ne peut pas revenir. WEBHOOK_URL est-il défini, et à quoi, votre domaine hostinger réel ou quelque chose comme localhost ?
D’après ce qu’a dit @achamm, sur Hostinger cela se configure généralement via le panneau des variables d’environnement de l’app n8n et non via SSH, dans la section paramètres/configuration de votre instance n8n. Vérifiez quelle valeur est définie pour WEBHOOK_URL ; elle doit correspondre exactement à l’URL à laquelle vous accédez à n8n (en incluant https://).
Une chose à vérifier indépendamment de cela : ce workflow est-il vraiment enregistré et activé (interrupteur en haut à droite de l’éditeur) ? L’URL de production du Chat Trigger ne répond que lorsque le workflow est actif. Si vous ouvrez simplement l’URL du chat alors que le workflow est en état brouillon/inactif, vous obtiendrez exactement ce symptôme (la page se charge, mais les messages ne vont nulle part, aucune exécution enregistrée).
S’il est actif et que WEBHOOK_URL semble correct, essayez le bouton « Ouvrir le chat » directement depuis le nœud plutôt qu’une URL copiée manuellement. Les configurations Hostinger utilisent parfois un proxy via un préfixe de chemin que l’aperçu du nœud prend en charge automatiquement, mais une URL saisie manuellement ne le fera pas.
Bonjour.
Merci pour vos réponses, mais il s’avère que ça n’avait rien à voir avec le webhook.
La clé « n8n_encryption_key » était vide. J’ai dû l’insérer manuellement dans le terminal Hostinger. Je ne sais pas pourquoi elle a été créée vide. Tout ce que je sais, c’est qu’aussitôt que je l’ai fait, mes nœuds ont commencé à réagir. Maintenant, je peux passer à l’étape suivante.
Encore une fois, merci pour vos réponses. Découvrir où vérifier les webhooks a été ce qui, finalement, m’a mené à la « encryption_key ».
@Caike_Oliveira bonne observation, ça explique parfaitement l’échec silencieux. Une clé N8N_ENCRYPTION_KEY vide signifie que n8n ne peut pas décrypter vos identifiants enregistrés, donc les nœuds basés sur les identifiants échouent simplement sans aucune erreur, exactement ce que vous aviez constaté.
Cela vaut le coup de verrouiller maintenant que ça marche : gardez cette clé exacte de façon permanente et sauvegardez-la quelque part. Si elle change ou se réinitialise à nouveau sur vide, chaque identifiant que vous avez déjà enregistré devient indéchiffrable et vous devriez tous les resaisir. Assurez-vous donc qu’elle soit épinglée dans les paramètres env de Hostinger plutôt que de la laisser se régénérer lors d’un redéploiement.
J’ai frappé exactement cette chose avec le Chat Trigger et ça m’a rendu fou parce que la page de chat se charge correctement tandis que rien ne parvient à n8n du tout. Le trigger ne se déclenche que lorsque le workflow est actif et que le chat poste vers l’URL webhook de production, pas celle de test, donc si vous êtes sur l’URL de test vous obtenez du vert mais rien à chaque fois. Sur un serveur auto-hébergé derrière un reverse proxy c’est généralement pire : le proxy avale les chemins webhook et chat, ou il abandonne la mise à niveau websocket, donc le message ne parvient jamais. Réglez WEBHOOK_URL sur votre véritable URL publique, activez le workflow, et assurez-vous que le proxy redirige à la fois les chemins chat/webhook et les connexions websocket. Une fois que ces éléments s’alignent, les réponses ont commencé à s’afficher pour moi tout de suite.
