Toda automação que fala com a internet sai por algum endereço IP. A pergunta que decide a arquitetura não é "qual proxy comprar", é o que essa automação está automatizando: uma identidade ou um volume.
As duas respostas levam a IPs opostos. Automação de identidade quer o mesmo endereço para sempre. Automação de volume quer muitos endereços e não se importa com qual. Montar a segunda com o produto da primeira (ou o contrário) é a causa mais comum de conta derrubada e de fatura estourada.
Automação de identidade: um IP fixo por conta
Aqui a automação age em nome de alguém: publica, responde, gerencia anúncios, mantém uma sessão de WhatsApp, opera um painel. A plataforma do outro lado associa aquela conta a um histórico, e a origem de rede faz parte desse histórico.
A unidade de compra é a conta, não a requisição. Um IP exclusivo e fixo por identidade, mantido no tempo. Na sessão de WhatsApp, esse IP deve ser um ISP, que passou no nosso teste de conexão ao WhatsApp. Trocar de endereço toda hora, ou colocar dez contas atrás do mesmo IP de datacenter compartilhado, é o que transforma uma operação organizada em padrão suspeito — a lógica está em um IP por conta.
Nesse grupo entram bots que operam contas, automações de mensagem e os perfis de navegador de proxy por contexto no Playwright, onde cada contexto carrega o seu próprio endereço dentro do mesmo processo.
O detalhe que mais derruba esse tipo de automação não é o endereço em si, e sim refazer o login a cada execução em vez de reaproveitar a sessão. O padrão correto está em automação que loga em conta.
Automação de volume: distribuir requisições e pagar por GB
Aqui a automação lê páginas públicas: preços, catálogos, editais, conteúdo para alimentar um modelo. Não há conta, não há login, não há identidade a preservar. O que existe é um servidor do outro lado contando quantas requisições vieram de cada endereço.
A unidade de compra passa a ser o tráfego. Você quer muitos endereços residenciais, cobrados por GB, e a métrica que importa é quanto cada página custa em bytes — assunto de consumo de GB no scraping. Quando o limite por origem estoura, o servidor responde erro 429, e a saída é respeitar o Retry-After e distribuir, não insistir mais rápido.
A coleta para modelos de IA é o caso novo desse grupo, com Crawl4AI e IP brasileiro, onde o proxy é configurado por requisição e a economia vem de pedir páginas mais leves.
Nunca misture os dois no mesmo endereço. O volume da coleta queima a reputação do IP que sustenta as contas logadas.
Onde cada ferramenta lê o proxy
O erro que mais aparece no suporte não é escolher o IP errado: é configurar o proxy num lugar que a ferramenta não lê, e a automação sair pelo IP do servidor sem ninguém perceber.
| Ferramenta | Onde o proxy entra |
|---|---|
Python (requests, httpx) |
Por sessão ou por requisição — proxy no Python requests |
| Selenium | Nas opções do driver, antes de abrir o navegador — proxy no Selenium |
| Playwright | No lançamento ou em cada contexto — proxy por contexto |
| Puppeteer e navegador headless | Argumento de linha de comando — proxy em automação de navegador |
| n8n | Na credencial ou no nó de requisição — proxy no n8n |
| Crawl4AI | Por requisição, na configuração da execução — Crawl4AI com IP brasileiro |
Em todos eles a autenticação é por usuário e senha, e o protocolo pode ser HTTP ou SOCKS5.
Entre as três ferramentas de navegador, a diferença que mais pesa na escolha é justamente o suporte a proxy com credencial — nativo em uma delas e trabalhoso nas outras. A comparação está em Selenium, Puppeteer ou Playwright.
Valide a origem antes de rodar em produção
Antes de disparar a automação de verdade, faça o script pedir o próprio IP e conferir o retorno. É um passo de trinta segundos que evita descobrir o vazamento depois de mil requisições — dá para conferir na ferramenta meu IP ou dentro do próprio código.
Se o endereço que volta é o do seu servidor, o proxy não está sendo lido. Se é o esperado, registre-o: quando uma conta reclamar de origem estranha, você vai querer saber por onde ela saiu naquele dia.
O que o proxy não resolve
Proxy é camada de rede. Ele muda a origem — e só.
- Limite por conta ou por token. Quando a plataforma conta requisições por chave de API ou por bot, trocar de IP não muda nada. É o caso dos limites de envio do bot de Telegram.
- Impressão digital do navegador. Fuso, idioma, fontes e resolução continuam iguais depois de trocar o endereço. Isso é assunto de navegador antidetect.
- Comportamento. Ritmo humano, horários, sequência de ações. Nenhum IP compensa uma automação que age como máquina onde se espera uma pessoa.
- Termos de uso. Se a plataforma proíbe automação naquele fluxo, o proxy não torna a prática permitida. Vale a nossa política de uso aceitável.
Quantos IPs, na prática
| A automação | Unidade | Tipo de IP |
|---|---|---|
| Opera 1 conta | 1 conta | 1 IPv4 ou ISP fixo |
| Opera 10 contas | 10 contas | 10 endereços fixos, um por identidade |
| Lê 50 mil páginas públicas por mês | Tráfego | Residencial por GB, rotação automática |
| Consulta uma API oficial com chave | Nenhuma | Em geral nenhum proxy |
| Precisa de origem brasileira estável para um integrador | 1 sistema | 1 IP fixo, informado na lista de permissões do parceiro |
Se a rotação te confunde, proxy rotativo: IP fixo, por sessão ou por requisição separa os três modos.
Por onde começar
Se a automação opera contas, o caminho é proxy para automação com endereços fixos. Se ela coleta em volume, olhe o residencial por GB. Se ela alimenta um modelo, proxy para agentes de IA trata do caso.
Em dúvida sobre o tipo, o recomendador em quatro perguntas resolve mais rápido que ler os quatro produtos.