Tu script se cae por una conexión cortada una vez cada cien solicitudes con una IP de centro de datos y una vez cada diez con un canal residencial o móvil. No es un defecto del proxy, sino una característica del entorno: las caídas en un canal doméstico o celular son normales, y el cliente debe superarlas por sí solo, sin intervención humana. Veamos de dónde viene la diferencia en la frecuencia de las caídas, qué timeouts y pausas entre reintentos conviene configurar, qué errores vale la pena reintentar y cuáles no, y cómo influyen los reintentos en el consumo de tráfico.
Por qué un canal residencial o móvil se corta más que uno de servidor
Una IP de centro de datos está en un canal dedicado del proveedor, con redundancia y un jitter casi nulo: allí una caída es rara y normalmente se trata de una avería del sistema. Una dirección residencial es una conexión doméstica real: el router se reinicia, el proveedor cambia al abonado entre nodos, se renueva la concesión DHCP, el dispositivo entra en suspensión por un minuto. El canal móvil añade a esto los traspasos entre estaciones base, el cambio de redes y la pérdida temporal de señal; todo esto ocurre en el dispositivo vivo de un abonado real, y no en un puerto dedicado para ti. El NAT del operador celular, gracias al cual cientos de abonados comparten una misma dirección, es la misma razón por la que casi es imposible bloquear una IP así: más detalles en el artículo por qué es difícil bloquear los proxies móviles. La otra cara de la resistencia a los bloqueos es que el propio canal es físicamente menos estable que uno de servidor.
Valores razonables de timeout de conexión y de lectura
El timeout de conexión (connect timeout) y el timeout de lectura (read timeout) son cosas distintas y no se deben confundir. El connect timeout limita el tiempo para establecer la sesión; para un canal de centro de datos bastan 3–5 segundos, y para uno residencial o móvil, 8–15, porque a través de un dispositivo real el paquete pasa por más nodos intermedios. El read timeout limita la espera de la respuesta una vez que la conexión ya está establecida; la referencia es el tiempo de respuesta esperado del servidor de destino con un margen de 2–3 veces, normalmente 15–30 segundos para solicitudes comunes y más para operaciones pesadas. Un timeout demasiado corto en un canal residencial convierte una latencia de red normal en un fallo falso; uno demasiado largo mantiene la conexión abierta sin utilidad y gasta tráfico en vano.
Pausa exponencial entre reintentos
Repetir la solicitud inmediatamente después de una caída es mala idea: si la causa es la sobrecarga de un nodo o una pérdida temporal de señal, el reintento instantáneo caerá en el mismo estado. El backoff exponencial aumenta la pausa con cada intento (por ejemplo, 1, 2, 4, 8 segundos) y le da tiempo al canal para recuperarse. A la pausa conviene sumarle un jitter aleatorio de entre el 20 y el 30 % del valor calculado: sin él, los hilos paralelos de un mismo script repiten las solicitudes de forma sincronizada tras un fallo común y generan su propio pico de carga. Es razonable limitar el número de intentos a tres o cuatro: más allá, la probabilidad de éxito casi no crece, mientras que el gasto de tiempo y de tráfico crece de forma lineal.
Qué errores reintentar y cuáles no
Vale la pena reintentar lo que parece un fallo temporal: una conexión cortada, un timeout, los errores 502/503/504 y las excepciones de red sin respuesta del servidor. No conviene reintentar lo que no cambiará con un nuevo intento: el error 400 con un cuerpo de solicitud incorrecto, 401/403 como problema de autorización, 404 como recurso inexistente. El código 429 requiere un tratamiento aparte: no es un fallo, sino una indicación directa de bajar el ritmo, y esa solicitud debe reintentarse con la pausa que el servidor suele indicar en un encabezado de la respuesta, y no según el esquema general de backoff. Reintentar ciegamente todos los errores sin distinguirlos es una causa típica de que un script pase horas golpeando una pared en lugar de detenerse y avisar del problema.
Cómo distinguir una caída del canal de un bloqueo por parte de la plataforma
Una caída del canal es la ausencia de respuesta: un timeout, un restablecimiento de la conexión, un error a nivel de TCP o TLS. Un bloqueo es una respuesta, solo que no deseada: un código 403, un captcha en lugar del contenido, una redirección a una página de verificación, un HTML de tamaño normal en lugar de los datos esperados. Lo primero se resuelve con un reintento; lo segundo, no: una nueva solicitud desde la misma dirección casi siempre recibe la misma respuesta de bloqueo, y cambiar de dirección mediante la rotación es otra cuestión, tratada en el artículo sobre la configuración de la rotación de IP por API. Cada reintento es una sesión aparte de un canal residencial o móvil, y estos canales se tarifican por tráfico: un reintento agresivo sobre una dirección bloqueada no resuelve el problema, solo gasta gigabytes en obtener el mismo rechazo. El límite de intentos y el análisis del código de respuesta son un asunto no solo de fiabilidad, sino también de presupuesto.
Preguntas frecuentes
¿Cuántas veces conviene repetir una solicitud antes de rendirse?
Para la mayoría de las tareas bastan tres o cuatro intentos con una pausa que crece de forma exponencial. Si todos fallan, la probabilidad de éxito del quinto intento en la misma dirección es baja y el consumo de tráfico sigue aumentando: es más sensato cambiar de dirección mediante la rotación o devolver el error al código que hizo la llamada.
¿Se necesitan configuraciones de timeout distintas para un canal de centro de datos y uno residencial?
Sí. El canal de centro de datos mantiene una latencia baja y estable, y allí un timeout corto se justifica. Los canales residenciales y móviles pasan por el equipo real de un abonado vivo, así que los timeouts en ellos conviene fijarlos bastante más amplios; de lo contrario, la latencia de red normal se tomará constantemente por un fallo.
¿Se puede usar el mismo algoritmo de reintentos para todos los errores?
No. Los fallos de red y las respuestas 5xx son candidatos a un reintento con retraso. Reintentar los errores de autorización y de solicitud incorrecta no tiene sentido. El código 429 exige una pausa según la instrucción del servidor, y los indicios de bloqueo (captcha, redirección, código 403) exigen cambiar de dirección, y no repetir desde la misma IP.
Los canales residenciales y móviles para tareas con reintentos están en la sección de proxies: allí mismo puedes estimar el consumo de tráfico de un escenario concreto y elegir el canal con el equilibrio de estabilidad y precio que necesitas, comparando antes la diferencia entre los proxies móviles y residenciales.