La mayoría de las descripciones de un pool de proxies residenciales lo hacen sonar como un almacén: una gran cantidad de direcciones en una estantería, esperando a ser repartidas. Ese modelo mental es erróneo de una forma que produce sorpresas operativas reales, porque un pool no es un inventario. Es una población de conexiones domésticas reales que se unen y se marchan continuamente, y casi todo lo que desconcierta a los equipos avanzados sobre el comportamiento del pool se deriva de ese único hecho.
A continuación se explica cómo se construye realmente un pool, qué significa “refresh” mecánicamente, y las consecuencias sobre las que deberías diseñar.
Cómo se construye un pool
Las direcciones de un pool residencial pertenecen a las conexiones de internet domésticas de personas reales, lo que significa que un proveedor no puede simplemente comprarlas como se compran los rangos de datacenter. Tienen que ser aportadas.
El mecanismo habitual es la participación mediante software. Una persona instala una aplicación, o un SDK integrado en una, que ofrece algo a cambio de compartir una parte de su conexión: un nivel sin publicidad, una función de pago, un pequeño pago, acceso a un servicio. Cuando ese dispositivo está en línea y suficientemente inactivo, puede transportar una solicitud en nombre de la red. El proveedor mantiene relaciones con los desarrolladores que integran ese SDK, y esas relaciones determinan la forma geográfica y de red del pool, razón por la cual dos proveedores con totales generales similares pueden diferir sustancialmente en un país concreto. La ética de ese acuerdo, y cómo auditarla, es el tema de cómo los proveedores obtienen sus IP de forma ética.
La consecuencia que conviene interiorizar: la composición del pool depende de qué aplicaciones son populares y dónde. No está distribuida uniformemente, no está planificada centralmente, y cambia a medida que esas aplicaciones ganan y pierden usuarios.
Qué significa realmente “refresh”
Los pools rotan constantemente, por razones que no tienen nada que ver con el proveedor.
Los dispositivos se desconectan cuando la gente cierra una aplicación, guarda el teléfono en el bolsillo, sale de casa o se va a dormir. Las conexiones domésticas obtienen nuevas direcciones cuando los routers se reinician o expira el contrato de un ISP, de modo que el mismo hogar puede aparecer como una dirección distinta mañana. Los participantes se retiran. Se unen otros nuevos. Además, los propios proveedores eliminan direcciones que se han degradado, ya sea por mala reputación o por comportamiento poco fiable.
Nada de eso es una ventana de mantenimiento. Es el estado estable, ocurriendo continuamente de fondo, razón por la cual un pool residencial se modela mejor como un flujo que como un stock.
El tamaño del pool no es disponibilidad
Este es el núcleo práctico de la cuestión, y es donde las cifras destacadas inducen a error.
Una cifra de pool publicada suele ser acumulativa: direcciones que la red ha visto durante un cierto periodo. Lo que determina tu experiencia es la disponibilidad concurrente, es decir, cuántas direcciones distintas pueden servirte en este momento, en el país que solicitaste, con los filtros que aplicaste. Esas dos cifras difieren en órdenes de magnitud, y solo la segunda condiciona tu trabajo.
Tres cosas la reducen aún más. Geografía: una cifra global no dice nada sobre tu mercado, que es el argumento en disponibilidad por país. Filtros: añadir una ciudad o un ASN recorta drásticamente el conjunto elegible, ya que solo califican las direcciones que cumplen todos los criterios. Y tiempo: como el pool sigue la actividad humana, el mismo país tiene más profundidad en su noche local que a las cuatro de la madrugada.
La conclusión es que “cuán grande es el pool” es casi imposible de responder de forma útil, mientras que “cuántas direcciones distintas obtengo realmente para mi filtro, en mi nivel de concurrencia, a la hora en que ejecuto” es medible en veinte minutos y es el número que importa.
Los cinco comportamientos que explica la rotación
Una vez que se modela el pool como una población en lugar de un inventario, un conjunto de comportamientos que de otro modo resultarían desconcertantes se vuelve evidente.
Las sesiones persistentes terminan antes de tiempo a veces. Pediste una sesión de diez minutos y duró cuatro, porque el dispositivo subyacente se desconectó. Una sesión persistente es un mejor esfuerzo por mantener una dirección durante una duración, no un contrato de infraestructura, y el código que asume lo contrario falla de forma intermitente. Trátalo como un evento normal: detecta el cambio y reinicia la secuencia en lugar de tratarlo como un error, según sticky versus rotating.
La misma dirección se repite. La rotación selecciona de forma independiente cada vez en lugar de recorrer una lista sin repetición, por lo que las repeticiones son esperables, y se vuelven frecuentes cuando un filtro estrecho reduce el conjunto elegible. Eso es aritmética más que un fallo, y es una de las causas cubiertas en IP not rotating.
El rendimiento varía entre direcciones. Se trata de conexiones de consumidores con su propio ancho de banda, congestión y uso doméstico, por lo que la latencia tiene una distribución mucho más amplia que la infraestructura de datacenter. Los percentiles son la forma honesta de describirlo; las medias ocultan la cola que realmente afecta a tu planificación.
La disponibilidad varía a lo largo del día. Un trabajo que tiene éxito a las 20:00 y tiene dificultades a las 04:00 en el mismo mercado suele estar viendo la profundidad diurna del pool más que un cambio en el objetivo.
Los resultados difieren entre dos ejecuciones del mismo trabajo. Direcciones distintas, redes distintas, reputaciones distintas. Cierta variación es inherente, y tratar cada fluctuación como una regresión desperdicia mucha investigación.
Diseñar para una población
Consecuencias prácticas para cualquiera que construya sobre esto.
Trata las direcciones como desechables y las rutas como la unidad que gestionas. Nunca elegiste una dirección y no puedes conservarla, así que el seguimiento del estado pertenece al nivel de ruta y sesión, que es el modelo en monitorización de la salud de proxies a escala y construir un gestor de proxies.
Haz que los trabajos sean reanudables e idempotentes. Si una sesión puede desaparecer a mitad de secuencia, la secuencia necesita poder reiniciarse sin duplicar trabajo ni corromper un registro.
Elige los TTL deliberadamente. Un TTL largo es una solicitud, no una garantía, y pedir una hora en una conexión de consumidor te expone a caídas a mitad de flujo. Pide lo que el flujo realmente necesita.
Mide tu pool efectivo en lugar de leer una cifra de marketing: muestrea unos cientos de salidas bajo tu filtro real, cuenta direcciones y organizaciones distintas, y repite en las horas en que ejecutas. Ese número, no la cifra destacada, es lo que debería informar las decisiones de concurrencia y distribución, junto con el razonamiento en cuántas IP de proxy necesitas realmente.
Y programa teniendo en cuenta la población, ya que ejecutar un trabajo pesado para un mercado pequeño durante sus horas de madrugada es luchar contra el pool sin motivo.
Cómo se ve desde fuera una buena gestión del pool
No puedes auditar el funcionamiento interno de un proveedor, pero los efectos son observables. Tasas de éxito consistentes en las horas en que ejecutas sugieren que el pool tiene suficiente profundidad en tus mercados en lugar de ser simplemente grande en conjunto. Una amplia variedad de organizaciones de ISP de consumidores en tu muestra de salidas sugiere un suministro residencial genuino en lugar de uno diluido, que es la comprobación en detectar IP de datacenter vendidas como residenciales. Una geolocalización que coincide con lo que los objetivos realmente creen, en lugar de solo lo que reporta un servicio de consulta, sugiere que el etiquetado geográfico se mantiene. Y un proveedor que puede describir su forma de obtención sin incomodidad te está diciendo algo sobre cómo se gestiona el pool en general.
La conclusión
Un pool residencial es una población, no un inventario. Se construye mediante participación en lugar de comprarse, su forma sigue el software que la gente realmente usa, y rota continuamente a medida que los dispositivos se desconectan, las direcciones se reasignan y los participantes van y vienen. Esa única propiedad explica que las sesiones persistentes terminen antes de tiempo, que las direcciones se repitan, que la latencia varíe ampliamente, que la disponibilidad se mueva a lo largo del día, y que dos ejecuciones idénticas produzcan resultados diferentes. Diseña teniendo esto en cuenta: trata las direcciones como desechables, controla el estado por ruta, haz que las secuencias sean reanudables, elige TTL que se ajusten al flujo, y mide tu pool efectivo bajo tus propios filtros en tus propias horas en lugar de confiar en una cifra destacada que describe algo distinto de lo que realmente te condiciona.
Ese pool es sobre lo que se apoyan los proxies residenciales, que abarcan 195 países con filtros de país, región, ciudad y ASN, y precios por GB, de modo que medir tu propia disponibilidad efectiva solo cuesta el ancho de banda que use la prueba.