La pregunta «¿cuántos hilos aguanta un puerto?» se hace sobre todo antes de lanzar un scraping masivo o de calentar decenas de cuentas, y no existe un número universal como respuesta. El límite depende de la combinación de tres factores: el ancho de banda del canal, la política del proveedor y cómo se comporta el sitio de destino bajo carga paralela. Veamos qué limita realmente el número de hilos y cómo evitar chocar con ese techo al arrancar la tarea.
De qué depende el límite de paralelismo
El primer factor es el ancho de banda del canal del lado del proveedor. Una dirección de datacenter o ISP suele estar en un canal dedicado y ancho, y soporta decenas de conexiones simultáneas sin degradarse. El tráfico residencial y móvil pasa por un abonado real o por una red celular: ahí el canal es más estrecho, y al aumentar los hilos de forma lineal se llega antes a problemas de latencia y pérdida de paquetes. La diferencia entre estos canales se explica con más detalle en el artículo proxies móviles frente a residenciales.
El segundo factor son los límites del propio proveedor. Algunos planes venden el puerto con un tope formal de conexiones paralelas: lo que excede ese tope se recorta o, simplemente, las nuevas conexiones no se establecen. La restricción está escrita en las condiciones del plan y no tiene que ver con la calidad del canal: es artificial y se elimina pasando a un plan más amplio o añadiendo puertos.
El tercer factor, y a menudo el decisivo, es el propio sitio de destino. Tiene su límite de solicitudes por IP en un intervalo de tiempo, normalmente más bajo de lo que puede pasar el canal. Incluso un puerto sin límite de hilos choca con ese techo: el sitio devuelve captcha, un bloqueo temporal de la IP o respuestas vacías mucho antes de que se agote el canal del proxy.
Señales de sobrecarga
La sobrecarga rara vez aparece como un error explícito de «límite excedido»; lo más común es que se disfrace de inestabilidad. La primera señal es el aumento de timeouts: las solicitudes que antes respondían en fracciones de segundo empiezan a colgarse y se cortan por el timeout del cliente. La segunda es el aumento de la proporción de conexiones que se cortan antes de recibir respuesta, mientras que el sitio de destino funciona con normalidad desde otras direcciones. Conviene seguir estas métricas con los mismos principios que se describen en el artículo cómo comprobar la calidad de un proxy.
La tercera señal es un aumento notable de captchas y bloqueos temporales precisamente desde esa IP, con el mismo escenario de solicitudes. Si antes el captcha aparecía solo de forma esporádica cada mil solicitudes y, tras aumentar los hilos, salta en una de cada diez, no es casualidad: es una señal de que el paralelismo superó tanto el límite del sitio como un tope razonable para una sola dirección.
Por qué más hilos no significa más rapidez
A primera vista parece que duplicar los hilos duplica la velocidad de recolección de datos, pero en la práctica la curva llega pronto a una meseta y luego baja. Cada solicitud cortada por timeout no es solo un intento perdido, sino un efecto secundario tóxico: el script la repite, con lo que aumenta la carga sobre la misma IP, o pierde datos que luego hay que recolectar en una pasada aparte.
En cuanto el sitio empieza a responder con captcha en lugar de contenido, la velocidad útil de procesamiento cae más rápido de lo que crece el número de conexiones: una parte de los hilos gasta tiempo en resolver o esquivar el captcha en vez de recolectar datos, y otra recibe una respuesta basura que hay que descartar y volver a solicitar. El punto óptimo casi siempre está por debajo del máximo técnico del canal: donde la proporción de errores y reintentos es mínima, no donde el canal está cargado por completo.
Cómo repartir la carga entre puertos
Cuando la tarea necesita más paralelismo del que una sola dirección puede sostener con seguridad, la solución no es «exprimir el puerto al máximo», sino repartir la carga entre varios puertos con IP distintas. El sitio ve cada dirección como un visitante independiente, con su propio límite de solicitudes por intervalo, así que diez puertos con cinco hilos seguros cada uno darán más rendimiento estable que un solo puerto forzado a cincuenta hilos.
El enfoque práctico es empezar con un número conservador de hilos por dirección, subirlo poco a poco, anotar el momento en que crecen los timeouts o la proporción de captchas y mantenerse claramente por debajo de ese umbral. En los canales residenciales y móviles con asignación de dirección por sesión, la rotación de IP entre solicitudes reduce por sí sola la carga sobre cada dirección, porque el sitio ve IP distintas en lugar de una sola sobrecargada. Cómo configurar esa rotación mediante API se explica en un artículo aparte, sobre la rotación de IP.
Relación entre hilos y consumo de tráfico
El número de hilos multiplica directamente el consumo de tráfico, no solo la velocidad. Los canales residenciales y móviles se tarifican por gigabytes, por eso un paralelismo agresivo sin desactivar la carga de medios innecesarios (imágenes, fuentes, reproducción automática) consume el presupuesto de tráfico muchas veces más rápido de lo que crece el resultado útil. Como referencia: mil comprobaciones de fichas de producto con imágenes son aproximadamente 3–5 GB, y mil páginas de texto, cerca de 1 GB; al escalar los hilos, las cifras se multiplican de forma lineal, y el presupuesto conviene calcularlo de antemano, no ajustarlo cuando ya se agotó el saldo.
Preguntas frecuentes
¿Existe un número universal de hilos «por puerto»?
No, porque el límite lo determina el sitio de destino tanto como el canal. Para un sitio son cómodas incluso treinta solicitudes paralelas desde una dirección; para otro, la sobrecarga empieza ya con cinco. Hay que partir del comportamiento del sitio concreto, no de una norma abstracta.
¿Qué pasa si se supera el límite del proveedor de conexiones paralelas?
Por lo general, las nuevas conexiones que exceden el límite no se establecen, o se cierra una parte de las sesiones ya abiertas; el comportamiento depende del plan. No es una degradación de la calidad del canal, sino una restricción estricta que se elimina pasando a un plan con un límite mayor o añadiendo puertos.
¿Ayuda la rotación de IP a mantener más hilos a la vez?
Sí, de forma indirecta: si cada nueva solicitud o sesión recibe una dirección nueva, el límite del sitio de destino se calcula de nuevo para cada IP en lugar de acumularse en una sola. Esto no elimina las restricciones del canal y del plan, pero quita parte de la carga asociada precisamente a los límites del sitio por dirección concreta.
Las tarifas vigentes según el número de hilos y los tipos de canal están en la sección de proxies. Allí mismo puedes comprar puertos adicionales para repartir la carga, sin forzar una sola dirección por encima de su límite seguro.