Guia de configuração de proxy no n8n: configurações de nós, variáveis de ambiente e proxy reverso

Executar workflows n8n a partir de um servidor na nuvem frequentemente aciona limites de taxa. Plataformas de destino bloqueiam solicitações originadas de IPs de datacenter conhecidos. A configuração adequada de proxy n8n restaura a estabilidade operacional. O objetivo principal é garantir uma integração perfeita de proxy de automação diretamente na sua arquitetura.

TL;DR: checklist de configuração de proxy n8n

O nó HTTP Request suporta roteamento isolado sem afetar o ambiente global do contêiner.
A autenticação de proxy n8n para workflows automatizados requer um Generic Credential Type usando um cabeçalho Proxy-Authorization.
O pacote interno proxy-from-env prioriza estritamente variáveis de ambiente em letras minúsculas.
Bancos de dados locais requerem uma definição de variável NO_PROXY para prevenir loopbacks de rede.
Um reverse proxy Apache precisa de roteamento de cabeçalho WebSocket para que a interface do editor funcione.
A variável N8N_PROXY_HOPS=1 resolve erros de detecção de IP do cliente atrás de load balancers.

O que é n8n e por que precisa de proxies

n8n é uma plataforma avançada de automação de workflows. Engenheiros usam seu editor visual baseado em nós para conectar bancos de dados, CRMs e aplicações de terceiros sem escrever código boilerplate pesado. O sistema orquestra dados através de centenas de APIs externas. No entanto, solicitações diretas ao servidor rapidamente esgotam os limites das plataformas de destino. Uma configuração rigorosa de proxy de saída n8n resolve três tarefas operacionais.

Primeiro, distribui a carga de solicitações para escalar limites de taxa de API com segurança.
Segundo, localiza a pegada de rede para acessar dados regionais.
Terceiro, isola ambientes ao gerenciar múltiplos perfis.

👉 O ecossistema CyberYozh App cobre essas necessidades de infraestrutura, oferecendo convenientemente cartões virtuais e números ISP reais para configurações completas de perfil.

Tipos de proxies para workflows de automação n8n

Sua escolha de rede determina a confiabilidade do workflow. Uma configuração de proxy n8n bem-sucedida depende fortemente da seleção do pool de IP correto.

Proxies móveis LTE/5G. Estes roteiam o tráfego através de dispositivos celulares reais. Eles fornecem a maior Taxa de Confiança para operações em plataformas sociais.
Proxies residenciais estáticos ISP. Endereços fixos de provedores de internet residenciais reais. Eles mantêm sessões longas para raspagem contínua de dados.
Proxies residenciais rotativos. Uma rede global de milhões de endereços. O recurso de Sticky session mantém um único IP por até 24 horas para tarefas escaláveis.
Proxies de datacenter. Servidores dedicados otimizados para processos analíticos de alta velocidade.

👉 O CyberYozh App fornece todos esses tipos de rede com controle por API e segmentação geográfica gratuita.

Como configurar proxy para o nó de requisição HTTP do n8n

Parâmetros globais frequentemente entram em conflito com handshakes TLS. O roteamento isolado resolve isso. Engenheiros configuram os parâmetros de proxy do nó HTTP Request do n8n diretamente dentro da interface do nó. Isso permite alterar configurações dinamicamente. Você evita restrições de ambiente global completamente.

Abra a interface do nó. Expanda a seção Options. Ative a opção Proxy e insira a URL do seu host como http://IP:PORT. A autenticação integrada padrão frequentemente descarta credenciais. Selecione Generic Credential Type e crie um novo registro Header Auth. Defina o Name como Proxy-Authorization. Ferramentas como cURL codificam credenciais de forma invisível, mas o n8n requer um cabeçalho explícito. Para o campo Value, use a expressão integrada do n8n para codificar suas credenciais do CyberYozh automaticamente:

javascript

={{'Basic ' + $btoa('your_username:your_password')}}

Processos de múltiplas etapas precisam de retenção de contexto e gerenciamento de sessão estável. Proxies residenciais rotativos exigem manter um único endereço IP em várias requisições. O painel do CyberYozh possui um gerador de proxy integrado para lidar com isso automaticamente. Selecione a configuração Custom duration (Sticky session) e defina seu período de tempo (até 24 horas). O sistema gera credenciais vinculadas diretamente a essa sessão estável no servidor backend. Você simplesmente codifica esse login e senha específicos no cabeçalho Proxy-Authorization dentro do nó HTTP Request.

Validando a arquitetura: Testando a conexão de proxy em workflows do n8n

Antes de colocar sua configuração de proxy do n8n em produção, construa um workflow de teste simples. Aponte um nó HTTP Request para uma API externa de identificação de IP (como api.ipify.org) usando uma requisição GET. Verifique a saída JSON. O serviço de destino deve ver o IP do proxy alugado, não o endereço IP da sua instância do n8n.

👉 O verificador de Fraud Score do CyberYozh avalia a qualidade do seu IP em relação a bancos de dados como ThreatMetrix e PerimeterX antes de você lançar. Isso ajuda a evitar que APIs de destino rejeitem suas requisições.

Infraestrutura global: variáveis de ambiente de proxy do n8n

Uma configuração de proxy do n8n em todo o contêiner depende da definição de parâmetros no seu arquivo .env. O CyberYozh usa autenticação padrão de nome de usuário e senha. Você passa essas credenciais diretamente dentro da string de URL. O núcleo do n8n lê esses parâmetros usando o pacote Node.js integrado proxy-from-env. Esta biblioteca impõe uma hierarquia estrita: variáveis em minúsculas sempre têm precedência sobre as em maiúsculas. Se você definir HTTPS_PROXY, mas o sistema operacional host tiver uma variável https_proxy vazia por padrão, o n8n ignora suas regras de roteamento completamente. Sempre defina ambos os estilos de formatação para garantir o roteamento bem-sucedido:

HTTP_PROXY=http://username:password@IP:PORT

HTTPS_PROXY=http://username:password@IP:PORT

http_proxy=http://username:password@IP:PORT

https_proxy=http://username:password@IP:PORT

ALL_PROXY=http://username:password@IP:PORT

Você deve configurar NO_PROXY. Inclua localhost, 127.0.0.1 e suas sub-redes Docker internas para manter conexões com bancos de dados PostgreSQL ou Redis locais. Caso contrário, esse tráfego interno atinge o gateway externo e expira. Definir NO_PROXY=* desabilita instantaneamente todos os proxies em todo o contêiner. Consulte a documentação oficial do n8n para a lista completa de variáveis de ambiente para ajustar sua infraestrutura de contêiner geral.

Tráfego de entrada: configuração de reverse proxy Apache do n8n

Servidores Apache ou Nginx lidam com a terminação SSL. Eles descriptografam o tráfego de entrada e o roteiam para dentro do contêiner na porta local 5678. Esta topologia cria dois problemas estruturais.

Primeiro, rotear webhooks do n8n através do reverse proxy Apache quebra os links da interface porque a aplicação pensa que seu endereço base é localhost. Corrija isso injetando a variável N8N_EDITOR_BASE_URL. Defina-a para seu domínio público exato (como https://n8n.cyberyozh.com). Formatos de variáveis mais antigos como WEBHOOK_URL estão obsoletos e vão gerar avisos do sistema.

Segundo, logs internos veem apenas o IP do servidor Apache. Listas de controle de acesso integradas param de funcionar. Adicione a variável N8N_PROXY_HOPS=1. Ela força o núcleo Express.js a confiar em cabeçalhos externos.

A interface do editor depende de WebSockets. Seu servidor deve interceptar e encaminhar essas requisições. Sem eles, a interface do editor vai congelar ciclicamente e perder a conexão. Adicione as seguintes diretivas dentro do seu bloco VirtualHost do Apache para garantir atualizações de protocolo transparentes e encaminhamento de IP real do cliente:

ProxyPreserveHost On

RequestHeader set X-Forwarded-Proto "https"

RewriteEngine On

RewriteCond %{HTTP:Upgrade} =websocket [NC]

RewriteRule /(.*)           ws://localhost:5678/$1 [P,L]

ProxyPass / http://localhost:5678/

ProxyPassReverse / http://localhost:5678/

Matriz de solução de problemas

Sintoma / Erro	Causa Provável	Solução de Engenharia
HTTP Request retorna 407 Proxy Authentication Required	Formato de credencial incorreto.	Mude para Generic Credential Type. Use Header Auth com um cabeçalho Proxy-Authorization.
Erro ECONNRESET ao acessar recursos HTTPS	Limitações do HTTP CONNECT da biblioteca Axios.	Use roteamento de proxy granular dentro das configurações do nó HTTP Request.
Links da UI do Webhook mostram http://localhost:5678	A aplicação está isolada atrás de um proxy reverso.	Injete N8N_EDITOR_BASE_URL=https://[domínio] no ambiente Docker. Não use variáveis legadas obsoletas.
O Editor lança erros cíclicos de Connection lost	Apache descarta conexões WebSocket.	Adicione diretivas de cabeçalho Upgrade e Connection à configuração do Apache.
Variáveis de proxy globais são ignoradas	Conflito de prioridade do proxy-from-env.	Declare os formatos em minúsculas e maiúsculas no docker-compose.yml.
Bancos de dados locais retornam timeouts	Tráfego interno atinge gateways externos.	Defina NO_PROXY com localhost e sub-redes Docker.

A orquestração de dados depende completamente da qualidade da pilha de transporte. Uma configuração de proxy n8n bem planejada previne falhas de handshake. Configurações granulares do nó HTTP Request e declarações explícitas de variáveis de ambiente eliminam conflitos de prioridade. Usar a infraestrutura CyberYozh garante consistência de sessão. Você obtém execução de pipeline previsível em qualquer escala.

Perguntas frequentes sobre configuração de proxy n8n

Como corrigir o erro "ValidationError: The X-Forwarded-For header is set"?

Isso acontece atrás de um proxy reverso. O núcleo Express.js rejeita cabeçalhos externos por padrão. Adicione N8N_TRUST_PROXY=true e N8N_PROXY_HOPS=1 à sua configuração Docker. Reinicie o contêiner.

Por que o nó HTTP Request ignora variáveis de ambiente HTTPS_PROXY?

A biblioteca Axios tem dificuldades com tunelamento HTTPS através de gateways HTTP padrão. Configure o roteamento diretamente dentro dos parâmetros do nó HTTP Request. Isso isola a conexão adequadamente.

Como resolver "400 Bad Request: plain HTTP request was sent to HTTPS port"?

O nó está tentando enviar tráfego HTTP para a porta 443. Verifique o protocolo na string da URL de destino. Verifique se não há incompatibilidade de protocolo nas próprias configurações de proxy.

Por que os nós da comunidade ignoram pacotes proxy-from-env?

Muitos nós de terceiros usam bibliotecas de requisição personalizadas. Eles não leem variáveis de ambiente globais. Você deve inserir as configurações de roteamento manualmente dentro dos parâmetros de cada nó personalizado.

Como manter um único IP em um fluxo de trabalho com múltiplos nós?

Use o gerador de credenciais integrado para proxies residenciais rotativos no seu painel CyberYozh. Selecione a configuração Custom duration para inicializar uma Sticky session. O sistema fornece credenciais específicas que bloqueiam sua conexão a um único endereço IP físico pelo período definido.

Quais cabeçalhos Apache impedem que o editor n8n congele?

A interface usa WebSockets para transmitir logs de execução. Configure roteamento transparente para cabeçalhos Upgrade e Connection. O editor lançará erros cíclicos de desconexão sem eles.

Posso rotear tráfego de banco de dados fora do gateway de proxy global?

Sim. Você usa a variável de sistema NO_PROXY. Insira localhost, 127.0.0.1 e suas máscaras de sub-rede Docker internas. Requisições de banco de dados irão contornar o gateway externo.

Como corrigir o erro "connect ECONNREFUSED ::1:11434"?

Isso ocorre quando seu sistema operacional tem IPv6 habilitado, mas um serviço local (como Ollama) escuta apenas em IPv4. Altere o endereço do host nas configurações de conexão do seu nó do alias localhost para o endereço IPv4 explícito: 127.0.0.1.