De Quantos IPs de Proxy Você Realmente Precisa?

É a pergunta que aparece antes de quase toda compra de proxies: de quantos IPs eu preciso? Soa como o tipo de coisa que deveria ter um número como resposta, e parece ser o número que determina se o trabalho vai funcionar. Na prática costuma ser a pergunta errada, e times que começam por ela muitas vezes compram a coisa errada. O que realmente decide se o seu scraping roda limpo não é quantos endereços você possui, é como suas requisições se distribuem entre os que você usa, e se algum alvo isolado chega a ver tráfego suficiente vindo de um único endereço a ponto de se importar.

Veja como pensar nisso direito, incluindo o único caso em que contar IPs é de fato a abordagem certa.

Por que a pergunta está mal formulada

O instinto de contar IPs é uma herança de um modelo de preços mais antigo. Quando proxies eram vendidos por porta ou por endereço estático, você comprava um número específico de IPs e esse número era a sua capacidade, então contar fazia sentido. Redes residenciais modernas não funcionam assim. Você extrai de um grande pool compartilhado, é cobrado pela banda que movimenta em vez dos endereços que toca, e o número de IPs distintos que você acaba usando é um resultado de como configura a rotação, não uma quantidade que compra antecipadamente. Essa mudança, tratada com mais profundidade no texto sobre por que a era do por-porta acabou, é o motivo de “quantos IPs” não corresponder mais a nada que você realmente compre.

Há um segundo motivo pelo qual esse enquadramento engana. Um site alvo não vê o seu pool. Ele vê as requisições chegando à própria porta, e forma uma opinião por endereço com base em como essas requisições se comportam. Dez mil IPs não vão salvar um trabalho que manda todo o seu volume por um punhado deles, e um número modesto de endereços bem distribuídos roda tranquilamente um trabalho que uma configuração ingênua não conseguiria. Distribuição é a variável, não estoque.

O que de fato determina suas necessidades

Quatro coisas decidem o que um trabalho precisa. Percorra-as em ordem e a resposta aparece.

A primeira é a sua taxa de requisições por alvo. Não o volume total de requisições somando tudo, mas quantas requisições você manda para um único site em uma dada janela, porque limites de taxa são aplicados por IP e por alvo. A segunda é a concorrência, ou seja, quantas requisições você tem em voo ao mesmo tempo, o que define quantos endereços estão em uso simultâneo. A terceira são os requisitos de sessão: se o seu trabalho precisa de um IP retido para um fluxo de várias etapas, que é o único caso que vira uma contagem real. A quarta é a abrangência geográfica, porque um trabalho que cobre muitos mercados precisa do volume distribuído por cada um desses mercados em vez de um grande pool concentrado em outro lugar, e onde há segmentação por cidade envolvida, a pergunta relevante é a disponibilidade naquela cidade, não o tamanho da rede como um todo.

A matemática aproximada para trabalho rotativo

Para coleta rotativa comum, o cálculo útil não é “quantos IPs existem” e sim “de quantos endereços distintos meu volume precisa para se manter educado em cada alvo”.

Pegue sua taxa de requisições para um único site e divida pela taxa que você aceita enviar de um único endereço. Se um trabalho manda 60.000 requisições por hora para um alvo, e você quer que nenhum endereço mande mais do que aproximadamente uma requisição a cada 20 segundos para esse alvo, o que dá 180 por hora, então esse volume precisa ser distribuído por algo da ordem de 330 endereços distintos a qualquer momento. Mude qualquer uma das entradas e a resposta se move: corte o volume pela metade e você precisa da metade, desacelere cada endereço e precisa de mais. Os números aqui são ilustrativos, já que cada alvo tolera uma taxa diferente e você deve ajustar ao que um site específico realmente aceita, mas o formato do cálculo é o ponto. Você está resolvendo para distribuição, e o pool simplesmente precisa ser grande o bastante e bem distribuído o bastante nos seus mercados alvo para fornecê-la.

É exatamente isso que o balanceamento de carga faz por você, e por que conexões concorrentes ilimitadas importam mais do que uma contagem de IPs de manchete: a restrição que morde é quantas requisições um endereço manda para um site, não quantos endereços existem no total. Se você está batendo em muitos alvos diferentes, a matemática se aplica por alvo, e volume distribuído por cinquenta sites é muito menos exigente do que o mesmo volume apontado para um só.

O caso em que você realmente conta: sessões sticky

Existe uma situação em que um número é genuinamente a resposta certa, e vale a pena ser preciso sobre ela. Quando seu trabalho precisa de uma identidade retida, uma busca de várias etapas, um fluxo de login, uma sequência tipo checkout, ou qualquer processo em que um site acompanha estado entre requisições, cada um desses fluxos concorrentes precisa da própria sessão sticky no próprio IP enquanto o fluxo durar. Aqui a contagem é direta: cinquenta sessões simultâneas significam cinquenta endereços retidos naquele momento, e quinhentas significam quinhentos.

Então a versão honesta da pergunta não é “de quantos IPs eu preciso” e sim “de quantas sessões sticky concorrentes eu preciso”, que é uma pergunta sobre o formato da sua carga de trabalho e não sobre a rede. Tudo o que não exigir identidade retida deve rotacionar, porque a rotação distribui a carga automaticamente e é assim que o modelo de rotação foi desenhado para ser usado.

Por que o tamanho bruto do pool é uma métrica de comparação fraca

Provedores anunciam tamanhos de pool, e os números são grandes o bastante para serem difíceis de comparar de forma significativa. Três coisas importam mais do que a cifra de manchete.

Distribuição nos seus mercados vem primeiro. Um pool enorme que é ralo no país ou na cidade de que você realmente precisa é pior para o seu trabalho do que uma rede menor que seja densa ali, então o único tamanho de pool que importa é o disponível onde você está coletando. Qualidade vem em segundo, já que endereços sinalizados ou sobrecarregados atraem desafios e respostas distorcidas independentemente de quantos existam, e é por isso que a reputação do IP afeta sua taxa de sucesso mais diretamente do que o volume, e por que ajuda entender o que é de fato um IP residencial. Disponibilidade concorrente vem em terceiro: o que é utilizável no momento em que você manda tráfego é o que importa, não uma contagem acumulada de todo endereço que a rede já viu.

A consequência prática é que você não deve escolher um provedor pelo tamanho do pool. Rode a sua própria carga de trabalho contra uma compra pequena e meça, que é para isso que serve o guia de testar velocidade, taxa de sucesso e precisão de localização.

O que dimensionar no lugar: banda

Como você é cobrado por dados movimentados em vez de endereços usados, o número que vale a pena projetar é a banda. Estime o tamanho de página ou de resposta dos seus alvos, multiplique pelo volume que planeja coletar, e você tem uma cifra que corresponde ao que vai realmente pagar, que é a abordagem exposta em estimar a banda mensal. Isso também deixa óbvia a maior alavanca de custo, e ela não é o número de IPs: buscar apenas o que você precisa em vez de páginas renderizadas inteiras é onde está a economia, como tratado em cortar custos de banda de proxy.

Configurando

Ambos os modos vêm do mesmo gateway, e a diferença é um campo no nome de usuário. Omita um identificador de sessão e cada requisição rotaciona, que é o que a maior parte da coleta deve fazer:

import requests

# Rotating: every request exits through a different address
ROTATING = "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443"
r = requests.get("https://example.com/page",
                 proxies={"http": ROTATING, "https": ROTATING}, timeout=15)

# Sticky: one held IP per concurrent flow, counted per session
def sticky(session_id):
    url = (f"http://customer-USERNAME-country-us-sid-{session_id}:"
           f"PASSWORD@p.shifter.io:443")
    return {"http": url, "https": url}

# 50 concurrent flows means 50 distinct session identifiers
for i in range(50):
    proxies = sticky(f"flow{i}")
    # run one multi-step sequence on this held address

Rotacione por padrão, retenha uma sessão apenas onde um fluxo genuinamente precisar de uma, e deixe o pool cuidar da distribuição em vez de tentar gerenciar você mesmo uma lista fixa de endereços.

Validando a resposta

Qualquer número a que você chegue é uma hipótese inicial, e a única confirmação confiável é a medição. Acompanhe a taxa de sucesso por alvo e por região, porque uma queda é o sinal de que a sua taxa por endereço está agressiva demais para aquele site bem antes de virar um buraco nos dados, que é o que monitorar o pipeline oferece. Quando uma rota degrada, o failover mantém o trabalho rodando enquanto você ajusta. E se você está vendo bloqueios, a correção é mais frequentemente ritmo e higiene de requisição do que mais endereços, que é a substância de evitar bloqueios.

Um checklist curto

1. Quantas requisições por hora para o seu alvo isolado mais movimentado? Isso, dividido pela taxa por endereço que aquele alvo tolera, é aproximadamente quanta distribuição você precisa.
2. Quantos fluxos concorrentes precisam de identidade retida? Essa é a sua contagem de sessões sticky, e é o único número que vale a pena declarar.
3. De quais países e cidades você precisa, e o pool é denso nesses lugares em vez de apenas grande no geral?
4. Quantos dados você vai movimentar? Esse é o número que determina o custo.
5. Você mediu a taxa de sucesso na sua própria carga de trabalho em vez de confiar numa cifra de manchete?

Conclusão

“De quantos IPs eu preciso” é uma pergunta herdada de um modelo de preços que não se aplica mais. Numa rede residencial moderna precificada por banda você não está comprando uma contagem de endereços, está comprando acesso a um pool e pagando pelos dados que movimenta através dele, então o que se projeta é distribuição: espalhamento suficiente para que nenhum alvo isolado veja mais do que tráfego comum vindo de um único endereço. Rotacione para volume, conte apenas suas sessões sticky concorrentes, julgue uma rede pela densidade nos mercados de onde você realmente coleta e pela taxa de sucesso que ela entrega na sua própria carga de trabalho, e dimensione seu orçamento em banda em vez de endereços. Acerte a distribuição e a contagem de IPs deixa de ser algo em que você precise pensar.

É isso que os proxies residenciais foram construídos para fornecer, um grande pool de IPs reais de nível doméstico com segmentação por país e cidade, rotação por padrão, e sessões sticky para os fluxos que precisam delas. O preço por GB é o número em torno do qual vale a pena planejar, porque você paga pelos dados que realmente puxa em vez de por uma quantidade de endereços que espera ser suficiente.