Em 29 de abril, minha mãe acionou o workflow a partir da página web, mas essa execução não aparece no n8n e também não funcionou corretamente. No entanto, quando eu executo o mesmo workflow a partir da página web, funciona sem nenhum problema.
Gostaria de entender por que isso pode acontecer:
por que uma execução pode não ser salva ou exibida,
por que funciona para mim mas não para outra pessoa,
e se isso poderia estar relacionado a permissões, autenticação, sessão ou à forma como o workflow é acionado.
Se alguém já vivenciou algo semelhante, eu realmente agradeceria qualquer ajuda.
Este é um cenário comum em automação onde “funciona na minha máquina” se torna uma realidade de resolução de problemas. Como a execução não aparece no histórico do n8n, isso sugere que o problema está ocorrendo antes da lógica do workflow ser totalmente processada ou durante a transferência entre a página da web e o webhook do n8n.
Aqui está uma análise das possíveis razões, categorizadas por onde a falha provavelmente ocorreu.
1. Por que uma execução pode não ser salva ou exibida
Se uma execução não aparecer na aba “Executions” do n8n, geralmente significa uma de três coisas:
o A requisição nunca chegou ao n8n: O gatilho (nó Webhook) nunca recebeu com sucesso a requisição HTTP. Se a requisição foi bloqueada por um firewall, um erro de CORS ou um problema de rede, o n8n nunca “viu” isso, então não conseguiu criar um registro de execução.
o Erro durante a fase de “Trigger” (Gatilho): Se o erro ocorrer dentro do nó Webhook (por exemplo, uma incompatibilidade nos headers esperados ou uma falha de autenticação no nível do servidor), o n8n pode rejeitar a requisição com um erro 401, 403 ou 404 antes mesmo do mecanismo de workflow iniciar uma “execução” formal.
o Configurações do n8n: No n8n, existe uma configuração para “Save Successful Executions” (Salvar Execuções com Sucesso). Se o workflow realmente conseguiu ser executado, mas tinha um bug que fez parecer que falhou, e você tiver “Save Successful Executions” desativado, você não o verá. No entanto, como você mencionou que “não funcionou corretamente”, é mais provável que seja uma falha.
2. Por que funciona para você, mas não para outra pessoa
Isso aponta para diferenças no Lado do Cliente (o navegador/dispositivo) ou no Ambiente de Rede.
o Problemas de CORS (Cross-Origin Resource Sharing): Este é o culpado mais provável. Se a página da web está hospedada em domain-a.com e seu n8n está em domain-b.com, o navegador realiza uma verificação de “preflight”. Se seu navegador tem uma permissão em cache ou uma configuração de segurança diferente, ele pode passar, enquanto o navegador dela (talvez com configurações de privacidade mais rigorosas ou extensões diferentes) bloqueia a requisição.
o Diferenças de Payload/Dados: Quando sua mãe ativa o workflow, ela está inserindo exatamente os mesmos dados que você? Se a página da web envia um formulário e ela insere um caractere especial, deixa um campo em branco ou insere um valor que viola um schema (por exemplo, uma string quando um número é esperado), o workflow pode falhar no primeiro nó.
o Autenticação & Sessões:
o Cookies/Tokens: Se a página da web depende de um cookie de sessão ou de um token Bearer para autorizar o gatilho, e a sessão dela expirou ou ela não está logada corretamente, a requisição será rejeitada.
o IP Whitelist (Lista de IPs Permitidos): Se sua instância do n8n está atrás de um firewall que apenas permite determinados endereços IP, seu IP pode estar permitido, enquanto o dela (em uma rede diferente ou VPN) está bloqueado.
o Extensões do navegador/Bloqueadores de anúncios: Muitos bloqueadores de anúncios ou extensões de privacidade (como uBlock Origin ou shields do Brave Browser) interceptam requisições “incomuns” de saída. Se a URL do webhook parecer um script de rastreamento para o navegador dela, ela será bloqueada antes de sair do computador dela.
3. Lista de Verificação de Resolução de Problemas
Para encontrar a causa exata, recomendo investigar nesta ordem:
Muito minucioso, @Rafael_Van_Meerbeek tenho 95% de certeza de que se você seguir as recomendações de @kjooleng você vai resolver seu problema. Quanto aos outros 5%, você poderia tentar deletar o nó de gatilho e começar com um novo.
a conexão intermitente perdida enquanto o workflow está aberto geralmente é um problema de estabilidade do websocket. as causas comuns em docker auto-hospedado: nginx não configurado para upgrades de websocket, ou um timeout de proxy mais curto que o intervalo de keepalive.
verifique se sua configuração do nginx tem proxy_http_version 1.1 e os headers Upgrade e Connection configurados corretamente. se você tem um load balancer ou reverse proxy com um timeout curto, essa é quase sempre a causa. a conexão cai, reconecta, cai novamente a cada poucos segundos.
A mensagem “Conexão perdida” piscando é um sintoma clássico de um canal de comunicação em tempo real instável entre seu navegador e o servidor n8n.
O n8n não apenas “atualiza” a página para mostrar as atualizações; ele usa uma tecnologia chamada WebSockets (ou às vezes Server-Sent Events) para manter um “tubo” ao vivo. Isso permite que o servidor envie atualizações para sua tela imediatamente (como quando um nó termina de executar ou uma nova execução é iniciada).
Quando você vê piscando a cada segundo, significa que o “heartbeat” (o sinal que diz “Ainda estou aqui!”) está sendo interrompido.
Aqui estão as razões mais prováveis para isso estar acontecendo:
1. Configuração de Proxy Reverso (A #1 Causa)
Se você está executando n8n atrás de um proxy reverso como Nginx, Traefik, Apache ou Cloudflare, o proxy provavelmente é o culpado.
-
Suporte a WebSocket: WebSockets requerem headers específicos (
UpgradeeConnection) para funcionar. Se seu proxy não estiver configurado para “permitir” esses headers, ele matará a conexão assim que ela tentar se estabelecer. -
Configurações de Timeout: Proxies geralmente têm um “read timeout” ou “idle timeout”. Se o proxy achar que a conexão ficou em silêncio por muito tempo (mesmo que esteja apenas aguardando uma tarefa), ele a fechará. O navegador então tenta reconectar imediatamente, criando esse loop de “piscada”.
-
Cloudflare/WAF: Se você usa Cloudflare, suas configurações de segurança ou “Rocket Loader” podem às vezes interferir com conexões WebSocket persistentes.
2. Esgotamento de Recursos do Servidor
O screenshot “Prod. executions” mostrando uma queda de -98.46% é uma pista significativa. Isso sugere que o sistema está sofrendo uma instabilidade massiva.
-
Picos de CPU/RAM: Se o servidor executando n8n atingir 100% de CPU ou ficar sem RAM, o processo n8n fica “sem resposta” por milissegundos. Durante esses milissegundos, ele falha em responder ao sinal de “heartbeat” do navegador, causando o erro “Conexão perdida”.
-
Gargalos de Banco de Dados: Se seu banco de dados (PostgreSQL/SQLite) está tendo dificuldade em escrever dados de execução, todo o processo n8n pode travar momentaneamente, quebrando a conexão ao vivo.
3. Instabilidade de Rede
-
Perda de Pacotes: Se sua conexão de internet local ou o caminho de rede para seu servidor está perdendo até uma pequena porcentagem de pacotes de dados, o WebSocket—que é muito sensível a interrupções—irá constantemente cair e reconectar.
-
VPN/Firewall: Se você está em uma VPN corporativa, ela pode estar agressivamente inspecionando o tráfego e terminando conexões de longa duração que percebe como “suspeitas” ou “ociosas”.
4. O que a queda em “Prod. executions” significa
A queda massiva de porcentagem em seu screenshot geralmente significa uma de duas coisas:
-
Lacuna de Dados: Porque a conexão é instável, o dashboard está falhando em buscar o histórico recente, fazendo parecer que as execuções despencarão.
-
Falha do Sistema: O problema subjacente causando a piscada de conexão (como CPU alta ou um serviço travando) está realmente prevenindo que os workflows executem com sucesso, levando a uma queda real nas execuções de produção bem-sucedidas.
Etapas de Troubleshooting Recomendadas:
-
Verificar Saúde do Servidor: Execute
topouhtop(no Linux) para ver se CPU ou Memória está spiking quando a piscada acontece. -
Verificar Logs do Proxy: Se estiver usando Nginx, verifique
/var/log/nginx/error.log. Procure por “upstream timed out” ou “connection reset by peer”. -
Testar a Conexão “Direta”: Se possível, tente acessar n8n via seu endereço IP e porta (ex:
http://your-ip:5678) contornando o domínio/proxy. Se a piscada parar, o problema é definitivamente sua configuração de proxy. -
Inspecionar Console do Navegador: Pressione
F12em seu navegador, vá para a aba Console e procure por erros comoWebSocket connection to 'wss://...' failed. Isso confirmará se é um erro de conexão.