Como configurar um forward proxy com nginx (HTTP + HTTPS)

Um forward proxy com nginx é um servidor nginx configurado para retransmitir as requisições de saída de um cliente para destinos externos, agindo em nome do cliente em vez de em nome de um servidor de origem. Este tutorial mostra como construir um forward proxy com nginx funcional tanto para HTTP quanto para HTTPS, testá-lo com curl, adicionar controle de acesso e encadeá-lo a um pool residential quando o IP de um único servidor não basta.

Ao final você terá uma configuração de forward proxy com nginx pronta para rodar e uma noção honesta de onde o nginx sozinho deixa de ser a ferramenta certa.

A DataImpulse é um provedor de proxies ético que oferece mais de 90 milhões de endereços IP residential, mobile e datacenter em 195 países. Usa um modelo de pagamento por uso a partir de 1 dólar por GB com tráfego que não expira, e é usada para web scraping, verificação de anúncios, monitoramento de preços, pesquisa de mercado e gestão de múltiplas contas.

O que é um forward proxy com nginx em comparação com um reverse proxy?

Um forward proxy fica na frente dos clientes e encaminha as requisições deles para qualquer destino, enquanto um reverse proxy fica na frente dos servidores e aceita as requisições de entrada em nome deles. A direção do tráfego é toda a diferença.

Tenha em mente este destaque, porque a maioria dos tutoriais de nginx descreve o caso reverse:

• Forward proxy. O cliente é configurado para enviar o tráfego através dele, o que oculta o cliente do alvo. É o que você define com curl -x ou no campo de proxy de um navegador.
• Reverse proxy. O cliente se conecta normalmente a um hostname público; o nginx roteia a requisição para um pool de backend atrás dele, e o cliente nunca sabe que existe um proxy.

Para uma comparação mais aprofundada, veja nosso guia sobre reverse proxy vs forward proxy. O restante deste artigo cobre apenas o caso forward.

O que você precisa antes de começar?

Você precisa de um servidor Linux com um IP público, nginx instalado e, para HTTPS, uma build do nginx que inclua o módulo CONNECT. O encaminhamento de HTTP simples funciona em qualquer nginx padrão.

Verifique se o seu binário já tem suporte a CONNECT:

nginx -V 2>&1 | grep -o proxy_connect
# empty output means the module is not compiled in

O nginx padrão não tem nenhuma diretiva para o método HTTP CONNECT que a tunelização de HTTPS exige, então navegadores e curl não conseguem tunelar TLS através de uma build sem modificações. Para adicioná-lo, aplique o patch e recompile o nginx com o módulo de código aberto ngx_http_proxy_connect_module:

git clone https://github.com/chobits/ngx_http_proxy_connect_module
cd nginx-1.27.0
patch -p1 < ../ngx_http_proxy_connect_module/patch/proxy_connect_rewrite_102101.patch
./configure --add-module=../ngx_http_proxy_connect_module
make && make install

Combine o arquivo de patch com a sua versão do nginx; o repositório do módulo lista qual patch corresponde a cada release.

Como configurar um forward proxy com nginx passo a passo?

Defina um bloco server dedicado que escute em uma porta de proxy, configure um resolver de DNS e encaminhe cada requisição para o host que o cliente pediu. Comece com HTTP simples e depois adicione as diretivas CONNECT para HTTPS.

Esta é uma configuração mínima de nginx como forward proxy para tráfego HTTP:

server {
    listen 8888;
    resolver 1.1.1.1 ipv6=off;

    location / {
        proxy_pass http://$http_host$request_uri;
        proxy_set_header Host $http_host;
        proxy_buffers 256 4k;
    }
}

A linha resolver é importante porque o nginx resolve o host de destino dinâmico no momento da requisição. Agora estenda o mesmo bloco para tunelar HTTPS com o método CONNECT. Este exemplo de forward proxy https com nginx habilita o CONNECT e o restringe às portas TLS padrão:

server {
    listen 8888;
    resolver 1.1.1.1 ipv6=off;

    proxy_connect;
    proxy_connect_allow            443 563;
    proxy_connect_connect_timeout  10s;
    proxy_connect_read_timeout     10s;
    proxy_connect_send_timeout     10s;

    location / {
        proxy_pass http://$http_host$request_uri;
        proxy_set_header Host $http_host;
    }
}

Um forward proxy aberto é um risco, então limite-o a clientes conhecidos. A lista de permissões por IP é o controle mais simples:

location / {
    allow 198.51.100.0/24;
    deny  all;
    proxy_pass http://$http_host$request_uri;
}

Para acesso baseado em credenciais em vez de regras por IP, combine o nginx com uma camada de autenticação; nosso guia de proxy authentication cobre a abordagem de usuário e senha e o handshake HTTP 407 por trás dela.

Como verificar se o forward proxy com nginx funciona e corrigir erros comuns?

Aponte o curl para o proxy com a flag -x e solicite um serviço de eco de IP; uma resposta que mostre o IP público do servidor proxy confirma que o tráfego está passando por ele. Teste HTTP e HTTPS separadamente.

curl -x http://203.0.113.10:8888 http://httpbin.org/ip
curl -x http://203.0.113.10:8888 https://httpbin.org/ip

Adicione um formato de log para poder ver cada requisição encaminhada e seu destino upstream enquanto depura:

log_format proxy '$remote_addr [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 'upstream=$upstream_addr';
access_log /var/log/nginx/forward_proxy.log proxy;

Quando um teste falha, percorra as causas habituais:

• HTTPS retorna 400 ou trava. O módulo CONNECT não está compilado, ou falta o proxy_connect. Reveja o nginx -V.
• Erros 502 ou de resolução. A diretiva resolver está ausente ou aponta para um servidor DNS inacessível.
• 403 para clientes permitidos. O IP que faz a requisição está fora do seu intervalo allow.
• 407 Proxy Authentication Required. Um upstream espera credenciais; veja o erro HTTP 407.

Como encadear o nginx a um pool de residential proxies?

Encadeie o nginx a um proxy upstream encaminhando o tráfego dele para um gateway residential que carregue um cabeçalho Proxy-Authorization. Essa é a ponte que transforma o IP estático de um servidor em acesso a um pool rotativo de IPs reais.

Pense no design como uma topologia de proxy de 3 camadas, onde nomear as camadas mantém claras as fronteiras de confiança e de rotação:

• Camada 1, cliente. Seu script ou navegador, configurado com -x para usar o nginx.
• Camada 2, forward proxy com nginx. Controle central, logging e regras de acesso em um IP que é seu.
• Camada 3, pool residential. Rotação e geo-targeting por muitos IPs reais, algo que o nginx não pode oferecer sozinho.

Um repasse mínimo para o gateway de residential proxies fica assim, onde o token Basic é a codificação em base64 do seu login:password:

server {
    listen 8890;

    location / {
        proxy_pass http://gw.dataimpulse.com:823;
        proxy_set_header Proxy-Authorization "Basic bG9naW46cGFzc3dvcmQ=";
        proxy_set_header Host $http_host;
    }
}

Seja honesto sobre o trade-off: para pura rotação, apontar seu cliente direto para gw.dataimpulse.com:823 é mais simples do que adicionar um salto de nginx. A configuração encadeada se justifica apenas quando você quer o nginx no meio para logging centralizado, caching ou controle de acesso compartilhado em uma equipe.

Qual configuração de proxy combina com o seu trabalho?

Use um forward proxy com nginx sozinho quando você controla os clientes e um único IP de saída basta; adicione um pool residential quando precisar de rotação, cobertura geográfica ou resistência a bloqueios. A decisão se resume a quantos IPs distintos o seu trabalho exige.

Aqui está a matriz de decisão em termos simples:

• Use o forward proxy com nginx sozinho quando você está centralizando o tráfego de saída, filtrando ou registrando requisições, ou compartilhando um único IP de saída em uma equipe interna.
• Evite o nginx sozinho quando um alvo aplica rate-limit ou bloqueia por IP, ou quando você precisa que as requisições venham de muitos países; o nginx encaminha a partir do IP de um único servidor e não pode rotacionar.

A comparação abaixo coloca os dois lado a lado.

Para automação mais pesada, nosso guia de boas práticas de web scraping cobre rotação e controle de ritmo, enquanto os datacenter proxies ou os mobile proxies se encaixam em trabalhos onde o custo ou os IPs de operadora importam mais do que a fidelidade residential.

Quais são as limitações e os riscos de um forward proxy com nginx?

Um forward proxy com nginx tem limites reais: ele encaminha a partir de um único IP, o suporte a HTTPS não vem embutido e uma instância aberta é um risco de segurança. Conhecê-los mantém as expectativas honestas.

• Um único IP, sem rotação. Toda requisição sai do mesmo endereço de servidor, então qualquer alvo que limite por IP vai reduzir sua velocidade ou banir você rapidamente.
• HTTPS exige uma build personalizada. A tunelização CONNECT depende de um módulo externo e de um patch compatível com a versão, o que complica as atualizações.
• Perigo de proxy aberto. Sem regras allow ou autenticação, qualquer um que encontre a porta pode rotear tráfego através do seu servidor, expondo você a abusos e a risco legal.
• Sem cobertura geográfica. A localização de saída fica fixada onde o servidor roda, então testes específicos por região precisam de mais servidores, e você fica responsável por todo o patching, monitoramento e uptime.

o nginx não é um produto da DataImpulse, e a DataImpulse não vende uma scraping API gerenciada nem um web proxy gratuito. Onde o nginx se encaixa, rode você mesmo; onde você precisa de escala, a DataImpulse obtém seus IPs como ethical proxies de usuários que optam por participar e são compensados.

Perguntas frequentes

Guias relacionados

• Reverse proxy com NGINX
• Rotating proxies no Scrapy
• Quanto custam os proxies

Precisa de uma rotação que o nginx não pode dar?

Quando o IP de um único servidor não basta, a DataImpulse adiciona mais de 90M de IPs rotativos residential, mobile e datacenter em 195 países, pagamento por uso a partir de um dólar por GB com tráfego que não expira. Crie uma conta para obter as credenciais do gateway e rotear seu nginx ou seu cliente direto para o pool.