---
title: "Qué es la rotación de IP y cómo funciona"
description: "La rotación de IP es el cambio de la IP de salida de tus peticiones dentro de un pool. Tres modos, el flujo del gateway y por qué a veces la IP no cambia."
url: https://proxynet.io/es/blog/ip-rotation-explained
date: 2026-09-19
author: "Acar Diveroli"
category: "Proxy 101, Web scraping"
lang: es
---

# Qué es la rotación de IP y cómo funciona

Compraste un proxy rotativo, conectaste tu script y enviaste tres peticiones seguidas a un servicio de eco de IP. Las tres devolvieron la misma dirección. O pasó lo contrario: un script que inicia sesión en tu propio panel volvió a caer en la pantalla de acceso en la segunda página, porque la IP de salida cambió en mitad de la sesión. En ninguno de los dos casos el proxy está averiado. Lo que hay es un montaje hecho sin saber qué evento dispara la rotación.

En este artículo definimos brevemente la rotación de IP y pasamos al tema de fondo, cómo funciona el proceso: el camino que sigue una petición detrás de un gateway, los tres modos de rotación (por petición, por tiempo, sesión fija), los términos que se confunden, la reutilización de conexiones como causa más habitual de que la IP no cambie como esperas y las cosas que la rotación rompe. Al final hay un ejemplo corto y probado en Python que verifica la rotación y una guía de decisión.

> **Nota: Respuesta breve**
>
> La rotación de IP es el cambio de la dirección IP de salida de tus peticiones dentro de un pool. Te conectas a una sola dirección (el gateway) y es el gateway quien decide qué IP de salida se usa. El cambio se dispara de tres maneras: con cada conexión nueva, cuando vence un plazo o cuando cambia el identificador de sesión que tú defines. La rotación no es un método para ignorar un bloqueo; sirve para repartir la carga entre direcciones, ver contenido según la ubicación y separar sesiones entre sí.

## ¿Qué es la rotación de IP?

La rotación de IP (también llamada rotación de proxies) consiste en que la IP de salida de las peticiones de red no se queda en una sola dirección, sino que va cambiando entre las direcciones de un pool de IP. El servicio que lo hace por ti se llama proxy rotativo o, en inglés, [rotating proxy](/es/rotating-proxy); la definición del producto, el pool y las opciones de segmentación están en esa página. Aquí no tratamos el producto sino el proceso: cuándo cambia la IP, cuándo no y quién lo decide.

El concepto no es tan ajeno. La IP dinámica de tu conexión doméstica también es una forma de rotación: tu proveedor cambia tu dirección de vez en cuando, pero no decides tú cuándo cambia ni qué dirección te toca. Esa parte la explicamos en [IP estática y dinámica: diferencias y cuál necesitas](/es/blog/static-ip-vs-dynamic-ip) y en [Cómo cambiar la dirección IP](/es/blog/how-to-change-ip-address). La diferencia de la rotación con proxy es que el control es tuyo: eliges la frecuencia del cambio, el país y qué peticiones salen por la misma dirección.

## ¿Para qué sirve la rotación y para qué no?

La rotación tiene tres fines legítimos:

- **Repartir la carga.** Un trabajo que recoge las páginas públicas de cientos de sitios y saca todo el tráfico por una sola dirección descarga sobre ella más peticiones de las que un visitante real podría generar. La rotación mantiene la carga por dirección en un nivel razonable.
- **Ver el contenido según la ubicación.** El precio, el stock y los resultados de búsqueda cambian según el país del visitante. Fijar el pool a un país o a una ciudad y rotar dentro de esa ubicación da la vista real de ese mercado.
- **Separar sesiones.** Cada trabajo independiente (cuentas de clientes distintos, escenarios de prueba distintos) sale por su propia dirección; ninguno arrastra el rastro del otro.

También está claro dónde no sirve. Si el sitio te pidió que bajaras el ritmo con un `429`, cerró una ruta en robots.txt o prohíbe el acceso automatizado en sus condiciones, cambiar de IP y seguir a la misma velocidad no resuelve el problema; es pasar por alto una preferencia que el dueño del sitio expresó con claridad. El marco completo está en [Cómo hacer web scraping sin que te bloqueen](/es/blog/web-scraping-without-getting-blocked), y la respuesta correcta a un `429` en [Qué es el error 429 Too Many Requests y el rate limit](/es/blog/http-429-too-many-requests).

## ¿Cómo funciona la rotación a través de un gateway (backconnect)?

En la rotación a la antigua tienes una lista de proxies y tu código elige la siguiente dirección. En el modelo de gateway la lista no está en tus manos. Te conectas a una sola dirección `host:port` y el proveedor gestiona el pool que hay detrás. Esta arquitectura se llama backconnect. El camino de una petición HTTPS es el siguiente:

1. **El cliente se conecta al gateway.** Tu script abre una conexión TCP con un endpoint fijo como `pr.proxynet.io:8000`.
2. **Se leen las credenciales y los parámetros.** El gateway valida el par `user:pass` de la cabecera `Proxy-Authorization`. Las preferencias como país, ciudad e identificador de sesión también se leen en este paso, a partir de parámetros añadidos al nombre de usuario. Los dos métodos de autenticación están en [Autenticación de proxy: user:pass o lista blanca de IP](/es/blog/proxy-authentication-methods).
3. **Se filtra el pool.** Si indicaste una ubicación, el gateway solo considera candidatas las salidas que cumplen ese criterio. La rotación ocurre dentro de ese subconjunto.
4. **Se elige el nodo de salida.** Según el modo de rotación, se asigna una salida nueva o se reutiliza la que ya estaba ligada a tu sesión. Este es el paso que distingue los tres modos de rotación.
5. **Se establece el túnel.** El gateway se conecta al destino a través de la salida elegida y devuelve al cliente `200 Connection Established`. La negociación TLS se hace después, entre el cliente y el sitio de destino.
6. **Se transmite el tráfico.** El sitio de destino ve la petición como si llegara desde la IP del nodo de salida. Ni la dirección del gateway ni la tuya llegan al destino.

Las primeras líneas que el cliente envía al gateway se parecen a esto:

```text
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dXNlcjpwYXNz
```

El método `CONNECT` está definido en la [sección 9.3.6 de RFC 9110](https://www.rfc-editor.org/rfc/rfc9110#name-connect) y aquí se esconde un detalle importante: una vez establecido el túnel, el proxy solo transporta bytes. No puede ver una a una las peticiones HTTPS que pasan por dentro. La IP de salida se elige al establecer el túnel y no cambia mientras el túnel siga abierto. Por eso «una IP nueva en cada petición» significa en la práctica «una IP nueva en cada conexión nueva». En HTTP sin cifrar el proxy ve cada petición por separado, así que ahí sí es posible un cambio real por petición; pero como hoy la mayoría de los sitios funciona con HTTPS, toma la conexión como unidad.

## Tres modos de rotación: por petición, por tiempo y sesión fija

Los modos se distinguen por el evento que dispara la decisión «salida nueva o salida anterior» del paso cuatro.

### Rotación por petición

Cada conexión nueva que se abre contra el gateway recibe una salida distinta del pool. El cliente no guarda estado y el gateway tampoco recuerda nada por ti. Es el modo de los trabajos que recogen muchas páginas independientes entre sí: cada página de producto es una sola petición y no hace falta que la siguiente llegue desde la misma dirección. El coste es una nueva negociación TCP y TLS en cada petición; la latencia sube frente a un montaje que reutiliza la conexión.

### Rotación por tiempo

La IP de salida cambia con un intervalo determinado. Hasta que vence el intervalo, todas las conexiones que abres salen por la misma dirección; cuando vence, todas pasan juntas a la nueva. El disparador es el reloj, no tus peticiones. Es frecuente en los puertos de proxy móvil que funcionan sobre un único módem o dispositivo: la IP se renueva cuando el dispositivo vuelve a conectarse a la red del operador. La configuración es sencilla, pero no puedes elegir en qué punto de tu trabajo caerá el cambio.

### Sesión fija (sticky)

Añades un identificador de sesión (session ID) al nombre de usuario. Las conexiones que llegan con el mismo identificador se ligan a la misma salida y los identificadores distintos a salidas distintas. Cuánto tiempo se mantiene la sesión en la misma IP se elige en el panel, entre 1 y 60 minutos; cuando vence el plazo o cuando cambias el identificador, el gateway asigna una salida nueva. La diferencia con la rotación por tiempo es que la agrupación la haces tú: si das un identificador propio a cada uno de veinte trabajos en paralelo, cada uno funciona junto a los demás con su propia dirección fija. Es el modo de los trabajos en los que el servidor guarda estado, como paneles con inicio de sesión, flujos de carrito y paginación. La parte de producto está en la página [Proxies de sesión fija](https://proxynet.io/es/sticky-proxy).

Tiene un límite: en los pools residenciales y móviles el nodo de salida es un dispositivo real y puede salir de la red. En ese caso el gateway traslada la sesión a otra salida antes de que venza el plazo. Sesión fija quiere decir «intenta mantener la misma IP durante este tiempo», no es una garantía. Para un trabajo que exige continuidad estricta se usa [Proxies estáticos](https://proxynet.io/es/static-proxy), donde la dirección está asignada a ti.

| | Por petición | Por tiempo | Sesión fija | Estática (para comparar) |
|---|---|---|---|---|
| Evento que cambia la IP | Cada conexión nueva | El vencimiento del intervalo | El cambio del identificador de sesión o el vencimiento del plazo | No cambia |
| Quién tiene el control | El gateway | El reloj | Tú | Nadie |
| Flujos con estado | Se rompen | Se rompen en el momento del cambio | Se conservan | Se conservan |
| En trabajos en paralelo | Una IP distinta por conexión | Todos en la misma IP | Una IP distinta por identificador | Tantas como IP tengas |
| Trabajo típico | Lectura masiva de páginas independientes | Puerto móvil de un solo dispositivo | Inicio de sesión, carrito, paginación | Lista de IP autorizadas de una API, cuenta de larga duración |

## Términos: rotating proxy, backconnect, sticky y los demás

Los términos se confunden porque a lo mismo se le dan varios nombres y a cosas distintas se les pone el mismo. En las fuentes en español, «proxy rotativo», «proxy rotatorio» y «rotating proxy» son el mismo producto.

| Término | Qué describe | Con qué se suele confundir |
|---|---|---|
| Rotación de IP / rotación de proxies | El proceso: la IP de salida cambia dentro de un pool | Se toma por el nombre del producto |
| Proxy rotativo / rotating proxy | El producto: un servicio de proxy que rota en el gateway | Una lista de proxies |
| Backconnect | La arquitectura: un solo endpoint y un pool detrás | Se toma por un tipo de proxy aparte; en realidad es la forma de funcionar del proxy rotativo |
| Gateway | El `host:port` al que te conectas; el servidor que elige la salida | La IP de salida. El sitio de destino no ve la dirección del gateway |
| Nodo de salida / IP de salida | La dirección que ve el sitio de destino | La dirección del gateway |
| Pool de IP | El conjunto de direcciones entre las que elige el gateway | Direcciones que te pertenecen. El pool es compartido |
| Sesión fija (sticky) | El mismo identificador de sesión ligado durante un tiempo a la misma salida | Una IP estática. La sesión fija es temporal |
| Proxy estático | Una dirección asignada a ti que no cambia | Una sesión fija larga |
| Lista de proxies | Una serie fija de direcciones que rotas con tu propio código | Un proxy rotativo |

Un aviso: al buscar «sticky session» también aparece documentación de balanceadores de carga. Ahí el término describe que un visitante se dirige siempre al mismo servidor backend. La lógica es la misma y el sentido es el inverso: en el balanceador se fija el tráfico entrante, en el proxy el saliente.

## ¿Quién debe rotar, tu código o el gateway?

Si tienes una lista de direcciones fijas que son tuyas, la rotación la hace tu código: antes de cada petición se elige la siguiente dirección de la lista o una al azar. La selección secuencial reparte la carga por igual; la selección aleatoria no exige mantener un contador común entre trabajos que corren en paralelo. Sacar de la lista la dirección que no responde y limitar el ritmo por dirección también queda de tu lado. El código Python de los dos métodos, paso a paso con Requests, lo dimos en [Cómo rotar proxies en Python](/es/blog/how-to-rotate-proxies-in-python); aquí no lo repetimos.

En el modelo de gateway todas esas tareas pasan al otro lado. En tu código queda una sola dirección de proxy y el modo de rotación se elige con parámetros en el nombre de usuario. A cambio, no conoces las direcciones una a una: no puedes saber de antemano por qué IP saldrá la siguiente petición, solo fijas su país, su ciudad y el comportamiento de la sesión. Para un trabajo pequeño con unas pocas direcciones basta una lista; a medida que el pool crece, mantener la lista lleva más tiempo que el propio trabajo.

## ¿Por qué no cambió la IP? La reutilización de conexiones

Cuando ves siempre la misma IP con la rotación por petición activada, la causa más habitual no es el proxy sino tu cliente. En HTTP/1.1 las conexiones son persistentes por defecto ([RFC 9112, 9.3](https://www.rfc-editor.org/rfc/rfc9112#name-persistence)): tras recibir una respuesta, el cliente mantiene abierta la misma conexión TCP para la siguiente petición. Detrás de un proxy eso significa que se reutiliza el mismo túnel `CONNECT`. Como la salida del túnel se elige al establecerlo, el gateway no encuentra ningún momento para rotar.

Los clientes que reutilizan la conexión son más de los que imaginas. En Python Requests, el objeto `Session` lo hace por sí solo; la [documentación de Requests](https://requests.readthedocs.io/en/latest/user/advanced/#keep-alive) indica que el keep-alive es automático dentro de una sesión. `Client` en HTTPX, `ClientSession` en AIOHTTP, los agentes con keep-alive activado en Node.js y todos los navegadores se comportan igual. Las diferencias entre bibliotecas están en [HTTPX, Requests y AIOHTTP: comparativa](/es/blog/httpx-vs-requests-vs-aiohttp).

Qué hacer depende de lo que quieras:

- **Si quieres una IP nueva en cada petición**, abre una conexión nueva para cada petición o añade la cabecera `Connection: close`. El destino cierra la conexión después de la respuesta y el túnel se cierra con ella. Aceptas el coste de volver a negociar cada vez.
- **Si quieres quedarte en la misma IP**, no confíes en el keep-alive. La conexión puede caerse por un tiempo de espera agotado, por decisión del servidor o por un reintento, y una conexión nueva trae una IP nueva. Construye la continuidad con el identificador de sesión, es decir, con una sesión fija.
- **En la automatización de navegadores**, una sola página abre muchas conexiones en paralelo para descargar sus recursos. Con rotación por petición, el HTML de una página se pide desde una dirección y sus imágenes desde otras. Cuando trabajes con un navegador usa sesión fija; la configuración está en [Qué es Playwright y cómo usarlo con un proxy](/es/blog/playwright-proxy).

## Verificar la rotación: tres peticiones seguidas

La manera de comprobar que tu montaje se comporta como esperas es enviar varias peticiones seguidas a un servicio que devuelve tu IP de salida como respuesta. El ejemplo siguiente envía las mismas tres peticiones de dos formas: primero con una conexión nueva cada vez y después a través de una única `Session`.

```python
import requests

PROXY = "http://user:pass@pr.proxynet.io:8000"
PROXIES = {"http": PROXY, "https": PROXY}
IP_ECHO = "https://api.ipify.org"

def new_connection_each_time(count=3):
    ips = []
    for _ in range(count):
        # Llamada sin sesión: cada petición abre y cierra su propia conexión
        response = requests.get(IP_ECHO, proxies=PROXIES, timeout=20)
        ips.append(response.text.strip())
    return ips

def shared_session(count=3):
    ips = []
    with requests.Session() as session:
        session.proxies.update(PROXIES)
        for _ in range(count):
            # Misma sesión: se reutiliza el túnel abierto en la primera petición
            response = session.get(IP_ECHO, timeout=20)
            ips.append(response.text.strip())
    return ips

def report(label, ips):
    print(f"{label}: {ips} -> {len(set(ips))} IP distintas")

report("conexión nueva cada vez", new_connection_each_time())
report("sesión compartida (keep-alive)", shared_session())
```

En un gateway que rota por petición, la salida esperada se parece a esto (las direcciones pertenecen a los rangos de ejemplo reservados para documentación):

```text
conexión nueva cada vez: ['203.0.113.24', '198.51.100.7', '203.0.113.181'] -> 3 IP distintas
sesión compartida (keep-alive): ['198.51.100.92', '198.51.100.92', '198.51.100.92'] -> 1 IP distintas
```

Al probar el ejemplo en un proxy de pruebas local, en el registro del proxy vimos que la primera función abría tres túneles `CONNECT` separados y la segunda uno solo; al añadir la cabecera `Connection: close` a la `Session`, el número de túneles volvió a subir a tres. Si en la primera línea también ves una sola IP, te estás conectando con un nombre de usuario de sesión fija o con una dirección estática. Para comprobar además el país de la IP de salida y las fugas, consulta [¿Funciona tu proxy? Cómo probar un proxy](/es/blog/how-to-test-a-proxy).

## ¿Cómo funciona un proxy móvil rotativo?

Al oír «proxy móvil rotativo» uno imagina una mesa llena de teléfonos, pero el mecanismo real está en la red del operador. Los operadores móviles reparten una sola dirección IPv4 pública entre muchos abonados a la vez (CGNAT); cuando un dispositivo vuelve a conectarse a la red puede recibir otra dirección del pool del operador. La rotación del proxy móvil se apoya en ese comportamiento: o bien un único dispositivo se reconecta a intervalos fijos (rotación por tiempo), o bien el gateway elige entre muchos dispositivos. Cómo funciona CGNAT lo explicamos en [Qué es CGNAT, cómo saber si lo tienes y cómo salir](/es/blog/what-is-cgnat).

Esto tiene dos consecuencias prácticas. La primera: una IP de salida móvil se comparte en ese momento con abonados reales; usar la dirección de forma intensiva no te afecta solo a ti sino también a ellos, por eso en un pool móvil un ritmo bajo no es una cortesía, es una obligación. La segunda: en un pool móvil, «IP nueva» no siempre significa una dirección que no hayas visto antes; el pool del operador es limitado y la misma dirección puede volver a tocarte. La parte de producto está en la página [Proxies móviles](https://proxynet.io/es/mobile-proxy).

## Lo que la rotación rompe

Hay varias cosas que se rompen en silencio al activar la rotación. Lo que tienen en común es que el servidor te reconoce también por algo distinto de la IP.

- **Incoherencia entre cookie e IP.** Tu almacén de cookies sigue igual y la IP cambia en cada petición. El sitio ve la misma cookie de sesión desde ciudades distintas en cuestión de minutos; su lógica de seguridad cierra la sesión o pide verificar de nuevo. La regla es sencilla: un almacén de cookies, un identificador de sesión, una IP. El diseño de los trabajos que requieren iniciar sesión con tu propia cuenta está en [Inicio de sesión, sesiones y cookies en Python](/es/blog/python-login-session-cookies).
- **La sesión que se corta en mitad de la paginación.** Los resultados de búsqueda y los listados con filtros suelen depender de un estado guardado en el servidor (un cursor, una sesión de búsqueda). Si la IP cambia en la quinta página, el sitio puede devolverte a la primera o servir otra vez los mismos registros; los datos salen incompletos o duplicados y no ves ningún código de error. El detalle está en [Paginación en web scraping](/es/blog/pagination-web-scraping).
- **Rotación sin ubicación definida.** Si no indicas una ubicación, rotas por todo el pool: una petición sale de Alemania y la siguiente de Brasil. Los precios llegan en otra moneda, las páginas en otro idioma y los datos que recoges dejan de ser comparables entre sí.
- **Contadores que no dependen de la IP.** Si el límite de peticiones se cuenta por cuenta, por cookie o por clave de API, la rotación no cambia nada. Qué hacer ante cada código lo reunimos en [Códigos de estado HTTP en web scraping](/es/blog/http-status-codes-web-scraping).

## Casos de uso

- **Seguimiento de precios y stock en muchos sitios.** Cada página de producto es una petición independiente; el país se fija y el modo es por petición. El planteamiento está en nuestra página de [monitorización de precios](/es/price-monitoring) y los métodos en [Cómo hacer seguimiento de precios de la competencia](/es/blog/competitor-price-tracking).
- **Recogida de catálogos y anuncios públicos.** Poca concurrencia por sitio y rotación para repartir la carga: [solución de extracción de datos](/es/data-scraping).
- **Comprobar cómo se ve algo desde una ubicación.** Para comprobar desde conexiones domésticas cómo se ve un anuncio, un precio o una página desde una ciudad concreta: [Proxies residenciales](https://proxynet.io/es/residential-proxy).
- **Paneles en los que trabajas con tus propias cuentas.** Un identificador de sesión por cuenta y la misma IP durante toda esa sesión: sesión fija.
- **API que exigen una lista de IP autorizadas.** Si la otra parte va a añadir tu dirección a su lista, la rotación no sirve, la dirección no debe cambiar: [IP estática para el acceso a API](/es/blog/static-ip-for-api-access).

## Errores frecuentes

- **Esperar rotación por petición con una `Session`.** La sesión reutiliza la conexión; la IP sigue igual hasta que el túnel se cierra.
- **Dar el mismo identificador de sesión a todos los trabajos en paralelo.** Todos se amontonan en una sola IP y se pierde la ventaja de repartir la carga.
- **Poner la rotación en lugar del límite de ritmo.** Aunque cambie la dirección, la carga total sobre el destino es la misma; el límite de concurrencia por sitio y las esperas siguen haciendo falta.
- **Reintentar enseguida con una IP nueva.** Volver a enviar sin esperar tras un `429` o un `503` pasa por alto la pausa que pidió el servidor.

## Guía de decisión

| Necesidad | Recomendación |
|---|---|
| Muchas páginas públicas independientes entre sí | Rotación por petición, país fijo |
| Inicio de sesión, carrito o formulario de varios pasos | Sesión fija, un identificador por flujo |
| Listado largo que se recorre con paginación | Sesión fija; cambia el identificador al terminar el listado |
| Automatización de navegadores (Playwright, Selenium) | Sesión fija, un identificador por perfil de navegador |
| Cuentas independientes que funcionan a la vez | Un identificador de sesión por cuenta |
| Lista de IP autorizadas, una sola identidad duradera | Proxy estático |
| Tienes unas pocas direcciones fijas | Rotación de lista en tu código |
| El sitio devuelve `429` | Rotación no: espera y menos velocidad |

## Preguntas frecuentes

### ¿Rotación de IP y proxy rotativo son lo mismo?

Una es el proceso y el otro es el producto. La rotación de IP es el cambio de la dirección de salida y también puedes hacerla en tu propio código con una lista de proxies. El proxy rotativo (rotating proxy) es el servicio que lo hace por ti en el gateway.

### ¿Un proxy backconnect es un tipo de proxy aparte?

No. Backconnect es el nombre de una arquitectura: te conectas a un solo endpoint y el gateway elige la salida en el pool que hay detrás. Los servicios de proxy rotativo residencial y móvil funcionan así. El tipo de IP (conexión doméstica, móvil, centro de datos) no lo determina el backconnect sino el origen del pool; la diferencia entre tipos está en [Proxy ISP o residencial: diferencias y cuál elegir](/es/blog/isp-vs-residential-proxy).

### ¿Por qué la IP no cambia en cada petición con la rotación activada?

Lo más probable es que tu cliente esté reutilizando la misma conexión. En HTTPS la IP de salida se elige al establecer el túnel `CONNECT` y no cambia mientras el túnel siga abierto. Abre una conexión nueva para cada petición o envía la cabecera `Connection: close`. Revisa también si en tu nombre de usuario ha quedado un parámetro de sesión fija.

### ¿Cuánto dura una sesión fija?

La duración se elige en el panel, entre 1 y 60 minutos, y, cambiando el identificador de sesión, puedes pasar a una IP nueva cuando quieras. La duración es un límite máximo, no una garantía: si el nodo de salida sale de la red, el gateway traslada la sesión antes a otra dirección. Escribe tu código de forma que reinicie el flujo si la IP cambia en mitad de la sesión.

### ¿Usar rotación hace innecesario respetar el límite de peticiones?

No. La rotación reduce la carga por dirección, no la carga total sobre el servidor de destino. El límite de concurrencia por sitio, las esperas entre peticiones y respetar la cabecera `Retry-After` siguen siendo necesarios con rotación.

### ¿Cuántas IP hacen falta para rotar?

No hay un número único correcto; el cálculo parte del ritmo de peticiones por dirección. En el modelo de gateway no necesitas hacerlo, porque no compras direcciones: rotas por todo el pool y la facturación suele ir por tráfico. Los criterios de elección están en [Qué tener en cuenta al comprar un proxy](/es/blog/proxy-buying-guide).

## En resumen

La rotación de IP es el cambio de la dirección de salida dentro de un pool y la decisión la toma el gateway: con cada conexión nueva, al vencer el plazo o al cambiar el identificador de sesión. Como en HTTPS la salida se elige al establecer el túnel, la rotación «por petición» es en realidad por conexión; un cliente que reutiliza la conexión se queda en la misma IP. Elige rotación por petición para páginas independientes, sesión fija para flujos con estado y una dirección estática para identidades que no deben cambiar, e indica siempre el país de forma explícita. La rotación no sustituye al límite de ritmo; reparte la carga, y un ritmo de rastreo respetuoso sigue haciendo falta. Puedes comparar los tipos adecuados para tu trabajo en nuestros [servicios de proxy](/es/proxy).