“Mis peticiones dan timeout” es uno de los mensajes de soporte más comunes que recibimos, y también uno de los menos específicos. Un timeout es un síntoma, no una causa. El mismo error aflora tanto si el gateway no pudo encontrarte una IP de salida coincidente, como si tu cliente se rindió a los 5 segundos en una conexión que necesitaba 8, como si el sitio objetivo es lento, o como si tu propio contenedor está mal configurado y nunca llega al proxy.
Esta es una guía de diagnóstico: cómo identificar cuál de esas está pasando de verdad, en el orden que lo encuentra más rápido. Es la compañera de reducir la latencia, que va de hacer más rápida una configuración que funciona; esta va de una configuración que se cuelga o falla, y por qué.
Paso 0: ¿es de verdad un timeout?
Antes de diagnosticar, clasifica con precisión, porque tres fallos distintos se reportan como “timeout” y tienen arreglos distintos:
- Connect timeout — tu cliente no pudo establecer conexión con el gateway en absoluto. Esto apunta a tu lado: salida de red, firewall, host/puerto equivocados, o configuración del contenedor.
- Read / response timeout — conectaste bien, la petición pasó, pero no volvió respuesta a tiempo. Esto apunta a la salida o al objetivo: ninguna IP coincidente, un dispositivo de salida lento, o un sitio objetivo lento.
- No es un timeout en absoluto — un
407(auth), un502(ninguna IP coincidió con tu filtro), o una página de CAPTCHA colgada. Estos a menudo se reportan como timeouts por código envoltorio que captura todo como una sola excepción.
La mayoría de los clientes te dejan separar los timeouts de connect y de read explícitamente. Hacerlo es el paso de diagnóstico de mayor valor, y normalmente es un cambio de una línea:
import requests
# (connect_timeout, read_timeout) - sepáralos, no pases un único númeror = requests.get(url, proxies=proxies, timeout=(10, 30))Si falla en los primeros 10 segundos, es un problema de connect. Si sobrevive al connect y muere a los 30, es un problema de read. Sigue a la sección correspondiente.
Causa 1: tu filtro geo está demasiado ajustado
Esta es la causa real más común, y la más fácil de arreglar.
Cada flag de targeting estrecha el pool de IPs de salida elegibles. country-us selecciona de un conjunto enorme. country-us-city-scranton-asn-12345 puede seleccionar de casi nada. Cuando pocas o ninguna salida coinciden, las peticiones esperan, luego fallan, y según tu cliente eso aflora como un timeout o un 502.
Diagnostícalo aflojando un flag cada vez:
# ¿Funciona solo con country?curl -x customer-USER-country-us:PASS@p.shifter.io:443 https://api.ipify.org --max-time 30
# Luego vuelve a añadir la ciudad y comparacurl -x customer-USER-country-us-city-chicago:PASS@p.shifter.io:443 https://api.ipify.org --max-time 30Si solo-country tiene éxito y el filtro más estrecho da timeout, has encontrado la causa. Arreglo: conserva solo la precisión que tus datos genuinamente necesitan. Si tu caso de uso de verdad requiere esa ciudad, espera un pool más pequeño y menos throughput, y presupuéstalo (cuándo importa el targeting a nivel de ciudad cubre cuándo merece el coste).
Causa 2: tu timeout está pensado para datacenter, no para residencial
Un segundo muy cercano, y produce “timeouts” en peticiones que nunca estuvieron rotas.
El tráfico residencial enruta por un dispositivo de consumidor real en una red doméstica, así que tiene un suelo de latencia que los proxies de datacenter no tienen (residencial vs datacenter). Un timeout total de 5 segundos, perfectamente razonable para datacenter, cortará una petición residencial sana a mitad de vuelo y la reportará como un fallo.
Diagnostícalo midiendo antes de ajustar: recoge la latencia p50 y p95 de tu objetivo real a través del proxy (cómo probar la velocidad, tasa de éxito, y precisión de ubicación de un proxy tiene el método). Si tu timeout está por debajo de tu p95, estás fabricando fallos.
Arreglo: pon el timeout por encima de tu p95 medido con margen, no a ojo. Como punto de partida, un connect timeout de unos 10s y un read timeout de 30s o más es sensato para residencial; luego aprieta según tus propios números.
Causa 3: el objetivo es lento, no el proxy
Fácil de confirmar, fácil de equivocarse. Cronometra el mismo camino de petición contra un endpoint rápido y neutral y contra tu objetivo real a través del mismo proxy:
# Endpoint neutral - mide el overhead del proxyrequests.get("https://api.ipify.org", proxies=proxies, timeout=(10, 30))
# Tu objetivo real - mide overhead del proxy + latencia del objetivorequests.get("https://your-target.example/page", proxies=proxies, timeout=(10, 30))Si el endpoint neutral es rápido y el objetivo lento, el proxy no es tu problema, y ninguna cantidad de ajuste del proxy lo arreglará. Sube el read timeout para ese objetivo, o reduce cuánto de la página traes.
Causa 4: la concurrencia es demasiado alta
Los timeouts que aparecen solo bajo carga y desaparecen cuando pruebas una única petición apuntan aquí.
Dos mecanismos: puedes estar agotando recursos locales (slots del pool de conexiones, descriptores de archivo, capacidad del event loop), así que las peticiones hacen cola en tu propio lado antes de salir siquiera; o el objetivo te está limitando y colgando en lugar de devolver un 429 limpio.
Diagnostícalo bajando la concurrencia a 1 y volviendo a probar. Si los timeouts desaparecen, es relativo a la carga. Arreglo: aplica límites de concurrencia por host en lugar de un único número global, que es la arquitectura de balanceo de carga de proxies.
Causa 5: manejo de conexiones
Dos errores opuestos, ambos produciendo timeouts:
Sin reutilización de conexiones. Crear una conexión fresca por petición significa pagar un handshake TCP + TLS completo a través del proxy cada vez, lo cual es lento y le da a tu timeout mucho menos margen. Usa una sesión/cliente con pooling.
Conexiones agrupadas rancias. Si agrupas conexiones pero rotas las IPs de salida por petición, los sockets agrupados pueden apuntar a salidas que ya no son válidas, y esos se cuelgan. Empareja el pooling con una sesión sticky para que la conexión agrupada se quede en una salida, y recicla las conexiones periódicamente.
Causa 6: el propio dispositivo de salida
Las salidas residenciales son dispositivos de consumidor reales en redes domésticas reales. Algunos están en enlaces congestionados, algunos son móviles, algunos se caen a mitad de petición. Un pequeño porcentaje de peticiones lentas o fallidas es normal y esperable en residencial, no un defecto.
Arreglo: no subas tu timeout para acomodar al peor dispositivo, eso solo hace más lento cada fallo. Falla rápido y reintenta con una identidad nueva, que te consigue una salida distinta. La guía de failover de ayer cubre clasificar fallos de transporte y reintentar correctamente. La calidad del pool determina cuán gruesa es esa cola (reputación de IP).
Causa 7: nunca llegó al proxy en absoluto
Vale la pena comprobarlo pronto si todo da timeout, especialmente en contenedores.
Confirma que la petición de verdad está saliendo por el gateway:
curl -x customer-USER-country-us:PASS@p.shifter.io:443 https://api.ipify.org# Devuelve una IP residencial -> el proxy funciona.# Devuelve tu propia IP -> tu cliente está ignorando el proxy.# Se cuelga por completo -> la salida local está bloqueada (firewall, VPN, red corporativa).En Docker y Kubernetes esta es una causa frecuente: el cliente no honra HTTP_PROXY en absoluto, o NO_PROXY está mal configurado, o localhost no significa lo que crees dentro de un contenedor. La guía de configuración de Docker cubre esos casos específicamente.
Causa 8: errores de auth o credenciales disfrazados
Un nombre de usuario malformado (un typo en un flag de targeting, un parámetro no soportado) o credenciales equivocadas pueden presentarse como un cuelgue o un fallo genérico según cómo maneje tu cliente un 407. Si tu configuración más laxa posible sigue fallando, verifica la cadena de credenciales carácter por carácter antes de asumir un problema de red.
El orden de diagnóstico
Corre estos en secuencia; cada uno elimina una gran clase de causas:
- Separa connect de read. Fallo de connect significa tu lado; fallo de read significa salida u objetivo.
- Verifica que estás en el proxy siquiera (la comprobación de ipify de arriba).
- Prueba solo con
country. Si eso funciona, tu filtro geo estaba demasiado ajustado. - Compara un endpoint neutral contra tu objetivo. Aísla el overhead del proxy de la lentitud del objetivo.
- Baja la concurrencia a 1. Si los timeouts desaparecen, es carga, no el proxy.
- Comprueba tu timeout contra tu p95 medido. Si está por debajo, estás creando los fallos.
Seis comprobaciones, y en la práctica una de ellas explica casi todo reporte de timeout que vemos.
Cuando los timeouts en realidad están bien
Una pequeña cola de peticiones lentas y fallidas es inherente a los proxies residenciales, porque los dispositivos de consumidor reales son inherentemente variables. Perseguir una tasa de éxito del 100% con timeouts cada vez más largos es el objetivo equivocado, hace tus fallos más lentos sin hacerlos menos.
El objetivo correcto es un SLO: define una tasa de éxito y un p95 aceptables para tu carga de trabajo, falla rápido en la cola, y reintenta con una identidad fresca. Un pipeline que falla una petición en 30 segundos y tiene éxito en el reintento es más sano que uno que espera 120 segundos con esperanza.
Preguntas frecuentes
¿Por qué recibo timeouts con un filtro de ciudad o ASN pero no solo con country? Porque cada flag estrecha el pool de salidas elegibles. Country + city + ASN puede dejar muy pocas IPs coincidentes, así que las peticiones esperan y luego fallan. Afloja hasta la precisión que tus datos de verdad necesitan, y espera menos throughput cuando genuinamente necesitas targeting ajustado.
¿Qué valores de timeout debería usar para proxies residenciales? Mide primero: tu timeout debería estar por encima de tu p95 observado, con margen. Como punto de partida, aproximadamente 10s de connect y 30s+ de read es sensato para residencial, luego ajusta según tus propios números. Los timeouts pensados para datacenter cortarán peticiones residenciales sanas.
¿Cómo sé si el lento es el proxy o el objetivo? Cronometra un endpoint neutral rápido y tu objetivo real a través del mismo proxy. El endpoint neutral mide el overhead del proxy; la diferencia es la latencia propia del objetivo. Si el endpoint neutral es rápido, el proxy no es el problema.
Todo da timeout, incluso peticiones simples. ¿Qué está mal? Comprueba que estás llegando al proxy siquiera: haz curl a un endpoint de echo de IP a través de él. Tu propia IP significa que el cliente está ignorando el proxy; un cuelgue total significa que la salida local está bloqueada (firewall, VPN, config del contenedor). Luego verifica tus credenciales y flags.
¿Debería simplemente aumentar mi timeout? Normalmente no. Si la causa es un filtro geo ajustado, un objetivo lento, o un dispositivo de salida malo, un timeout más largo solo hace que el fallo tarde más. Arregla la causa, y para la cola inevitable, falla rápido y reintenta con una identidad nueva.
En resumen
Un timeout es un síntoma con al menos ocho causas distintas, y el arreglo depende por completo de cuál tengas. Separa connect de read, confirma que de verdad estás en el proxy, afloja tu filtro geo, aísla la lentitud del objetivo del overhead del proxy, prueba con concurrencia 1, y comprueba tu timeout contra tu p95 medido. Esa secuencia resuelve la abrumadora mayoría de los casos, normalmente en minutos.
Y acepta la cola: las salidas residenciales son dispositivos reales, así que algo de variabilidad es el coste de la confianza de usuario real. Falla rápido, reintenta con una identidad fresca, y juzga la configuración por tasa de éxito y p95 en lugar de por si alguna petición da timeout alguna vez. Si sigues atascado tras las seis comprobaciones, los docs del gateway residencial y nuestro equipo pueden ayudar a acotarlo, trae tu separación connect/read y una muestra de la cadena de credenciales que falla, y la respuesta suele ser rápida.