Meu nó "When chat message received" não funciona

Descreva o problema/erro/pergunta

Olá.
Tenho um N8N hospedado em uma conta Hostinger.
Quando tento executar um nó “When chat message received” (Quando mensagem de chat recebida), ele não faz absolutamente nada. Sem mensagens de erro, sem marca verde mostrando que tentou… nada. Tentei abrir a URL do chat no meu navegador, pelo menos abre, mas não há respostas lá também. Criei uma API no Hostinger e configurei no N8N, mas isso não resolveu o problema.
O fato é que tenho outra conta N8N, fora do Hostinger, e funciona perfeitamente lá, mesmo que essa versão seja completamente desatualizada.
Tentei procurar soluções online, mas ainda não encontrei ninguém falando sobre esse problema específico. Alguém mais passou por isso?

Qual é a mensagem de erro (se houver)?

Por favor, compartilhe seu workflow

Este é o que não funciona (recriado a partir do que funciona):

Este é o que funciona.

Compartilhe a saída retornada pelo último nó

Informações sobre sua configuração n8n

  • Versão n8n:
  • Banco de dados (padrão: SQLite):
  • Configuração n8n EXECUTIONS_PROCESS (padrão: own, main):
  • Executando n8n via (Docker, npm, n8n cloud, aplicativo desktop): Hostinger
  • Sistema operacional:

@Caike_Oliveira os logs não mostram nada executado, então a mensagem de chat na verdade não está chegando ao n8n para disparar o trigger, não é o workflow. em uma máquina auto-hospedada como hostinger isso quase sempre é WEBHOOK_URL não correspondendo ao seu URL público real, então a requisição de chat não consegue voltar. WEBHOOK_URL está definida, e para quê, seu domínio hostinger real ou algo como localhost?

Com base no que @achamm disse, no Hostinger isso geralmente é configurado através do painel de variáveis de ambiente do app n8n, não via SSH, na seção de configurações/settings da sua instância n8n. Verifique qual é o valor de WEBHOOK_URL lá; ele precisa corresponder exatamente à URL que você usa para acessar o n8n (incluindo https://).

Uma coisa para verificar independentemente disso: este workflow está realmente salvo e ativado (toggle no canto superior direito do editor)? A URL de produção do Chat Trigger só responde quando o workflow está ativo; se você está apenas abrindo a URL do chat enquanto o workflow está em estado de rascunho/inativo, você terá exatamente esse sintoma (a página carrega, mas as mensagens não vão para lugar nenhum, nenhuma execução registrada).

Se está ativo e WEBHOOK_URL está correto, tente o botão “Open chat” diretamente de dentro do node em vez de uma URL copiada manualmente; as configurações do Hostinger às vezes fazem proxy através de um prefixo de caminho que o próprio preview do node leva em conta automaticamente, mas uma URL digitada manualmente não levará.

Oi.

Obrigado pelas respostas, mas, como se mostrou, não tinha nada a ver com webhook.

A “n8n_encryption_key” estava vazia. Tive que inserir manualmente no terminal Hostinger. Não sei por que foi criada vazia. Tudo que sei é que assim que fiz isso, meus nodes começaram a responder. Agora posso avançar para o próximo passo.

Novamente, obrigado pelas respostas. Descobrir onde verificar os webhooks foi o que, eventualmente, me levou à “encryption_key”.

@Caike_Oliveira boa observação, isso explica perfeitamente a falha silenciosa. Uma N8N_ENCRYPTION_KEY vazia significa que o n8n não consegue descriptografar suas credenciais salvas, então os nós com suporte a credenciais simplesmente falham sem nenhuma mensagem de erro, exatamente o que você estava vendo.

Vale a pena travar agora que está funcionando: mantenha essa chave exata de forma permanente e faça backup em algum lugar. Se ela mudar ou voltar a ficar vazia, todas as credenciais que você já salvou se tornarão indecifráveis e você teria que reinseri-las todas. Então certifique-se de que está fixada nas configurações de env do Hostinger em vez de ser deixada para regenerar em um redeploy.

Bati exatamente isso com o Chat Trigger e me deixou louco porque a página de chat carrega bem enquanto nada chega ao n8n. O trigger dispara apenas quando o workflow está ativo e o chat publica na URL do webhook de produção, não na de teste, então se você está na URL de teste fica verde mas nada acontece toda vez. Em self-hosted atrás de um reverse proxy geralmente é pior: o proxy engole o webhook e os caminhos de chat, ou derruba o upgrade de websocket, então a mensagem nunca chega. Configure WEBHOOK_URL para sua URL pública real, ative o workflow e certifique-se de que o proxy encaminha tanto os caminhos chat/webhook quanto as conexões websocket. Quando tudo se alinhar as respostas começaram a aparecer para mim imediatamente.