Como expor webhooks do n8n com HTTPS (reverse proxy, porta 443 e tunnel) sem virar refém de gambiarra

1. 1) Defina a URL pública que o mundo vai acessar

   Escolha um domínio/subdomínio (ex.: automacoes.suaempresa.com.br) e decida se o n8n ficará na raiz (/) ou em um caminho (/n8n). Essa decisão impacta diretamente a configuração do proxy e as variáveis de ambiente do n8n (URL base e, quando aplicável, path/base path). Evite trocar isso depois de ter fluxos em produção.

2. 2) Escolha o método de publicação: reverse proxy ou tunnel

   Se você controla uma VPS com IP público e consegue abrir 80/443, use reverse proxy. Se está atrás de CGNAT, rede corporativa, ou não quer/ não pode expor portas, use tunnel. Em ambos os casos, a meta é a mesma: uma URL HTTPS estável apontando para o serviço do n8n.

3. 3) Configure TLS (certificado) e force HTTPS

   No reverse proxy, termine o TLS na borda (proxy) e faça o n8n rodar internamente em HTTP na rede local/bridge do Docker. Em tunnel, o TLS normalmente é tratado pelo provedor do tunnel (você ainda deve manter HTTP interno restrito). Garanta redirecionamento 80→443 quando usar reverse proxy.

4. 4) Garanta que o n8n sabe qual é a URL externa

   O n8n precisa gerar links e endpoints coerentes com a URL pública. Se a ferramenta “acha” que está em http://localhost:5678, você verá callbacks quebrados, redirects estranhos e webhooks que parecem certo mas não batem. Ajuste as variáveis de ambiente relacionadas a host/protocolo/porta e (se usar) base path, conforme seu layout.

5. 5) Valide proxy headers e tamanho de payload

   No proxy, repasse headers padrão (Host, X-Forwarded-Proto, X-Forwarded-For). Muitos problemas de login/cookies e redirects vêm daqui. Se você recebe payloads grandes (ex.: arquivos, JSONs extensos), ajuste limites do proxy (client_max_body_size no Nginx, por exemplo) com bom senso.

6. 6) Teste o webhook de ponta a ponta (sem “achar” que está funcionando)

   Crie um workflow mínimo com Webhook Trigger e uma resposta simples. Teste: (a) acesso direto via navegador/HTTP client, (b) chamada real do sistema de origem. Verifique logs do proxy e do n8n. Se aparecer 404/502/301 em loop, pare e corrija base URL, path e headers antes de seguir.

7. 7) Endureça a segurança do endpoint

   Não trate webhook como “porta aberta”. Use um token/segredo na URL ou header, valide assinatura quando a plataforma oferecer, aplique rate limit no proxy e registre tentativas inválidas. Se for webhook crítico (pagamentos/pedidos), implemente idempotência no workflow para evitar duplicidade em retries.

Reverse proxy vs tunnel: quando cada um faz mais sentido

Na prática, reverse proxy é o caminho mais previsível para produção: você controla DNS, portas, TLS e observabilidade no seu servidor. Já tunnel brilha quando a rede é hostil (CGNAT, firewall do provedor, roteador que você não manda) ou quando você quer reduzir superfície de ataque sem expor 443 diretamente.

O trade-off é governança: tunnel adiciona um intermediário. Dependendo do seu caso (LGPD, auditoria, clientes exigentes), isso pode ser ok ou pode ser um ponto de atenção.

Checklist de configuração que evita 80% dos erros

Se você só quer uma lista para conferir antes de culpar o webhook, aqui vai o que mais aparece em suporte e bastidor:

• DNS do domínio aponta para o lugar certo (IP da VPS ou destino do tunnel)
• HTTPS ativo e válido (sem certificado expirado e sem mixed content)
• Proxy repassa Host e X-Forwarded-Proto corretamente
• URL pública do n8n configurada para bater com o domínio real (e com o path, se existir)
• Portas internas corretas (container/serviço escutando onde o proxy acha que está)
• Sem loop de redirect HTTP↔HTTPS (muito comum quando o n8n “pensa” que está em HTTP)
• Limites de payload do proxy compatíveis com o que você recebe
• Logs habilitados (proxy e n8n) para ver o erro em vez de adivinhar

Erros comuns (e o que normalmente está errado)

Dois sintomas dominam: 404 (rota não existe) e 502 (proxy não consegue alcançar o n8n). 404 costuma ser path/base path errado ou webhook path diferente do que você está chamando. 502 geralmente é porta errada, serviço fora do ar, rede do Docker mal ligada ou healthcheck falhando.

Loop 301/302 quase sempre é protocolo: você força HTTPS no proxy, mas o n8n gera URLs em HTTP (ou vice-versa). Corrigir a URL externa e os headers de forwarded resolve.

Perguntas frequentes

Leia também

Guia

Webhook no n8n: como receber, tratar e responder HTTP (sem gambiarra)

Aprenda a criar um webhook no n8n, validar assinatura, tratar payload, evitar duplicidade e responder HTTP 200/400/500 com padrão de produção.

Ler →

Guia

Como colocar o n8n em produção: checklist de segurança, monitoramento e backup (sem susto)

Guia prático para subir n8n em produção com HTTPS, credenciais, filas/retry, logs, alertas e backup/restauração. Focado em cenários comuns no Brasil e em operação estável.

Ler →

Guia

Como rodar n8n em Docker Compose com Postgres e HTTPS (sem dor de cabeça)

Aprenda a subir o n8n self-hosted com Docker Compose, Postgres e HTTPS (Traefik ou Nginx). Checklist de variáveis, persistência, webhooks e erros comuns no Brasil.

Ler →

Guia

Webhook ou polling em automações: como escolher (sem perder eventos e sem estourar limites)

Guia direto para decidir entre webhook e polling: latência, confiabilidade, custo por execução, rate limit e como evitar duplicidades. Inclui tabela e checklist prático.

Ler →