Oi a todos,
Estou executando uma instância n8n auto-hospedada em uma VPS da Hostinger atrás do Traefik.
Construí meu próprio chatbot JavaScript customizado que envia requisições diretamente para um webhook n8n usando fetch().
O problema estranho é que o chatbot funciona perfeitamente em alguns dispositivos, mas falha completamente em outros.
Por exemplo: Funciona no meu celular. Funciona no meu computador. Não funciona no computador da minha mãe. Alguns outros usuários também relatam o mesmo problema.
O importante é que o problema é específico do dispositivo, não do usuário.
Há alguns meses atrás mudei meu domínio do webhook porque achei que o software antivírus estava bloqueando.
Originalmente eu usava outro domínio, mas mudei tudo para:
usando Traefik com HTTPS.
Infelizmente, nada mudou. O chatbot ainda funciona em alguns dispositivos, mas não em outros.
Hoje também consertei outro problema onde o Traefik havia parado porque o Nginx estava ocupando a porta 80. O Traefik agora está funcionando corretamente, o HTTPS funciona e o webhook está acessível.
A parte confusa é:
Em dispositivos onde funciona, tudo é perfeito.
Em dispositivos onde não funciona, a requisição nunca parece chegar corretamente ao chatbot.
Meu frontend exibe „Erro desconhecido", mas essa mensagem é minha própria mensagem de fallback, não um erro do n8n. É mostrada sempre que o fetch() do JavaScript falha ou a requisição não pode ser concluída.
O fluxo de trabalho em si funciona corretamente quando a requisição chega ao n8n.
Estou anexando capturas de tela de:
Minha configuração.
Executações de fluxo de trabalho bem-sucedidas.
O comportamento do frontend.
Alguém já vivenciou uma situação onde um webhook funciona em alguns dispositivos, mas não em outros?
Poderia estar relacionado a:
CORS?
Segurança do navegador?
Software antivírus?
DNS ou SSL?
Proxy reverso (Traefik)?
Algo mais que estou deixando passar?
Ademais, qual seria a melhor forma de debugar por que fetch() funciona em alguns dispositivos mas falha em outros?
Qualquer sugestão seria muito apreciada.
Descreva o problema/erro/pergunta
Qual é a mensagem de erro (se houver)?
Por favor, compartilhe seu fluxo de trabalho
(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
@Rafael_Van_Meerbeek falhas específicas do dispositivo + seu próprio fallback disparando significa que o fetch está morrendo no nível de rede antes mesmo de chegar ao n8n, então não é seu workflow, é DNS/TLS/antivírus nesses dispositivos específicos. a forma mais rápida de separar: em um dispositivo onde falha, abra a URL do webhook diretamente no navegador e verifique o console. um aviso de certificado/segurança aponta para confiança TLS (dispositivos mais antigos não confiando na cadeia), e cant-resolve ou connection-refused aponta para DNS ou antivírus bloqueando o domínio. qual aparece?
@Rafael_Van_Meerbeek connection-timed-out (não name-not-resolved, sem aviso de certificado) significa que o DNS se resolve bem mas a conexão TCP com o IP nunca se completa, e isso variar por dispositivo é geralmente IPv6. verifique se seu domínio tem um registro AAAA, se tem mas o VPS/Traefik não está realmente servindo v6 (ou está mal configurado), os dispositivos que tentam o endereço v6 travam enquanto os v4 se conectam sem problema. a correção mais rápida, remova o registro AAAA para que todos usem IPv4, ou corrija IPv6 no servidor. confirme com curl -6 vs curl -4 para o domínio de uma rede com falha.
dig api.novaintellectagents.com A
dig api.novaintellectagents.com AAAA
A consulta AAAA não retorna resposta, então a API é apenas IPv4.
Isso descarta a teoria de IPv6?
O estranho é que os dispositivos afetados ainda recebem ERR_CONNECTION_TIMED_OUT, enquanto outros dispositivos em redes diferentes conseguem acessar exatamente o mesmo endpoint sem problemas.
@Rafael_Van_Meerbeek sim isso descarta IPv6, boa verificação. então DNS resolve mas o mesmo IP sofre timeout em algumas redes, e um timeout (não connection-refused) significa que os pacotes estão sendo silenciosamente descartados, o que é quase sempre um firewall. o principal suspeito é server-side: fail2ban, ufw, ou o próprio firewall da Hostinger banindo esses IPs de origem. verifique fail2ban-client status, ufw status, e o painel de firewall da Hostinger para bans. depois execute tracert para 31.97.199.227 de uma rede com falha, se chegar na Hostinger e parar lá é o firewall do servidor, se morrer antes é ISP/roteamento nessa rede.
@Rafael_Van_Meerbeek legal, isso descarta totalmente seu lado, servidor e firewall estão limpos. então é upstream, ou a rota para 31.97.199.227 está quebrada nessas redes (seu tracert vai mostrar onde morre), ou mais provavelmente o IP está em uma blocklist de reputação que essas redes/ISPs/antivírus honram e silenciosamente descartam, IPs reciclados de VPS Hostinger frequentemente carregam uma má reputação de um inquilino anterior. verifique no abuseipdb ou spamhaus. a solução mais limpa de qualquer forma: coloque o domínio atrás do Cloudflare (grátis), você recebe um IP bem reputado que toda rede consegue alcançar e esconde sua origem, o que contorna os problemas de roteamento e reputação simultaneamente.
Opa @Rafael_Van_Meerbeek, a sugestão do Cloudflare é o caminho certo aqui. passos para fazer isso:
Verifique a reputação do IP primeiro, cole 31.97.199.227 em abuseipdb.com e spamhaus.org. Se mostrar um histórico ruim, isso confirma a causa raiz.
Adicione seu domínio ao Cloudflare (grátis), crie uma conta, adicione novaintellectagents.com e aponte seus nameservers para o Cloudflare. Seu registro A permanece o mesmo, mas o tráfego agora flui através dos IPs limpos do Cloudflare, que toda rede confia.
Certifique-se de que a nuvem laranja está ON para api.novaintellectagents.com no DNS do Cloudflare, é isso que faz proxy do tráfego e esconde seu IP de origem.
No Traefik, restrinja conexões de entrada apenas aos intervalos de IP do Cloudflare (eles publicam a lista em IP Ranges | Cloudflare) isso protege sua origem e impede que alguém contorne o Cloudflare direto para seu IP de VPS.
Isso deve corrigir as falhas específicas do dispositivo completamente, já que ninguém estará atingindo seu IP do Hostinger direto mais.
ERR_CONNECTION_TIMED_OUT significa que a requisição falha antes mesmo de n8n poder estar errado. A primeira divisão que faria seria:
zero request nos logs do Traefik/Hostinger = roteamento, firewall, ISP ou edge do servidor;
requisição aparece mas sem execução do workflow = problema no caminho n8n/webhook;
execução aparece e falha = problema na lógica do workflow.
Então eu pararia de debugar CORS até você provar se o dispositivo que falha alcança o Traefik.
De uma rede que falha, você consegue ver alguma linha de access-log para essa requisição no lado do servidor?
A divisão de Tony (logs do Traefik primeiro) é a abordagem certa - não persiga CORS até confirmar que a requisição está chegando ao seu servidor.
Se você vir a requisição chegando ao Traefik mas falhando lá, verifique a cadeia de certificados SSL. Certificados intermediários ausentes causam quedas específicas do dispositivo que parecem idênticas a timeouts - dispositivos com stores de raiz mais rigorosos (Windows antigos, algumas versões do Android) descartarão silenciosamente a conexão. Teste a cadeia em SSL Server Test (Powered by Qualys SSL Labs) ou execute curl -v --max-time 5 https://api.novaintellectagents.com da máquina que está falhando. Se você vir SSL certificate verify failed ou a cadeia está incompleta, esse é o seu culpado - o Traefik precisa do pacote de certificado completo incluindo intermediários.
Concordo com o uso do Cloudflare para aplicações assim!
@Rafael_Van_Meerbeek pergunta óbvia, mas você já descartou a possibilidade do navegador estar bloqueando a requisição? Você testou, digamos, Safari vs Chrome vs Firefox? para ver se você está recebendo o mesmo comportamento nos 3?
Funciona no meu celular.
Não funciona no computador da minha mãe.
