Quantos Proxies Você Precisa

O número ideal de proxies é determinado pelo caso de uso específico, pelas defesas antibot do site de destino, pelo volume de requisições desejado, pelas conexões simultâneas e pela frequência de rotação de IP necessária.

Entendendo os fatores centrais

Definir a quantidade necessária de proxies envolve avaliar várias variáveis interligadas. O cálculo preciso costuma ser iterativo e refinado com testes, mas uma estimativa inicial pode ser obtida analisando o seguinte:

Defesas antibot do site de destino

Os sites aplicam diversas técnicas para detectar e bloquear requisições automatizadas. A agressividade dessas medidas impacta diretamente a necessidade de proxies.
* Segurança baixa: rate limiting básico, bloqueio de IP após requisições excessivas.
* Segurança média: limites de taxa mais sofisticados, desafios CAPTCHA, fingerprinting básico de navegador.
* Segurança alta: detecção avançada de bots, fingerprinting detalhado de navegador, análise comportamental, blacklisting extensivo de IPs, CAPTCHAs frequentes, armadilhas honeypot.

Alvos altamente protegidos exigem um pool de proxies maior e mais diverso, muitas vezes com IPs residenciais ou móveis e rotação frequente.

Volume e velocidade de requisições desejados

O número total de requisições planejadas dentro de um período específico (por exemplo, requisições por hora, por dia) e a velocidade desejada (Queries Per Second - QPS) são fundamentais.
* Total de requisições (TR): o número absoluto de requisições HTTP/S a serem feitas.
* QPS desejado (DQPS): a taxa-alvo de requisições por segundo.

Um TR ou DQPS mais alto normalmente exige mais proxies para distribuir a carga e evitar disparar limites de taxa em IPs individuais.

Rotação de proxies e sessões sticky

• Frequência de rotação: com que frequência o endereço IP é trocado. Uma rotação rápida (por exemplo, a cada requisição, a cada poucos segundos) consome mais IPs únicos do pool ao longo do tempo, mas reduz a chance de um IP ser sinalizado.
• Sessões sticky: a necessidade de manter uma conexão persistente ou uma série de requisições usando o mesmo endereço IP por um período definido (por exemplo, fazer login, navegar por formulários de várias páginas). Sessões sticky prendem um IP por mais tempo, o que pode reduzir o tamanho efetivo do pool para outras tarefas.

Período de cooldown

Depois que um IP foi usado, especialmente se ele encontrou um soft block ou um CAPTCHA, é prudente deixá-lo descansar por um período de "cooldown". Isso permite que os sistemas de detecção do site de destino sejam reiniciados ou que a reputação do IP se recupere. Um cooldown mais longo significa menos IPs ativamente disponíveis a cada momento, aumentando assim o tamanho total exigido do pool.

Diversidade geográfica e de rede

Algumas tarefas exigem IPs de localizações geográficas específicas (países, regiões, cidades) ou de tipos de rede diversos (por exemplo, ISPs variados). Isso segmenta o seu pool de proxies: mesmo com um número total grande de proxies, o pool disponível para um geo-alvo específico pode ser bem menor.

Estimando a necessidade de proxies: um modelo prático

Um modelo de estimativa robusto considera os proxies ativos simultâneos necessários e os proxies adicionais requeridos para viabilizar rotação e cooldown.

Variáveis:

• DQPS: Desired Queries Per Second (QPS desejado).
• APQPS: QPS médio que um único proxy sustenta antes de precisar rotacionar ou correr risco de bloqueio (estime de forma conservadora, por exemplo, 0.1 a 1 QPS).
• AUT: Average Usage Time (em segundos) — tempo em que um proxy individual fica fazendo requisições antes de ser rotacionado ou colocado em cooldown (por exemplo, 30s a 300s).
• CDT: Cooldown Duration Time (em segundos) — tempo que um proxy individual precisa descansar após o uso antes de ser reutilizado (por exemplo, 300s a 3600s).
• BF: Buffer Factor (por exemplo, 0.10 a 0.25), para cobrir falhas de proxies, bloqueios inesperados ou aumento de carga.

Etapas do cálculo:

1. Calcular os proxies ativos simultâneos (CAP):
   É o número mínimo de proxies que precisam estar ativos ao mesmo tempo para atingir seu DQPS, assumindo que cada proxy entregue APQPS.
   CAP = DQPS / APQPS

2. Calcular o multiplicador de rotação (RM):
   Esse fator determina quantos "slots" um IP ocupa no pool por causa do seu uso ativo e do cooldown subsequente.
   RM = (AUT + CDT) / AUT

   • Autocorreção: se AUT for muito curto e CDT muito longo, RM pode ficar grande. Isso indica alta demanda por IPs únicos. Se CDT for 0 (sem cooldown), RM se torna 1.

3. Calcular o pool base de proxies (BPP):
   É o mínimo teórico de proxies necessários para sustentar CAP acomodando AUT e CDT.
   BPP = CAP * RM

4. Aplicar o buffer (BP):
   Adicione uma folga para imprevistos, como uma parcela dos proxies ficar lenta, não responder ou ser bloqueada antes do previsto.
   BP = BPP * BF

5. Total estimado de proxies (TEP):
   TEP = BPP + BP

Exemplo de cálculo:

Suponha os seguintes requisitos e estimativas:
* DQPS: 20 requisições/segundo
* APQPS: 0.5 requisições/segundo (estimativa conservadora para um alvo de alta segurança)
* AUT: 60 segundos (cada proxy faz 30 requisições antes de rotacionar)
* CDT: 900 segundos (15 minutos de cooldown)
* BF: 0.20 (20% de buffer)

1. Cálculo do CAP:
   CAP = 20 QPS / 0.5 QPS/proxy = 40 proxies
   (Você precisa de 40 proxies fazendo requisições ativamente a qualquer momento.)

2. Cálculo do RM:
   RM = (60 segundos + 900 segundos) / 60 segundos = 960 / 60 = 16
   (Cada proxy ativo exige 15 proxies adicionais em cooldown/rotação para cada proxy ativo.)

3. Cálculo do BPP:
   BPP = 40 proxies * 16 = 640 proxies

4. Cálculo do BP:
   BP = 640 proxies * 0.20 = 128 proxies

5. Cálculo do TEP:
   TEP = 640 + 128 = 768 proxies

Nesse cenário, seriam necessários aproximadamente 768 proxies para sustentar 20 QPS contra um alvo moderadamente protegido com 15 minutos de cooldown.

Exemplo de código (função Python para estimativa):

def estimate_proxies(desired_qps, avg_qps_per_proxy, avg_usage_time_sec, cooldown_time_sec, buffer_factor):
    """
    Estima o número total de proxies necessários com base nos parâmetros operacionais.

    Args:
        desired_qps (float): Requisições por segundo desejadas.
        avg_qps_per_proxy (float): QPS médio que um único proxy sustenta.
        avg_usage_time_sec (float): Tempo (segundos) em que um proxy fica ativo antes da rotação/cooldown.
        cooldown_time_sec (float): Tempo (segundos) de descanso do proxy após o uso.
        buffer_factor (float): Fator de proxies adicionais (ex.: 0.15 para 15%).

    Returns:
        int: Número total estimado de proxies.
    """
    if avg_qps_per_proxy <= 0 or avg_usage_time_sec <= 0:
        raise ValueError("avg_qps_per_proxy and avg_usage_time_sec must be positive.")

    # 1. Calcula os proxies ativos simultâneos (CAP)
    concurrent_active_proxies = desired_qps / avg_qps_per_proxy

    # 2. Calcula o multiplicador de rotação (RM)
    rotation_multiplier = (avg_usage_time_sec + cooldown_time_sec) / avg_usage_time_sec

    # 3. Calcula o pool base de proxies (BPP)
    base_proxy_pool = concurrent_active_proxies * rotation_multiplier

    # 4. Aplica o buffer (BP)
    buffered_proxies = base_proxy_pool * buffer_factor

    # 5. Total estimado de proxies (TEP)
    total_estimated_proxies = base_proxy_pool + buffered_proxies

    return int(round(total_estimated_proxies))

# Exemplo de uso:
# total_proxies = estimate_proxies(
#     desired_qps=20,
#     avg_qps_per_proxy=0.5,
#     avg_usage_time_sec=60,
#     cooldown_time_sec=900,
#     buffer_factor=0.20
# )
# print(f"Estimated proxies: {total_proxies}") # Saída: Estimated proxies: 768

Recomendações de tipo de proxy

A escolha do tipo de proxy impacta significativamente a eficácia e o custo.

Considerações avançadas

Monitoramento e gestão da saúde dos proxies

Implementar um sistema que monitore continuamente a saúde dos proxies (tempos de resposta, taxas de sucesso, status de bloqueio) é fundamental. Proxies com desempenho ruim ou bloqueios frequentes devem ser removidos temporária ou permanentemente do pool ativo e substituídos. Essa gestão dinâmica garante que o fator de buffer do cálculo seja de fato aproveitado.

Lógica de retentativa e tratamento de erros

Mecanismos robustos de retentativa e um tratamento de erros inteligente reduzem a demanda imediata por novos proxies. Em vez de trocar instantaneamente de IP diante de um soft block, um atraso estratégico e uma nova tentativa com o mesmo IP podem ser mais eficientes, especialmente se o bloqueio for temporário. Por outro lado, uma lógica de retentativa agressiva pode acelerar o blacklisting do IP.

Ajuste dinâmico

A estimativa inicial é apenas um ponto de partida. O desempenho real contra os sites de destino é que vai ditar os ajustes. Monitore continuamente as taxas de sucesso, as taxas de bloqueio e o QPS. Se as taxas de bloqueio estiverem altas, aumente CDT ou TEP. Se o desempenho ficar abaixo do DQPS, aumente CAP ou otimize APQPS. Esse processo iterativo garante a alocação ideal de recursos.