A automação de navegador — Chrome headless, Playwright, Puppeteer, Selenium — se conecta ao proxy de um jeito diferente de um cliente HTTP comum: o endereço é definido nos parâmetros de inicialização do driver, e não nas configurações do sistema operacional. Um erro nessa ligação entrega o bot antes mesmo de qualquer configuração antidetect fazer efeito, e a própria automação gasta várias vezes mais tráfego do que parece no início. Vamos ver como o canal se encaixa na cadeia navegador—driver—rede, de onde vem o consumo extra de gigabytes e o que realmente o reduz.

Como o proxy se conecta ao navegador headless e ao driver

No navegador headless, o endereço não é «do sistema»: ele fica nos parâmetros de inicialização. No Chromium é a flag «--proxy-server=host:port», no Playwright e no Puppeteer é o campo proxy nas opções do contexto, no Selenium é o objeto Proxy nas capabilities do driver. A configuração do sistema redireciona todo o tráfego da máquina, inclusive os processos em segundo plano; a configuração no nível do driver vale apenas dentro da sessão do navegador — e é isso que você precisa quando dezenas de perfis com endereços diferentes rodam em paralelo na mesma máquina.

A autenticação é feita com login e senha na URL (funciona no Playwright e no Puppeteer pelos parâmetros do contexto, mas não ao iniciar o Chromium só com a flag) ou com vínculo ao IP branco do servidor de automação. O segundo método é mais confiável para um runner de CI com endereço de saída fixo: não é preciso guardar a senha do proxy em variáveis de ambiente.

Por que a automação consome mais tráfego do que parece

Uma pessoa, ao rolar a página, vê só a parte de cima da tela. O driver, por padrão, carrega a página inteira: fontes (centenas de kilobytes por família), scripts de analytics e de redes de anúncios, pixels de retargeting, websockets de chats de suporte. Nenhum desses elementos é necessário para checar um preço ou um texto, mas todos são baixados junto com o conteúdo-alvo.

Na página de um produto, os dados úteis — o HTML com preço e características — pesam dezenas de kilobytes, enquanto os outros 2–5 MB da página são imagens, fontes e scripts de terceiros, dos quais a tarefa nem toma conhecimento. É esse o excedente pago por um tráfego que nunca chegará ao resultado. Uma análise detalhada do que desativar e de como calcular a economia passo a passo está no artigo como reduzir o consumo de GB no proxy.

Desativar mídia é o principal jeito de economizar

A principal alavanca de economia é bloquear, no nível do driver, tudo o que não entra no resultado do parsing, em vez de escolher um canal mais barato. No Playwright e no Puppeteer isso é feito interceptando as requisições e cancelando os tipos image, media, font e, às vezes, stylesheet. No Selenium com Chrome, o mesmo efeito vem de uma configuração de perfil que desativa o carregamento de imagens.

O efeito é uma redução de 3 a 10 vezes no peso da página, dependendo da quantidade inicial de imagens e vídeos. Para tarefas em que só o texto importa — preço, disponibilidade, status do pedido —, bloquear a mídia não afeta o resultado: os dados estão no HTML, e não nas próprias imagens. Correr atrás do canal mais barato em vez de desativar a mídia muitas vezes tem o efeito contrário — a diferença é explicada no artigo proxies baratos versus caros.

Consistência de locale, fuso horário e idioma da requisição com o geo do endereço

Trocar o IP não muda automaticamente nem o locale do navegador, nem o fuso horário do sistema, nem o cabeçalho Accept-Language. Se o endereço é americano, mas o contexto informa o fuso Europe/Moscow e o idioma russo, a plataforma recebe sinais contraditórios. Algumas plataformas entregam o conteúdo de acordo com o idioma do cabeçalho, e não com o IP, de modo que a dessincronização altera os próprios resultados exibidos, e não apenas torna a sessão mais suspeita.

No Playwright e no Puppeteer, locale, timezoneId e os cabeçalhos são definidos nas opções do contexto ao criar a página e devem ser sincronizados com o geo do endereço a cada inicialização, e não uma única vez para todos os perfis de uma só vez. O checklist da combinação «perfil mais canal», incluindo a verificação de WebRTC e DNS, está no artigo proxy para navegador antidetect passo a passo.

Perfis paralelos e uma porta separada por perfil

Quando a automação inicia vários perfis ao mesmo tempo, uma única porta para todos cria dois problemas. Um deles é de rede: as sessões dividem a largura de banda e o limite de threads, daí os timeouts e as repetições. O outro é comportamental: se o provedor troca o IP de saída em uma porta durante a reconexão, a plataforma vê a mudança de endereço dentro da sessão e pode tratá-la como uma anomalia.

A regra é simples: uma porta separada e um endereço estável durante a sessão para cada perfil paralelo. Isso aumenta o número de canais comprados, mas elimina as duas fontes de repetições. Controlar a troca de endereço em cada porta de forma programática, sem remontar a configuração manualmente antes da execução, é possível com a rotação por API — ela é explicada no artigo como configurar a rotação de IP por API.

Perguntas frequentes

Posso usar um único proxy para vários perfis headless ao mesmo tempo?

Tecnicamente sim, mas não vale a pena: sessões paralelas por uma única porta dividem a banda e provocam timeouts, e a plataforma pode interpretar o revezamento de requisições vindas de um só endereço como atividade suspeita. Para execução paralela, use uma porta separada por perfil.

Desativar imagens e fontes não vai quebrar a coleta de dados?

Não, se os dados necessários estão no HTML e não são renderizados como imagem ou elemento canvas. Antes de uma execução em massa, vale rodar a tarefa com a mídia ligada e desligada e comparar o resultado — para preços, disponibilidade e campos de texto, normalmente não há diferença.

Como verificar se o locale e o fuso horário do navegador coincidem com o geo do proxy?

Por meio de qualquer serviço de verificação de fingerprint do navegador — ele mostra o IP, o país, o fuso horário e o idioma que o site enxerga. A verificação deve ser incorporada ao próprio script de automação como primeiro passo antes da tarefa principal, e não feita manualmente de vez em quando.

Uma porta separada para cada perfil de automação, autenticação por IP branco para CI e a escolha do canal conforme a tarefa — endereços residenciais e móveis cobrados por tráfego ou de datacenter cobrados por mês — estão na seção de proxies.