Os proxies residenciais são mesmo residenciais? Como medir um pool

Todos os fornecedores de proxies residenciais publicam um tamanho de pool. Nenhum publica a composição do pool — quanto dele é realmente uma linha de banda larga doméstica e quanto é um servidor num centro de dados com rótulo residencial. É esse segundo número que decide se o prémio residencial que está a pagar compra alguma coisa. E mede-se numa tarde com ferramentas gratuitas.

Esta página é ao mesmo tempo o método e o resultado: a regra exata, os comandos exatos, o tamanho da amostra fixado à partida e aquilo que a execução produziu — publicado tal como foi medido.

O que o rótulo «residencial» promete de facto

Um proxy residencial é vendido com a premissa de que o seu endereço de saída pertence a uma ligação de internet de consumo, para que o tráfego pareça uma pessoa comum a navegar e não uma máquina num bastidor. É essa toda a proposta de valor, e é por isso que a largura de banda residencial custa várias vezes a de centro de dados. A diferença é explicada em proxies residenciais vs. de centro de dados, e a mecânica de base em o que é um proxy residencial.

O que o rótulo não promete é que cada endereço do pool cumpra essa descrição. Um pool é montado — a partir de parcerias de SDK, de aplicações de recompensas, de revendedores, de outras redes de proxies. E quanto mais longe um endereço está da cadeia de fornecimento do próprio fornecedor, menos este consegue dizer sobre ele. O nosso raciocínio sobre por que essa cadeia merece escrutínio está em obtenção ética de proxies.

Existe portanto uma diferença entre o rótulo e os endereços, essa diferença é um número, e esse número é verificável. Ninguém o verifica — é a única razão pela qual esta página é interessante.

O método, fixado antes da execução

Quatro decisões definem esta medição. As quatro foram tomadas antes de qualquer recolha de dados, e as quatro estão publicadas para que a execução possa ser contestada em vez de apenas acreditada.

1. Apenas fontes livres e redistribuíveis

As redes de origem vêm do serviço público IP-to-ASN da Team Cymru e os tipos de rede da PeeringDB, que é CC BY — de uso e republicação livres com atribuição, que esta página dá.

A opção aparentemente mais fácil foi rejeitada após avaliação. O ip-api.com devolve diretamente um booleano hosting, um sinal mais rico do que qualquer reconstrução a partir de nomes de rede, mas os seus termos limitam o nível gratuito a uso não comercial num ambiente não comercial. Este site é monetizado, pelo que publicar números dele derivados violaria esses termos — o mesmo tipo de atalho que este texto critica nos fornecedores. Além disso, o nível gratuito é apenas HTTP, e uma medição cujo valor inteiro é a credibilidade não pode obter as suas entradas por um canal que qualquer intermediário consegue reescrever.

Essa rejeição tem custo, e é a principal razão pela qual o número principal é um limite inferior e não uma proporção exata.

2. Uma regra de classificação conservadora

Um endereço conta como alojamento quando o nome registado da sua rede de origem contém um dos termos de uma lista publicada — hosting, cloud, datacenter, colocation, hetzner, digitalocean, vps e semelhantes. Conta como residencial quando a PeeringDB regista a sua rede como Cable/DSL/ISP. Todo o resto fica não classificado e permanece no denominador.

Duas propriedades desta regra pesam mais do que a lista em si. O alojamento vence quando ambos os sinais disparam, porque a direção conservadora é não subdeclarar servidores num pool vendido como residencial. E os endereços cuja rede não foi possível resolver ficam no denominador em vez de serem descartados: encolher o denominador em silêncio inflacionaria a proporção que interessa ao leitor, que é precisamente a manobra que esta medição existe para verificar noutros.

3. Um tamanho de amostra escolhido à partida

1.087 IP de saída únicos, o tamanho que dá uma margem de mais ou menos dois pontos percentuais com 95 % de confiança para uma proporção próxima de 13 %. O script de medição recusa arrancar sem um tamanho de amostra explícito e imprime o método completo antes do primeiro pedido, pelo que o número não pode ser afinado em silêncio depois de os dados chegarem.

4. Cada número traz o seu intervalo

As proporções são reportadas com um intervalo de score de Wilson a 95 % em vez de uma percentagem nua. Wilson e não a aproximação normal porque, em proporções próximas de zero, o intervalo normal desce abaixo de zero e reporta um limite inferior que não pode existir. Uma estatística de pool sem intervalo convida o leitor a tratá-la como exata — o erro contra o qual todo este texto argumenta.

Resultados

A tabela apresenta a medição mais recente de cada pool. Todas as medições alguma vez publicadas, incluindo as ultrapassadas, permanecem no JSON em /data/pool-composition.json, com licença CC BY 4.0, a par do tamanho da amostra, do intervalo, da regra de classificação exata que cada execução usou e de uma contagem por rede que permite a qualquer pessoa reclassificá-la sem voltar a amostrar o pool.

A execução de 17 de setembro de 2026: DataImpulse, residencial dos EUA

Configuração. O pool residencial padrão da DataImpulse, direcionado aos Estados Unidos no painel, sessão rotativa, segmentação por defeito, filtro de anonimato desligado, sem exclusões de ASN — o pool que um cliente recebe sem tocar numa única definição. 1.120 pedidos através do proxy produziram os 1.087 endereços de saída únicos fixados de antemão. Resolveram-se em 131 redes de origem, todas classificadas contra uma única exportação da PeeringDB com 35.393 redes, obtida no mesmo dia às 06:12 UTC. A execução consumiu cerca de 1 MB de tráfego de avaliação que a DataImpulse forneceu gratuitamente, o que fica aqui registado porque é o tipo de coisa que deve ficar.

Alojamento: pelo menos 5,1 %. 55 das 1.087 saídas vieram de redes cujo nome registado diz centro de dados — um intervalo de 95 % de 3,9 % a 6,5 %. A lista é curta e concreta: 45 das 55 eram Leaseweb USA, em oito dos seus sítios (Dallas, Washington, Los Angeles, Miami, Phoenix, Chicago, Nova Iorque e Seattle); nove eram Colocation America; uma era Dedicated.com. Lida como limite inferior, é uma saída em cada vinte a vir de um bastidor de alojamento, num pool vendido e cobrado como residencial.

ISP de consumo: 43,0 %. 467 saídas estavam em redes que a PeeringDB regista como acesso por cabo, DSL ou ISP — Comcast (109), RCN (98), Charter (81 em seis registos), T-Mobile (40), Cox (28) e Windstream (20) à cabeça. Estas contagens dizem respeito apenas a este grupo: a Charter tem mais quatro registos, 22 saídas, aos quais a PeeringDB não atribui tipo algum, e que caem nos não classificados mais abaixo. São estes os endereços que o rótulo residencial promete.

Não classificado: 52,0 %, e desta vez é um facto sobre o pool. Uma tentativa anterior desta execução teve de ser descartada quando a PeeringDB limitou a meio as consultas rede a rede, o que teria transformado «não classificado» numa medida do serviço de consulta. Esta execução julgou cada rede contra uma única exportação, pelo que as 565 saídas não classificadas se decompõem com clareza:

• 334 (30,7 %) estão em redes de que a PeeringDB não tem registo nem tipo. Quatro operadores somam 215 — DynaNode LLC (83), Rocks Computer Services (77), eSited Solutions (28) e Flash Edge Information Technology (27). Nenhum é um nome que apareça numa fatura de banda larga doméstica; nenhum tem tampouco um nome que a regra publicada reconheça como alojamento, por isso a regra não os conta. Entre os quatro são uma saída em cada cinco. O que são é a maior questão em aberto deste resultado.
• 194 (17,8 %) estão registadas como NSP — fornecedores de serviços de rede como Verizon Business (61), AT&T (57), Frontier (25) e CenturyLink (9). Estes operadores também vendem linhas de consumo, pelo que este grupo pende provavelmente para o residencial; a regra não o presume.
• 32 (2,9 %) estão registadas como Content — Enzu, Hype Enterprises, Latitude.sh e Psychz Networks entre outros, operadores que na prática são negócios de alojamento mas cujos nomes não o dizem.
• 5 (0,5 %) correspondem a tipos de registo isolados — Educational/Research (2), Non-Profit (1), Network Services (1) e Enterprise (1). Poucas demais para mover o resultado, listadas para que os quatro grupos somem 565.

Juntando as peças, a verdadeira proporção de alojamento desta amostra fica algures entre os 5,1 % que a regra consegue provar e cerca de 8 % se o grupo Content for contado, enquanto a proporção de consumo fica entre 43 % e cerca de 61 % se os operadores NSP forem incluídos. Os dois operadores que decidem onde nesse intervalo está a verdade são a DynaNode e a Rocks Computer Services, 160 saídas entre ambas. A regra de classificação não foi alterada depois de estes nomes aparecerem: acrescentá-los agora seria escolher a resposta depois de ver os dados, a prática que esta página existe para recusar.

O que isto diz e não diz sobre o número da Proxyway. O benchmark da Proxyway de abril de 2026 colocou cerca de uma saída norte-americana em cada oito num servidor, usando a base de dados de tipo de utilização da IP2Location. Esta execução não pode confirmar nem contradizer esse número — entrada diferente, regra diferente, grandeza diferente — e não o tenta. O que se pode dizer é que uma regra livre, conservadora e baseada apenas em nomes já encontra uma saída em cada vinte a vir de centros de dados identificáveis pelo nome, e que a direção dos dois resultados é a mesma.

Resposta do fornecedor, 19 de setembro de 2026. Estes números foram enviados à DataImpulse antes da publicação, como prometido; a empresa já nos tinha dito por escrito que não mede nem publica um número de composição próprio. Depois de verificar as quatro redes por explicar com a sua equipa técnica, respondeu:

• A DynaNode LLC e a eSited Solutions são fornecedores de centros de dados, nas palavras da própria DataImpulse, e a empresa diz que já pediu à sua equipa técnica que as exclua ambas do pool residencial.
• A Rocks Computer Services e a Flash Edge Information Technology não as consegue confirmar como fornecedores de centros de dados com a informação de que dispõe, e diz que continuarão no pool.

Somando as duas redes que o fornecedor identifica às 55 saídas que a regra já conta, pelo menos 166 das 1.087 saídas — 15,3 %, com um intervalo de 95 % de 13,3 % a 17,5 % — vieram de centros de dados confirmados. A DataImpulse fez ela própria esse cálculo e pediu que fosse citado o número mais alto: «Preferimos que esse número seja exato a que seja subestimado.» É raro um fornecedor rever em alta o seu próprio número, e isso fica aqui reconhecido. A 29 de setembro a DataImpulse confirmou mais três operadores desta amostra como fornecedores de centro de dados, o que reexprime esta execução em 17,3 %; a correção está na secção de 26 de setembro, mais abaixo.

A medição publicada não muda. A regra continua a indicar 5,1 %, porque foi fixada antes da execução e a confirmação do fornecedor é uma evidência que a regra nunca viu; os 15,3 % ficam ao lado, como um número à parte e atribuído, em vez de serem incorporados nela. Estão acima dos cerca de 13 % da Proxyway, embora os dois continuem a vir de métodos diferentes. Ficam em aberto 104 saídas (9,6 %) na Rocks Computer Services e na Flash Edge: se ambas fossem também centros de dados, a proporção confirmada desta amostra chegaria a 24,8 %, e nada aqui indica que sejam.

A DataImpulse tinha oferecido tráfego de avaliação novo para um novo teste depois de concluídas as exclusões, e comunicou essa conclusão a 22 de setembro. Essa medição é relatada abaixo, como uma segunda execução datada ao lado desta e não em seu lugar.

A medição de 22 de setembro de 2026: depois da limpeza

Montagem. Idêntica à primeira medição de propósito — o mesmo pool residencial padrão, a mesma segmentação para os Estados Unidos, a mesma sessão rotativa e as mesmas predefinições, o mesmo tamanho de amostra pré-registado (uma nova extração de 1.087 saídas únicas a partir de 1.120 pedidos através do proxy), e a mesma regra de classificação congelada, inalterada desde antes de ambas as execuções. Resolveram-se em 127 redes de origem, avaliadas contra uma exportação da PeeringDB de 35.441 redes gerada às 22:50 UTC e obtida às 23:25 UTC do mesmo dia. A DataImpulse voltou a fornecer o tráfego de avaliação e pediu que a medição esperasse até sinalizar o fim da sua limpeza. Foi um pedido razoável e foi aceite, mas condiciona o que o resultado pode significar — o último parágrafo desta secção diz exatamente isso.

Alojamento pela regra: 0,7 %. 8 das 1.087 saídas, um intervalo de 95 % de 0,4 % a 1,5 %, face aos 5,1 % anteriores. As oito eram Colocation America. A Leaseweb, que na primeira medição forneceu 45 saídas a partir de oito dos seus sítios norte-americanos, não forneceu nenhuma; a Dedicated.com também não.

ISP de consumo: 55,7 %, não classificadas 43,6 %. 605 saídas estão agora em redes que a PeeringDB regista como acesso por cabo, DSL ou ISP, face a 467 — lideram Comcast (174), RCN (112), T-Mobile (49) e Cox (42). O grupo não classificado desceu de 565 para 474 saídas.

As quatro redes por explicar, cinco dias depois. A eSited Solutions passou de 28 saídas para nenhuma, e a Rocks Computer Services de 77 para nenhuma. A Flash Edge caiu de 27 para 10. E a DynaNode LLC, a única das quatro que a DataImpulse tinha identificado positivamente como fornecedora de centro de dados e pedido à sua equipa que excluísse, passou de 83 saídas para 79: praticamente inalterada, e ainda a quarta maior fonte de endereços da amostra. A queda da Rocks para zero leu-se então como mais do que a DataImpulse se tinha comprometido, já que a 19 de setembro afirmou não conseguir confirmar a Rocks como centro de dados e que a rede ficaria. Não foi assim: uma semana depois a empresa apurou que a Rocks tinha sido removida por engano — a correção está abaixo.

Nada mudou para bastidores novos. Nem uma única rede com cinco ou mais saídas aparece nesta medição estando ausente da primeira. Vale a pena verificá-lo explicitamente, porque a forma mais fácil de passar um novo teste não é remover tráfego mas movê-lo para redes com outros nomes. Aqui, a queda é remoção.

Resposta do fornecedor, 24 de setembro de 2026 — entretanto retirada. Questionada sobre por que razão a DynaNode estava inalterada, a DataImpulse respondeu primeiro: «A DynaNode LLC opera sob dois ASN. Um foi removido (continha cerca de 6.500 IP). O segundo ASN está ainda em processo de exclusão. Foi por isso que ficaram 79 saídas no vosso novo teste.» Esse relato deixou de ser válido. Fica aqui em vez de ser apagado, porque uma correção cujo original o leitor não pode ver não é uma correção.

Duas partes desse relato não puderam ser confrontadas com o registo público. O AS400463 é o único ASN registado com o nome DynaNode nos dados públicos dos registos, e na amostra de 17 de setembro também não tinha aparecido qualquer segunda rede com esse nome. Nenhuma das observações provava fosse o que fosse por si só — um ASN pode estar registado em nome de outra entidade, e 6.500 endereços podem facilmente não produzir saída nenhuma em 1.087 extrações — pelo que ambas foram colocadas à DataImpulse em vez de publicadas como conclusão.

Correção da DataImpulse, 25 de setembro de 2026. A empresa verificou de novo e retirou a afirmação: «Não existe um segundo ASN da DynaNode. A rede que já tinha sido removida era a Rocks Computer Services, LLC, mas estava internamente marcada por engano como DynaNode. Isso explica também por que a Rocks caiu para zero no vosso novo teste enquanto o AS400463 se manteve presente.» O AS400463 é o ASN da DynaNode e, à data daquela medição, ainda estava no pool.

Essa correção traz uma consequência que não abona o resultado acima. A Rocks Computer Services foi removida por engano. A DataImpulse disse a 19 de setembro que não conseguia confirmar a Rocks como centro de dados e que a rede ficaria, e nada desde então alterou essa avaliação: aquelas 77 saídas saíram da amostra por causa de uma marcação interna errada, não porque alguém tenha concluído que deviam sair. Nessa rede, o pool ficou mais limpo pela razão errada. Saber se a exclusão é agora deliberada é uma pergunta colocada à empresa e ainda sem resposta.

Contado à maneira do fornecedor: 8,0 %. Somando a DynaNode, que a DataImpulse identifica como centro de dados, às 8 saídas que a regra conta, 87 das 1.087 saídas — 8,0 %, com um intervalo de 95 % de 6,5 % a 9,8 % — vinham de centros de dados confirmados, contra 15,3 % cinco dias antes. As 10 saídas restantes da Flash Edge levariam o valor a 8,9 % se também esta fosse alojamento, o que nada aqui estabelece. Tal como na primeira medição, o valor publicado mantém-se no que a regra reporta: 0,7 % é o número que o método produziu, e 8,0 % fica ao lado como número distinto e atribuído. Esse valor também foi ultrapassado: a mesma confirmação de 29 de setembro reexprime esta execução em 10,1 %, como expõe a correção abaixo.

O que esta medição não pode mostrar. Foi feita depois de o fornecedor saber exatamente que redes estavam a ser verificadas e de nos dizer que tinha terminado. Mostra que essas redes desapareceram desta amostra. Não mostra que o pool esteja mais limpo em geral, e um pool pode estar limpo durante uma semana. Estavam previstas mais duas execuções, com a mesma regra congelada e o mesmo tamanho de amostra pré-registado: uma assim que a DataImpulse confirmasse a exclusão do AS400463 — é a execução relatada a seguir — e outra algumas semanas depois, numa data não anunciada com antecedência.

A medição de 26 de setembro de 2026: a rede que o fornecedor indicou desapareceu

Montagem. De novo inalterada — o mesmo pool residencial padrão, a mesma segmentação para os Estados Unidos, a mesma sessão rotativa e as mesmas predefinições, 1.087 saídas únicas retiradas de 1.120 pedidos através do proxy, e a mesma regra de classificação congelada. Resolveram-se em 125 redes de origem, avaliadas contra uma exportação da PeeringDB de 35.475 redes gerada às 01:01 UTC e obtida às 01:22 UTC do mesmo dia. A DataImpulse confirmou a 25 de setembro a remoção do AS400463 e convidou à execução; o tráfego de avaliação foi de novo fornecido pela empresa.

DynaNode: de 79 saídas para nenhuma. O AS400463 não apareceu uma única vez em 1.087 extrações. A rede que a DataImpulse identificou como fornecedora de centro de dados a 19 de setembro, e que três dias depois era ainda a quarta maior fonte de endereços da amostra, desapareceu. Das outras três redes acompanhadas desde a primeira medição, a eSited Solutions e a Rocks Computer Services continuam ausentes, e a Flash Edge, que a DataImpulse disse não poder confirmar como centro de dados, voltou a descer, de 10 saídas para 4.

Alojamento pela regra: 0,7 %. De novo 8 das 1.087 saídas, um intervalo de 95 % de 0,4 % a 1,5 % — sete da Colocation America e uma da IHOR Hosting.

Correção, 29 de setembro de 2026: isto foi primeiro publicado como uma convergência, e não era. Aqui afirmava-se que os 0,7 % da regra e a identificação da própria DataImpulse tinham chegado ao mesmo número pela primeira vez na série. Três dias depois a empresa confirmou que a Hype Enterprises, a Enzu Inc e a Psychz Networks — os operadores que o parágrafo abaixo listava como por explicar — são fornecedores de centro de dados, e que tinha excluído os seus ASN. Esses três forneciam 28 saídas desta amostra. Contada à maneira do fornecedor, esta execução é de 36 das 1.087 saídas, 3,3 %, com um intervalo de 95 % de 2,4 % a 4,6 %: não 0,7 %, e não uma convergência.

A mesma confirmação alcança o passado, porque os três operadores estavam presentes em todas as amostras. Reexpressa com base no que a DataImpulse já confirmou, a série lê-se assim:

• 17 de setembro: 5,1 % pela regra, 17,3 % confirmados (188 de 1.087 saídas), publicados na altura como 15,3 %.
• 22 de setembro: 0,7 % pela regra, 10,1 % confirmados (110 saídas), publicados na altura como 8,0 %.
• 26 de setembro: 0,7 % pela regra, 3,3 % confirmados (36 saídas), publicados na altura como 0,7 %.

A direção mantém-se e a melhoria é real. O que mudou foi a distância entre as duas colunas — e esse é o argumento deste artigo virado contra si próprio. Entre 22 e 26 de setembro a regra não saiu dos 0,7 %, enquanto a quota confirmada era de 10,1 % e depois de 3,3 %. Nenhuma destas revisões nasceu de uma alteração do pool. A única variável foi quais redes tinham sido apresentadas ao fornecedor pelo nome. Um limite inferior não é uma estimativa, e todos os números que a regra produz devem ser lidos como o piso que são.

ISP de consumo: 61,8 %, não classificadas 37,4 %. Ao longo das três medições, a quota de consumo passou de 43,0 % para 55,7 % e depois 61,8 %, e a não classificada de 52,0 % para 43,6 % e depois 37,4 %. Lideram Comcast (172) e RCN (146), seguidas de T-Mobile (60), Cox (52) e Cablevision (31); a Charter soma 101 saídas nos seus registos do grupo de consumo.

Também desta vez nada mudou para bastidores novos. Aparece aqui uma rede com cinco ou mais saídas que faltava na segunda medição: a Castro Telecom (AS33733, 5 saídas), um segundo registo de um operador já presente, e não um nome de alojamento. A prova mais forte é agregada: o grupo de redes de que a PeeringDB não tem registo nem tipo, contado como na primeira medição, ou seja, sem as saídas que a regra já conta como alojamento, desceu de 234 saídas para 140. Se o tráfego removido tivesse sido apenas reetiquetado em redes com outros nomes, esse grupo teria crescido.

O que continuava por explicar e já não está. 38 saídas (3,5 %) estavam em operadores que a PeeringDB regista como Content — entre eles Hype Enterprises (12), Enzu (11) e Psychz Networks (5) — empresas de alojamento cujos nomes registados a regra não reconhece. Esses três nomes foram apresentados à DataImpulse, que confirmou a 29 de setembro que os três são fornecedores de centro de dados e que tinha excluído os seus ASN. É nessa confirmação que assenta a correção acima. Cinco operadores mais pequenos do mesmo grupo — Clouvider (3 saídas), PEG TECH (2), H4Y Technologies (2), Railway (2) e Antbox Networks (1) — foram também apresentados à empresa e continuam sem resposta.

O que esta medição resolve e o que não resolve. Resolve que o AS400463 saiu do pool, que é aquilo para que foi feita. Não resolve que o pool fique assim, porque todas as execuções desta série foram feitas em datas que o fornecedor conhecia de antemão — e a execução relatada a seguir, três dias depois, é a demonstração mais clara de por que esse limite importa.

A medição de 29 de setembro de 2026: a regra marca 0,1 %, e é o número menos útil deste artigo

Montagem. Inalterada — o mesmo pool, a mesma segmentação para os Estados Unidos, as mesmas predefinições, 1.087 saídas únicas de 1.120 pedidos através do proxy, a mesma regra congelada. Resolveram-se em 124 redes de origem, avaliadas contra uma exportação da PeeringDB de 35.487 redes gerada às 08:21 UTC e obtida às 08:51 UTC do mesmo dia. A DataImpulse tinha comunicado nessa mesma manhã que excluíra a Hype Enterprises, a Enzu e a Psychz Networks, e convidou à execução.

As redes confirmadas desapareceram, todas. A Hype Enterprises passou de 12 saídas para nenhuma, a Enzu de 11 para nenhuma, a Psychz Networks de 5 para nenhuma. DynaNode, eSited, Rocks Computer Services e Leaseweb mantiveram-se em zero. Todas as redes que a DataImpulse alguma vez confirmou como centro de dados estão agora ausentes da amostra.

Alojamento pela regra: 0,1 %. Uma saída em 1.087, um intervalo de 95 % de 0,02 % a 0,5 % — um único endereço da Colocation America. É o valor mais baixo que este teste já produziu e, tomado isoladamente, diria que o pool está praticamente limpo.

Tomado isoladamente, estaria errado. A Flash Edge Information Technology (AS219329) fornecia 4 saídas a 26 de setembro e 75 a 29 de setembro — dezanove vezes mais em três dias, o suficiente para ser a segunda maior fonte de endereços da amostra. A Flash Edge é a rede que a DataImpulse nos disse a 19 de setembro não conseguir confirmar como fornecedora de centro de dados e que ficaria no pool. A PeeringDB não lhe atribui tipo e a regra não reconhece o seu nome, pelo que a regra não a consegue ver. Se a Flash Edge for um centro de dados, esta medição é de 76 das 1.087 saídas — 7,0 %, com um intervalo de 95 % de 5,6 % a 8,7 % — e não de 0,1 %.

Os grupos também recuaram. Os ISP de consumo caíram de 61,8 % para 56,3 % e os não classificados subiram de 37,4 % de volta para 43,6 %, desfazendo a maior parte do ganho da medição anterior. Duas redes com cinco ou mais saídas são novas desde a última medição: Grande Communications (14 saídas, registada como cabo de consumo) e GoCodeIT (7, sem tipo).

O que dizemos e o que não dizemos. Não dizemos que isto foi arranjado. Retirar quatro operadores em dez dias tem de deslocar esse tráfego para algum lado, e um fornecedor sobrevivente absorvê-lo é uma consequência banal, não prova de intenção. Dizemos algo mais estreito e mais difícil de contestar: o número de destaque da regra melhorou enquanto crescia a parte do pool que ela não consegue classificar — e esse crescimento recaiu quase todo na única rede sobre a qual o fornecedor tinha sido questionado e que se recusou a classificar. É exatamente a falha que uma estatística de pool isolada convida, e é por isso que esta página nunca publicou uma sozinha. A resposta da DataImpulse e o que a medição seguinte encontrou estão na secção de 13 de outubro, mais abaixo.

A medição de 13 de outubro de 2026: a regra não encontra nada, e a terceira maior rede da amostra está por classificar

Montagem. Inalterada — o mesmo pool, a mesma segmentação para os Estados Unidos, as mesmas predefinições, 1.087 saídas únicas de 1.120 pedidos através do proxy, a mesma regra congelada. Resolveram-se em 116 redes de origem, avaliadas contra uma exportação da PeeringDB de 35.608 redes gerada às 09:41 UTC e obtida às 10:06 UTC do mesmo dia. A 13 de outubro a DataImpulse disse-nos ter excluído os seis operadores restantes que lhe tínhamos colocado — Clouvider, PEG TECH, H4Y Technologies, Railway, Antbox Networks e Datacamp — e convidou à execução.

As exclusões mantiveram-se, com uma exceção. Clouvider, PEG TECH, H4Y Technologies, Railway e Antbox Networks não forneceram saídas. A Datacamp Limited (AS212238) forneceu 5, face a 10; colocou-se à empresa a questão de saber se a exclusão ainda está a propagar-se, e esta respondeu a 25 de outubro que, após uma revisão manual, classifica a Datacamp Limited (AS212238) e a GoCodeIT (AS835 / AS62513) como redes de centro de dados e está a removê-las ambas do pool residencial. A 27 de outubro a empresa disse-nos que ambas tinham sido removidas e convidou a uma nova medição, que se apresenta abaixo. Hype Enterprises, Enzu, Psychz Networks, DynaNode, eSited, Rocks Computer Services e Leaseweb mantiveram-se todas em zero.

Alojamento pela regra: nenhum. Nem uma das 1.087 saídas estava numa rede cujo nome registado a regra reconheça como alojamento — um intervalo de 95 % de 0 % a 0,4 %, e a primeira medição em que a regra não encontrou rigorosamente nada. Tomado isoladamente, diria que o pool está limpo.

Tomado isoladamente, estaria errado, outra vez. A Flash Edge Information Technology (AS219329) forneceu 105 saídas, 9,7 % da amostra — 27, 10, 4, 75 e 105 ao longo das cinco medições. Ficou em terceiro entre 116 redes, à frente de AT&T (70 saídas), Verizon (55), Frontier (53) e Cox (50); a maior outra rede para a qual a PeeringDB não tem tipo forneceu 21. A regra não a consegue ver. Se a Flash Edge for um centro de dados, esta medição é de 105 das 1.087 saídas — 9,7 %, com um intervalo de 95 % de 8,0 % a 11,6 % — e não de 0 %. Os ISP de consumo estavam em 58,0 % e as saídas não classificadas em 42,0 %, pouco alterados desde 29 de setembro, e nenhuma rede com cinco ou mais saídas é nova desde essa medição.

O que a DataImpulse nos disse sobre a Flash Edge. Questionada sobre por que razão a rede cresceu dezanove vezes entre 26 e 29 de setembro, a empresa escreveu a 13 de outubro que os seus IP residenciais são obtidos através da TraffMonetizer, «o nosso próprio serviço de fornecimento baseado em SDK», e que «Um fornecedor de IP dentro dessa rede começou a encaminhar endereços da Flash Edge para o pool, e é por isso que a contagem saltou entre 26 e 29 de setembro. Não foi organizado em resposta ao teste.» A Flash Edge Information Technology LLC opera o flashproxy.com, «que é ele próprio um serviço de proxies que oferece proxies de centro de dados, móveis, residenciais e residenciais premium», não coopera diretamente com a DataImpulse, e «A nossa melhor avaliação é que os IP deles entram no nosso pool através dos seus utilizadores finais que participam na TraffMonetizer, mas não o podemos confirmar com certeza.» Sobre excluí-la: «A Flash Edge opera uma rede mista. Se precisar de uma resposta binária para o artigo, a honesta é: ainda não sabemos se estes IP concretos são residenciais ou de centro de dados, e continuamos a rever.» A 25 de outubro respondeu que não compra endereços a outros fornecedores e que todo o seu fornecimento residencial, tanto da aplicação como do SDK, passa por clientes da TraffMonetizer, pelo que os endereços da Flash Edge entraram por esses clientes; não consegue determinar se são utilizadores finais da própria Flash Edge ou a própria Flash Edge a disponibilizar endereços da sua rede, e recusou divulgar quantas instalações ou IDs de parceiro existem por trás do AS219329. Disse que a TraffMonetizer verifica a qualidade de cada ligação antes de a passar à DataImpulse e não paga ligações com problemas; reproduzimo-la como declaração da fornecedora. A 27 de outubro acrescentou que a verificação não incide apenas na qualidade da ligação: cada IP é também cruzado com vários serviços de classificação de IP, que decidem se entra no pool residencial ou no de centro de dados, e que não pode partilhar mais nada sobre quem opera os clientes por trás do AS219329. A Flash Edge chegou, ainda assim, ao pool residencial e a empresa diz que continua sem a conseguir classificar, pelo que estas verificações não resolvem em que dispositivo a ligação corre. A empresa continua sem ter decidido se exclui a Flash Edge.

Como a DataImpulse encontra centros de dados. Questionada a 7 de outubro sobre como identifica uma rede de centro de dados antes de alguém a nomear, a empresa descreveu «um serviço interno que combina dados de três fontes: IP-API, DB-IP e um sistema proprietário que verifica endereços IP não só por localização mas também por tipo de proxy», filtra os IP segundo essa classificação e confirmou que paga pelo IP-API. Acrescentou: «O sistema existe e funciona de forma proativa, mas, como esta série mostrou, não detetou tudo o que o seu método encontrou.» Disse também que a Rocks Computer Services foi julgada operadora de servidores dedicados por uma revisão manual do fornecedor, dos seus serviços e da sua infraestrutura, e que nenhuma base de dados a classificou como ISP. Isto é um filtro, não uma medição: um filtro mostra o que removeu, não o que deixou escapar.

O que os registos públicos acrescentam, e o que não. O próprio sítio da Flash Edge, flashproxy.com, vende proxies de centro de dados, ISP, móveis e residenciais; diz que os seus IP residenciais são «obtidos através de parcerias com ISP», não faz qualquer afirmação sobre o consentimento dos utilizadores finais e não menciona a TraffMonetizer. Os dados do registo RIPE mostram que o AS219329 foi criado a 29 de junho de 2026 e anuncia 118 prefixos através de uma única rede a montante, a GoCodeIT Inc — um nome que também apareceu nas nossas amostras (27 saídas a 17 de setembro, 11 a 29 de setembro, nenhuma a 13 de outubro). Dos 108 prefixos cujo registo foi possível resolver, 22 estão em blocos de endereços registados com nomes RapidSeedbox, uma empresa de alojamento de seedbox e proxies. A data em que os prefixos foram anunciados pela primeira vez não explica o salto: surgiram entre julho e outubro, com o maior lote de 57 a 17 de setembro. Nada disto classifica a Flash Edge, e a regra não o usa. Ficam duas partes do relato da DataImpulse por conciliar: a empresa deu dois mecanismos — um fornecedor de IP dentro da rede a encaminhar endereços, e os próprios utilizadores finais da Flash Edge a participar na TraffMonetizer — e para um cliente da TraffMonetizer sair de um endereço que a rede da Flash Edge anuncia, o seu tráfego teria de estar dirigido a um proxy da Flash Edge. Ambas as questões, e quantas instalações distintas explicam estas saídas, foram colocadas à empresa.

A medição de 27 de outubro de 2026: a regra encontra duas saídas e a Flash Edge cai para 42

Montagem. Inalterada — o mesmo pool, a mesma segmentação para os Estados Unidos, as mesmas predefinições, 1.087 saídas únicas de 1.120 pedidos através do proxy, a mesma regra congelada. Resolveram-se em 107 redes de origem, avaliadas contra uma exportação da PeeringDB de 35.752 redes gerada às 03:03 UTC e obtida às 03:33 UTC do mesmo dia. A 27 de outubro a DataImpulse disse-nos que a Datacamp Limited (AS212238) e a GoCodeIT (AS835 / AS62513) tinham sido removidas do pool residencial e que podíamos voltar a medir quando nos conviesse; esta medição começou poucas horas depois.

As remoções mantiveram-se. A Datacamp não forneceu saídas, face a 5. Nenhum dos dois ASN da GoCodeIT forneceu alguma, tal como a 13 de outubro. Todas as outras redes que a DataImpulse alguma vez confirmou ou removeu — DynaNode, eSited, Rocks Computer Services, Hype Enterprises, Enzu, Psychz Networks, Leaseweb, Clouvider, PEG TECH, H4Y Technologies, Railway e Antbox Networks — mantiveram-se também em zero.

Alojamento pela regra: duas saídas. 2 das 1.087 saídas (0,18 %, intervalo de 95 % de 0,05 % a 0,67 %) estavam numa rede cujo nome registado a regra reconhece como alojamento: uma na Dedicated.com (AS63018), que também tinha fornecido uma a 17 de setembro, e uma na Mullcloud LLC (AS397006), que nenhuma medição anterior tinha visto. Nenhuma das duas foi colocada à DataImpulse. Uma única saída numa rede não é um padrão, e comunicamo-la porque a regra está congelada e o resultado é publicado seja ele qual for.

A Flash Edge caiu mais de metade, e nada do que nos disseram o explica. A Flash Edge Information Technology (AS219329) forneceu 42 saídas, 3,9 % da amostra (intervalo de 95 % de 2,9 % a 5,2 %) — 27, 10, 4, 75, 105 e 42 ao longo das seis medições. Ficou em sétimo entre 107 redes, atrás de RCN (176 saídas), Comcast (154), AT&T (64), Cox (64), Frontier (52) e Verizon (50), e à frente de Charter (38); a maior outra rede para a qual a PeeringDB não tem tipo forneceu 26. A regra não a consegue ver. Se a Flash Edge for um centro de dados, esta medição é de 44 das 1.087 saídas — 4,0 %, com um intervalo de 95 % de 3,0 % a 5,4 % — e não de 0,2 %. A mensagem da DataImpulse de 27 de outubro não disse nada sobre a Flash Edge, e a sua decisão sobre excluí-la continua pendente, pelo que não sabemos se a queda reflete uma alteração da DataImpulse, da TraffMonetizer ou da própria Flash Edge. Os ISP de consumo estavam em 64,9 % e as saídas não classificadas em 35,0 %, contra 58,0 % e 42,0 % a 13 de outubro, e nenhuma rede com cinco ou mais saídas é nova desde essa medição.

Flash Edge, a 28 de outubro. A DataImpulse escreveu de novo depois da medição. Nada mudou do seu lado: não excluiu nem ajustou a Flash Edge, e os endereços continuam a entrar no pool através da TraffMonetizer, onde, nas suas palavras, «someone is sharing IP addresses from this provider». Ainda não decidiu excluir a rede. Essa frase não diz a que dispositivo pertence a ligação nem como essa pessoa aceitou partilhá-la, pelo que a questão que levantámos a 13 de outubro não mudou.

Onde está a série. Seis execuções, uma regra congelada, um tamanho de amostra, todos os números publicados com o seu intervalo. Pela regra: 5,1 %, 0,7 %, 0,7 %, 0,1 %, 0,0 %, 0,2 %. Pelo que o fornecedor confirmou: 17,3 %, 10,1 %, 3,3 %; para as três últimas execuções, algures entre 0,1 % e 7,0 % (29 de setembro), entre 0 % e 9,7 % (13 de outubro) e entre 0,2 % e 4,0 % (27 de outubro), consoante uma única revisão que a DataImpulse não terminou. A direção ao longo dos 40 dias desde a primeira execução é genuinamente descendente, e a DataImpulse removeu todas as redes que lhe foram mostradas e que confirmou. Nada disso estabelece durabilidade, porque o fornecedor escolheu ou conheceu a data de todas as vezes, e a maior questão em aberto encolheu, mas não se fechou. A execução que testa isso é a última desta série: daqui a algumas semanas, numa data não anunciada, a partir de uma conta que a empresa não consiga identificar, paga por nós em vez de cedida como tráfego de avaliação. Mesma regra, mesmo tamanho de amostra, publicada ao lado destas seis, diga o que disser.

Faça a verificação você mesmo, antes de pagar

A versão útil deste artigo é aquela que você executa contra o pool que está prestes a comprar. Rode o endpoint, recolha endereços de saída únicos e depois pergunte à Team Cymru de que rede veio cada um. A consulta é um simples pedido DNS: não precisa de chave nem de conta.

# 1. Get an exit IP through the proxy you are evaluating.
ip=$(curl -s --proxy "http://$PROXY_HOST:$PROXY_PORT" \
          --proxy-user "$PROXY_USER:$PROXY_PASS" https://api.ipify.org)

# 2. Ask Team Cymru which network announces it (reverse the octets).
reversed=$(echo "$ip" | awk -F. '{print $4"."$3"."$2"."$1}')
asn=$(dig +short TXT "$reversed.origin.asn.cymru.com" | awk -F'"' '{print $2}' | awk '{print $1}')

# 3. Resolve that ASN to the name its operator registered.
dig +short TXT "AS$asn.asn.cymru.com"

Repita algumas centenas de vezes e conte quantas vezes o nome devolvido soa a centro de dados. Se preferir não escrever o ciclo, a execução pré-registada completa — amostragem, classificação, intervalos de Wilson e o artefacto JSON — é um único comando no nosso método aberto:

pnpm run measure:pool -- --provider=dataimpulse --sample=1087

Dois avisos práticos. Passe a palavra-passe do proxy pela entrada padrão ou por uma variável de ambiente, nunca como argumento de linha de comandos: numa máquina partilhada os argumentos são legíveis na lista de processos enquanto o pedido durar, e esta verificação emite milhares. E seja cortês com a PeeringDB — é um serviço mantido por voluntários que permite cerca de um pedido anónimo por hora à sua exportação completa: descarregue o registo inteiro uma única vez, guarde-o em disco e julgue cada endereço de uma execução contra esse único instantâneo, em vez de consultar as redes uma a uma. É também isso que torna a execução reproduzível: o artefacto regista que instantâneo usou.

O que uma proporção de alojamento diz e não diz

Uma proporção alta de alojamento não é prova de desonestidade, e lê-la assim é a forma mais rápida de errar a análise.

Algumas gamas registadas como alojamento estão realmente atribuídas a ligações domésticas. Alguns ISP residenciais operam as suas próprias gamas de alojamento com o mesmo nome. Alguns endereços são simplesmente inclassificáveis a partir de dados públicos — é por isso que unclassified é uma coluna publicada e não um erro de arredondamento.

O que uma proporção alta de alojamento diz, isso sim, é comercial. A largura de banda de centro de dados é barata e a residencial não é; um pool com grande componente de servidores está a vender-lhe inventário barato ao preço caro. É também pior em termos operacionais, porque as gamas de alojamento são a primeira lista que o fornecedor antibots de um site alvo compra — o mecanismo por trás da maioria dos bloqueios descritos em como fazer scraping sem ser bloqueado. E se está a recolher dados sob uma obrigação de conformidade, «não conseguimos justificar um endereço em cada oito» é uma frase que não quer dizer numa auditoria.

O inverso merece ser dito com igual clareza: uma proporção baixa de alojamento é prova sobre a composição, não sobre o consentimento. Um pool pode ser inteiramente de ISP residenciais e ainda assim ter sido montado a partir de pessoas que nunca concordaram de forma significativa em encaminhar tráfego de estranhos. Composição e origem são duas perguntas diferentes, e esta medição responde apenas à primeira.

Escolher um fornecedor capaz de justificar os seus endereços

Enquanto os números de composição não forem rotina, o substituto prático é saber se um fornecedor documenta de onde vêm os seus endereços e a quem vende. Isso é observável hoje, em páginas publicadas e não em conversas comerciais, e está resumido para todo o mercado no relatório do mercado de proxies. A versão curta:

E o fornecedor cujo pool este benchmark visou primeiro:

Escolher entre eles pelo preço e não pela postura é outro exercício — esse está em melhores proxies residenciais e comparação de preços de proxies.

Limites desta medição

Ditos com clareza, porque uma secção de método que esconde as suas fraquezas é publicidade.

A proporção de alojamento é um limite inferior, não uma estimativa da proporção real. A regra só dispara com nomes de rede autodescritivos, pelo que qualquer operador de alojamento com nome neutro escapa.

Estes números não são comparáveis com qualquer valor derivado de uma base de dados comercial de tipo de utilização, incluindo o benchmark da Proxyway citado acima. Entradas diferentes, regra diferente, grandeza diferente. Apresentá-los como duas leituras da mesma coisa seria errado mesmo quando coincidem.

Um pool não é estático. Uma amostra descreve os endereços que esse pool entregou durante uma execução, a partir de um ponto de observação, num dado momento. A composição pode variar consoante o país alvo, a hora do dia e quanto está a gastar.

E a amostra nada diz sobre taxa de sucesso, latência ou consentimento. É uma propriedade de um pool, medida com cuidado. Tratada assim, é útil; tratada como um veredicto sobre um fornecedor, não é.

Esta é uma medição independente, não uma estatística fornecida por um vendedor, e não constitui aconselhamento jurídico. Se repetir o método e obtiver outra resposta, é essa correção que queremos — é para isso que a regra é publicada.