Devo rotear todo o n8n pelo proxy?

Não. Roteie apenas as chamadas externas que precisam de IP dedicado. Tráfego interno — banco de dados, webhooks locais, comunicação entre containers — deve ficar fora do proxy, senão você adiciona latência sem ganho.

Preciso reiniciar o n8n depois de configurar?

Sim, quando a configuração é por variável de ambiente. Configuração por nó vale a partir da próxima execução.

Dá para usar proxies diferentes em nós diferentes?

Sim, configurando o proxy nas opções de cada nó HTTP Request em vez de globalmente. É o caminho para workflows que atendem clientes distintos.

O proxy funciona com nós prontos (Google, Slack, etc.)?

Nós prontos usam o cliente HTTP interno, então respeitam a variável de ambiente global. Configuração por nó só está disponível em nós HTTP Request genéricos.

Como usar proxy no n8n (nós HTTP e automações)

O n8n usa o cliente HTTP do Node por baixo, o que significa que ele respeita as variáveis de ambiente padrão de proxy. Isso dá dois caminhos de configuração, com trade-offs diferentes.

Antes de decidir: o que rotear

Este é o ponto que mais gera dor de cabeça. O n8n faz vários tipos de tráfego:

Tipo de tráfego	Rotear pelo proxy?
Chamadas a APIs externas	Sim, quando precisa de IP dedicado
Coleta de páginas web	Sim
Banco de dados (Postgres, MySQL)	Não
Webhooks internos	Não
Comunicação entre containers	Não
Redis / fila	Não

Rotear o tráfego interno pelo proxy adiciona latência, consome recurso e não traz benefício nenhum. Pior: pode quebrar a conexão com o banco.

Opção 1 — Variável de ambiente (global)

Aplica a todos os nós que fazem chamada HTTP, incluindo os nós prontos de integração.

export HTTP_PROXY="http://usuario:[email protected]:8000"
export HTTPS_PROXY="http://usuario:[email protected]:8000"
export NO_PROXY="localhost,127.0.0.1,postgres,redis,n8n"

A variável NO_PROXY é a parte crítica. Ela lista o que não deve passar pelo proxy — e é aqui que você protege o tráfego interno. Inclua os nomes de host dos seus containers.

Em Docker Compose:

services:
  n8n:
    image: n8nio/n8n:latest
    environment:
      - HTTP_PROXY=http://usuario:[email protected]:8000
      - HTTPS_PROXY=http://usuario:[email protected]:8000
      - NO_PROXY=localhost,127.0.0.1,postgres,redis
      - N8N_HOST=seu-dominio.com
    depends_on:
      - postgres

Reinicie o container depois de alterar as variáveis.

Opção 2 — Por nó (granular)

Melhor quando só algumas requisições precisam do proxy, ou quando workflows diferentes usam proxies diferentes.

No nó HTTP Request, abra Options → Proxy e informe:

http://usuario:[email protected]:8000

Vantagem: controle total, sem afetar o resto da instância. Desvantagem: precisa ser configurado em cada nó, e nós prontos de integração não oferecem esse campo.

Opção 3 — Proxies diferentes por cliente

Se você atende vários clientes no mesmo n8n, use uma variável por cliente e monte a URL dinamicamente.

Em um nó Code antes da requisição:

const proxies = {
  'cliente-a': 'http://user_a:[email protected]:8000',
  'cliente-b': 'http://user_b:[email protected]:8000',
}

return items.map(item => ({
  json: {
    ...item.json,
    proxyUrl: proxies[item.json.cliente],
  },
}))

E no nó HTTP Request, use {{ $json.proxyUrl }} no campo de proxy.

Valide com um workflow de teste

Antes de colocar em produção, monte um workflow mínimo:

Nó Manual Trigger
Nó HTTP Request apontando para https://ipinfo.io/json
Execute e confira a resposta

O IP retornado deve ser o que você contratou, com country: "BR". Se aparecer o IP do servidor, o proxy não está sendo aplicado.

Guarde esse workflow. Ele vira sua ferramenta de diagnóstico quando algo mudar.

Senha com caractere especial

Se a senha contém @, :, / ou #, codifique dentro da URL: @ vira %40, : vira %3A, / vira %2F, # vira %23.

O @ é o caso crítico, porque é o separador entre credencial e host na estrutura da URL.

Problemas comuns

n8n não sobe depois de configurar o proxy — provavelmente o banco de dados está sendo roteado pelo proxy. Adicione o host do banco em NO_PROXY.

Webhooks pararam de funcionar — tráfego de entrada não passa por proxy de saída, mas se você roteou tudo, chamadas internas de retorno podem estar quebradas. Revise o NO_PROXY.

Alguns nós usam o proxy e outros não — comportamento esperado quando você mistura configuração global e por nó. A configuração do nó tem precedência.

Erro de autenticação — senha com caractere especial não codificado, ou credencial com espaço extra.

Tudo lento depois da mudança — você está roteando tráfego interno. Ajuste o NO_PROXY.

Quando você precisa de IP dedicado no n8n

Não é sempre. Vale quando:

A API de destino limita requisições por IP e você compartilha o IP do provedor de nuvem
Você precisa que as chamadas venham do Brasil
O workflow acessa contas que devem parecer independentes entre clientes
O IP do seu provedor de nuvem já está com histórico ruim

Se o workflow só chama APIs públicas sem limite relevante, o IP do servidor resolve e não há motivo para adicionar proxy.

Proxy no n8n