Sesiones persistentes
Una sesión persistente indica al servicio de proxies que conserve una IP de salida para solicitudes relacionadas. Tu aplicación puede abrir páginas, enviar datos y recibir un resultado mediante esa dirección mientras la asignación sea válida y la salida siga disponible. Cuando termina la tarea, tu aplicación puede iniciar otra sesión para la siguiente.
Normalmente es un modo de acceso a un grupo rotativo. La comparación general se trata en Proxies estáticos y rotativos. Aquí la cuestión es cómo mantener una dirección durante una tarea, cuánto dura esa asignación y qué puede interrumpirla.
Cómo conserva el servicio la IP seleccionada
El servicio necesita reconocer qué conexiones pertenecen a una misma tarea. Un método habitual es utilizar un identificador de sesión en la configuración del proxy. En la primera conexión, el servicio elige una salida y la vincula con ese identificador. Las conexiones posteriores con la misma configuración de sesión utilizan la salida asignada mientras la sesión siga activa.
Por ejemplo, una prueba del navegador utiliza el nombre de sesión task1. Su primera conexión recibe la IP de salida de ejemplo 198.51.100.27. Abrir la siguiente página y enviar un formulario mediante la misma asignación activa también utilizan esa dirección. El nombre identifica la asignación; no codifica la IP ni la reserva permanentemente.
El identificador de sesión puede añadirse al nombre de usuario del proxy, seleccionarse mediante una API o representarse mediante un puerto configurado. Algunos servicios también proporcionan una sesión predeterminada sin un nombre separado. Son formas distintas de gestionar la asignación, por lo que no existe un formato universal de nombre de usuario ni un número de puerto universal para el acceso persistente.
Una sesión persistente puede abarcar varias conexiones de red. Esto es distinto de reutilizar una sola conexión abierta: las solicitudes dentro de la misma conexión TCP ordinaria ya mantienen su IP de salida. Para comprobar si una sesión conserva la dirección entre conexiones, lo útil es observar qué sucede al abrir una conexión nueva con la misma configuración de sesión.
Cuándo necesitan varias solicitudes una misma IP
Una prueba del navegador con varios pasos es un ejemplo claro. Puede iniciar sesión, abrir una página de configuración, enviar un cambio y comprobar el resultado. Mantener estable la IP de origen elimina un cambio evitable durante la prueba, especialmente si el sitio utiliza la dirección como una de sus comprobaciones de sesión.
Una prueba de compra o reserva también puede depender de una experiencia regional constante. La aplicación busca, elige una opción y comprueba la siguiente etapa mediante la misma salida. Esto ayuda a mantener la ubicación de red entre pasos, aunque el sitio también puede utilizar la configuración de la cuenta, los datos de entrega o las cookies para decidir qué mostrar.
Otro caso es una secuencia de llamadas a una API cuyo servicio de destino espera acciones relacionadas desde una dirección de origen constante. La asignación debe cubrir toda la secuencia, incluidas las pausas y los reintentos. En cambio, las consultas independientes de páginas públicas no necesitan necesariamente una misma IP. Conservar una dirección resulta útil cuando la continuidad importa para la tarea; no mejora por sí sola la reputación de la dirección ni garantiza que el sitio acepte una solicitud.
Una sesión de proxy no conserva el inicio de sesión de un sitio web
El servicio de proxies controla la dirección de salida. El sitio web controla su propia sesión: tu estado de inicio de sesión, el carrito o el avance en un formulario. Un navegador o cliente HTTP suele conservar ese estado mediante cookies o tokens de autenticación. Ambos sistemas pueden utilizar la palabra sesión, pero mantienen información distinta.
Esto significa que un inicio de sesión puede vencer mientras la IP de salida permanece igual. Borrar las cookies también puede hacer que el sitio deje de reconocer al usuario sin afectar a la asignación del proxy. También puede ocurrir lo contrario: un sitio web puede aceptar un inicio de sesión válido después de un cambio de IP. Su comportamiento depende de sus propias reglas.
Un objeto de sesión de una biblioteca HTTP suele almacenar cookies y reutilizar conexiones. Crear ese objeto no activa automáticamente el acceso persistente en el servicio de proxies. Para un proceso completo, la aplicación debe mantener juntos el estado del sitio web y la asignación de proxy prevista. Siguen siendo necesarios perfiles de navegador separados o estados de cliente aislados cuando distintas tareas no deben compartir cookies.
Qué significa realmente la duración de una sesión
Dos temporizadores pueden describirse como duración de una sesión. Una duración fija limita el tiempo que existe la asignación desde su inicio. Un tiempo de espera por inactividad limita la pausa desde la última solicitud que cumpla los requisitos. Las nuevas solicitudes pueden reiniciar el temporizador de inactividad sin ampliar una duración fija independiente.
| Límite | Qué inicia la cuenta atrás | Qué hace otra solicitud |
|---|---|---|
| Duración fija | La creación de la asignación o su primer uso, según lo defina el servicio | Mantiene sin cambios la hora de vencimiento original |
| Tiempo de espera por inactividad | La última solicitud u otra actividad reconocida por el servicio | Reinicia la cuenta atrás de inactividad cuando la solicitud cuenta como actividad |
Considera dos sesiones ilustrativas con un límite de diez minutos. Ambas empiezan a las 14:00 y reciben otra solicitud a las 14:08. Con una duración fija, el vencimiento sigue siendo a las 14:10. Con un tiempo de espera por inactividad, esa solicitud desplaza el vencimiento por inactividad a las 14:18. Por tanto, la misma duración indicada puede producir comportamientos muy distintos durante una tarea activa.
Un servicio puede aplicar ambos límites. En ese caso, la asignación termina cuando se alcanza cualquiera de ellos. El valor predeterminado habitual también puede ser distinto de la duración máxima disponible en la configuración. Mantener el tráfico puede evitar el vencimiento por inactividad, pero no elimina una duración máxima independiente.
El vencimiento termina la asignación a la salida anterior. Una conexión posterior puede recibir otra dirección incluso con el mismo nombre de sesión. Según el servicio, una conexión abierta puede terminar con normalidad o cerrarse. El temporizador no traslada un intercambio TCP pendiente a otra IP.
Elige un período que incluya toda la tarea, las respuestas lentas y las pausas previstas. Iniciar un proceso nuevo cerca del final de una asignación anterior deja menos tiempo del que sugiere la duración configurada. Las solicitudes destinadas únicamente a mantener activa una sesión inactiva siguen siendo tráfico real y pueden contar para la cuota de solicitudes o tráfico del servicio.
Separar las tareas paralelas
Cuando varias tareas independientes necesitan cada una una dirección estable, asigna a cada tarea su propio identificador de sesión y consérvalo durante sus pasos. Un proceso que carga la siguiente página debe reutilizar la sesión de la tarea, en lugar de generar un nombre nuevo para cada solicitud. Un reintento dentro de esa tarea no debe cambiar silenciosamente a una configuración de proxy ajena.
Supongamos que dos pruebas del navegador se ejecutan al mismo tiempo. La primera utiliza task1, la segunda utiliza task2, y cada una mantiene sus propias cookies. Asignar a ambas el mismo nombre de sesión pediría al servicio compartir una asignación cuando los demás ajustes también coincidan. Abrir una pestaña ordinaria nueva no crea por sí solo una configuración de proxy separada ni un almacén de cookies independiente.
Los identificadores distintos solicitan asignaciones separadas, pero no garantizan universalmente IP de salida diferentes. Que el servicio prometa direcciones distintas es una característica aparte del producto. El acceso persistente tampoco hace que una salida sea exclusiva de tu cuenta: otros clientes pueden seguir utilizando la dirección si pertenece a un grupo compartido.
Cuando se admite, varias conexiones pueden utilizar la misma sesión a la vez. Comparten su salida y siguen sujetas a los límites de conexión y uso de la cuenta. Más nombres de sesión no aumentan esos límites. Antes de una ejecución completa, comprueba tanto el número de tareas paralelas como el de conexiones que abre cada tarea.
Por qué puede cambiar la dirección antes de lo previsto
Un temporizador válido no puede mantener operativa una salida no disponible. Un dispositivo residencial puede desconectarse, una conexión móvil puede recibir otra IP pública o un servidor puede dejar de ser accesible. La duración solicitada describe las reglas temporales de la asignación; por sí sola, no garantiza que la salida original siga disponible.
Hay dos respuestas posibles a la pérdida de esa salida. Un servicio puede elegir una sustituta para que las solicitudes posteriores continúen, o devolver un error y mantener el requisito de utilizar la salida original. Algunos productos permiten elegir. La sustitución automática prioriza establecer otra conexión; un error da a la aplicación la posibilidad de detenerse antes de continuar desde otra dirección.
Que el nombre no cambie no demuestra que el resto de la configuración de la sesión siga igual. Pasar a otra puerta de enlace o cambiar un filtro de país puede crear otra asignación. El alcance depende del servicio: una sesión puede pertenecer a una cuenta, producto o servidor de entrada concretos, en lugar de estar disponible en todas partes con ese nombre.
Si la dirección cambia durante una tarea, la siguiente decisión depende del estado de esa tarea. Puede ser seguro repetir un paso de solo lectura. Una acción que haya enviado un pedido o cambiado datos exige más cuidado: perder la respuesta no demuestra que haya fallado. Determina qué se completó antes de reiniciar o continuar por otra salida.
Cuándo basta una continuidad temporal
El acceso persistente encaja con una tarea que tiene un principio y un final claros, cuando solo se necesita una IP durante esa ejecución. Comprueba tres cosas: que la asignación soporte las pausas previstas, dure toda la tarea y gestione la pérdida de una salida como necesitas. Incluye en la prueba una conexión nueva después de una pausa normal; la actividad dentro de una conexión ya abierta no demuestra que la asignación sobreviva a la siguiente conexión.
Si la misma dirección debe permanecer en la lista de permitidas de un servidor o volver a estar disponible mañana, utiliza un servicio que proporcione una asignación fija para ese fin. Reutilizar un nombre de sesión persistente después del vencimiento no recupera de forma fiable su antigua dirección. La conservación temporal y una IP asignada duradera resuelven necesidades de continuidad distintas.