Muitas descrições de um pool de proxies residenciais o fazem parecer um armazém: um grande número de endereços em uma prateleira, esperando para ser distribuídos. Esse modelo mental está errado de um jeito que produz surpresas operacionais reais, porque um pool não é um estoque. É uma população de conexões domésticas reais que entram e saem continuamente, e quase tudo que intriga equipes avançadas sobre o comportamento do pool decorre desse único fato.
Veja a seguir como um pool é de fato montado, o que “atualização” significa mecanicamente, e as consequências para as quais você deveria projetar seu sistema.
Como um pool é montado
Os endereços em um pool residencial pertencem a conexões domésticas reais de pessoas de verdade, o que significa que um provedor não pode simplesmente comprá-los como se compram faixas de datacenter. Eles precisam ser contribuídos.
O mecanismo predominante é a participação por meio de software. Uma pessoa instala um aplicativo, ou um SDK embutido em um, que oferece algo em troca do compartilhamento de uma fatia de sua conexão: um plano sem anúncios, um recurso pago, um pequeno pagamento, acesso a um serviço. Quando esse dispositivo está online e suficientemente ocioso, ele pode transportar uma requisição em nome da rede. O provedor mantém relações com os desenvolvedores que embutem esse SDK, e essas relações determinam o formato geográfico e de rede do pool, motivo pelo qual dois provedores com totais gerais semelhantes podem diferir substancialmente em um determinado país. A ética desse arranjo, e como auditá-la, é o tema de como os provedores obtêm seus IPs de forma ética.
A consequência que vale a pena internalizar: a composição do pool depende de quais aplicativos são populares em cada lugar. Ela não é distribuída uniformemente, não é planejada centralmente, e muda conforme esses aplicativos ganham e perdem usuários.
O que “atualização” realmente significa
Os pools se renovam constantemente, por motivos que nada têm a ver com o provedor.
Dispositivos ficam offline quando as pessoas fecham um aplicativo, colocam o celular no bolso, saem de casa, ou vão dormir. Conexões domésticas recebem novos endereços quando roteadores reiniciam ou a concessão de um ISP expira, então a mesma residência pode aparecer como um endereço diferente amanhã. Participantes saem. Novos entram. Além disso, os próprios provedores removem endereços que se degradaram, seja por má reputação ou comportamento pouco confiável.
Nada disso é uma janela de manutenção. É o estado estacionário, acontecendo continuamente em segundo plano, motivo pelo qual um pool residencial é melhor modelado como um fluxo do que como um estoque.
Tamanho do pool não é disponibilidade
Este é o cerne prático da questão, e é onde os números de destaque enganam.
Um número de pool divulgado costuma ser cumulativo: endereços que a rede já viu ao longo de algum período. O que determina sua experiência é a disponibilidade concorrente, ou seja, quantos endereços distintos podem atendê-lo neste exato momento, no país solicitado, com os filtros aplicados. Esses dois números diferem em ordens de grandeza, e apenas o segundo restringe o seu trabalho.
Três fatores o reduzem ainda mais. Geografia: um número global nada diz sobre o seu mercado, argumento explorado em disponibilidade por país. Filtros: adicionar uma cidade ou um ASN corta drasticamente o conjunto elegível, já que só se qualificam os endereços que atendem a todos os critérios. E tempo: como o pool acompanha a atividade humana, o mesmo país tem uma profundidade maior à noite local do que às quatro da manhã.
O resultado é que “qual é o tamanho do pool” é uma pergunta praticamente sem resposta útil, enquanto “quantos endereços distintos eu realmente obtenho para o meu filtro, na minha concorrência, na hora em que executo” é mensurável em vinte minutos e é o número que importa.
Os cinco comportamentos que o churn explica
Uma vez que você modela o pool como uma população em vez de um estoque, um conjunto de comportamentos que antes pareciam intrigantes se torna óbvio.
Sessões fixas terminam cedo às vezes. Você pediu uma sessão de dez minutos e ela durou quatro, porque o dispositivo subjacente ficou offline. Uma sessão fixa é um melhor esforço para manter um endereço por uma duração, não um contrato de infraestrutura, e código que presume o contrário quebra intermitentemente. Trate isso como um evento normal: detecte a mudança e reinicie a sequência em vez de tratá-la como um erro, conforme sticky versus rotating.
O mesmo endereço se repete. A rotação seleciona de forma independente a cada vez em vez de percorrer uma lista sem repetição, então repetições são esperadas, e se tornam frequentes quando um filtro estreito reduz o conjunto elegível. Isso é aritmética, não uma falha, e é uma das causas abordadas em IP não rotaciona.
O desempenho varia entre endereços. São conexões de consumidor com sua própria largura de banda, congestionamento e uso doméstico, então a latência tem uma distribuição muito mais ampla do que a infraestrutura de datacenter. Percentis são a forma honesta de descrevê-la; médias escondem a cauda que de fato afeta seu cronograma.
A disponibilidade se move ao longo do dia. Um trabalho que tem sucesso às 20:00 e enfrenta dificuldades às 04:00 no mesmo mercado geralmente está enxergando a profundidade diurna do pool, e não uma mudança no alvo.
Os resultados diferem entre duas execuções do mesmo trabalho. Endereços diferentes, redes diferentes, reputações diferentes. Alguma variância é inerente, e tratar toda flutuação como uma regressão desperdiça muita investigação.
Projetando para uma população
Consequências práticas para quem constrói sobre essa base.
Trate os endereços como descartáveis e as rotas como a unidade que você gerencia. Você nunca escolheu um endereço e não pode mantê-lo, então o rastreamento de saúde pertence ao nível de rota e sessão, que é o modelo descrito em monitorando a saúde de proxies em escala e construindo um gerenciador de proxies.
Torne os trabalhos retomáveis e idempotentes. Se uma sessão pode desaparecer no meio de uma sequência, a sequência precisa ser reiniciável sem duplicar trabalho ou corromper um registro.
Escolha os TTLs deliberadamente. Um TTL longo é um pedido, não uma garantia, e solicitar uma hora em uma conexão de consumidor o predispõe a quedas no meio do fluxo. Peça o que o fluxo realmente precisa.
Meça seu pool efetivo em vez de ler um número de marketing: amostre algumas centenas de saídas sob seu filtro real, conte endereços e organizações distintas, e repita nos horários em que você executa. Esse número, não o número de destaque, é o que deveria orientar as decisões de concorrência e distribuição, junto com o raciocínio em quantos IPs de proxy você realmente precisa.
E programe considerando a população, já que executar um trabalho pesado para um mercado pequeno durante suas horas noturnas é lutar contra o pool sem motivo.
Como se parece uma boa gestão de pool vista de fora
Você não pode auditar os componentes internos de um provedor, mas os efeitos são observáveis. Taxas de sucesso consistentes ao longo das horas em que você executa sugerem que o pool é profundo o suficiente nos seus mercados, e não apenas grande em agregado. Uma ampla dispersão de organizações de ISPs de consumidor em sua amostra de saída sugere um fornecimento residencial genuíno em vez de um diluído, que é a verificação descrita em identificando IPs de datacenter vendidos como residenciais. Uma geolocalização que corresponde ao que os alvos de fato acreditam, e não apenas ao que um serviço de consulta reporta, sugere que a rotulagem geográfica é mantida. E um provedor que consegue descrever sua origem sem desconforto está lhe dizendo algo sobre como o pool é gerenciado de modo geral.
Conclusão
Um pool residencial é uma população, não um estoque. Ele é montado por meio de participação em vez de comprado, seu formato acompanha o software que as pessoas realmente usam, e ele se renova continuamente conforme dispositivos ficam offline, endereços são reatribuídos, e participantes entram e saem. Essa única propriedade explica sessões fixas terminando cedo, endereços se repetindo, latência variando amplamente, disponibilidade se movendo ao longo do dia, e duas execuções idênticas produzindo resultados diferentes. Projete para isso: trate os endereços como descartáveis, rastreie a saúde por rota, torne as sequências retomáveis, escolha TTLs que correspondam ao fluxo, e meça o seu pool efetivo sob seus próprios filtros nos seus próprios horários em vez de confiar em um número de destaque que descreve outra coisa que não aquilo que de fato o restringe.
É sobre esse pool que os proxies residenciais se apoiam, abrangendo 195 países com filtros de país, região, cidade e ASN, e preços por GB, de modo que medir sua própria disponibilidade efetiva custa apenas a largura de banda que o teste utiliza.