A maioria das pessoas que compra proxies pela primeira vez trata isso como uma única pergunta, qual plano, e acaba escolhendo apenas pelo preço. Isso costuma gerar um de dois resultados: um plano pequeno demais para o trabalho, descoberto na metade do mês, ou um plano comprado para uma capacidade que nunca é usada. Nenhum dos dois é realmente um erro de precificação. Eles vêm de pular as duas decisões que deveriam acontecer antes mesmo de olhar para o preço.
Escolher bem é uma sequência de três decisões: que tipo de proxy o seu projeto precisa, quanta largura de banda esse projeto realmente vai consumir, e quais recursos são genuinamente necessários em vez de apenas listados. Acerte essas três e o plano se escolhe sozinho.
Decisão um: de qual produto o seu projeto precisa
Os tipos de produto não são níveis de uma mesma coisa. Eles se comportam de forma diferente, e escolher o errado não se resolve comprando mais dele.
Residencial rotativo é o padrão para coleta de dados. Você utiliza um grande pool de endereços residenciais reais e, por padrão, cada requisição sai por um endereço diferente, o que distribui seu volume para que nenhum endereço isolado chame atenção. Escolha esta opção quando o trabalho for scraping, monitoramento de preço ou disponibilidade, coleta de SERP e ranking, verificação de anúncios, ou qualquer tarefa cujo formato seja muitas requisições em muitos alvos ou mercados.
Residencial estático, ou proxies ISP, são endereços hospedados registrados em um provedor de internet de consumo, portanto carregam confiança de nível residencial mas permanecem os mesmos ao longo do tempo. Escolha esta opção quando persistência é o requisito, e não volume: gerenciar contas que devem sempre ser vistas a partir do mesmo endereço, sessões de longa duração, ou qualquer situação em que um endereço mudando por baixo dos panos seja o problema, não a solução. O trade-off é abordado em ISP versus residencial e o que são proxies residenciais estáticos.
Datacenter é o mais barato e mais rápido, e é a resposta certa quando seus alvos não se importam. Se você está acessando uma API aberta, sua própria infraestrutura, ou sites sem defesas relevantes, pagar preços residenciais é desperdício. A comparação honesta está em residencial versus datacenter.
A regra prática é usar o tipo mais barato que consistentemente passa pelos seus alvos reais, e estabelecer isso por meio de testes em vez de suposições. Muitos projetos acabam mistos: datacenter para as fontes fáceis, residencial para as defendidas.
Decisão dois: quanta largura de banda
Proxies residenciais são cobrados por dados transferidos, não pelo número de endereços que você utiliza, então largura de banda é o número que determina seu plano. O raciocínio por trás desse modelo está em por que a era do preço por porta acabou, e o método de dimensionamento é direto.
Estime o tamanho médio de uma resposta dos seus alvos, multiplique pelo número de requisições que você espera em um mês, e adicione margem para retentativas e falhas. Uma página HTML simples ou uma resposta de API JSON costuma ter dezenas de kilobytes; uma página completa renderizada em um navegador, com imagens, fontes e scripts, pode chegar a vários megabytes, o que é a maior variável de todo o cálculo. Dez mil chamadas JSON por dia é um plano muito diferente de dez mil páginas totalmente renderizadas por dia, e a diferença é de aproximadamente duas ordens de grandeza. O método detalhado está em estimando a largura de banda mensal.
Duas coisas reduzem esse número antes da compra. Buscar o endpoint de dados subjacente em vez de renderizar a página inteira é a maior alavanca, e bloquear imagens, mídia e fontes quando você realmente precisa renderizar é a segunda, ambas abordadas em cortando custos de largura de banda de proxy. Vale a pena fazer essa otimização antes de dimensionar um plano, porque ela pode fazer você descer um nível.
Note o que não está nesta lista: quantos IPs você recebe. Em uma rede compartilhada essa não é a quantidade que você compra, e o raciocínio está em quantos IPs de proxy você realmente precisa. A única exceção são sessões sticky simultâneas, que é um requisito real a ser declarado se o seu trabalho precisa de identidades mantidas.
Decisão três: quais recursos são realmente necessários
As listas de recursos são onde os planos começam a parecer complicados. Na maior parte, isso se reduz a cinco perguntas.
Granularidade geográfica. Segmentação por país cobre a maioria dos projetos. Se o seu trabalho depende de resultados locais, preços locais, ou dados no nível de loja, você precisa de segmentação em nível de cidade, e se você lida com comportamento específico de operadora, precisa de segmentação por ASN. Verifique se os países que importam para você têm boa cobertura, não apenas se um grande número global é anunciado.
Controle de sessão. Confirme que você pode tanto rotacionar por requisição quanto manter uma sessão sticky quando um fluxo de múltiplas etapas precisar. A maioria dos projetos reais precisa de ambos em momentos diferentes.
Concorrência. Pergunte qual limite se aplica a conexões simultâneas, porque um plano que mede concorrência separadamente vai estrangular um trabalho que um plano baseado apenas em largura de banda executaria com folga. Veja conexões simultâneas ilimitadas.
Protocolos e integração. HTTP e SOCKS5 cobrem quase tudo; o que importa mais é que a segmentação seja expressa de uma forma que a sua stack consiga controlar por requisição, o que, em um gateway, significa credenciais no nome de usuário em vez de um botão no painel.
Todo o resto geralmente é secundário até você operar em escala, momento em que a capacidade de resposta do suporte e a flexibilidade de faturamento passam a importar mais do que qualquer item de recurso na lista.
Combinando formatos comuns de projeto com planos
Alguns padrões cobrem a maioria das primeiras compras.
Um projeto pequeno de pesquisa ou monitoramento, acompanhando algumas centenas de páginas diariamente, costuma exigir alguns gigabytes por mês em residencial rotativo com segmentação por país. Comece no menor nível que atenda sua estimativa com margem, já que subir depois é fácil e comprar um nível grande para um projeto ainda não validado não é.
Um pipeline de scraping em produção com muitos alvos é onde a estimativa de largura de banda se justifica, e onde o trabalho de otimização se paga diretamente. Dimensione com base no uso medido em um teste, não em um chute, e espere que o número real difira da sua estimativa em ambas as direções.
Trabalho baseado em contas ou sessões aponta para endereços ISP estáticos e um número declarado de sessões simultâneas, em vez de um grande pool rotativo.
Cargas de trabalho mistas são comuns e não há problema nisso: datacenter para fontes sem defesa, residencial para o resto. Dimensionar cada uma separadamente é mais barato do que fazer tudo passar pelo caminho caro.
Valide antes de se comprometer
Seja qual for sua conclusão, trate-a como uma hipótese e teste em um trial ou em uma pequena primeira compra antes de escalar. Execute contra seus alvos reais, não uma URL de teste genérica, e meça a taxa de sucesso com validação de resposta em vez de apenas códigos de status, já que uma página de desafio retornada com um 200 vai parecer um sucesso se não for verificada. Confirme que a geografia pela qual você pagou é a geografia que você recebe. Meça os bytes reais por requisição para que sua estimativa de largura de banda vire uma medição. O método está em testando velocidade, taxa de sucesso e precisão de localização, e os critérios em nível de provedor estão em como escolher uma rede de proxy.
Uma semana de uso real diz mais do que qualquer ficha técnica, e converte as três decisões acima de estimativas em fatos.
Conclusão
Escolha o tipo de produto pelo que seus alvos exigem, não pelo preço: residencial rotativo para volume e geografia, ISP estático para persistência, datacenter onde os alvos não se importam. Dimensione o plano pela largura de banda, o que significa estimar o tamanho da resposta multiplicado pelo volume de requisições e otimizar o que você busca antes de comprar, já que isso sozinho pode fazer você descer um nível. Exija apenas os recursos que o seu projeto realmente usa, sendo granularidade geográfica e controle de sessão os dois que mais costumam importar. Depois, valide em alvos reais antes de escalar, porque uso medido supera qualquer estimativa.
Se isso apontar para residencial rotativo, proxies residenciais oferecem segmentação por país e cidade, rotação por padrão, e sessões sticky quando um fluxo precisa, com preço por GB para que o plano acompanhe os dados que você realmente move, em vez de uma contagem de assentos ou uma alocação de portas.