Webhook do n8n não funciona: URL de teste, produção, proxy e SSL
Webhook n8n não funciona? Entenda URL de teste e produção e diagnostique workflow inativo, WEBHOOK_URL, proxy reverso, Cloudflare, SSL e timeout.
Por que um webhook do n8n pode parar de funcionar
O nó Webhook transforma uma requisição HTTP em gatilho para um workflow. Para isso funcionar, o sistema remetente precisa alcançar o domínio correto, passar por DNS, Cloudflare e proxy reverso, negociar HTTPS, usar o método e a autenticação esperados e chegar a um workflow apto a receber o evento.
Quando o webhook do n8n não funciona, o problema pode estar antes, dentro ou depois do n8n. Uma resposta 404 pode indicar workflow inativo ou caminho errado; 401 e 403 apontam para autenticação ou bloqueio; 502 e 504 podem nascer no proxy; e um status 2xx não garante que todos os nós posteriores terminaram corretamente.
O diagnóstico mais eficiente acompanha a requisição de ponta a ponta. Em vez de trocar várias configurações ao mesmo tempo, registre a URL chamada, método, horário, status, corpo da resposta e identificador do evento. Depois correlacione essas informações com os logs de cada camada.
URL de teste e URL de produção no n8n
O nó Webhook apresenta duas URLs com finalidades diferentes. Confundi-las é uma das causas mais frequentes de integração que funciona no editor e para logo depois.
| URL | Quando usar | Condição para receber |
|---|---|---|
| Teste | Desenvolvimento, inspeção do payload e configuração inicial. | O editor precisa estar aguardando o evento de teste; o registro é temporário. |
| Produção | Integrações permanentes, sistemas externos e tráfego real. | O workflow precisa estar publicado ou ativo, conforme a versão do n8n. |
Por que o teste funciona e a produção retorna 404?
Normalmente o sistema externo continua usando o endereço de teste, o workflow não foi ativado ou a versão publicada não contém o Webhook esperado. Copie a URL diretamente do nó, publique o workflow, confirme seu estado e faça uma nova chamada controlada para a URL de produção.
O inverso também ocorre: a URL de produção está cadastrada no fornecedor, mas o usuário observa apenas o painel de teste e conclui que nada chegou. Consulte a lista de execuções de produção e filtre pelo horário do evento.
Workflow inativo, versão não publicada e instância errada
Salvar alterações no editor não significa necessariamente disponibilizá-las para produção. Dependendo da versão do n8n, confirme se a versão correta está publicada ou se o workflow está ativo. Depois verifique se o fornecedor aponta para a mesma instância em que você fez a alteração.
Workflow inativo
A URL de produção não fica registrada para receber chamadas. Ative ou publique o fluxo e confirme o estado exibido pelo n8n.
Alteração apenas no rascunho
O editor mostra um caminho ou configuração nova, mas produção continua executando a versão anteriormente publicada.
Ambientes misturados
Homologação e produção usam domínios parecidos. Compare hostname, path, ID do workflow e credenciais do remetente.
Container ou banco antigo
Após migração, o domínio pode chegar a outra instalação, ou uma réplica pode estar com configuração e banco diferentes.
Domínio incorreto e WEBHOOK_URL
Em uma instalação direta, o n8n consegue montar URLs a partir do próprio host e protocolo. Atrás de Docker, Coolify, Traefik, Nginx ou outro proxy, porém, o container pode enxergar apenas um endereço interno como HTTP e uma porta privada, enquanto o usuário acessa um domínio público por HTTPS.
A variável WEBHOOK_URL informa ao n8n qual URL pública deve ser exibida e registrada. Um exemplo conceitual é:
WEBHOOK_URL=https://n8n.exemplo.com/Use o domínio real, o protocolo externo e, se houver, o caminho base correto. Não copie o endereço interno do container. Após alterar variável de ambiente, a aplicação precisa ser recriada ou reiniciada pelo mecanismo de deploy para carregar a nova configuração; confirme a URL que o próprio nó passa a exibir.
Sinais de WEBHOOK_URL incorreta
- O n8n mostra http:// quando o acesso público usa https://.
- A URL contém hostname do container, localhost ou uma porta interna.
- OAuth e serviços externos retornam para um domínio antigo.
- O editor abre em um domínio, mas o Webhook exibe outro.
- Depois de uma migração, fornecedores continuam chamando a URL anterior.
Proxy reverso e cabeçalhos encaminhados
O proxy recebe a conexão pública e encaminha a requisição para o n8n. Ele precisa preservar host, protocolo e IP de origem nos cabeçalhos encaminhados. A documentação oficial cita X-Forwarded-For, X-Forwarded-Host e X-Forwarded-Proto.
O n8n também precisa saber quantos proxies confiáveis existem entre o cliente e a aplicação por meio de N8N_PROXY_HOPS. O valor depende da topologia real. Informar um número arbitrário pode fazer o n8n interpretar incorretamente a origem ou confiar em cabeçalhos enviados por uma camada que não deveria ser confiável.
Rota não chega ao container
Domínio aponta para o servidor, mas Traefik ou Nginx não possui uma rota correspondente ou encaminha para a porta interna errada.
Prefixo removido ou duplicado
O proxy reescreve o caminho e transforma /webhook/... em uma rota diferente da registrada pelo n8n.
Protocolo interpretado como HTTP
Sem X-Forwarded-Proto adequado, o n8n pode gerar URL incorreta ou provocar redirecionamentos inesperados.
Corpo ou header limitado
Proxy, WAF ou ingress rejeita payload grande, content type específico ou cabeçalhos de autenticação.
Timeout no proxy
A conexão é encerrada antes do workflow responder, mesmo que a execução continue no n8n.
Mais de uma camada
Cloudflare, proxy do Coolify e proxy interno precisam ser considerados juntos ao definir confiança e diagnosticar logs.
Cloudflare pode bloquear o webhook do n8n?
Sim, mas o proxy da Cloudflare não é automaticamente um problema. Ele pode proteger e terminar a conexão TLS, enquanto regras específicas podem bloquear ou alterar a chamada. O diagnóstico deve observar o evento na Cloudflare, os logs do proxy de origem e a execução no n8n no mesmo horário.
- WAF ou regra de segurança bloqueando método, origem, user agent, path ou payload.
- Cloudflare Access exigindo login interativo em uma rota chamada por servidor.
- Modo SSL incompatível com o certificado configurado no servidor de origem.
- Redirecionamento entre HTTP, HTTPS, www e domínio raiz alterando método ou autenticação.
- Regra de cache aplicada indevidamente a uma rota dinâmica de webhook.
- Timeout em processamento longo antes de o n8n devolver a resposta.
Em vez de desligar toda a proteção, identifique a regra responsável e crie uma exceção mínima para o hostname ou caminho necessário. Se a rota precisa ser protegida, prefira autenticação adequada ao remetente e restrições compatíveis com chamadas servidor a servidor.
Problemas de SSL e HTTPS
Muitos fornecedores recusam webhooks HTTP ou certificados inválidos. Mesmo quando o navegador abre o editor do n8n, a rota chamada por uma integração pode usar outro hostname, atravessar outro proxy ou apresentar uma cadeia de certificado diferente.
| Falha | Efeito comum | Verificação |
|---|---|---|
| Certificado expirado | O remetente encerra a conexão TLS. | Validade, renovação automática e logs do emissor. |
| Hostname não coberto | O certificado pertence a outro domínio. | SANs do certificado e domínio exato da URL. |
| Cadeia incompleta | Alguns clientes aceitam e outros rejeitam. | Certificados intermediários enviados pelo proxy. |
| Origem sem certificado válido | Cloudflare não consegue conectar em modo estrito. | TLS entre Cloudflare e servidor, não apenas entre navegador e borda. |
| Redirecionamento inesperado | POST pode não ser repetido como esperado pelo cliente. | URL final e regras de redirecionamento no proxy. |
Método HTTP, caminho e autenticação
A URL correta não compensa uma requisição incompatível. Compare a configuração do nó Webhook com o que o sistema externo realmente envia — não apenas com o que está descrito no painel do fornecedor.
Método HTTP
POST, GET, PUT, PATCH, DELETE e outros métodos não são intercambiáveis. Um caminho registrado para POST não deve ser testado apenas abrindo a URL no navegador, que normalmente faz GET.
Path
Confira barras, prefixos, letras, parâmetros de rota e qualquer reescrita feita pelo proxy. Copie o endereço completo exibido pelo nó.
Content-Type
JSON, formulário, texto e binário chegam de maneiras diferentes. Confirme o cabeçalho e examine a entrada real recebida pelo n8n.
Autenticação
Se o nó usa Basic, Header ou JWT conforme os recursos da versão, o remetente precisa enviar exatamente a credencial e o formato configurados.
Secret no lugar errado
Token na query string não substitui um header esperado. Além de falhar, segredos em URLs podem aparecer em logs e históricos.
WAF antes do n8n
Uma resposta 401 ou 403 pode vir da Cloudflare ou do proxy, não do nó. Identifique quem gerou a resposta pelos headers e logs.
Timeout e modo de resposta do Webhook
O evento pode chegar e iniciar uma execução, mas o remetente ainda registrar timeout. Isso acontece quando ele espera uma resposta por menos tempo do que o workflow leva para processar banco, IA, arquivos ou APIs externas.
O nó Webhook permite estratégias de resposta, como responder imediatamente, responder quando o último nó terminar ou usar o nó Respond to Webhook. A opção correta depende do contrato da integração. Alguns fornecedores precisam apenas de uma confirmação rápida; outros esperam dados produzidos pelo workflow.
Antes de aumentar o timeout
- 1Meça a duração total e identifique qual nó consome o tempo.
- 2Descubra o limite do sistema remetente, da Cloudflare e do proxy reverso.
- 3Confirme se a resposta está configurada para o momento correto.
- 4Avalie se o processamento longo pode continuar depois de uma confirmação rápida, sem violar a regra de negócio.
- 5Implemente idempotência, pois o remetente pode repetir o evento após timeout.
- 6Monitore execuções que continuam rodando mesmo depois que a conexão HTTP foi encerrada.
Como localizar a camada que está falhando
| Evidência | Interpretação inicial | Próximo passo |
|---|---|---|
| Fornecedor não tentou enviar | Evento, assinatura ou configuração na origem. | Revisar eventos habilitados e histórico do fornecedor. |
| Cloudflare bloqueou | WAF, Access ou regra de segurança. | Analisar evento e ajustar somente a regra necessária. |
| Proxy registra 404 | Rota, domínio ou path não chegou ao n8n. | Comparar host, path, regra de roteamento e porta interna. |
| n8n registra 404 | Webhook não registrado para aquele método e caminho. | Verificar teste/produção, publicação e URL do nó. |
| Execução aparece com erro | A entrega funcionou; a falha está no workflow. | Abrir execução e analisar o primeiro nó que falhou. |
| Execução termina, origem dá timeout | Resposta tardia ou conexão encerrada em camada intermediária. | Comparar duração e modo de resposta com todos os limites. |
Checklist para webhook n8n que não funciona
- 1Registre URL completa, método, horário, status e corpo da última tentativa.
- 2Confirme se o fornecedor usa a URL de teste ou de produção adequada.
- 3Verifique se o editor está escutando o teste ou se o workflow está publicado/ativo.
- 4Compare domínio e protocolo exibidos pelo nó com a URL pública real.
- 5Revise WEBHOOK_URL e a configuração efetivamente carregada pelo container.
- 6Mapeie Cloudflare e cada proxy até o n8n, incluindo quantidade de hops confiáveis.
- 7Confira DNS, certificado, cadeia TLS, portas e regras de firewall.
- 8Valide path, método HTTP, content type, autenticação e tamanho do payload.
- 9Consulte eventos da Cloudflare, logs do proxy, logs do n8n e lista de execuções.
- 10Meça o tempo da execução e compare com os timeouts de todas as camadas.
- 11Teste com payload anonimizado e um identificador único para evitar duplicidade.
- 12Registre alterações recentes em domínio, deploy, workflow, proxy, SSL ou fornecedor.
Segurança para webhooks em produção
Um webhook público precisa ser alcançável pelo fornecedor, mas não precisa aceitar qualquer requisição. A documentação de auditoria do n8n inclui webhooks desprotegidos entre os riscos que podem ser identificados.
Autentique a origem
Use o mecanismo suportado pela integração e pelo nó. Quando disponível, valide assinatura e timestamp conforme a documentação do fornecedor.
Proteja segredos
Não grave tokens em URLs, prints ou logs públicos. Use credenciais do n8n e secrets da plataforma.
Valide o payload
Não confie apenas no Content-Type. Verifique campos obrigatórios, tipos, limites e identificador do evento.
Implemente idempotência
Provedores podem repetir entregas. Impeça que o mesmo evento gere duas ações irreversíveis.
Restrinja com cuidado
Allowlist de IP só funciona quando o fornecedor publica faixas estáveis e o proxy preserva a origem corretamente.
Monitore
Acompanhe falhas, latência, volume anormal, códigos HTTP, certificados e alterações de configuração.
Quando contratar suporte especializado
Vale contratar suporte n8n quando o webhook afeta vendas, atendimento, pagamentos ou outras rotinas de produção; quando existe risco de eventos duplicados; ou quando a falha atravessa várias camadas, como Cloudflare, Coolify, Traefik, Docker e n8n.
A Jupiter TI analisa workflows, webhooks, execuções, WEBHOOK_URL, Docker, Coolify, proxy reverso, DNS e SSL, Cloudflare, autenticação e timeouts. Também atuamos com automações e APIs, WhatsApp, monitoramento e infraestrutura self-hosted.
Se o problema faz parte de um cenário maior, consulte também o guia n8n com problemas: erros comuns e diagnóstico. A correção deve preservar dados, credenciais e eventos pendentes, sem prometer uma solução única antes de examinar a instalação.
Fontes técnicas oficiais
Este artigo foi revisado em 2 de agosto de 2026. A interface, os nomes de estados e as opções do nó podem mudar entre versões; consulte a documentação correspondente à instalação em uso.
Perguntas frequentes
Qual é a diferença entre a URL de teste e a URL de produção do webhook no n8n?
A URL de teste é temporária e recebe eventos enquanto o editor está aguardando um teste. A URL de produção é destinada à integração permanente e depende do workflow publicado ou ativo, conforme a versão do n8n. O sistema externo deve usar a URL correspondente ao modo desejado.
Por que a URL de produção do webhook retorna 404?
As causas frequentes são workflow inativo, caminho ou método HTTP diferente do configurado, URL de teste usada por engano, deploy ainda não publicado ou requisição chegando a outra instância. Verifique primeiro o estado do workflow e a URL copiada do próprio nó Webhook.
Para que serve a variável WEBHOOK_URL no n8n?
WEBHOOK_URL informa ao n8n a URL pública usada para exibir e registrar webhooks quando a aplicação está atrás de proxy reverso. Ela deve conter protocolo e domínio externos corretos, mesmo que internamente o container use outro hostname, porta ou HTTP.
A Cloudflare pode impedir o webhook do n8n?
Pode, dependendo das regras configuradas. WAF, Cloudflare Access, redirecionamentos, modo SSL incompatível, bloqueio por origem ou limites de conexão podem rejeitar a chamada. Compare os eventos da Cloudflare com os logs do proxy e do n8n antes de desativar proteções.
Por que o webhook executa, mas o sistema remetente informa timeout?
O workflow pode demorar mais do que o remetente aceita esperar, ou a resposta pode estar configurada para ocorrer somente ao final. Verifique o modo de resposta do Webhook, o nó Respond to Webhook, a duração da execução e os timeouts do remetente, Cloudflare e proxy.
A Jupiter TI oferece suporte para webhook e n8n self-hosted?
Sim. A Jupiter TI analisa workflows, URLs públicas, Docker, Coolify, proxy reverso, Cloudflare, DNS, SSL, autenticação, logs e timeouts em ambientes n8n self-hosted, com atendimento remoto para empresas em todo o Brasil.
Jupiter TI
Seu webhook do n8n continua sem receber eventos?
A Jupiter TI pode analisar o workflow, a URL pública, os logs e a infraestrutura para identificar se a falha está no n8n, no proxy reverso, no DNS, no SSL, na Cloudflare ou no sistema que envia o evento. A correção adequada depende do diagnóstico do ambiente.