Você configurou um workflow no n8n, ele funcionou por duas semanas e depois começou a falhar constantemente com 403 Forbidden. A primeira ideia é "o site quebrou" ou "as credenciais expiraram". Na maioria das vezes, o problema é outro: o servidor de destino percebeu que a solicitação não veio de um navegador, mas de uma automação que está usando o IP do data center do seu VPS. O n8n possui um mecanismo de proxy embutido — apenas não está ativado por padrão, e parte das configurações não está onde você espera.
Vamos analisar passo a passo: onde exatamente configurar o proxy no n8n, como o self-hosted difere do Cloud e quais três armadilhas consomem mais tempo.
Por que o n8n é bloqueado com mais frequência do que seu navegador
O n8n é a maior plataforma de automação open-source: quase 198 mil estrelas e 59,6 mil forks no GitHub, a versão atual no momento da publicação é [email protected] (24 de julho de 2026). A popularidade tem um lado negativo: sistemas anti-bot conhecem bem sua impressão digital na rede.
Três fatores se combinam:
- User-Agent revela sua identidade instantaneamente. Isso não é uma suposição, mas um comportamento documentado oficialmente. No n8n, existe uma variável
N8N_ENFORCE_GLOBAL_USER_AGENT(por padrãofalse), e a documentação descreve claramente sua finalidade: substituir a string "crua" do User-Agentn8npor uma compatível com RFCMozilla/5.0 (compatible; n8n/<version>; +https://n8n.io/), para evitar o bloqueio de solicitações por firewalls de aplicativos web. O problema chegou a gerar relatórios de bugs: na issue #28280 (aberta em 10 de abril de 2026, fechada) foi descrito como os nós nativos retornavam um bare-UAn8n, e os sites respondiam com 403 devido ao "Bad User-Agent". O próprio nó HTTP Request usa axios por baixo dos panos e é facilmente reconhecido sem um cabeçalho manual. - O IP do seu servidor é de data center. O n8n quase sempre opera em VPS ou na nuvem. Esses intervalos são publicamente conhecidos e rotulados como "não residenciais": alguns sites aplicam restrições mais severas, com limites de solicitações muito mais baixos do que para conexões residenciais.
- A taxa de solicitações é desumana. Um nó em loop emite dezenas de solicitações por segundo de um único endereço — isso é um clássico gatilho para rate-limit e subsequente banimento do IP.
Passo 1. Proxy no próprio nó (funciona também no Cloud)
A maneira mais rápida é definir um proxy pontualmente para uma única solicitação HTTP:
- Abra o nó HTTP Request.
- Na parte inferior, clique em Add Option e escolha Proxy — este é um campo de texto para a URL do servidor proxy.
- Digite a string no formato padrão com autenticação:
http://LOGIN:SENHA@host:port. - Adicione também a opção de cabeçalhos: ative Send Headers e defina
User-Agentde um navegador real — copie manualmente a string atual do DevTools do seu Chrome.
Esse método é o único disponível no n8n Cloud: lá você não controla o ambiente de execução, portanto, as variáveis de ambiente do sistema não estão disponíveis para você, e o IP de saída não é fixo, mudando a cada execução. A vantagem desse método é a granularidade: diferentes nós de um mesmo workflow podem usar diferentes proxies e diferentes geolocalizações. A desvantagem é que, se houver vinte nós, você terá que editar vinte lugares.
Passo 2. Proxy global através de variáveis de ambiente (self-hosted)
No seu servidor, é mais lógico encapsular todo o tráfego de saída de uma vez. O n8n lê variáveis padrão:
HTTP_PROXY— URL do proxy para tráfego HTTP não criptografado dos nós;HTTPS_PROXY— o mesmo para solicitações TLS/SSL (na prática, este é seu parâmetro principal);ALL_PROXY— usado quando não estão definidas variáveis mais específicasHTTP_PROXY/HTTPS_PROXY;NO_PROXY— lista de hosts separados por vírgula, para os quais o n8n irá diretamente, ignorando o proxy.
No docker-compose.yml, isso se parece com:
HTTPS_PROXY=http://LOGIN:[email protected]:8080NO_PROXY=localhost,127.0.0.1,postgres,n8n.example.comN8N_ENFORCE_GLOBAL_USER_AGENT=true
Certifique-se de preencher NO_PROXY. Caso contrário, através do proxy externo, também serão enviados acessos internos — para seu Postgres, para contêineres vizinhos, para seu próprio domínio de webhook. O sintoma é "tudo quebrou após ativar o proxy", embora os sites de destino tenham começado a abrir.
Se você não quiser expor a versão do n8n externamente, em vez da string RFC, defina a sua através de N8N_GLOBAL_USER_AGENT_VALUE — ela substitui o valor padrão. A lógica geral de configuração do tráfego em contêineres é a mesma que em outros cenários: a análise de formatos e armadilhas está no guia sobre proxies para contêineres Docker.
Passo 3. Três armadilhas que roubam a sua noite
Armadilha 1: o registro das variáveis faz a diferença
Isso não é óbvio e quase nunca aparece em tutoriais. O n8n processa variáveis que terminam com _PROXY através do pacote npm proxy-from-env, que impõe sua própria ordem de prioridade: as versões minúsculas (http_proxy) têm prioridade sobre as maiúsculas (HTTP_PROXY), se ambas estiverem definidas. Um cenário clássico de dor: um https_proxy esquecido está na sua configuração há muito tempo, você cuidadosamente define HTTPS_PROXY no compose — e o tráfego teimosamente continua indo para o antigo endereço. Verifique ambos os registros.
Um detalhe separado para Enterprise: a variável de proxy para solicitações ao servidor de licenças https_proxy_license_server deve ser apenas em minúsculas, no formato https://user:pass@proxy:port.
Armadilha 2: o Code node não faz o que você imaginou
Um conselho comum em fóruns é "escreva sua solicitação no Code node usando um agente proxy com axios". Por padrão, isso não funcionará: o n8n desativa a importação de módulos no Code node. É necessário permitir explicitamente — NODE_FUNCTION_ALLOW_BUILTIN para módulos internos e NODE_FUNCTION_ALLOW_EXTERNAL para externos (de n8n/node_modules). Um detalhe adicional: se você tiver task runners em modo externo, essas variáveis são definidas não no ambiente do contêiner, mas na configuração dos runners /etc/n8n-task-runners.json como env-override. É mais simples e seguro permanecer na opção padrão de Proxy no nó.
Armadilha 3: proxy existe, mas a taxa permanece a mesma
O proxy muda o endereço, mas não o comportamento. Se o workflow ainda emite uma enxurrada de solicitações, você simplesmente queimará novos IPs. No mesmo nó, existem controles embutidos:
- Batching — Items per Batch (quantos itens por lote) e Batch Interval em milissegundos (
0= sem pausa). Defina o lote entre 1–5 e o intervalo entre 1000–3000 ms. - Timeout — em milissegundos; canais residenciais são mais lentos do que os de data center, o padrão deve ser elevado.
- Response → Never Error — não derruba todo o workflow no primeiro 403, permitindo processar o código de resposta com ramificações.
- Pagination — modos Update a Parameter e Response Contains Next URL em vez de loops feitos à mão.
No nível da instância, a taxa é limitada por N8N_CONCURRENCY_PRODUCTION_LIMIT (por padrão -1, ou seja, sem limite) — um valor razoável protegerá tanto o pool de proxies quanto o próprio servidor. Mais detalhes sobre como as plataformas contam suas solicitações e o que fazer com os limites estão na análise sobre como contornar o rate limiting através de proxies.
Quais proxies usar para n8n
A escolha depende não da "qualidade", mas de quem está do outro lado.
- Data center. Barato e rápido. Serve para APIs oficiais, serviços internos, sites amigáveis a bots e qualquer tarefa que precise apenas de um endereço estável e estático — por exemplo, para que seu IP seja incluído na lista branca de um parceiro. Em plataformas protegidas, eles dão exatamente o mesmo 403 que um VPS nu: seus intervalos são conhecidos. Esta é a base para tarefas em lote sem anti-bot.
- Residenciais. Endereços de provedores residenciais reais — o que é necessário para coleta de dados em sites com proteção rigorosa, para conteúdo dependente de geolocalização e monitoramento de preços. Para workflows que acessam sites públicos, proxies residenciais são o padrão funcional: use rotação por solicitação para scraping em massa e sessões sticky quando precisar manter uma sessão em uma cadeia de nós.
- Móveis. O mais alto nível de confiança: por trás de um operador estão milhares de assinantes reais, banir tal IP é caro para a plataforma. Justificam-se onde as restrições são mais severas — trabalho com redes sociais e mensageiros. Em troca, você paga por velocidade e preço.
Um esquema prático em um workflow misto: APIs oficiais — diretamente ou através de data centers, sites públicos — através de residenciais, redes sociais — através de móveis. A opção Proxy é configurada em cada nó separadamente, então você pode combinar tudo isso em um único cenário sem gambiarras.
Checklist antes de iniciar
- Proxy definido — seja pela opção Proxy no nó, seja através de
HTTPS_PROXY; no Cloud, apenas a primeira opção está disponível. - Verificados ambos os registros das variáveis — minúsculas sobrepõem as maiúsculas.
NO_PROXYcobre localhost, banco de dados e hosts internos.- User-Agent substituído:
N8N_ENFORCE_GLOBAL_USER_AGENT=trueou seu próprio cabeçalho no nó. Aproveite para verificar a consistência dos outros cabeçalhos — um conjunto inconsistente de cabeçalhos revela automação tão bem quanto o próprio User-Agent. - Batching ativado com intervalo não nulo.
- Teste realizado com 3–5 itens, e não com toda a lista.
Conclusão
Um 403 no n8n — quase sempre não é uma única razão, mas a soma de três: User-Agent reconhecível, IP de data center e uma taxa de solicitações muito uniforme. Isso também é tratado como um conjunto, e não com um único clique: substitua o UA, redirecione o tráfego através do proxy do tipo certo e desacelere o nó através do Batching. Todos os três alavancas já estão embutidos na plataforma — basta encontrá-los e ativá-los.
Comece mais facilmente com um canal residencial nos nós mais problemáticos e um de data center nos demais: o pagamento na ProxyCove é baseado no tráfego, portanto, para testes, você pode adquirir um volume mínimo e observar como seu workflow específico se comporta. Escolher um proxy para a tarefa e inserir a string no campo Proxy é questão de minutos.
```