Entrega automática tras confirmar el pago · IP dedicado · Soporte por ticket en el panel Pago local según tu país · Precios en dólares (USD)
ProxyBox
Automatización

Automatización que inicia sesión en una cuenta: la sesión, las cookies y la IP que no puede cambiar a mitad

Por qué una automatización con sesión iniciada necesita una IP fija, cómo reutilizar la sesión sin iniciarla cada vez y qué errores provocan verificaciones.

Por Redacción ProxyBox · Editor técnico 5 min de lectura automatización · sesión · inicio de sesión
Guía completa de Automatización

Este artículo profundiza en un punto del tema. Para la visión completa, lee Automatización con proxy: cuántas IP necesitas (y dónde las lee cada herramienta).

Hay un error de arquitectura que aparece en casi todas las automatizaciones con sesión iniciada, y sale caro: el script abre el navegador, inicia sesión, ejecuta la tarea, cierra todo y tira la sesión. Al día siguiente, lo repite.

Para la plataforma, eso no parece una automatización que se porta bien. Parece un inicio de sesión nuevo cada día, muchas veces desde un lugar distinto. Es el retrato de un acceso sospechoso.

Si todavía estás decidiendo cuántas direcciones necesita la operación, empieza por automatización con proxy: cuántas IP necesitas. Aquí el enfoque es solo la automatización que opera una cuenta.

Lo que ve la plataforma en cada ejecución

Cuando un sistema evalúa un acceso, lo compara con lo anterior: desde dónde suele entrar la cuenta, con qué navegador, con qué sesión activa. Iniciar sesión desde cero una y otra vez borra esa continuidad: cada ejecución empieza sin pasado.

Súmale una dirección que cambia y tienes dos cambios a la vez. Una automatización que reutiliza la sesión y mantiene la dirección produce lo contrario: un acceso que continúa donde se quedó.

Guarda la sesión, no la contraseña

La solución es reutilizar el estado de la sesión (cookies y almacenamiento local) en lugar de repetir el inicio de sesión.

# Playwright, Python: se guarda en el primer inicio de sesión
contexto.storage_state(path="sesiones/cliente-acme.json")

# En las ejecuciones siguientes, se abre ya autenticado
contexto = navegador.new_context(
    storage_state="sesiones/cliente-acme.json",
    proxy={"server": "http://host:puerto",
           "username": "usuario", "password": "contrasena"},
)

Tres cuidados que marcan la diferencia:

  • Un archivo de sesión por cuenta, con el mismo nombre que el perfil y la IP correspondientes. Mezclar sesiones es el equivalente digital de intercambiar las llaves de dos coches.
  • Fuera del repositorio. Un archivo de sesión da acceso a la cuenta sin pedir contraseña. Trátalo como una credencial: permisos restringidos y nunca en el control de versiones.
  • Detecta la caducidad. El código tiene que darse cuenta de que la sesión cayó, volver a iniciarla una vez y guardarla de nuevo. Si inicia sesión en todas las ejecuciones, la sesión no se está reutilizando de verdad.

Por qué la rotación no sirve aquí

Un proxy rotativo cambia la dirección de salida por sesión o por petición. Es justo lo que quieres al recoger páginas públicas, y justo lo que no quieres con una cuenta autenticada.

Una sesión que empieza en una dirección y sigue en otra es el escenario que más peticiones de verificación provoca, porque describe algo que una persona real no hace. Los tres modos de rotación y dónde sirve cada uno están en rotación de IP: fija, por sesión o por petición.

Para una automatización con sesión iniciada la regla es una sola: dirección fija, exclusiva, siempre la misma para esa cuenta. Es la lógica de una IP por cuenta aplicada a un programa en lugar de a una persona.

Una dirección por identidad, dentro del mismo proceso

Si la automatización opera varias cuentas, no abras un navegador por cuenta: usa contextos aislados, cada uno con su propia dirección y su propio archivo de sesión. El patrón, con el código, está en proxy por contexto en Playwright.

El error que lo anula todo es sutil: reutilizar el mismo contexto entre cuentas distintas "para ahorrar". Basta una cookie superviviente para que las dos cuentas queden vinculadas, y ningún proxy lo deshace después.

Valida el origen antes de iniciar sesión, no después

El orden importa más de lo que parece. Si la sesión inicial se crea desde la dirección equivocada, esa es la dirección que queda registrada como el lugar desde el que la cuenta entró por primera vez.

Haz que el script compruebe la salida antes del inicio de sesión:

pagina.goto("https://ipinfo.io/json")
# comprueba la IP y el país antes de pasar a la pantalla de inicio de sesión

Si aparece la dirección de tu servidor, el proxy no se está leyendo, y no tiene sentido iniciar sesión todavía. Para una comprobación manual, puedes abrir /mi-ip desde el mismo navegador o perfil.

Lo que sigue dependiendo de ti

Una dirección fija y una sesión conservada eliminan dos variables. No eliminan las demás:

  • Ritmo. Una automatización que ejecuta cien acciones en dos minutos sigue pareciendo lo que es.
  • Entorno del navegador. Zona horaria, idioma y huella digital tienen que ser coherentes con la dirección; es el tema de navegador antidetect y fingerprint.
  • Términos de uso. Si la plataforma prohíbe la automatización en ese flujo, nada de lo que hay aquí convierte la práctica en permitida. Se aplica la política de uso aceptable.

Resumen

  1. Guarda el estado de la sesión y reutilízalo; iniciar sesión desde cero es la excepción, no la rutina.
  2. Un archivo de sesión, un contexto y una dirección fija por cuenta.
  3. Nada de rotación en una cuenta con sesión iniciada.
  4. Comprueba la salida antes del primer inicio de sesión, no después.

Para la infraestructura, proxy para automatización reúne los tipos de dirección fija por escenario.

Preguntas frecuentes

¿Por qué mi automatización pide verificación cada vez que se ejecuta?
Casi siempre porque inicia sesión desde cero en cada ejecución, sin reutilizar la sesión anterior, y a menudo también sale por una dirección distinta. Para la plataforma, eso parece un inicio de sesión nuevo desde un lugar nuevo, repetido todos los días.
¿Puedo usar un proxy rotativo en una automatización con sesión iniciada?
No es lo indicado. La rotación cambia la dirección durante la operación, y cambiar de origen en mitad de una sesión autenticada es el patrón que más verificaciones provoca. Para una cuenta con sesión iniciada, lo correcto es una dirección fija.
¿Cómo guardo la sesión sin dejar la contraseña en el código?
Guarda el estado de la sesión, es decir, las cookies y el almacenamiento local, en un archivo por cuenta, fuera del repositorio y con permisos restringidos. La contraseña solo se usa en el primer inicio de sesión y queda en una variable de entorno o en un gestor de secretos.
¿La sesión guardada dura para siempre?
No. Caduca, y el código tiene que detectarlo y volver a iniciar sesión una vez, no en cada ejecución. Tratar la caducidad como una excepción, y no como una rutina, es lo que separa un caso del otro.

¿Quieres aplicarlo en tu operación?

Precio público en dólares, pago local según tu país y entrega automática en el panel tras confirmar el pago. Si no sabes qué tipo elegir, cuéntanos tu operación por WhatsApp: te indicamos el más barato que lo resuelve.

Este contenido es informativo. Un proxy es infraestructura de red: controlamos el origen, la exclusividad y la geolocalización del IP. La aprobación o restricción de cuentas depende también del comportamiento de uso, la huella digital del navegador y las políticas internas de cada plataforma. Consulta la política de uso aceptable.

¿Tienes dudas? Escríbenos por WhatsApp