“¿Debería rotar en cada solicitud?” es una de las primeras preguntas que se hacen los equipos cuando empiezan a usar proxies residenciales, y la respuesta honesta es: depende de qué tengan en común tus solicitudes. Rotar demasiado rompe flujos que un sitio espera que vengan de un solo visitante. Rotar demasiado poco acumula todo tu tráfico en una sola dirección. Ambos te cuestan bloqueos, reintentos y ancho de banda.
Esta guía ofrece una forma sencilla de decidir. La pregunta decisiva no trata sobre el proxy en absoluto. Trata sobre tu trabajo: qué solicitudes van juntas, y durante cuánto tiempo.
Los tres modos
| Modo | Qué hace | En Shifter |
|---|---|---|
| Rotar por solicitud | Cada solicitud sale desde una IP residencial diferente | El valor predeterminado: sin indicador de sesión en el nombre de usuario |
| Sesión persistente (sticky) | Las solicitudes con el mismo ID de sesión comparten una IP hasta que la sesión termina | Añade sid-<id> al nombre de usuario, opcionalmente ttl-<seconds>; la duración predeterminada es 120 segundos |
| IP fija | Una dirección en una ciudad e ISP elegidos durante todo el periodo de facturación | Proxies ISP |
Una sesión persistente también termina antes de tiempo si la IP residencial que hay detrás se desconecta, así que el código que usa sesiones debería esperar un cambio ocasional de IP a mitad de sesión. Las sesiones persistentes se mantienen por región, de modo que las herramientas que comparten una sesión deben conectarse a través del mismo punto de entrada regional.
La pregunta decisiva: ¿qué va junto?
Observa la unidad de trabajo más pequeña que repite tu scraper, y pregúntate dos cosas sobre ella.
1. ¿Cuántas solicitudes componen una unidad? Una página de producto obtenida por sí sola es una solicitud. Una búsqueda seguida de seis páginas de detalle es un flujo. Una prueba de checkout es un flujo con estado: un carrito, una cookie de sesión, quizá un token CSRF.
2. ¿Cuánto dura una unidad? ¿Segundos, minutos u horas?
A partir de esas dos respuestas:
- Solicitudes independientes y aisladas: rotar. Cada página se sostiene por sí sola, así que no hay nada que ganar manteniendo una IP, y repartir las solicitudes entre muchas direcciones evita que alguna de ellas parezca ocupada.
- Un flujo que termina en 30 minutos: sesión persistente. El sitio establece cookies en la primera solicitud y espera el resto del flujo del mismo visitante. Cambiar de IP a mitad de una búsqueda o un carrito parece una sesión secuestrada, y es una causa habitual de bloqueos repentinos y pérdida de estado.
- Cualquier cosa más larga, o un inicio de sesión al que vuelves: IP fija. Las sesiones persistentes están pensadas para minutos, no para horas. Para una sesión que dura todo el día, o una cuenta que usas a diario, usa un proxy ISP. Nuestra guía sobre configuración de proxy ISP para sesiones largas lo trata en detalle.
Como código
Las dos funciones siguientes codifican la regla y construyen el nombre de usuario de Shifter correspondiente:
def proxy_username(user, country=None, session_id=None, ttl_seconds=None):
"""Build a Shifter residential username: rotate per request, or stick to one IP."""
parts = [f"customer-{user}"]
if country:
parts.append(f"country-{country}")
if session_id:
parts.append(f"sid-{session_id}")
if ttl_seconds:
parts.append(f"ttl-{ttl_seconds}")
elif ttl_seconds:
raise ValueError("ttl only works together with a session id")
return "-".join(parts)
def choose_rotation(steps, minutes, needs_login=False, same_ip_required=False):
"""Pick a rotation mode for one unit of work.
steps: requests that belong together (one page = 1, a checkout flow = many)
minutes: how long that unit of work takes
"""
if needs_login and minutes > 30:
return "isp" # a login that outlives a sticky session
if steps == 1 and not same_ip_required:
return "rotate" # independent requests: new IP each time
if minutes <= 30:
return "sticky" # a short flow: one IP until it ends
return "isp"Aplicado a cuatro trabajos típicos:
from rotation import choose_rotation, proxy_username
jobs = { # session ids must not contain hyphens: the username uses them as separators
"products": dict(steps=1, minutes=0.1),
"search": dict(steps=6, minutes=2),
"checkout": dict(steps=15, minutes=8),
"seller": dict(steps=400, minutes=240, needs_login=True),
}
for name, job in jobs.items():
mode = choose_rotation(**job)
if mode == "rotate":
user = proxy_username("USERNAME", "us")
elif mode == "sticky":
user = proxy_username("USERNAME", "us", session_id=name, ttl_seconds=job["minutes"] * 60 + 120)
else:
user = "an ISP proxy username from your plan"
print(f"{name:<9} {mode:<7} {user}")products rotate customer-USERNAME-country-us
search sticky customer-USERNAME-country-us-sid-search-ttl-240
checkout sticky customer-USERNAME-country-us-sid-checkout-ttl-600
seller isp an ISP proxy username from your planEl TTL se fija según la duración esperada del flujo más dos minutos de margen, de modo que la sesión dure más que el trabajo pero no se prolongue innecesariamente. Da a cada flujo concurrente su propio ID de sesión: dos workers que comparten un ID comparten una IP, lo cual anula el propósito.
Cómo afecta la elección al coste y al éxito
Tasa de éxito. El error de rotación más común es rotar dentro de un flujo. La primera solicitud recibe una cookie, la segunda llega desde el ISP de otro país con esa cookie, y el sitio lo trata como sospechoso. Las sesiones persistentes para flujos suelen arreglar más fallos que cualquier otro cambio individual. El error contrario, enviar miles de solicitudes independientes a través de una sola IP persistente, hace que esa única dirección parezca un bot. Nuestra guía sobre proxies residenciales persistentes frente a rotativos profundiza en ambos modos de fallo.
Ancho de banda. El tráfico residencial se factura por gigabyte, y la rotación en sí no cambia eso. Lo que lo cambia son los reintentos: cada flujo fallido se descarga de nuevo. Ajustar el modo al trabajo reduce los reintentos, y de ahí viene el ahorro. Dentro de una sesión persistente, reutilizar la misma conexión y las mismas cookies también puede evitar descargar los mismos recursos dos veces.
Velocidad. Rotar por solicitud significa una nueva ruta para cada solicitud. Si además abres una nueva conexión cada vez, el tiempo de configuración se acumula. Reutilizar conexiones importa más que el modo de rotación; nuestra prueba en tu scraper es lento y probablemente no es el proxy midió cuánto.
Señales de que elegiste mal
| Lo que ves | Causa probable | Cambio |
|---|---|---|
| Los flujos fallan tras el primer paso; se pierde el carrito o la sesión | Rotar dentro de un flujo | Sesión persistente por flujo |
| Una IP bloqueada tras una ráfaga de solicitudes | Demasiado trabajo independiente en una sola sesión persistente | Rotar por solicitud para páginas independientes |
| Las sesiones se caen antes de que termine el trabajo | TTL demasiado corto, o el flujo es demasiado largo para una sesión persistente | Aumenta el TTL; traslada el trabajo de horas de duración a un proxy ISP |
| Dos workers interfieren entre sí | ID de sesión compartido | Un ID de sesión por flujo concurrente |
| Inicios de sesión cuestionados cada día | Un inicio de sesión sobre IPs rotativas o persistentes | IP ISP fija por cuenta |
Preguntas frecuentes
¿Debería rotar la IP de mi proxy en cada solicitud?
Para solicitudes independientes, como obtener páginas de producto no relacionadas, sí. Para cualquier cosa que abarque varias solicitudes con estado compartido, como una búsqueda, un carrito o un inicio de sesión, mantén una IP durante todo el flujo con una sesión persistente.
¿Cuánto debería durar una sesión persistente?
Tanto como el flujo al que sirve, más un pequeño margen. En Shifter el valor predeterminado es 120 segundos y puedes establecerlo con ttl-<seconds>. Los flujos de más de unos 30 minutos, y los inicios de sesión a los que vuelves, pertenecen a los proxies ISP.
¿Rotar las IPs reduce los bloqueos?
Reparte la carga para que ninguna dirección parezca ocupada, lo cual ayuda en solicitudes independientes. Rotar dentro de un flujo hace lo contrario: hace que un solo visitante parezca muchos, algo que los sitios suelen bloquear.
¿Afecta la rotación al coste de ancho de banda?
No directamente, ya que el tráfico residencial se factura por volumen. Indirectamente, el modo equivocado provoca flujos fallidos y reintentos, que se descargan de nuevo y se suman a la factura.
La conclusión
Rota por solicitud para trabajo independiente, mantén una sesión persistente para cada flujo que vaya unido, y usa una IP ISP fija para todo lo que dure horas o implique un inicio de sesión al que vuelves. Decide mirando tu unidad de trabajo, no los ajustes del proxy, da a cada flujo concurrente su propio ID de sesión, y presta atención a las señales de la tabla anterior. Nuestro artículo explicativo sobre cómo funciona la rotación de proxies residenciales cubre la mecánica detrás de cada modo.