La arquitectura hacia la que convergen la mayoría de los sistemas de scraping es contenedores en un proveedor cloud, escalados por profundidad de cola, sin estado y desechables. Es el diseño correcto para el cómputo. Es el peor diseño posible para el egress, porque las direcciones que obtienen esos contenedores son lo primero que comprueba un sitio defendido.
Los rangos de los proveedores cloud están publicados. Cualquiera puede enumerarlos, y la mayoría de los proveedores de anti-bot lo hacen. El tráfico procedente de ellos no se bloquea por lo que hizo, se puntúa por su procedencia antes de que termine la primera petición. La solución no son más workers ni mejores headers. Es separar dónde se ejecuta el código de dónde sale el tráfico.
La capa de egress es una cuestión separada
El modelo mental útil es que tus workers son cómputo y tus direcciones son identidad, y deben escalar de forma independiente.
Los workers efímeros son buenos: arrancas cincuenta, terminas la cola, los detienes. Las identidades efímeras suelen ser malas: cada nuevo worker que llega desde una nueva dirección cloud es un flujo de tráfico desconocido. Lo que quieres es un conjunto estable de direcciones de salida que persista a través de las generaciones de workers, de modo que la identidad que ven tus objetivos no cambie cada vez que tu autoscaler reacciona.
Las ISP proxies encajan en ese papel precisamente porque son fijas. Cada dirección está dedicada a tu cuenta durante la vida del plan, registrada a un ISP real en lugar de a un bloque cloud, y no rota. Tus workers vienen y van; las direcciones no.
Dos modos de autenticación, y la elección es arquitectónica
Cada dirección de un plan usa el mismo puerto (1337), con dos formas de autenticarse. En un despliegue cloud esto no es una preferencia, se deriva de tu networking.
IP de origen autorizada. Añades a la lista blanca en el panel la dirección pública de tu infraestructura y te conectas sin credenciales:
185.199.108.153:1337Esto funciona cuando tu egress es predecible, lo que en la práctica significa un NAT gateway o equivalente con una dirección estable delante de tus workers. Es la opción más limpia cuando aplica, porque no hay credenciales en tus contenedores en absoluto.
Usuario y contraseña. Funciona desde cualquier lugar, sin lista blanca:
185.199.108.153:1337:USERNAME:PASSWORDEsto es lo que quieres cuando los workers son genuinamente efímeros a través de direcciones cambiantes, o están repartidos entre regiones, o se ejecutan en un entorno donde no controlas la dirección de salida. Las funciones serverless y los despliegues multirregión caen aquí.
La trampa es elegir la autenticación por IP de origen en un entorno donde la dirección de origen no es realmente fija. Funciona durante las pruebas desde una subred y luego falla de forma intermitente en producción a medida que la plataforma asigna otra. Si no puedes indicar tu dirección de egress con confianza, usa credenciales.
Distribuir direcciones entre workers
Tienes N direcciones y un número variable de workers, así que algo tiene que asignar una a otro.
El enfoque que se sostiene es tratar la lista de direcciones como un recurso compartido con arrendamientos explícitos en lugar de dejar que cada worker elija. Un worker toma una dirección de una capa de coordinación, la mantiene durante la duración de su tarea, y la devuelve. Dos propiedades importan: que dos workers no usen una dirección simultáneamente de forma que se duplique su tasa de peticiones aparente, y que un fallo de worker no elimine permanentemente una dirección de la circulación.
La alternativa naíf, hacer hash de la identidad del worker a un índice, se rompe en el momento en que cambia el número de workers, lo cual en un despliegue con autoescalado es constante. Obtienes colisiones al escalar hacia arriba y direcciones inactivas al escalar hacia abajo.
La tasa de peticiones por dirección es el presupuesto real aquí. El ancho de banda en los planes de ISP es ilimitado, así que la restricción no son los gigabytes, es cuánto tráfico puede producir de forma plausible una dirección fija. Ese número es lo que determina cuántas direcciones necesita tu despliegue, y por eso el dimensionamiento por rendimiento en lugar de por volumen de datos es el ejercicio correcto.
Las comprobaciones de salud pertenecen al pool
Las direcciones no fallan de forma uniforme. Una puede empezar a recibir challenges de un objetivo específico mientras todo lo demás está bien, y un worker que reciba esa dirección producirá datos basura hasta que algo lo note.
Registra los resultados por dirección en lugar de en agregado. Una tasa de éxito por dirección sobre una ventana móvil, por objetivo si recopilas de varios, te da la capacidad de poner en cuarentena una dirección sin retirar todo el pool. Las métricas agregadas te mostrarán una caída del cinco por ciento y ocultarán el hecho de que es una sola dirección la que está fallando por completo.
La cuarentena debe ser temporal y automática, con una sonda que devuelva la dirección cuando se recupere. El método para establecer en primer lugar cómo es lo normal está en cómo probar la velocidad, la tasa de éxito y la precisión de ubicación de proxies residenciales.
Planifica la geografía antes de comprar
Un detalle que pilla a los equipos cloud: en los planes de ISP eliges la distribución por países una sola vez, antes de que se aprovisionen las direcciones, y no se puede cambiar después. Hay siete países disponibles.
Esto es distinto a casi todo lo demás en un despliegue cloud, donde estás acostumbrado a cambiar de opinión de forma económica. Decide el reparto en función de los objetivos de los que realmente recopilas, y si no estás seguro entre dos mercados, compra el plan del que estés seguro y añade en lugar de adivinar.
Cuándo ISP es la herramienta equivocada
Las direcciones estáticas no son un sustituto general de la rotación, y la infraestructura cloud tienta a fingir lo contrario porque el modelo operativo es mucho más simple.
Si tu carga de trabajo es recopilación de alto volumen entre muchos objetivos, la tasa de peticiones por dirección se vuelve implausible mucho antes de que lo haga el coste, y el síntoma son datos degradados en lugar de errores. Ese trabajo pertenece a las proxies residenciales rotativas, donde cada petición puede venir de una dirección distinta por diseño. La compensación se explica en ISP proxies frente a datacenter y residencial.
Las cargas de trabajo donde una capa de egress fija es genuinamente correcta: sesiones de larga duración, cualquier cosa autenticada, objetivos que ponen en lista blanca tus direcciones, APIs de partners que esperan un origen conocido, y recopilación constante donde la consistencia importa más que el volumen. La arquitectura mixta es habitual y correcta, con direcciones de ISP para el trabajo persistente y una puerta de enlace rotativa para el grueso.
Notas operativas
Mantén la lista de direcciones en la configuración, no en las imágenes. Reconstruir contenedores para cambiar el pool es evitable. Léela al arranque desde tu secret store o servicio de configuración.
No registres en logs la URL con credenciales. Es la forma más común, con diferencia, en que las credenciales de proxy llegan a un agregador de logs, porque la línea de depuración natural es la cadena de conexión completa.
Limita la concurrencia por dirección, no solo globalmente. Un límite global repartido de forma desigual entre un pool pequeño concentra la carga en las direcciones que favorezca tu lógica de asignación. La mecánica relevante está en rate limiting y throttling de peticiones.
Prueba desde dentro del despliegue. Una comprobación de conectividad desde un portátil demuestra que tus credenciales funcionan. No demuestra nada sobre si la definición de tu tarea pasa correctamente las variables de entorno, que es el fallo real la mayoría de las veces.
Preguntas frecuentes
¿Puedo usar ISP proxies desde funciones serverless?
Sí, con autenticación por credenciales. La lista blanca por IP de origen es poco práctica ahí porque la dirección de salida no está bajo tu control.
¿Cuántas direcciones necesita un despliegue con autoescalado?
Dimensiona según los trabajos concurrentes máximos y una tasa de peticiones por dirección conservadora, no según el número de workers. Los workers pueden estar inactivos; las direcciones no deberían ser lo que se agote en el pico.
¿Se convierte la capa de proxy en un cuello de botella?
Las direcciones de ISP se ejecutan sobre infraestructura de datacenter a velocidades de gigabit, así que el rendimiento por dirección rara vez es el límite. La política de concurrencia suele ser la restricción primero.
¿Debería cada servicio tener sus propias direcciones?
Si sus patrones de tráfico difieren sustancialmente, sí. Mezclar un servicio estable de baja tasa con uno a rachas en la misma dirección hace que el que va a rachas determine cómo se trata a ambos.
Conclusión
La infraestructura de scraping en cloud se bloquea por una razón que no tiene nada que ver con la calidad del código: las direcciones están publicadas como direcciones cloud. Poner una capa de egress de ISP fija delante de workers efímeros separa la identidad del cómputo, que es la separación que la arquitectura necesitaba de todos modos.
Arrienda las direcciones de forma explícita, monitoriza la salud por dirección, dimensiona por tasa de peticiones en lugar de por ancho de banda, y decide la geografía antes de comprar, porque esa elección es permanente. Los planes están en la página de precios de ISP proxies.