Cómo scrapear sitios que requieren login: sesiones, cookies y proxies sticky a escala

Buena parte de los datos que vale la pena recolectar está tras un login, y scrapearlos es una disciplina distinta de scrapear páginas públicas. En el momento en que te autenticas, dejas de ser un visitante anónimo y empiezas a operar una cuenta, y las cuentas reciben límites de ritmo, desafíos y baneos de formas que las peticiones anónimas nunca reciben. Todo el juego pasa de “rota libremente para que ninguna identidad destaque” a “mantén una identidad estable para que la cuenta parezca un usuario real y consistente”.

Una salvedad antes del cómo: solo scrapea datos que estés autorizado a acceder, tus propias cuentas, los datos de un partner que tengas permiso para extraer, una API que tengas derecho a usar. Los datos logueados son una categoría legal y ética distinta de los datos públicos, y si el scraping es legal depende mucho de esa línea. Esta guía asume que estás del lado correcto de ella.

El scraping público rota. El scraping autenticado se mantiene consistente.

El instinto del scraping público es rotar todo, una IP nueva por petición impide que una sola identidad destaque. Tras un login, ese instinto es exactamente al revés. Ahora tienes una identidad persistente, la cuenta, y la consistencia es lo que la hace parecer legítima. Una cuenta que se loguea desde cincuenta países en una hora, o salta de IP a mitad de sesión, no parece un usuario avanzado. Parece comprometida, y eso es lo que dispara un bloqueo.

Así que el scraping autenticado se reduce a dos cosas bien hechas: gestionar la sesión para mantenerte logueado de forma eficiente, y anclar cada cuenta a una identidad estable y limpia para que nunca parezca que se teletransportó.

Gestionar la sesión

Cuando te logueas, el servidor te devuelve estado de sesión, normalmente cookies, a veces un token. El mayor error, con diferencia, es volver a loguearse en cada petición. La re-autenticación es lenta, y una avalancha de logins es en sí una bandera roja que los endpoints de login limitan con dureza. Loguéate una vez, captura la sesión, y reúsala.

Con un cliente HTTP simple, eso significa un objeto de sesión persistente que conserva el tarro de cookies y va sobre el proxy:

import requests

proxies = {"https": "http://customer-USER-country-us-sid-acct42-ttl-600:PASS@p.shifter.io:443"}
s = requests.Session()
s.proxies.update(proxies)

# Loguéate una vez; la respuesta Set-Cookie puebla el tarro.
s.post("https://example.com/login", data={"user": USER, "password": PW})

# Reúsa la misma sesión (y la misma IP sticky) para cada petición posterior.
r = s.get("https://example.com/account/data")

Más allá de eso importan dos detalles. Muchos sitios requieren un token CSRF o anti-forgery por sesión que scrapeas de un formulario o una página previa y envías con las acciones de escritura, así que léelo de la sesión en lugar de hardcodearlo. Y muchos sitios, tras el login, exponen una API JSON limpia que el propio frontend del sitio llama; observar la pestaña de red a menudo la revela, y golpear esa API autenticada directamente con tus cookies o token capturados es mucho más rápido y ligero que re-renderizar páginas.

Ancla cada cuenta a una IP sticky y limpia

Aquí es donde la capa de proxy se gana su sitio. Una cuenta debería presentar una ubicación consistente, así que cada cuenta obtiene su propia sesión sticky: siempre sale por la misma IP residencial durante la vida de esa sesión, codificada aquí como el sid en el nombre de usuario. Rotar IPs en una cuenta logueada es un disparador de baneo clásico, porque la cuenta parece saltar entre ubicaciones a mitad de sesión.

Tres cosas hacen que la identidad aguante:

• Coincidencia de geo. La IP debería coincidir con donde la cuenta opera normalmente. Una cuenta de EE. UU. que de repente aparece en una IP alemana parece un secuestro, y muchos sitios responden con un prompt de re-verificación o un bloqueo.
• Reputación limpia. Los endpoints de login escrutan la reputación de la IP más duro que las páginas públicas, porque ahí es donde ocurren los robos de cuenta. Una dirección marcada recibe fricción extra, prompts de 2FA, CAPTCHAs, pantallas de “confirma que eres tú”, antes siquiera de llegar a los datos.
• Una cuenta, una identidad. Si corres varias cuentas, cada una necesita su propia IP sticky, no una compartida. Las cuentas que se loguean todas desde una única dirección quedan vinculadas y marcadas juntas. Esta es la versión a escala de cuentas de la identidad de dos capas que un navegador antidetección maneja a nivel de dispositivo: cuenta distinta, IP distinta, y si usas un navegador, huella distinta.

Escalar a muchas cuentas

El patrón escala mapeando cada cuenta a su propia identidad estable y manteniendo ese mapeo. Piensa en un registro: cuenta a sid sticky, cuenta a tarro de cookies, y, si manejas un navegador, cuenta a perfil de navegador.

# Una identidad duradera por cuenta: mismo sid -> misma IP de salida, tarro propio.
def session_for(account):
    s = requests.Session()
    sid = f"acct-{account['id']}"
    s.proxies.update({
        "https": f"http://{BASE_USER}-country-{account['geo']}-sid-{sid}-ttl-600:{PW}@p.shifter.io:443"
    })
    load_cookies(s, account)     # restaura el tarro persistido, o loguéate si no existe
    return s

Luego reparte la carga entre cuentas en lugar de empujar una cuenta fuerte, y limita la concurrencia por cuenta y por destino, ya que cada cuenta tiene su propio límite de ritmo. El principio de reparto de carga aplica, pero la unidad sobre la que distribuyes son cuentas, cada una en su identidad fija, no IPs crudas.

Maneja los modos de fallo

Tres cosas salen mal, y cada una tiene una respuesta específica.

Expiración de sesión. Las sesiones caducan. Detéctalo, un redirect a la página de login, o un 401, y re-autentícate en la misma identidad, luego reanuda. La regla crítica es no cambiar de IP cuando te re-autenticas; un re-login desde una nueva ubicación es mucho más sospechoso que la expiración en sí.

Logout silencioso. A veces obtienes un 200 que en realidad es la versión deslogueada de la página, todo el marco público, nada de los datos de la cuenta. Este es el primo autenticado de un bloqueo suave: valida que sigues logueado comprobando un elemento que solo ve un usuario con sesión, en lugar de fiarte del código de estado. Si el marcador solo-de-cuenta desapareció, re-autentícate antes de registrar filas vacías.

Re-verificación forzada. Un prompt de 2FA o un desafío de “confirma que eres tú” normalmente significa que la identidad pareció arriesgada, a menudo porque la IP estaba marcada o la ubicación cambió. Una IP limpia, estable y geo-coincidente es lo que mantiene esto raro. Cuando uno sí se dispara, trata esa identidad como bajo sospecha y retrocede en lugar de forzar a través de él.

Navegador o HTTP para el login en sí

Ajusta la herramienta al login, no a todo el scrape. Un login de formulario simple que devuelve cookies funciona bien con un cliente HTTP simple, captura las cookies, reúsalas, mantente ligero. Pero las páginas de login son con frecuencia la parte más defendida de un sitio, con desafíos JS, redirects SSO, tokens dinámicos y fingerprinting agresivo, precisamente porque ahí es donde ocurre el fraude. Cuando el login resiste a un cliente simple, loguéate con un navegador real (Playwright, Puppeteer o Selenium), y luego o sigue manejándolo o exporta las cookies a un cliente más ligero para el grueso del trabajo. Aquí es también donde el fingerprinting de TLS y HTTP/2 muerde más fuerte, así que la huella de red de un navegador real a menudo marca la diferencia en el paso del login aunque el resto del scrape vaya bien con un cliente simple.

Verifica antes de fiarte de una corrida

Tras autenticarte, confirma dos cosas: que de verdad estás logueado (obtén un endpoint solo-de-cuenta y comprueba un marcador de sesión iniciada), y que sales por la IP sticky que esperas (un chequeo que devuelva la IP debería dar la misma dirección durante la vida de la sesión). Si el login “tuvo éxito” pero falta el marcador de cuenta, o la IP de salida deriva entre peticiones, arréglalo antes de recolectar nada, ambos se cubren en las guías de timeout y detección.

En resumen

Scrapear tras un login va de consistencia de identidad, no de rotación. Loguéate una vez y reúsa la sesión en lugar de re-autenticarte constantemente, ancla cada cuenta a una IP residencial sticky, limpia y geo-coincidente, mantén una cuenta por identidad, re-autentícate en la misma identidad cuando una sesión expire, y valida que sigues logueado en lugar de fiarte de un 200. Escala añadiendo cuentas, cada una con su propia identidad estable, no rotando una sola cuenta entre direcciones.

Hazlo bien y la recolección autenticada es duradera en lugar de una ristra de bloqueos. Una IP residencial limpia y sticky por cuenta es el cimiento sobre el que descansa todo, y el precio por GB te deja correr muchas identidades de cuenta estables y pagar solo por los datos que cada una de verdad extrae.