¿Son los proxies residenciales realmente residenciales? Cómo medir un pool

Todos los proveedores de proxies residenciales publican un tamaño de pool. Ninguno publica la composición del pool — cuánto de él es realmente una línea de banda ancha doméstica y cuánto un servidor en un centro de datos con etiqueta residencial. Es esa segunda cifra la que decide si el sobreprecio residencial que paga compra algo en absoluto. Y se puede medir en una tarde con herramientas gratuitas.

Esta página es a la vez el método y el resultado: la regla exacta, los comandos exactos, el tamaño de muestra fijado de antemano y lo que la ejecución haya producido — publicado tal como se midió.

Qué promete realmente la etiqueta «residencial»

Un proxy residencial se vende sobre la premisa de que su dirección de salida pertenece a una conexión de internet de consumo, de modo que el tráfico parece una persona corriente navegando y no una máquina en un rack. Esa es toda la propuesta de valor, y por eso el ancho de banda residencial cuesta varias veces lo que cuesta el de centro de datos. La diferencia se explica en proxies residenciales vs. de centro de datos, y la mecánica de fondo en qué es un proxy residencial.

Lo que la etiqueta no promete es que cada dirección del pool cumpla esa descripción. Un pool se ensambla — a partir de acuerdos con SDK, de aplicaciones de recompensas, de revendedores, de otras redes de proxies. Y cuanto más lejos está una dirección de la cadena de suministro propia del proveedor, menos puede decir este sobre ella. Nuestro razonamiento sobre por qué esa cadena merece escrutinio está en obtención ética de proxies.

Existe, pues, una brecha entre la etiqueta y las direcciones, esa brecha es una cifra, y esa cifra es comprobable. Nadie la comprueba: esa es la única razón por la que esta página resulta interesante.

El método, fijado antes de la ejecución

Cuatro decisiones definen esta medición. Las cuatro se tomaron antes de recoger dato alguno, y las cuatro están publicadas para que la ejecución pueda discutirse en lugar de simplemente creerse.

1. Solo fuentes libres y redistribuibles

Las redes de origen proceden del servicio público IP-to-ASN de Team Cymru y los tipos de red de PeeringDB, que es CC BY — de uso y republicación libres con atribución, que esta página ofrece.

La opción aparentemente más fácil se descartó tras evaluarla. ip-api.com devuelve directamente un booleano hosting, una señal más rica que cualquier reconstrucción a partir de nombres de red, pero sus términos limitan la capa gratuita a un uso no comercial en un entorno no comercial. Este sitio se monetiza, así que publicar cifras derivadas de él incumpliría esos términos — el mismo tipo de atajo que este texto critica en los proveedores. Además, su capa gratuita es solo HTTP, y una medición cuyo valor entero es la credibilidad no puede tomar sus entradas por un canal que cualquier intermediario puede reescribir.

Esa renuncia no sale gratis, y es la razón principal de que la cifra principal sea una cota inferior y no una proporción exacta.

2. Una regla de clasificación conservadora

Una dirección se cuenta como hosting cuando el nombre registrado de su red de origen contiene alguno de los términos de una lista publicada — hosting, cloud, datacenter, colocation, hetzner, digitalocean, vps y similares. Se cuenta como residencial cuando PeeringDB registra su red como Cable/DSL/ISP. Todo lo demás queda sin clasificar y permanece en el denominador.

Dos propiedades de esa regla importan más que la lista en sí. El hosting gana cuando ambas señales se activan, porque la dirección conservadora es no infradeclarar servidores en un pool vendido como residencial. Y las direcciones cuya red no pudo resolverse en absoluto se mantienen en el denominador en lugar de descartarse: encoger el denominador en silencio inflaría la proporción que le importa al lector, que es exactamente la maniobra que esta medición existe para comprobar en otros.

3. Un tamaño de muestra elegido de antemano

1.087 IP de salida únicas, el tamaño que da un margen de más o menos dos puntos porcentuales con un 95 % de confianza para una proporción cercana al 13 %. El script de medición se niega a arrancar sin un tamaño de muestra explícito e imprime el método completo antes de la primera petición, así que la cifra no puede ajustarse en silencio una vez llegan los datos.

4. Cada cifra lleva su intervalo

Las proporciones se informan con un intervalo de puntuación de Wilson al 95 % en lugar de un porcentaje desnudo. Wilson y no la aproximación normal porque, con proporciones cercanas a cero, el intervalo normal baja de cero e informa una cota inferior que no puede existir. Un estadístico de pool sin intervalo invita al lector a tratarlo como exacto, que es el error contra el que argumenta todo el texto.

Resultados

La tabla recoge la medición más reciente de cada pool. Todas las mediciones publicadas, incluidas las superadas, permanecen en el JSON de /data/pool-composition.json, con licencia CC BY 4.0, junto con el tamaño de la muestra, el intervalo, la regla de clasificación exacta que usó cada ejecución y un recuento por red que permite a cualquiera reclasificarla sin volver a muestrear el pool.

La pasada del 17 de septiembre de 2026: DataImpulse, residencial de EE. UU.

Configuración. El pool residencial estándar de DataImpulse, dirigido a Estados Unidos en el panel, sesión rotatoria, segmentación por defecto, filtro de anonimato desactivado, sin exclusiones de ASN — el pool que recibe un cliente sin tocar un solo ajuste. 1.120 peticiones a través del proxy produjeron las 1.087 direcciones de salida únicas fijadas de antemano. Se resolvieron en 131 redes de origen, todas clasificadas contra una única exportación de PeeringDB de 35.393 redes obtenida el mismo día a las 06:12 UTC. La pasada consumió alrededor de 1 MB de tráfico de evaluación que DataImpulse proporcionó gratis, lo que se indica aquí porque es de esas cosas que deben indicarse.

Hosting: al menos el 5,1 %. 55 de las 1.087 salidas procedían de redes cuyo nombre registrado dice centro de datos — un intervalo del 95 % de 3,9 % a 6,5 %. La lista es corta y concreta: 45 de las 55 eran Leaseweb USA, en ocho de sus sedes (Dallas, Washington, Los Ángeles, Miami, Phoenix, Chicago, Nueva York y Seattle); nueve eran Colocation America; una era Dedicated.com. Leído como cota inferior, es una salida de cada veinte desde un rack de hosting, en un pool que se vende y se cobra como residencial.

ISP de consumo: 43,0 %. 467 salidas estaban en redes que PeeringDB registra como acceso por cable, DSL o ISP — Comcast (109), RCN (98), Charter (81 en seis registros), T-Mobile (40), Cox (28) y Windstream (20) a la cabeza. Estos recuentos se limitan a este grupo: Charter tiene otros cuatro registros, 22 salidas, a los que PeeringDB no asigna ningún tipo, y que caen en los sin clasificar de más abajo. Estas son las direcciones que promete la etiqueta residencial.

Sin clasificar: 52,0 %, y esta vez es un hecho sobre el pool. Un intento anterior de esta pasada tuvo que descartarse cuando PeeringDB limitó a mitad de camino las consultas red por red, lo que habría convertido «sin clasificar» en una medida del servicio de consulta. Esta pasada juzgó cada red contra una sola exportación, así que las 565 salidas sin clasificar se descomponen con claridad:

• 334 (30,7 %) están en redes de las que PeeringDB no tiene registro ni tipo. Cuatro operadores suman 215 — DynaNode LLC (83), Rocks Computer Services (77), eSited Solutions (28) y Flash Edge Information Technology (27). Ninguno es un nombre que aparezca en una factura de banda ancha doméstica; ninguno tiene tampoco un nombre que la regla publicada reconozca como hosting, así que la regla no los cuenta. Entre los cuatro son una salida de cada cinco. Qué son es la mayor pregunta abierta de este resultado.
• 194 (17,8 %) están registradas como NSP — proveedores de servicios de red como Verizon Business (61), AT&T (57), Frontier (25) y CenturyLink (9). Estos operadores también venden líneas de consumo, así que este grupo probablemente se inclina hacia lo residencial; la regla no lo presupone.
• 32 (2,9 %) están registradas como Content — Enzu, Hype Enterprises, Latitude.sh y Psychz Networks entre otras, operadores que en la práctica son negocios de hosting pero cuyos nombres no lo dicen.
• 5 (0,5 %) corresponden a tipos de registro aislados — Educational/Research (2), Non-Profit (1), Network Services (1) y Enterprise (1). Demasiado pocas para mover el resultado, pero se listan para que los cuatro grupos sumen 565.

Juntando las piezas, la verdadera proporción de hosting de esta muestra está entre el 5,1 % que la regla puede demostrar y aproximadamente el 8 % si se cuenta el grupo Content, mientras que la proporción de consumo está entre el 43 % y aproximadamente el 61 % si se incluyen los operadores NSP. Los dos operadores que deciden en qué punto de ese rango está la verdad son DynaNode y Rocks Computer Services, 160 salidas entre ambos. La regla de clasificación no se modificó después de que aparecieran esos nombres: añadirlos ahora sería elegir la respuesta después de ver los datos, la práctica que esta página existe para rechazar.

Lo que esto dice y no dice sobre la cifra de Proxyway. El benchmark de Proxyway de abril de 2026 situó aproximadamente una salida estadounidense de cada ocho en un servidor usando la base de datos de tipo de uso de IP2Location. Esta pasada no puede confirmar ni contradecir esa cifra — distinta entrada, distinta regla, distinta magnitud — y no lo intenta. Lo que sí puede decirse es que una regla libre, conservadora y basada solo en nombres ya encuentra una salida de cada veinte desde centros de datos identificables por su nombre, y que la dirección de ambos hallazgos es la misma.

Respuesta del proveedor, 19 de septiembre de 2026. Estas cifras se enviaron a DataImpulse antes de la publicación, como se prometió; la empresa nos había dicho antes por escrito que no mide ni publica una cifra de composición propia. Tras revisar las cuatro redes sin explicar con su equipo técnico, respondió:

• DynaNode LLC y eSited Solutions son proveedores de centros de datos, en palabras de la propia DataImpulse, y la empresa dice que ya ha pedido a su equipo técnico que excluya a ambas del pool residencial.
• Rocks Computer Services y Flash Edge Information Technology no puede confirmarlas como proveedores de centros de datos con la información de que dispone, y dice que seguirán en el pool.

Si se suman las dos redes que identifica el proveedor a las 55 salidas que la regla ya cuenta, al menos 166 de las 1.087 salidas — el 15,3 %, con un intervalo del 95 % de 13,3 % a 17,5 % — procedían de centros de datos confirmados. DataImpulse hizo ese cálculo por sí misma y pidió que se citara la cifra más alta: «Preferimos que esa cifra sea exacta antes que subestimada». Es raro que un proveedor corrija al alza su propia cifra, y se le reconoce aquí. El 29 de septiembre DataImpulse confirmó tres operadores más de esta muestra como proveedores de centro de datos, lo que recalcula esta medición en el 17,3 %; la corrección está en la sección del 26 de septiembre, más abajo.

La medición publicada no cambia. La regla sigue indicando el 5,1 %, porque se fijó antes de la pasada y la confirmación del proveedor es una evidencia que la regla nunca vio; el 15,3 % figura a su lado como una cifra aparte y atribuida, en lugar de integrarse en ella. Supera el aproximadamente 13 % de Proxyway, aunque ambas siguen procediendo de métodos distintos. Quedan abiertas 104 salidas (9,6 %) en Rocks Computer Services y Flash Edge: si ambas fueran también centros de datos, la proporción confirmada de esta muestra llegaría al 24,8 %, y nada aquí indica que lo sean.

DataImpulse había ofrecido tráfico de evaluación nuevo para una nueva prueba una vez terminadas las exclusiones, y comunicó que estaban completas el 22 de septiembre. Esa medición se recoge más abajo, como una segunda ejecución fechada junto a esta y no en su lugar.

La medición del 22 de septiembre de 2026: después de la limpieza

Montaje. Idéntico al de la primera medición a propósito: el mismo pool residencial estándar, la misma segmentación a Estados Unidos, la misma sesión rotativa y los mismos ajustes por defecto, el mismo tamaño de muestra prerregistrado (una nueva extracción de 1.087 salidas únicas a partir de 1.120 peticiones a través del proxy), y la misma regla de clasificación congelada, sin cambios desde antes de ambas ejecuciones. Se resolvieron en 127 redes de origen, juzgadas contra una exportación de PeeringDB de 35.441 redes generada a las 22:50 UTC y descargada a las 23:25 UTC del mismo día. DataImpulse volvió a aportar el tráfico de evaluación y pidió que la medición esperara a que comunicara el fin de su limpieza. Era una petición razonable y se aceptó, pero condiciona lo que el resultado puede significar, como explica el último párrafo de esta sección.

Alojamiento según la regla: 0,7 %. 8 de las 1.087 salidas, un intervalo del 95 % de 0,4 % a 1,5 %, frente al 5,1 % anterior. Las ocho eran Colocation America. Leaseweb, que en la primera medición aportó 45 salidas desde ocho de sus sedes estadounidenses, no aportó ninguna; Dedicated.com tampoco.

ISP de consumo: 55,7 %, sin clasificar 43,6 %. 605 salidas están ahora en redes que PeeringDB registra como acceso de cable, DSL o ISP, frente a 467 — encabezan Comcast (174), RCN (112), T-Mobile (49) y Cox (42). El grupo sin clasificar bajó de 565 a 474 salidas.

Las cuatro redes sin explicar, cinco días después. eSited Solutions pasó de 28 salidas a ninguna, y Rocks Computer Services de 77 a ninguna. Flash Edge cayó de 27 a 10. Y DynaNode LLC, la única de las cuatro que DataImpulse había identificado positivamente como proveedor de centro de datos y pedido a su equipo que excluyera, pasó de 83 salidas a 79: prácticamente igual, y aún la cuarta mayor fuente de direcciones de la muestra. Que Rocks bajara a cero se leyó entonces como más de lo que DataImpulse se había comprometido, ya que el 19 de septiembre dijo que no podía confirmar Rocks como centro de datos y que la red se quedaría. No fue así: una semana después la empresa estableció que Rocks se había retirado por error, y la corrección va más abajo.

Nada se mudó a racks nuevos. Ni una sola red con cinco o más salidas aparece en esta medición faltando en la primera. Conviene comprobarlo de forma explícita, porque la manera más fácil de superar una nueva prueba no es retirar tráfico sino trasladarlo a redes con otro nombre. Aquí la caída es retirada.

Respuesta del proveedor, 24 de septiembre de 2026 — luego retractada. Preguntado por qué DynaNode seguía igual, DataImpulse respondió primero: «DynaNode LLC opera bajo dos ASN. Uno se ha retirado (contenía unas 6.500 IP). El segundo ASN todavía está en proceso de exclusión. Por eso quedaron 79 salidas en su nueva prueba». Ese relato ya no es válido. Se mantiene aquí en lugar de borrarse, porque una corrección cuyo original el lector no puede ver no es una corrección.

Dos partes de ese relato no podían contrastarse con el registro público. AS400463 es el único ASN inscrito con el nombre DynaNode en los datos públicos de los registros, y en la muestra del 17 de septiembre tampoco había aparecido ninguna segunda red con ese nombre. Ninguna de las dos observaciones probaba nada por sí sola — un ASN puede estar inscrito a nombre de otra entidad, y 6.500 direcciones pueden perfectamente no producir ni una salida en 1.087 extracciones —, así que ambas se plantearon a DataImpulse en lugar de publicarse como hallazgo.

Corrección de DataImpulse, 25 de septiembre de 2026. La empresa volvió a comprobarlo y retiró su afirmación: «No hay un segundo ASN de DynaNode. La red que ya se había retirado era Rocks Computer Services, LLC, pero internamente estaba marcada por error como DynaNode. Eso explica también por qué Rocks bajó a cero en su nueva prueba mientras AS400463 seguía presente». AS400463 es el ASN de DynaNode, y en el momento de aquella medición seguía en el pool.

Esa corrección tiene una consecuencia que no favorece al resultado anterior. Rocks Computer Services se retiró por error. DataImpulse dijo el 19 de septiembre que no podía confirmar Rocks como centro de datos y que la red se quedaría, y nada desde entonces ha cambiado esa valoración: aquellas 77 salidas desaparecieron de la muestra por un etiquetado interno equivocado, no porque alguien lo decidiera. En esa red, el pool se limpió por el motivo equivocado. Si la exclusión es ahora deliberada es una pregunta planteada a la empresa y todavía sin respuesta.

Contado a la manera del proveedor: 8,0 %. Si se suma DynaNode, al que DataImpulse identifica como centro de datos, a las 8 salidas que cuenta la regla, 87 de las 1.087 salidas — el 8,0 %, con un intervalo del 95 % de 6,5 % a 9,8 % — procedían de centros de datos confirmados, frente al 15,3 % de cinco días antes. Las 10 salidas restantes de Flash Edge lo llevarían al 8,9 % si también resultara ser alojamiento, cosa que nada de lo aquí expuesto establece. Como en la primera medición, la cifra publicada se mantiene en lo que informa la regla: 0,7 % es lo que produjo el método, y el 8,0 % figura al lado como cifra distinta y atribuida. Esa cifra también ha quedado superada: la misma confirmación del 29 de septiembre recalcula esta medición en el 10,1 %, como expone la corrección de más abajo.

Lo que esta medición no puede mostrar. Se tomó después de que el proveedor supiera exactamente qué redes se estaban comprobando y nos dijera que había terminado. Muestra que esas redes han desaparecido de esta muestra. No muestra que el pool esté más limpio en general, y un pool puede estar limpio una semana. Había dos mediciones más previstas, con la misma regla congelada y el mismo tamaño de muestra pre-registrado: una en cuanto DataImpulse confirmara la exclusión de AS400463 — es la que se informa a continuación — y otra algunas semanas después, en una fecha no anunciada de antemano.

La medición del 26 de septiembre de 2026: la red que el proveedor señaló ya no está

Montaje. Otra vez sin cambios: el mismo pool residencial estándar, la misma segmentación a Estados Unidos, la misma sesión rotativa y los mismos ajustes por defecto, 1.087 salidas únicas extraídas de 1.120 peticiones a través del proxy, y la misma regla de clasificación congelada. Se resolvieron en 125 redes de origen, juzgadas contra una exportación de PeeringDB de 35.475 redes generada a las 01:01 UTC y descargada a las 01:22 UTC del mismo día. DataImpulse confirmó el 25 de septiembre la retirada de AS400463 e invitó a repetir la medición; el tráfico de evaluación lo aportó de nuevo la empresa.

DynaNode: de 79 salidas a ninguna. AS400463 no apareció ni una vez en 1.087 extracciones. La red que DataImpulse identificó como proveedor de centro de datos el 19 de septiembre, y que tres días después seguía siendo la cuarta mayor fuente de direcciones de la muestra, ha desaparecido. De las otras tres redes seguidas desde la primera medición, eSited Solutions y Rocks Computer Services siguen ausentes, y Flash Edge, que DataImpulse dijo no poder confirmar como centro de datos, volvió a bajar, de 10 salidas a 4.

Alojamiento según la regla: 0,7 %. De nuevo 8 de las 1.087 salidas, un intervalo del 95 % de 0,4 % a 1,5 %: siete de Colocation America y una de IHOR Hosting.

Corrección, 29 de septiembre de 2026: esto se publicó primero como una convergencia, y no lo era. Aquí se afirmaba que el 0,7 % de la regla y la propia identificación de DataImpulse habían llegado a la misma cifra por primera vez en la serie. Tres días después la empresa confirmó que Hype Enterprises, Enzu Inc y Psychz Networks — los operadores que el párrafo de abajo incluía entre los sin explicar — son proveedores de centro de datos, y que había excluido sus ASN. Esos tres aportaban 28 salidas de esta muestra. Contada a la manera del proveedor, esta medición es de 36 de las 1.087 salidas, el 3,3 %, con un intervalo del 95 % de 2,4 % a 4,6 %: no el 0,7 %, y no una convergencia.

La misma confirmación alcanza hacia atrás, porque los tres operadores estaban presentes en todas las muestras. Recalculada sobre lo que DataImpulse ha confirmado ya, la serie queda así:

• 17 de septiembre: 5,1 % según la regla, 17,3 % confirmado (188 de 1.087 salidas), publicado entonces como 15,3 %.
• 22 de septiembre: 0,7 % según la regla, 10,1 % confirmado (110 salidas), publicado entonces como 8,0 %.
• 26 de septiembre: 0,7 % según la regla, 3,3 % confirmado (36 salidas), publicado entonces como 0,7 %.

La dirección no cambia y la mejora es real. Lo que ha cambiado es la distancia entre las dos columnas, y ese es el argumento de este artículo vuelto contra sí mismo. Entre el 22 y el 26 de septiembre la regla no se movió del 0,7 %, mientras la cuota confirmada era del 10,1 % y luego del 3,3 %. Ninguna de esas revisiones nació de un cambio en el pool. La única variable fue qué redes se le habían planteado al proveedor por su nombre. Una cota inferior no es una estimación, y toda cifra que produzca la regla debe leerse como el suelo que es.

ISP de consumo: 61,8 %, sin clasificar 37,4 %. A lo largo de las tres mediciones, la cuota de consumo ha pasado de 43,0 % a 55,7 % y luego a 61,8 %, y la no clasificada de 52,0 % a 43,6 % y luego a 37,4 %. Encabezan Comcast (172) y RCN (146), seguidos de T-Mobile (60), Cox (52) y Cablevision (31); Charter suma 101 salidas entre sus registros del grupo de consumo.

Tampoco esta vez nada se mudó a racks nuevos. Aparece aquí una red con cinco o más salidas que faltaba en la segunda medición: Castro Telecom (AS33733, 5 salidas), un segundo registro de un operador ya presente, y no un nombre de alojamiento. La prueba más sólida es agregada: el grupo de redes de las que PeeringDB no tiene registro ni tipo, contado como en la primera medición, es decir, sin las salidas que la regla ya cuenta como alojamiento, bajó de 234 salidas a 140. Si el tráfico retirado se hubiera limitado a reetiquetarse en redes con otro nombre, ese grupo habría crecido.

Lo que seguía sin explicación y ya no. 38 salidas (3,5 %) estaban en operadores que PeeringDB registra como Content — entre ellos Hype Enterprises (12), Enzu (11) y Psychz Networks (5) —, empresas de alojamiento cuyo nombre registrado la regla no reconoce. Esos tres nombres se plantearon a DataImpulse, que confirmó el 29 de septiembre que los tres son proveedores de centro de datos y que había excluido sus ASN. Sobre esa confirmación se apoya la corrección de arriba. Cinco operadores menores del mismo grupo — Clouvider (3 salidas), PEG TECH (2), H4Y Technologies (2), Railway (2) y Antbox Networks (1) — también se le han planteado y siguen sin respuesta.

Lo que esta medición zanja y lo que no. Zanja que AS400463 está fuera del pool, que es para lo que se hizo. No zanja que el pool vaya a seguir así, porque todas las mediciones de la serie se han tomado en fechas que el proveedor conocía de antemano — y la medición que se informa a continuación, tres días después, es la demostración más clara de por qué ese límite importa.

La medición del 29 de septiembre de 2026: la regla marca 0,1 %, y es la cifra menos útil de este artículo

Montaje. Sin cambios: el mismo pool, la misma segmentación a Estados Unidos, los mismos ajustes por defecto, 1.087 salidas únicas de 1.120 peticiones a través del proxy, la misma regla congelada. Se resolvieron en 124 redes de origen, juzgadas contra una exportación de PeeringDB de 35.487 redes generada a las 08:21 UTC y descargada a las 08:51 UTC del mismo día. DataImpulse había comunicado esa misma mañana que había excluido a Hype Enterprises, Enzu y Psychz Networks, e invitó a hacer la medición.

Las redes confirmadas han desaparecido, todas. Hype Enterprises pasó de 12 salidas a ninguna, Enzu de 11 a ninguna, Psychz Networks de 5 a ninguna. DynaNode, eSited, Rocks Computer Services y Leaseweb siguieron en cero. Toda red que DataImpulse haya confirmado alguna vez como centro de datos está ahora ausente de la muestra.

Alojamiento según la regla: 0,1 %. Una salida de 1.087, un intervalo del 95 % de 0,02 % a 0,5 %: una única dirección de Colocation America. Es la cifra más baja que ha producido este benchmark y, tomada sola, diría que el pool está prácticamente limpio.

Tomada sola, sería falsa. Flash Edge Information Technology (AS219329) aportaba 4 salidas el 26 de septiembre y 75 el 29 de septiembre: diecinueve veces más en tres días, suficiente para ser la segunda mayor fuente de direcciones de la muestra. Flash Edge es la red que DataImpulse nos dijo el 19 de septiembre que no podía confirmar como proveedor de centro de datos y que se quedaría en el pool. PeeringDB no le asigna tipo y la regla no reconoce su nombre, así que la regla no puede verla. Si Flash Edge es un centro de datos, esta medición es de 76 de las 1.087 salidas — el 7,0 %, con un intervalo del 95 % de 5,6 % a 8,7 % — y no del 0,1 %.

Los grupos también retrocedieron. Los ISP de consumo bajaron del 61,8 % al 56,3 % y los sin clasificar subieron del 37,4 % de vuelta al 43,6 %, deshaciendo la mayor parte de la ganancia de la medición anterior. Dos redes con cinco o más salidas son nuevas desde la última medición: Grande Communications (14 salidas, registrada como cable de consumo) y GoCodeIT (7, sin tipo).

Lo que decimos y lo que no. No decimos que esto se haya amañado. Retirar cuatro operadores en diez días tiene que desplazar ese tráfico a alguna parte, y que un proveedor superviviente lo absorba es una consecuencia ordinaria, no prueba de intención. Decimos algo más estrecho y más difícil de rebatir: la cifra de titular de la regla mejoró mientras crecía la parte del pool que no sabe clasificar, y ese crecimiento recayó casi por completo en la única red por la que se había preguntado al proveedor y que este se negó a clasificar. Ese es exactamente el fallo que invita una estadística de pool aislada, y por eso esta página nunca ha publicado una sola por su cuenta. La respuesta de DataImpulse y lo que encontró la medición siguiente están en la sección del 13 de octubre, más abajo.

La medición del 13 de octubre de 2026: la regla no encuentra nada, y la tercera mayor red de la muestra está sin clasificar

Montaje. Sin cambios: el mismo pool, la misma segmentación a Estados Unidos, los mismos ajustes por defecto, 1.087 salidas únicas de 1.120 peticiones a través del proxy, la misma regla congelada. Se resolvieron en 116 redes de origen, juzgadas contra una exportación de PeeringDB de 35.608 redes generada a las 09:41 UTC y descargada a las 10:06 UTC del mismo día. El 13 de octubre DataImpulse nos dijo que había excluido a los seis operadores restantes que le habíamos planteado — Clouvider, PEG TECH, H4Y Technologies, Railway, Antbox Networks y Datacamp — e invitó a hacer la medición.

Las exclusiones se mantuvieron, con una excepción. Clouvider, PEG TECH, H4Y Technologies, Railway y Antbox Networks no aportaron ninguna salida. Datacamp Limited (AS212238) aportó 5, frente a 10; se le planteó a la empresa si su exclusión aún se está propagando, y esta respondió el 25 de octubre que, tras una revisión manual, clasifica Datacamp Limited (AS212238) y GoCodeIT (AS835 / AS62513) como redes de centro de datos y está retirando ambas del pool residencial. El 27 de octubre la empresa nos dijo que ambas habían sido retiradas e invitó a volver a medir, lo que se recoge más abajo. Hype Enterprises, Enzu, Psychz Networks, DynaNode, eSited, Rocks Computer Services y Leaseweb siguieron todos en cero.

Alojamiento según la regla: ninguno. Ni una sola de las 1.087 salidas estaba en una red cuyo nombre registrado la regla reconozca como alojamiento — un intervalo del 95 % de 0 % a 0,4 %, y la primera medición en que la regla no encontró nada en absoluto. Tomado solo, diría que el pool está limpio.

Tomado solo, volvería a ser falso. Flash Edge Information Technology (AS219329) aportó 105 salidas, el 9,7 % de la muestra — 27, 10, 4, 75 y 105 a lo largo de las cinco mediciones. Ocupó el tercer lugar entre 116 redes, por delante de AT&T (70 salidas), Verizon (55), Frontier (53) y Cox (50); la mayor otra red para la que PeeringDB no tiene tipo aportó 21. La regla no puede verla. Si Flash Edge es un centro de datos, esta medición es de 105 de las 1.087 salidas — el 9,7 %, con un intervalo del 95 % de 8,0 % a 11,6 % — y no del 0 %. Los ISP de consumo estaban en el 58,0 % y las salidas sin clasificar en el 42,0 %, casi sin cambios desde el 29 de septiembre, y ninguna red con cinco o más salidas es nueva desde aquella medición.

Lo que DataImpulse nos dijo sobre Flash Edge. Preguntada por qué la red se multiplicó por diecinueve entre el 26 y el 29 de septiembre, la empresa escribió el 13 de octubre que sus IP residenciales se obtienen a través de TraffMonetizer, «nuestro propio servicio de suministro basado en SDK», y que «Un proveedor de IP dentro de esa red empezó a encaminar direcciones de Flash Edge hacia el pool, y por eso el recuento saltó entre el 26 y el 29 de septiembre. No fue organizado como respuesta a la prueba.» Flash Edge Information Technology LLC opera flashproxy.com, «que es en sí mismo un servicio de proxies que ofrece proxies de centro de datos, móviles, residenciales y residenciales premium», no coopera directamente con DataImpulse, y «Nuestra mejor valoración es que sus IP entran en nuestro pool a través de sus usuarios finales que participan en TraffMonetizer, pero no podemos confirmarlo con certeza.» Sobre si excluirla: «Flash Edge opera una red mixta. Si necesita una respuesta binaria para el artículo, la honesta es: todavía no sabemos si estas IP concretas son residenciales o de centro de datos, y seguimos revisándolo.» El 25 de octubre respondió que no compra direcciones a otros proveedores y que todo su suministro residencial, tanto de la aplicación como del SDK, llega a través de clientes de TraffMonetizer, de modo que las direcciones de Flash Edge entraron a través de esos clientes; no puede determinar si son usuarios finales del propio Flash Edge o si es el propio Flash Edge quien pone a disposición direcciones de su red, y se negó a revelar cuántas instalaciones o ID de socio hay detrás de AS219329. Dijo que TraffMonetizer comprueba la calidad de cada conexión antes de pasarla a DataImpulse y no paga por las conexiones que presentan problemas; la reproducimos como declaración del proveedor. El 27 de octubre añadió que la comprobación no se limita a la calidad de la conexión: cada IP se contrasta además con varios servicios de clasificación de IP, que deciden si entra en el pool residencial o en el de centros de datos, y que no puede compartir nada más sobre quién opera los clientes detrás de AS219329. Aun así, Flash Edge llegó al pool residencial y la empresa dice que todavía no puede clasificarlo, de modo que estas comprobaciones no determinan en qué dispositivo se ejecuta la conexión. La empresa sigue sin haber decidido si excluye a Flash Edge.

Cómo encuentra DataImpulse los centros de datos. Preguntada el 7 de octubre cómo identifica una red de centro de datos antes de que nadie la nombre, la empresa describió «un servicio interno que combina datos de tres fuentes: IP-API, DB-IP y un sistema propio que comprueba las direcciones IP no solo por ubicación sino también por tipo de proxy», filtra las IP según esa clasificación y confirmó que paga por IP-API. Añadió: «El sistema existe y funciona de forma proactiva, pero, como ha mostrado esta serie, no detectó todo lo que encontró su método.» También dijo que Rocks Computer Services fue juzgada operadora de servidores dedicados mediante una revisión manual del proveedor, sus servicios y su infraestructura, y que ninguna base de datos la clasificó como ISP. Eso es un filtro, no una medición: un filtro muestra lo que retiró, no lo que pasó por alto.

Lo que aportan los registros públicos, y lo que no. El propio sitio de Flash Edge, flashproxy.com, vende proxies de centro de datos, ISP, móviles y residenciales; dice que sus IP residenciales se «obtienen mediante acuerdos con ISP», no dice nada sobre el consentimiento de los usuarios finales y no menciona TraffMonetizer. Los datos del registro RIPE muestran que AS219329 se creó el 29 de junio de 2026 y anuncia 118 prefijos a través de una única red ascendente, GoCodeIT Inc — un nombre que también apareció en nuestras muestras (27 salidas el 17 de septiembre, 11 el 29 de septiembre, ninguna el 13 de octubre). De los 108 prefijos cuyo registro pudo resolverse, 22 están en bloques de direcciones registrados con nombres de RapidSeedbox, una empresa de alojamiento de seedbox y proxies. La fecha en que se anunciaron por primera vez los prefijos no explica el salto: aparecieron entre julio y octubre, con el mayor lote de 57 el 17 de septiembre. Nada de esto clasifica a Flash Edge, y la regla no lo usa. Quedan dos partes del relato de DataImpulse por conciliar: la empresa dio dos mecanismos — un proveedor de IP dentro de la red que encamina direcciones, y los propios usuarios finales de Flash Edge que participan en TraffMonetizer — y para que un cliente de TraffMonetizer salga desde una dirección que anuncia la red de Flash Edge, su tráfico tendría que estar dirigido a un proxy de Flash Edge. Ambas preguntas, y cuántas instalaciones distintas explican estas salidas, se le han planteado a la empresa.

La medición del 27 de octubre de 2026: la regla encuentra dos salidas, y Flash Edge baja a 42

Montaje. Sin cambios: el mismo pool, la misma segmentación a Estados Unidos, los mismos ajustes por defecto, 1.087 salidas únicas de 1.120 peticiones a través del proxy, la misma regla congelada. Se resolvieron en 107 redes de origen, juzgadas contra una exportación de PeeringDB de 35.752 redes generada a las 03:03 UTC y descargada a las 03:33 UTC del mismo día. El 27 de octubre DataImpulse nos dijo que Datacamp Limited (AS212238) y GoCodeIT (AS835 / AS62513) habían sido retiradas del pool residencial y que podíamos volver a medir cuando nos conviniera; esta medición empezó a las pocas horas.

Las retiradas se mantuvieron. Datacamp no aportó ninguna salida, frente a 5. Ninguno de los dos ASN de GoCodeIT aportó ninguna, igual que el 13 de octubre. Todas las demás redes que DataImpulse ha confirmado o retirado alguna vez — DynaNode, eSited, Rocks Computer Services, Hype Enterprises, Enzu, Psychz Networks, Leaseweb, Clouvider, PEG TECH, H4Y Technologies, Railway y Antbox Networks — siguieron también en cero.

Alojamiento según la regla: dos salidas. 2 de las 1.087 salidas (0,18 %, intervalo del 95 % de 0,05 % a 0,67 %) estaban en una red cuyo nombre registrado la regla reconoce como alojamiento: una en Dedicated.com (AS63018), que ya había aportado una el 17 de septiembre, y otra en Mullcloud LLC (AS397006), que ninguna medición anterior había visto. Ninguna de las dos se ha planteado a DataImpulse. Una sola salida en una red no es un patrón, y la comunicamos porque la regla está congelada y el resultado se publica diga lo que diga.

Flash Edge bajó a menos de la mitad, y nada de lo que nos dijeron lo explica. Flash Edge Information Technology (AS219329) aportó 42 salidas, el 3,9 % de la muestra (intervalo del 95 % de 2,9 % a 5,2 %) — 27, 10, 4, 75, 105 y 42 a lo largo de las seis mediciones. Ocupó el séptimo lugar entre 107 redes, por detrás de RCN (176 salidas), Comcast (154), AT&T (64), Cox (64), Frontier (52) y Verizon (50), y por delante de Charter (38); la mayor otra red para la que PeeringDB no tiene tipo aportó 26. La regla no puede verla. Si Flash Edge es un centro de datos, esta medición es de 44 de las 1.087 salidas — el 4,0 %, con un intervalo del 95 % de 3,0 % a 5,4 % — y no del 0,2 %. El mensaje de DataImpulse del 27 de octubre no decía nada sobre Flash Edge, y su decisión sobre si excluirla sigue pendiente, así que no sabemos si la bajada refleja un cambio de DataImpulse, de TraffMonetizer o del propio Flash Edge. Los ISP de consumo estaban en el 64,9 % y las salidas sin clasificar en el 35,0 %, frente al 58,0 % y el 42,0 % del 13 de octubre, y ninguna red con cinco o más salidas es nueva desde aquella medición.

Flash Edge, el 28 de octubre. DataImpulse volvió a escribirnos después de la medición. No ha cambiado nada por su parte: no ha excluido ni ajustado a Flash Edge, y las direcciones siguen entrando en el pool a través de TraffMonetizer, donde, según sus palabras, «someone is sharing IP addresses from this provider». Todavía no ha decidido excluir la red. Esa frase no dice en qué dispositivo se ejecuta la conexión ni cómo lo aceptó esa persona, así que la cuestión que planteamos el 13 de octubre sigue igual.

Dónde está la serie. Seis mediciones, una regla congelada, un tamaño de muestra, cada cifra publicada con su intervalo. Según la regla: 5,1 %, 0,7 %, 0,7 %, 0,1 %, 0,0 %, 0,2 %. Según lo que el proveedor ha confirmado: 17,3 %, 10,1 %, 3,3 %; para las tres últimas mediciones, en algún punto entre el 0,1 % y el 7,0 % (29 de septiembre), entre el 0 % y el 9,7 % (13 de octubre) y entre el 0,2 % y el 4,0 % (27 de octubre), según una única revisión que DataImpulse no ha terminado. La dirección a lo largo de los 40 días desde la primera medición es realmente descendente, y DataImpulse ha retirado todas las redes que se le mostraron y confirmó. Nada de ello acredita durabilidad, porque el proveedor eligió o conocía la fecha en todos los casos, y la mayor pregunta abierta se ha encogido pero no se ha cerrado. La medición que pone eso a prueba es la última de la serie: dentro de algunas semanas, en una fecha no anunciada, desde una cuenta que la empresa no pueda identificar, pagada por nosotros en lugar de cedida como tráfico de evaluación. Misma regla, mismo tamaño de muestra, publicada junto a estas seis diga lo que diga.

Haga la comprobación usted mismo, antes de pagar

La versión útil de este artículo es la que usted ejecuta contra el pool que está a punto de comprar. Rote el endpoint, reúna direcciones de salida únicas y luego pregunte a Team Cymru de qué red proviene cada una. La consulta es una petición DNS corriente: no necesita clave ni cuenta.

# 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"

Repítalo unos cientos de veces y cuente cuántas veces el nombre devuelto suena a centro de datos. Si prefiere no montar el bucle, la ejecución preregistrada completa — muestreo, clasificación, intervalos de Wilson y el artefacto JSON — es un solo comando en nuestro método abierto:

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

Dos advertencias prácticas. Pase la contraseña del proxy por la entrada estándar o una variable de entorno, nunca como argumento de línea de comandos: en una máquina compartida los argumentos son legibles en la lista de procesos mientras dure la petición, y esta comprobación emite miles. Y sea cortés con PeeringDB — es un servicio llevado por voluntarios que permite aproximadamente una petición anónima por hora a su exportación completa: descargue el registro entero una sola vez, guárdelo en disco y juzgue cada dirección de una pasada contra esa única instantánea en lugar de consultar las redes una por una. Eso es también lo que hace reproducible la pasada: el artefacto registra qué instantánea usó.

Qué dice y qué no dice una proporción de hosting

Una proporción alta de hosting no es prueba de deshonestidad, y leerla así es la manera más rápida de equivocarse en el análisis.

Algunos rangos registrados como hosting están realmente asignados a conexiones domésticas. Algunos ISP residenciales operan sus propios rangos de hosting bajo el mismo nombre. Algunas direcciones son sencillamente inclasificables a partir de datos públicos — por eso unclassified es una columna publicada y no un error de redondeo.

Lo que una proporción alta de hosting sí dice es comercial. El ancho de banda de centro de datos es barato y el residencial no; un pool con un gran componente de servidores le está vendiendo inventario barato al precio caro. También es peor operativamente, porque los rangos de hosting son lo primero de lo que el proveedor antibots de un sitio objetivo compra una lista — el mecanismo detrás de la mayoría de los bloqueos descritos en cómo hacer scraping sin que te bloqueen. Y si recoge datos bajo una obligación de cumplimiento, «no pudimos justificar una de cada ocho direcciones» es una frase que no quiere decir en una auditoría.

Lo inverso merece decirse igual: una proporción baja de hosting es evidencia sobre la composición, no sobre el consentimiento. Un pool puede ser íntegramente de ISP residenciales y aun así haberse ensamblado a partir de personas que nunca aceptaron de forma significativa enrutar tráfico ajeno. Composición y procedencia son dos preguntas distintas, y esta medición solo responde a la primera.

Elegir un proveedor que pueda justificar sus direcciones

Hasta que las cifras de composición sean rutina, su sustituto práctico es si un proveedor documenta de dónde vienen sus direcciones y a quién vende. Eso es observable hoy, en páginas publicadas y no en llamadas comerciales, y está resumido para todo el mercado en el informe del mercado de proxies. La versión corta:

Y el proveedor a cuyo pool apuntó primero este benchmark:

Elegir entre ellos por precio y no por postura es otro ejercicio — ese está en mejores proxies residenciales y comparativa de precios de proxies.

Límites de esta medición

Dichos con claridad, porque una sección de método que esconde sus debilidades es marketing.

La proporción de hosting es una cota inferior, no una estimación de la proporción real. La regla solo se activa con nombres de red autodescriptivos, así que se pierde a todo operador de hosting con nombre neutro.

Estas cifras no son comparables con ninguna derivada de una base de datos comercial de tipo de uso, incluido el benchmark de Proxyway citado arriba. Entradas distintas, regla distinta, magnitud distinta. Presentarlas como dos lecturas de lo mismo sería erróneo incluso cuando coincidan.

Un pool no es estático. Una muestra describe las direcciones que ese pool entregó durante una ejecución, desde un punto de observación, en un momento dado. La composición puede variar según el país objetivo, la hora del día y cuánto esté gastando.

Y la muestra no dice nada sobre tasa de éxito, latencia o consentimiento. Es una propiedad de un pool, medida con cuidado. Tratada así resulta útil; tratada como un veredicto sobre un proveedor, no lo es.

Esta es una medición independiente, no una estadística facilitada por un proveedor, y no constituye asesoramiento legal. Si repite el método y obtiene otra respuesta, es esa corrección la que queremos — para eso se publica la regla.