A pergunta "quantas threads uma porta aguenta" costuma aparecer antes de iniciar uma coleta em massa ou o aquecimento de dezenas de contas, e não existe um número universal para ela. O limite depende da combinação de três fatores: a largura de banda do canal, a política do provedor e o comportamento da plataforma de destino sob carga paralela. Vamos ver o que de fato limita o número de threads e como evitar bater nesse limite logo no início da tarefa.

Do que depende o limite de paralelismo

O primeiro fator é a largura de banda do canal no lado do provedor. Endereços de datacenter e ISP normalmente ficam em um canal dedicado e largo e suportam dezenas de conexões simultâneas sem degradação. O tráfego residencial e móvel passa por um assinante real ou pela rede celular, onde o canal é mais estreito, e o aumento linear de threads esbarra mais rápido em latência e perda de pacotes. A diferença entre esses canais está explicada em detalhes no artigo proxies móveis versus residenciais.

O segundo fator são os limites do próprio provedor. Alguns planos vendem a porta com uma restrição formal de conexões paralelas: o excedente é cortado ou as novas conexões simplesmente não são estabelecidas. Essa restrição está nas condições do plano e não tem relação com a qualidade do canal. Ela é artificial e some ao migrar para um plano mais amplo ou ao adicionar portas.

O terceiro fator, muitas vezes decisivo, é a própria plataforma de destino. Ela tem seu próprio limite de requisições por IP em um intervalo de tempo, normalmente mais baixo do que o canal consegue passar. Mesmo uma porta sem limite de threads esbarra nesse teto: a plataforma devolve captcha, bloqueio temporário de IP ou respostas vazias muito antes de o canal do proxy se esgotar.

Sinais de sobrecarga

A sobrecarga raramente aparece como um erro explícito de "limite excedido". Na maioria das vezes ela se disfarça de instabilidade. O primeiro sinal é o aumento de timeouts: requisições que antes respondiam em frações de segundo começam a travar e são interrompidas pelo timeout do cliente. O segundo é o aumento da parcela de conexões encerradas antes de receber a resposta, enquanto a plataforma de destino funciona normalmente com outros endereços. Vale acompanhar essas métricas seguindo os mesmos princípios descritos no artigo como verificar a qualidade do proxy.

O terceiro sinal é o aumento perceptível da parcela de captchas e bloqueios temporários justamente nesse IP, com o cenário de requisições inalterado. Se antes o captcha aparecia de vez em quando a cada mil requisições e, depois de aumentar o número de threads, passou a aparecer a cada dez, isso não é coincidência: é um sinal de que o paralelismo ultrapassou tanto o limite da plataforma quanto o limite razoável para um único endereço.

Por que mais threads não significa mais velocidade

Intuitivamente, parece que dobrar as threads dobra a velocidade da coleta de dados, mas na prática a curva logo chega a um platô e começa a cair. Cada requisição interrompida por timeout não é apenas uma tentativa perdida, mas um efeito colateral tóxico: o script a repete, aumentando a carga sobre o mesmo IP, ou perde dados que depois precisam ser coletados em uma passada separada.

Quando a plataforma começa a responder com captcha em vez de conteúdo, a velocidade útil de processamento cai mais rápido do que cresce o número de conexões: parte das threads gasta tempo resolvendo ou contornando o captcha em vez de coletar dados, e outra parte recebe uma resposta inútil, que precisa ser descartada e requisitada de novo. O ponto ideal quase sempre fica abaixo do máximo técnico do canal, onde a parcela de erros e repetições é mínima, e não onde o canal inteiro está carregado.

Como distribuir a carga entre as portas

Quando a tarefa exige mais paralelismo do que um endereço consegue sustentar com segurança, a solução não é "espremer o máximo da porta", e sim distribuir a carga em várias portas com IPs diferentes. A plataforma enxerga cada endereço como um visitante separado, com seu próprio limite de requisições por intervalo de tempo. Por isso, dez portas com cinco threads seguras cada entregam mais vazão estável do que uma única porta forçada a cinquenta threads.

A abordagem prática é começar com um número conservador de threads por endereço, aumentá-lo aos poucos, registrar o momento em que os timeouts ou a parcela de captchas sobem e depois ficar bem abaixo desse limite. Em canais residenciais e móveis com entrega de endereço por sessão, a rotação de IP entre requisições já reduz a carga sobre cada endereço, porque a plataforma vê IPs diferentes em vez de um único sobrecarregado. Como configurar essa rotação via API está explicado em um artigo separado sobre rotação de IP.

Relação entre threads e consumo de tráfego

O número de threads multiplica diretamente o consumo de tráfego, e não apenas a velocidade. Canais residenciais e móveis são cobrados por gigabyte, então um paralelismo agressivo, sem desativar o carregamento desnecessário de mídia (imagens, fontes, reprodução automática), queima o orçamento de tráfego muitas vezes mais rápido do que cresce o resultado útil. Como referência: mil verificações de páginas de produto com imagens consomem cerca de 3 a 5 GB, e mil páginas de texto, cerca de 1 GB. Ao escalar as threads, esses números se multiplicam de forma linear, e o orçamento deve ser planejado com antecedência, não calculado depois que o saldo acabar.

Perguntas frequentes

Existe um número universal de threads "por porta"?

Não, porque o limite é definido pela plataforma de destino tanto quanto pelo canal. Para um site, trinta requisições paralelas a partir de um endereço são confortáveis; para outro, a sobrecarga começa já em cinco. O ponto de partida deve ser o comportamento da plataforma específica, e não uma norma abstrata.

O que acontece se eu exceder o limite do provedor de conexões paralelas?

Normalmente, as novas conexões acima do limite não são estabelecidas, ou parte das sessões já abertas é encerrada, dependendo do plano. Isso não é uma degradação da qualidade do canal, mas uma restrição rígida, que some ao migrar para um plano com limite maior ou ao adicionar portas.

A rotação de IP ajuda a manter mais threads ao mesmo tempo?

Sim, de forma indireta: se cada nova requisição ou sessão recebe um novo endereço, o limite da plataforma de destino é contado do zero para cada IP, em vez de se acumular em um só. Isso não elimina as restrições do canal e do plano, mas alivia a parte da carga ligada especificamente aos limites da plataforma por endereço.

Os planos atuais por número de threads e tipos de canal estão na seção de proxies. Lá também é possível comprar mais portas para distribuir a carga, sem forçar um único endereço acima do limite seguro.