De quantos proxies é que realmente precisa?

Vendemos proxies em Geonode, o que faz com que este artigo defenda que se deve comprar menos do que tinha planeado. Essa é, de facto, a nossa posição: um conjunto de proxies demasiado grande não o torna mais seguro e, num modelo de preços baseado no tráfego, nem sequer custa mais — o que significa que as pessoas têm uma perceção errada sem nunca verem a fatura que a corrigiria. O número que importa é a simultaneidade de ligações a um único alvo, e isso é mensurável numa tarde. Se tiver de retirar uma lição disto, que seja a medição apresentada na secção seguinte, em vez de qualquer valor que possamos fornecer-lhe.

O único método que funciona

Três passos, todos empíricos.

Primeiro passo: determine o limite máximo por endereço. Execute a sua carga de trabalho real a partir de um único endereço, aumentando gradualmente a taxa de pedidos, e identifique o ponto em que o alvo começa a apresentar resistência — erros 429, verificações de autenticidade, respostas mais lentas ou conteúdo degradado. Esse limiar é a sua capacidade por endereço para esse destino, e é o único número neste cálculo que não é uma estimativa.

Passo dois: defina o débito necessário. Quantas solicitações, durante quanto tempo. Seja honesto quanto à parte «durante quanto tempo», porque é o fator que mais pesa nesta equação.

Passo três: divida. A taxa de transferência necessária dividida pela capacidade por endereço dá o número de endereços simultâneos necessários. Acrescente uma margem para novas tentativas e variabilidade — 50% é generoso e, se precisar de mais do que isso, a sua medição no primeiro passo foi provavelmente otimista.

É este todo o método. A razão pela qual não é o conselho padrão é que requer a realização de um teste antes da compra, e os fornecedores não têm qualquer incentivo para o sugerir.

Uma nota sobre o primeiro passo: meça as respostas úteis concluídas por segundo, não as tentativas de pedidos. Um pool que devolve códigos 200 com conteúdo removido não está a funcionar, e uma métrica agregada de taxa de sucesso irá reportá-lo como estando em bom estado. Verifique se existe um marcador conhecido como estável na resposta e conte apenas as respostas que o contenham.

Realizar a medição corretamente

Todo o método assenta no primeiro passo, pelo que vale a pena ser específico sobre como o fazer sem se induzir em erro.

Teste em relação ao seu alvo real, não a um ponto final de teste. Uma execução num serviço que repete o seu endereço IP indica apenas que o seu proxy funciona, mas não diz nada sobre como o site que lhe interessa irá tratá-lo. Cada alvo tem a sua própria tolerância, e o valor de que necessita é específico para cada alvo.

Aumente gradualmente e registe tudo. Comece bem abaixo do que espera que seja o limite e vá aumentando, mantendo cada taxa durante tempo suficiente para identificar um padrão — pelo menos alguns minutos. Registe a taxa, os códigos de estado, os tamanhos das respostas e o tempo real para cada etapa:

for rate in 0.2 0.5 1 2 5 10; do
  echo "=== $rate req/s"
  for i in $(seq 1 60); do
    code=$(curl -s -x "$PROXY" -o /tmp/body -w '%{response_code}' "$URL")
    size=$(stat -c%s /tmp/body 2>/dev/null || stat -f%z /tmp/body)
    echo "$rate $code $size"
    sleep "$(echo "1/$rate" | bc -l)"
  done
done | tee ramp.log

Preste tanta atenção ao tamanho da resposta como ao código de estado. A forma mais comum de recusa não é um 429; é um 200 acompanhado de uma página mais pequena. Uma queda no tamanho médio da resposta a uma determinada taxa significa que o alvo está a começar a servir-lhe algo reduzido, e isso é invisível se contar apenas os códigos de estado.

Execute o teste em diferentes alturas do dia. A tolerância é frequentemente menor durante as horas de pico de um site, e um limite medido às 3 da manhã não se manterá ao meio-dia. Considere o valor mais pessimista.

Repita com um segundo endereço. Se um endereço atingir um limite máximo com duas solicitações por segundo e um segundo endereço atingir o mesmo limite ao mesmo tempo, o limite não é por endereço — está na sua sub-rede, no padrão das suas solicitações ou noutro fator que mais endereços não irão resolver. Esse é um resultado negativo importante e custa uma execução adicional para o obter.

Depois, pare antes do limite máximo, não ao atingi-lo. Operar à taxa máxima que um alvo tolera significa que qualquer flutuação normal o empurra para além desse limite. Dimensionar entre 60% e 70% do limite máximo medido garante-lhe uma tarefa que é concluída de forma fiável, em vez de uma que só é concluída quando as condições são favoráveis.

Exemplo prático: Monitorização diária de preços

A carga de trabalho mais comum e aquela cuja resposta mais surpreende as pessoas.

Requisito: 50 000 páginas de produtos verificadas uma vez por dia.

Limite máximo medido: o sistema tolera aproximadamente um pedido a cada dois segundos proveniente de um único endereço antes de aplicar a limitação de taxa — digamos, 1 800 pedidos por hora.

Distribuído por 24 horas: 50 000 ÷ 24 ≈ 2 100 pedidos por hora.

Endereços necessários: 2 100 ÷ 1 800 ≈ 1,2. Arredondar para cima e adicionar margem: dois a quatro endereços.

Dois endereços. Para cinquenta mil páginas por dia, face a um conjunto anunciado na ordem dos milhões.

Agora, altere uma premissa. Suponha que o trabalho tenha de ser concluído num intervalo de duas horas, em vez de se distribuir ao longo do dia:

Requisito: 50 000 páginas em 2 horas = 25 000 por hora. Endereços necessários: 25 000 ÷ 1 800 ≈ 14, mais margem: cerca de 20.

O mesmo volume, o mesmo objetivo, dez vezes mais endereços — devido a uma decisão de agendamento, não a um requisito de recolha de dados.

Essa é a conclusão mais útil deste artigo. O intervalo de tempo que se concede é a variável dominante. Antes de comprar mais endereços, pergunte-se se o trabalho precisa realmente de ser concluído rapidamente e quanto vale essa rapidez. Muitas vezes, não vale absolutamente nada, porque os dados são consumidos na manhã seguinte.

Exemplo prático: Verificações geográficas

Uma forma completamente diferente, e os cálculos são feitos de forma oposta.

Requisito: verificar os preços regionais e a disponibilidade em 30 mercados, quatro vezes por dia, em 50 páginas por mercado.

Volume: 30 × 4 × 50 = 6 000 pedidos por dia. Trivial.

Endereços necessários para o débito: essencialmente um. Seis mil pedidos distribuídos ao longo de um dia correspondem a um pedido a cada catorze segundos.

Endereços necessários para a cobertura: pelo menos uma saída operacional em cada um dos 30 países, no momento em que for necessária.

Aqui, a restrição não é de todo o volume, é a presença. O que deve avaliar é se o fornecedor tem, de facto, uma cobertura fiável nos mercados específicos de que necessita, nos momentos em que opera — e não quantos endereços o conjunto contém. Um conjunto de dez milhões com cobertura limitada em três dos seus mercados é pior do que um conjunto de dez mil que cubra todos os trinta.

É por isso que «de quantos preciso?» é a pergunta errada para trabalhos geográficos e «onde é possível chegar, de forma fiável, e posso testá-lo?» é a pergunta certa.

Exemplo prático: Trabalho baseado em sessões

O caso em que a concorrência e a identidade são a mesma coisa.

Requisito: gerir 10 sessões autenticadas em paralelo, cada uma a executar sequências de vários passos.

Endereços necessários: 10, e estes devem ser fixos — um endereço mantido durante toda a duração de cada sessão.

O volume é irrelevante neste caso. O que importa é que cada sessão tenha uma identidade coerente: o mesmo endereço durante todo o tempo, com localização e fuso horário correspondentes. Uma sessão cujos pedidos chegam de quatro países não é uma sessão, é um padrão.

O erro a evitar é utilizar um ponto de extremidade rotativo por pedido para este fim, o que é a configuração predefinida na maioria dos gateways. Os pedidos são bem-sucedidos, o estado da sessão perde-se e o sintoma parece um erro da aplicação enquanto demorar alguém a verificar os endereços de saída.

Note-se também que dez sessões simultâneas não significam dez endereços para sempre — significa dez ao mesmo tempo. Uma carga de trabalho que execute 200 sessões sequencialmente ao longo do dia continua a precisar apenas de dez endereços fixos, reutilizados.

Por que mais não significa mais segurança

A suposição subjacente à maioria das compras em excesso está errada em três aspetos específicos.

O bloqueio é feito por sub-rede, não por endereço. Os sites costumam bloquear com uma granularidade de /24. Cinquenta endereços num bloco comportam-se como um único endereço quando esse bloco é bloqueado; por isso, um conjunto grande com má distribuição não é um conjunto grande no que realmente importa. A distribuição é mais importante do que a quantidade, e abordámos os mecanismos em o que é um ID de sub-rede.

A taxa é o sinal, não a identidade. Se os teus pedidos parecerem automatizados devido ao tempo, aos cabeçalhos ou à impressão digital TLS, distribuí-los por mais endereços espalha o sinal sem o eliminar. Acabas por sinalizar mais endereços em vez de menos.

Os endereços não utilizados ficam obsoletos. Num conjunto rotativo, um endereço que não tenha utilizado não tem qualquer relação com o alvo, seja ela positiva ou negativa. Manter «capacidade de reserva» não é um armazenamento de nada.

Há uma razão genuína para manter mais endereços do que a taxa de transferência exige: rotatividade. Se um alvo sinalizar endereços ao longo do tempo, precisas de substitutos para rodar. Essa é uma necessidade real, e a sua dimensão é determinada pela taxa de sinalização observada, e não pela intuição — mede quantos endereços ficam inoperacionais por dia e mantém uma reserva para alguns dias.

O que está realmente a comprar

Vale a pena deixar isto claro, porque a resposta varia consoante o modelo de preços e isso altera o próprio significado da pergunta.

No modelo de preços por gigabyte, que é como o tráfego residencial e, frequentemente, o tráfego dos centros de dados é vendido, não está, de todo, a comprar endereços. O que compra são dados, e o número de endereços é uma característica do conjunto de endereços (pool), e não do seu plano. Perguntar «de quantos proxies preciso?» neste contexto é um erro de categoria — as verdadeiras questões são quanto tráfego irá transferir e se o conjunto de endereços tem cobertura onde precisa. O nosso tráfego residencial começa em 0,79 $/GB e o de centros de dados em 0,14 $/GB, verificado em setembro de 2026 na nossa página de preços.

No que diz respeito aos preços por IP, que é a forma como os produtos dos ISP e de muitos centros de dados são vendidos, a contagem é, literalmente, aquilo pelo qual paga e todo este cálculo constitui uma rubrica orçamental. Os nossos custam 1,25 $/IP. Aqui, a aritmética acima traduz-se em dinheiro, e fazer as contas corretamente vale bem os vinte minutos.

O modelo que mais lhe convém depende da natureza da sua carga de trabalho, e não da tarifa nominal, e os dois não são comparáveis. Uma carga de trabalho que necessite de muitos endereços favorece, a curto prazo, o preço por tráfego; uma que necessite de poucos endereços favorece fortemente o preço por IP. Analisámos a aritmética em pormenor no guia de preços de proxy.

Regras gerais, com as suas limitações

Se precisar de um ponto de partida antes de efetuar a medição, estas regras são defensáveis. Considere-as como uma primeira estimativa a ser substituída, e não como uma resposta definitiva.

Dois números que vale a pena ter em conta. Quase nenhuma carga de trabalho necessita de mais do que algumas dezenas de endereços simultâneos, e as que realmente necessitam são ou de natureza geográfica (muitos locais, baixo volume em cada um) ou estão sujeitas a um prazo autoimposto. E o número que mais frequentemente precisa de ser alterado não é a contagem de endereços, mas sim o horário.

Sinais de que o valor está errado

Demasiado pouco manifesta-se da seguinte forma: aumento dos 429s, surgimento de desafios, diminuição da taxa de sucesso à medida que a execução avança, tarefas concluídas mais tarde do que o planeado. A solução passa por aumentar a concorrência ou alargar o intervalo de tempo.

Demasiado manifesta-se da seguinte forma: nada. É por isso que o erro persiste. Um conjunto de endereços demasiado grande não produz qualquer sintoma na tarifação por tráfego, pelo que ninguém o descobre. Na tarifação por IP, gera uma fatura, o que, pelo menos, suscita a questão.

Duas situações que parecem «demasiado poucos» mas não o são:

Um conjunto de endereços bloqueado. Se a taxa de sucesso descer drasticamente em todos os endereços simultaneamente, adicionar mais não vai ajudar — algo mudou no destino, ou o padrão das suas solicitações está a ser identificado através de um sinal que não está relacionado com o endereço.

Um destino lento. Se as respostas forem lentas mas bem-sucedidas, mais concorrência ajudará a aumentar o débito até certo ponto e depois deixará de o fazer. Meça as solicitações concluídas por segundo e pare de aumentar quando esse número estabilizar, o que acontecerá mais cedo do que o esperado.

O diagnóstico geral: aumente a simultaneidade gradualmente e observe as respostas úteis concluídas por segundo. O número sobe, estabiliza e depois desce. O ponto ideal é a estabilização, e geralmente é um número menor do que qualquer um prevê.

Perguntas frequentes

De quantos proxies preciso para fazer web scraping?

É melhor medir do que adivinhar: descubra a taxa de pedidos a partir da qual um único endereço começa a ser limitado no seu alvo real, divida a largura de banda necessária por esse valor e acrescente uma margem. A maioria das cargas de trabalho situa-se na casa de um único dígito ou de dois dígitos baixos de endereços simultâneos, e não na casa dos milhares.

Utilizar mais proxies diminui a probabilidade de ser bloqueado?

Apenas se o bloqueio for específico de um endereço. Se as suas solicitações forem identificadas como automatizadas com base no tempo, na composição do cabeçalho ou na impressão digital TLS, um maior número de endereços distribui o mesmo sinal por mais endereços do seu conjunto, em vez de o evitar. A taxa e o padrão das solicitações são mais importantes do que a quantidade.

Quantos proxies são necessários para 1 milhão de solicitações por dia?

Depende inteiramente do período. Distribuído por 24 horas, isso equivale a cerca de 12 pedidos por segundo, o que, a um pedido a cada dois segundos por endereço, significa aproximadamente 25 endereços simultâneos. Comprimido em duas horas, é doze vezes mais. A variável é a programação, não o volume.

Preciso de um proxy por conta?

Para qualquer coisa baseada em sessões, um endereço fixo por sessão simultânea — não por conta. Dez contas operadas sequencialmente ao longo do dia precisam de dez endereços apenas se todas as dez estiverem ativas simultaneamente. Note que muitas plataformas proíbem explicitamente a operação com várias contas, por isso verifique os termos antes de planear em função disso.

É melhor ter mais IPs ou melhores IPs?

Melhores, no sentido de estarem bem distribuídos pelas sub-redes e serem adequados ao alvo. O bloqueio ocorre normalmente ao nível de /24, pelo que cinquenta endereços num bloco comportam-se como um único. Um conjunto mais pequeno e bem distribuído tem melhor desempenho do que um conjunto maior e concentrado.

Como sei se tenho poucos proxies?

Aumento dos erros 429, aparecimento de páginas de desafio e diminuição da taxa de sucesso à medida que a execução avança. Se a taxa de sucesso cair em todos os endereços de uma só vez, trata-se de um problema diferente — algo mudou no destino ou as suas solicitações estão a ser identificadas com base num sinal que não é o endereço, e ter mais endereços não vai ajudar.

O número de proxies afeta o preço?

No modelo de preços por IP, afeta diretamente — o número de proxies é o que se compra. No modelo de preços por gigabyte, não afeta de todo, porque se paga pelos dados e o número de endereços é uma característica do conjunto. É por isso que os dois modelos não podem ser comparados com base nas tarifas nominais.

Quantos proxies são necessários para a segmentação geográfica?

É necessária uma saída fiável por localização, e o volume é normalmente irrelevante. A pergunta a fazer a um fornecedor não é quantos endereços tem, mas sim se dispõe de uma cobertura fiável nos seus mercados específicos e se pode testá-la antes de se comprometer.

Conclusão

O número de que precisa resulta de uma medição e de uma divisão: descubra a partir de que ponto um único endereço começa a ser limitado na sua meta real e divida a sua exigência de débito por esse valor. Tudo o resto é um ajuste.

A variável que determina o resultado não é o volume, mas sim a janela de tempo que permite. Cinquenta mil páginas por dia requerem alguns endereços distribuídos ao longo de vinte e quatro horas e vinte distribuídos por duas. Antes de adquirir capacidade para acelerar o processo, verifique se há realmente algo que dependa de o trabalho terminar mais cedo — muitas vezes não há, e a otimização mais barata disponível é a paciência.

E, no caso de trabalho geográfico, a questão muda completamente de forma. O volume é trivial, a presença é tudo, e a avaliação útil consiste em saber se um fornecedor cobre de forma fiável os seus mercados específicos, em vez de quão grande é o conjunto de endereços. Isso pode ser testado numa versão de avaliação, demora uma tarde e dir-lhe-á mais do que qualquer número que um fornecedor coloque numa página de destino — incluindo a nossa.