Proxies rotativos: como funciona a rotação de IP e quando ela interrompe sua tarefa

Um script de monitoramento de preços verificava centenas de páginas todas as noites e funcionou por meses. Depois aumentou a frequência, entrou outra loja e os logs se encheram de respostas 429 e CAPTCHA. Nos fóruns, recomendam um proxy rotativo. A ideia de que mais IPs significam menos bloqueios só é verdadeira pela metade.

O proxy envia solicitações por IPs variáveis atrás de um gateway fixo, distribuindo tráfego abaixo do limite por IP. Mas o endereço pode mudar durante o login e a sessão autenticada frequentemente não resiste. Resolve-se um problema e cria-se outro.

A versão curta

• Um proxy rotativo apresenta um gateway com host e porta, encaminha solicitações por IPs de um pool e usa uma regra para decidir quando trocá-los.
• Rotação por solicitação serve para tarefas sem estado, como obter páginas públicas. Para login e carrinhos, prefira sessões persistentes ou proxy estático, sobretudo quando há verificação de continuidade do IP.
• Um pool pode rotacionar corretamente e falhar: outros clientes desgastam a reputação dos IPs compartilhados. Endereços novos e pouco compartilhados dizem mais sobre sucesso que o tamanho do pool.
• Rotação não resolve limites por conta, token ou cookie. Em baixo volume, reduza o ritmo e respeite Retry-After, que indica quanto esperar.

O que é um proxy rotativo?

O gateway encaminha cada solicitação por um IP do pool. A regra decide a troca: por solicitação, temporizador ou sessão. Host e porta permanecem iguais; o gateway escolhe o endereço visto pelo destino.

Acompanhe uma solicitação pelo gateway:

1. O cliente envia a solicitação sempre ao mesmo host e porta do gateway.
2. O gateway aplica a regra e escolhe um IP do pool.
3. A solicitação sai desse IP e chega ao site de destino.
4. O destino vê o IP de saída. Seu endereço fica oculto, salvo se o gateway o encaminhar em um cabeçalho como X-Forwarded-For.

Pool, verificações de integridade e failover pertencem ao provedor; seu script conhece apenas host e porta. Essa conveniência explica o serviço. Ter seu próprio proxy não oferece rotação grátis: normalmente ele fornece um IP de saída estável; manter o pool é o que você pagaria a terceiros.

Os fornecedores chamam gateway mais pool de proxy backconnect. O guia da MDN sobre servidores proxy usa «gateway» como outro nome, mais simples, para proxy direto. Serem endereços residenciais, de datacenter ou móveis é independente da frequência de troca.

O que determina quando o proxy muda seu IP?

A regra e o provedor determinam a troca: por solicitação ou conexão, janela fixa ou comando explícito. Cliente ou gerenciador também podem trocar antes de repetir uma solicitação bloqueada ou malsucedida. Confira «por solicitação»: várias solicitações HTTPS podem compartilhar túnel e IP. Um gateway que encaminha HTTPS criptografado normalmente não lê o código do destino para iniciar sozinho a rotação.

A tabela mostra uma escolha de distribuição. Espalhar mantém cada IP abaixo do limite; continuidade permite reconhecer um visitante. A rotação por solicitação prioriza inteiramente a distribuição. Após falha, parece um meio-termo resistente, mas esconde custos: os logs mostram sucesso na repetição até nada funcionar. Uma sessão persistente faz o contrário e mantém um IP por uma janela.

Qual a diferença entre sessão persistente, rotação e proxy estático?

Uma sessão persistente reserva temporariamente um IP do pool para que as solicitações pareçam do mesmo visitante, depois o libera. O proxy estático mantém um IP enquanto você o conservar. Rotação por solicitação não reserva nada. A escolha depende da necessidade de reconhecimento entre solicitações.

A rotação por solicitação é habitual em buscas sem estado. Para login, restam as duas opções que mantêm IP; a duração decide. A sessão persistente toma uma IP emprestada e a devolve; o estático continua atribuído e logins diários do mesmo endereço parecem um usuário recorrente. Cada provedor define suas janelas: compare com seu fluxo mais longo. Confira falhas de saída: alguns trocam de IP antecipadamente; modos estritos de IP único falham a solicitação. Uma janela longa, sozinha, não garante continuidade.

Quando a rotação interrompe uma tarefa?

Trocar IP durante login, 2FA, carrinho, checkout ou formulário em etapas pode interromper o fluxo. O cookie não deixa de funcionar automaticamente. Porém, sites que vinculam sessões ao IP ou verificam mudanças de rede contra fraude podem desconectar, pedir novo desafio ou sinalizar a sessão.

Não vejo isso como perseguição a proxies, mas como o site cumprindo sua função. O cookie afirma ser o mesmo navegador de um minuto atrás; o IP fornece evidência verificável. Mudar de rede numa sessão autenticada se parece com reutilizar um cookie roubado em outro lugar, justamente o que sistemas antifraude detectam. Logout e 2FA são respostas proporcionais.

As orientações da OWASP sobre sessões descrevem verificar mudanças de IP e User-Agent durante a sessão. Conforme os controles, uma alteração inesperada pode gerar alerta ou encerramento.

Pergunte se o site precisa lembrar você entre solicitações. Se sim, mantenha um IP no fluxo; se não, rotacione. Monitorar preços públicos à noite não exige isso. Entrar num painel para exportar relatórios exige uma IP do início ao fim.

Dica prática: Separe cargas mistas: pool rotativo para dados sem estado, IP persistente ou estático para login e trabalho autenticado. Necessidades opostas não devem compartilhar a regra.

Por que um pool para de funcionar após alguns dias?

Pode falhar mesmo rotacionando corretamente: muda-se a IP, não sua reputação. Endereços compartilhados herdam atividades anteriores; reutilização intensa nos mesmos sites pode marcá-los e reduzir o sucesso.

O pool é um recurso comum limitado: cada cliente consome sua reputação nos sites. Se outros usam os mesmos IPs nos seus destinos, você paga em CAPTCHA e bloqueios. No suporte, vi a reputação como um ecossistema de sites e listas de bloqueio reagindo ao tráfego observado.

O tamanho do pool, fácil de anunciar, prevê menos do que parece. O resultado depende de:

• Uso recente no mesmo destino: um endereço usado por outro cliente há uma hora já chega contabilizado.
• Quantidade de clientes compartilhando: mais tarefas desgastam a IP mais rápido.
• Diversidade das redes: IPs concentrados em poucas faixas podem ser bloqueados juntos.
• Sinalizações existentes: pools que mantêm IPs considerados abusivos continuam distribuindo-os.

Um pool grande muito reutilizado pode render menos que um pequeno com IPs novos nos seus destinos. Compare o sucesso ao longo do tempo; um primeiro teste bem-sucedido não comprova desempenho sustentado.

Você realmente precisa de um proxy rotativo?

Ele pode distribuir solicitações sob limites por IP, sem substituir o cumprimento de limites e instruções. Segundo a referência 429 da MDN, limites costumam ser por IP, mas podem acompanhar usuários e aplicativos com autenticação ou cookies. Limites por conta ignoram novas IPs; em baixo volume, respeite primeiro Retry-After.

A norma é RFC 6585, que definiu o código 429. Ela permite Retry-After para indicar espera, sem definir como identificar usuários ou contar solicitações. Cita credenciais de autenticação ou cookie com estado como exemplos de identificação.

Três compras erradas: limite por conta, token de API ou cookie, em que todos os IPs consomem a mesma cota e os 429 continuam; tarefa pequena que pode espaçar centenas de páginas noturnas, esperar Retry-After e repetir com recuo exponencial sem custo; tarefa autenticada que precisa de identidade estável e IP fixo.

Rotação cabe quando o limite é por IP, o valor depende do volume e as solicitações independentes respeitam o uso permitido. Os termos do site continuam valendo. Além disso, o site avalia identificação do cliente na conexão e ritmo de solicitações: rotação não garante acesso.

Antes de pagar, leia documentação e cabeçalhos. Se solicitações autenticadas comparáveis recebem 429, mas anônimas do mesmo endereço funcionam, isso sugere, sem provar, limite por conta ou autenticação. Se ambas falham, pode ser por IP, recurso ou servidor inteiro. Mantenha endpoint e frequência comparáveis e respeite Retry-After antes de testar novamente.

Perguntas frequentes