Quando os proxies residenciais surgiram como produto comercial por volta de 2012, o modelo de precificação dominante era a “porta” ou “canal”. Você comprava um plano que dava, digamos, 100 portas. Cada porta era uma única conexão simultânea. Se precisasse de mais concorrência, comprava um plano maior.
Esse modelo se encaixava no mercado por um tempo. Ele correspondia à forma como os clientes pensavam sobre escala naquela época. Tornava as faturas previsíveis. Funcionou bem o suficiente para que a maior parte da indústria o mantivesse até meados dos anos 2010.
Também deixou de fazer sentido, gradualmente, e depois de repente.
Por que as portas faziam sentido no início
Os primeiros casos de uso para proxies residenciais eram restritos. Bots de sneakers, bots de ingressos, scrapers de nicho. Cargas de trabalho em que você executava um número conhecido de sessões paralelas e precisava que cada sessão parecesse distinta. Um plano baseado em portas era um mapeamento direto para esse modelo mental: uma porta, uma sessão, comportamento previsível.
As próprias redes de proxy eram pequenas. Pools de algumas centenas de milhares de IPs, concentrados principalmente em um punhado de países. Os operadores não conseguiam sustentar concorrência ilimitada na prática, então expunham a concorrência como um eixo cobrável.
E as portas eram defensáveis economicamente. Um cliente com 100 portas era um tamanho significativamente diferente de um cliente com 10. A precificação acompanhava a escala aparente do cliente.
Por que as portas deixaram de funcionar
Três coisas aconteceram, mais ou menos em paralelo, que tornaram os planos baseados em portas o primitivo errado:
Os pools ficaram maiores em uma ordem de grandeza. O mercado de proxies residenciais se consolidou e escalou. Os principais provedores passaram de algumas centenas de milhares de IPs para mais de 100 milhões. A concorrência deixou de ser uma restrição significativa no nível da rede. Um cliente que pedia 1.000 conexões simultâneas não estava pedindo nada que a rede não pudesse entregar trivialmente.
As cargas de trabalho se afastaram do modelo mental de portas. A coleta de dados moderna não são 100 scrapers paralelos rodando de forma constante durante um mês. É um fan-out em rajadas: mil requisições às 9h de segunda-feira para uma atualização de preços, e depois tráfego quase zero até a segunda-feira seguinte. Ou é um scrape acionado por evento: um webhook dispara, você precisa de 50 requisições simultâneas por 90 segundos, e depois volta a zero. Alocações fixas de portas se encaixavam mal em qualquer um desses formatos. Ou você superprovisionava (pagando por capacidade ociosa) ou era limitado.
Os clientes pararam de querer pensar sobre isso. A pergunta real que os compradores se importam em responder é “quantos dados posso movimentar por meio disso?” Largura de banda é a unidade natural. Ela escala com a carga de trabalho. Ela corresponde a faturas parecidas com as da AWS: custo por unidade previsível, custo total determinado pelo uso real.
A transição
A mudança para a precificação por largura de banda levou cerca de cinco anos (2019-2024) para atingir a maior parte do mercado de proxies residenciais. Não porque alguém estivesse escondendo isso. Pura inércia: grandes clientes tinham contratos plurianuais em planos de portas, os planos de migração eram trabalhosos de escrever, e a maioria dos provedores queria manter os dois modelos vivos por tempo suficiente para dar aos compradores legados uma saída.
Em 2024, toda rede residencial séria da indústria oferecia precificação por largura de banda como padrão. A Shifter inclusive. Mantivemos os planos legados de portas disponíveis para clientes que haviam construído sua infraestrutura em cima deles, esse compromisso legado continua valendo, mas tudo que era novo passou a ser precificado por largura de banda.
O que a precificação por largura de banda realmente muda
Algumas coisas ficam mais fáceis e uma fica mais difícil.
Mais fácil, comprar. “Preciso fazer scrape de cerca de 200 GB de páginas por mês” é uma frase que um cliente consegue escrever antes mesmo de ter construído algo. “Preciso de 80 portas” é uma frase que exige rodar a carga de trabalho primeiro para descobrir.
Mais fácil, prever. A largura de banda escala linearmente com os dados que você está movimentando. Dobrar a frequência do scrape dobra a largura de banda. Triplicar, você triplica. Sem penhascos de limite, sem gargalos de concorrência no pico.
Mais fácil, faturar. Um único número na fatura. Sem “você usou 110% da sua concorrência mas apenas 40% do seu tráfego, aqui está a conta.” Os clientes sabem exatamente pelo que estão pagando.
Mais difícil, disciplina. Largura de banda é uma torneira aberta. Um scraper mal configurado que baixa todos os ativos da página quando só precisava do corpo HTML pode quadruplicar a largura de banda sem produzir nenhum dado útil a mais. Com portas, esse scraper teria esbarrado no limite de concorrência e o operador teria percebido. Com largura de banda, ele simplesmente aumenta a conta até que alguém audite o egress.
A mitigação é ser deliberado quanto ao formato das requisições. Não busque imagens quando você só quer dados de produto. Use Accept-Encoding: gzip (a maioria dos clientes já faz isso por padrão, mas vale a pena verificar). Remova parâmetros de consulta que disparam pacotes de ativos. Faça HEAD antes de GET se você só precisa dos códigos de resposta.
Para onde a indústria vai a partir daqui
A precificação por largura de banda venceu no mercado residencial. O próximo eixo de diferenciação não é mais o modelo de precificação, é o que vem incluído, quais recursos são gratuitos e o que conta contra o medidor de largura de banda.
Alguns exemplos de onde os provedores estão se diferenciando em 2026:
Precificação de sessão sticky. Alguns provedores cobram a largura de banda de sessão sticky com um adicional. Nós não, sessões sticky são cobradas na mesma taxa que a rotação por requisição.
Segmentação geográfica como recurso. Alguns provedores cobram a segmentação em nível de cidade ou de ASN como um upgrade. Nós não, toda a precisão geográfica está incluída em todos os planos.
Limites de concorrência. Alguns provedores ainda impõem limites de concorrência além das cotas de largura de banda. Nós não, conexões simultâneas ilimitadas em todos os planos.
API e painel. Agora que a largura de banda é o medidor, os clientes querem visibilidade. Quantos GB por endpoint, por geo, por sessão, com granularidade de hora. Isso agora é o mínimo esperado, não um recurso premium.
Para os compradores, a lição é a mesma de sempre para qualquer categoria de infraestrutura: leia as letras miúdas sobre o que é cobrado e o que está incluído. A taxa de destaque por GB não significa nada se metade dos recursos que você realmente vai usar geram cobranças extras.
Olhando para frente
A precificação por largura de banda não é a forma final. Conforme as cargas de trabalho continuam a migrar para agentes de IA que fazem um pequeno número de requisições de alto valor, em vez de scrapers que se espalham em fan-out por milhões de requisições de baixo valor, modelos de precificação por requisição ou por taxa de sucesso provavelmente vão ressurgir para verticais específicas.
Por enquanto, no entanto, a largura de banda se consolidou como a unidade certa. A era da porta cumpriu seu propósito, e ela acabou.