Cómo funcionan los proxies móviles: rotación de IP y sesiones

Por qué un sitio te sigue reconociendo tras cambiar la IP: de qué está hecha la salida móvil, para qué usa el operador CGN, los tres tipos de «sesión», qué cambia de verdad la rotación y qué comprobar antes de alquilar.

Cómo funcionan los proxies móviles: rotación de IP y sesiones

Pulsas el enlace de cambio de IP, la página de consulta de IP muestra otra región y la tienda online te sigue saludando por tu nombre y conserva el carrito. No se ha roto nada: cambió la salida a la red, no la sesión del navegador. Aquí explicamos qué capas intervienen, qué hace realmente la rotación y cómo probar una salida móvil en tu propio cliente. Si lo que eliges es el modo y no cómo funciona, mira proxy rotativo y sesiones sticky.

01La dirección cambió, pero el sitio te sigue recordando#

Una imagen típica. Conectaste el navegador a través de proxies móviles, abriste la página «cuál es mi IP» y anotaste la dirección.

Hiciste clic en el enlace de cambio de IP, actualizaste la página y la dirección cambió, a veces incluso con otra ciudad en la base de geolocalización. Entras al área de cliente de la tienda en línea y sigues autenticado, el carrito está en su sitio, las recomendaciones son las mismas.

Para quien empieza, esto parece una contradicción: la dirección es nueva, pero la identidad es la misma. En realidad no hay contradicción, porque la IP de salida y la sesión de la aplicación viven en niveles distintos y casi no saben una de la otra.

Para dejar de confundirse, vale la pena desglosar de qué está hecha la salida móvil y qué cambia exactamente la rotación.

02De qué está hecha la salida móvil#

Un proxy móvil envía las solicitudes a través de una salida en la red celular. En el caso típico, el cliente se conecta a una puerta de enlace y luego el tráfico pasa por un módem con tarjeta SIM u otro dispositivo con conexión móvil. La implementación concreta varía según el servicio. El cliente (navegador, script, aplicación) se conecta a la puerta de enlace por HTTP(S) o SOCKS5, la puerta de enlace redirige el tráfico al módem, el módem lo entrega al operador y el operador libera los paquetes a internet ya con su propia dirección.

De aquí surge la primera distinción, que a menudo se pierde.

La palabra «móvil» describe la red de salida, es decir, desde dónde el sitio ve tu conexión. Las palabras HTTP y SOCKS5 describen el protocolo con el que hablas con la puerta de enlace. Son cosas independientes. Una misma salida móvil puede estar disponible por HTTP y SOCKS5; la dirección, el puerto y el método de autorización deben tomarse de la configuración de la conexión concreta. El protocolo de conexión no dice nada sobre el tipo de salida, y el tipo de salida no determina el protocolo. La distinción también es práctica. SOCKS5 opera a nivel de conexiones TCP y puede proxificar no solo la web, mientras que un proxy HTTP entiende la estructura de las solicitudes, sabe hacer CONNECT para HTTPS, pero en su forma pura está orientado al tráfico web.

Con la misma salida, ambas variantes pueden usar una misma dirección pública. Pero el sitio también puede tener en cuenta otras señales de la solicitud: una IP idéntica no hace que las conexiones sean completamente indistinguibles.

03Por qué la IP puede ser compartida#

La dirección que ve el sitio no necesariamente está asignada solo a tu dispositivo.

Para distribuir las direcciones IPv4 públicas entre los abonados, el operador puede usar CGN (carrier-grade NAT), es decir, traducción de direcciones a nivel de operador. En ese caso, la dirección interna del abonado y la dirección pública que ve el sitio son distintas; una misma dirección pública puede atender a varios abonados. Para esta capa interna, en la RFC 6598 se reserva un bloque propio 100.64.0.0/10, que no se enruta en internet, así que los sitios nunca lo ven. Aquí hacen falta dos advertencias. Primero, cada operador construye el esquema NAT a su manera, y el tamaño de los grupos, la asignación de abonados a direcciones y el tiempo de vida de las traducciones varían, así que no existe un esquema único para todos los operadores móviles. Segundo, del hecho de que la dirección sea compartida no se sigue ni unicidad ni anonimato.

Una misma IP pública puede ser usada por muchos abonados en un momento dado, y tu módem puede recibir al minuto siguiente una dirección que acaba de tener otro. Esta es una propiedad natural de las redes celulares, no una particularidad de un proxy concreto.

De esto mismo se sigue que la base de geolocalización y el ASN siguen siendo señales indirectas. Muestran a qué operador y aproximadamente a qué región pertenece el rango, pero no demuestran que el módem esté en una ciudad concreta y no dicen nada sobre la calidad de la dirección. La reputación de una IP concreta se comprueba aparte, por ejemplo en listas negras DNSBL.

04Tres «sesiones» diferentes#

La palabra «sesión» en las conversaciones sobre proxies significa como mínimo tres cosas distintas, y la confusión entre ellas genera la mayoría de los malentendidos.

1. La sesión del canal móvil, o la IP de salida. Es el intervalo de tiempo durante el cual el módem mantiene una misma dirección pública. Termina por tu comando (rotación), por el temporizador de la puerta de enlace o sin tu participación, cuando el operador rehace la traducción, el módem se reconecta a la red; el simple cambio entre estaciones base no necesariamente cambia la IP pública. A este nivel se asocia el concepto de sesión sticky: la puerta de enlace procura mantener la salida elegida para las solicitudes con un mismo identificador de sesión durante una ventana acordada. Esto no es lo mismo que la sesión de la conexión móvil ni la autorización en el sitio. Es importante entender de quién es esa promesa. Lo sticky sigue siendo una condición del servicio concreto, que simplemente no inicia el cambio por sí mismo. El operador no da ninguna garantía al respecto, y un cambio forzado de la dirección por parte de la red sigue siendo posible en cualquier momento. Cuánto aguanta la dirección sin comando depende de la red concreta y del día concreto; aquí no hay constantes.

2. La sesión de la conexión, es decir, TCP y HTTP. Según la RFC 9293, una conexión TCP se define por un par de sockets, la dirección y el puerto de cada lado. Si una conexión ya abierta pierde su dirección anterior o la correspondencia NAT, puede cortarse o quedarse colgada hasta el timeout. Pero la puerta de enlace puede aplicar la rotación solo a las conexiones nuevas, conservando la ruta antigua para las ya abiertas: el comportamiento debe comprobarse por separado.

Las conexiones HTTP largas y WebSocket dependen del transporte. Además, la conexión del cliente con la puerta de enlace y la conexión de la puerta de enlace con el sitio son tramos distintos: la pérdida de la salida móvil no necesariamente cierra de inmediato la primera. La recuperación del transporte y la de la autorización también requieren comprobaciones diferentes.

3. La sesión de la aplicación, cookies y autorización. Este nivel lo gestionan el sitio y el navegador. El servidor emite una cookie, el navegador la guarda y la devuelve con cada solicitud según las reglas de dominio, ruta, plazo y atributos, como se describe en la guía de MDN sobre cookies. Ninguna de esas reglas menciona la dirección IP del cliente. El cambio de la dirección externa por sí mismo no borra ni las cookies, ni el localStorage, ni la caché. Si el sitio quiere reaccionar al cambio de dirección, pedir un nuevo inicio de sesión, mostrar una advertencia o limitar acciones, será una decisión de la lógica del servidor. Esa reacción no es una consecuencia automática de la rotación.

Ahora la situación inicial se explica sin magia: la rotación afectó el nivel 1, quizá cortó algo en el nivel 2, y el nivel 3 quedó intacto porque la cookie está en el navegador y se envía como antes.

Esquema conceptual: la salida de la red móvil y la sesión de la aplicación son capas distintas.

05Qué ocurre durante la rotación#

El comando de cambio de IP suele implementarse de una de dos maneras. O por temporizador, cuando la puerta de enlace inicia el cambio por sí misma tras un intervalo dado, o por enlace o llamada a la API, cuando lo lanzas tú. Técnicamente, el cambio se reduce a reconectar el módem a la red del operador. El módem corta la sesión de datos y levanta una nueva, el operador emite una nueva traducción y hacia fuera aparece otra dirección pública. Esa reconexión puede interrumpir temporalmente el acceso; su duración debe comprobarse en la conexión concreta. En una arquitectura con grupo, el cambio de salida puede ejecutarse de otra manera, sin reconectar el mismo módem. De aquí surgen varias consecuencias que conviene tener en cuenta quienes usan proxies móviles en su trabajo.

La nueva dirección no tiene por qué diferir radicalmente de la anterior, porque el grupo del operador es finito, y tras la reconexión el módem puede recibir una dirección de la misma subred, y a veces exactamente la misma que antes. No es un error del proxy, porque la puerta de enlace hizo todo lo que podía, y la distribución de direcciones sigue siendo competencia del operador.

Por la misma razón, carece de sentido juzgar la calidad de la rotación por si cambió el primer octeto. El comando puede incluso no dar resultado. El módem no se registró en la red, venció el tiempo de espera de respuesta del operador, se perdió brevemente la cobertura, y todo eso termina en que no hay dirección nueva o aparece con retraso. El código de cliente normal comprueba la dirección después del comando, en lugar de suponer que cambió. Las conexiones antiguas no se trasladan. En unas puertas de enlace, la nueva rotación se aplica a las conexiones nuevas y las ya abiertas se cierran por separado; en otras, todo se rompe a la vez. Un cambio de dirección sin interrupciones a nivel TCP no existe, porque la conexión por definición está ligada a las direcciones.

Si la rotación afectó la ruta de una descarga ya abierta o de un WebSocket, el cliente puede necesitar reconectarse. Si la salida antigua se conserva hasta terminar la operación, esta puede completarse sin corte.

El intervalo del temporizador sigue siendo tu parámetro, no una propiedad de la red.

Aparte, sobre DNS e IPv6. Si el cliente resuelve los nombres localmente y envía solo TCP a través del proxy, el sitio ve la dirección móvil, pero las consultas DNS salen desde tu dirección doméstica, y con IPv6 pasa algo parecido, porque parte de los clientes y sistemas prefieren la ruta IPv6 fuera del proxy si está disponible.

Ambas fugas no dependen de la rotación y se comprueban por separado.

06Dónde es útil la red móvil y dónde importa más la estabilidad#

El beneficio de una salida móvil en escenarios permitidos es suficiente, y no está relacionado con eludir nada. Aquí es donde los proxies móviles son apropiados.

Comprobar tu propio sitio con los ojos de un abonado móvil. Desde esa salida es cómodo verificar la visualización regional, la geosegmentación y el comportamiento de la CDN en tus propias plataformas. Eso sí, la IP móvil por sí misma no convierte un navegador de escritorio en un teléfono: la maquetación adaptable, el User-Agent y el comportamiento del dispositivo se prueban por separado.

Probar la resistencia del cliente al cambio de dirección. Si desarrollas una aplicación con conexiones largas, la rotación da una forma reproducible de comprobar cómo sobrevive el cliente a un corte, si se reconecta, si pierde datos y si se cuelga hasta el timeout. Aquí precisamente hacen falta cambios controlados, no estabilidad.

Depurar la lógica de autorización de tu lado. Es útil ver qué hace tu sitio cuando cambia la IP dentro de una sesión: nada, una advertencia o una solicitud de nuevo inicio de sesión. Es una prueba de tu propia lógica de servidor, no de la ajena.

También hay casos inversos, por ejemplo descargas largas, subidas grandes, llamadas por WebRTC y sesiones de API prolongadas con estado, donde la pérdida de la conexión anterior puede obligar a repetir la operación, y una salida móvil con su inestabilidad natural no es la mejor elección ahí. Si la tarea exige una sola dirección durante horas, hace falta o un modo sin temporizador, sabiendo que el operador puede intervenir igualmente, o directamente otro tipo de salida.

Y la regla general es que los proxies móviles no te hacen invisible, no crean una identidad nueva y no te protegen de las comprobaciones de los sitios. Cambian una cosa, y es desde qué dirección y a través de qué red llega la conexión, y todo lo demás queda en tus manos y en las reglas de las plataformas que uses.

07Qué cambia y qué no cambia con la rotación#

La tabla explica por qué la tienda sigue saludándote por tu nombre. La dirección de red y el estado del navegador cambian de forma independiente; el servidor de la aplicación puede usar ambas señales al comprobar la sesión.

08Lista de comprobación antes de alquilar#

Antes de alquilar proxies móviles, conviene probarlos en un cliente real y en tu propio sitio o banco de pruebas al que tengas derecho a conectarte. Brevemente, punto por punto.

1. Tipo de red de salida. Asegúrate de que la dirección pertenece realmente a un operador móvil y no a un centro de datos con fachada de móvil. Una consulta a la página de determinación de IP y la revisión del ASN dan una comprobación mínima, pero recuerda que es una señal indirecta.
2. Modo de rotación. Por temporizador, por enlace o por API, y si se puede desactivar el temporizador por completo. Comprueba que el comando realmente cambia la dirección y cuántos segundos tarda en tu caso.
3. Conservación de la dirección durante la operación. Ejecuta una operación larga, por ejemplo una carga de archivo o una serie de solicitudes, y observa si la dirección aguanta hasta el final sin comando. Repítelo varias veces, porque un resultado único no demuestra nada.
4. Cierre de las conexiones antiguas. Abre una conexión larga, cambia la IP y registra qué ocurrió: corte inmediato, cuelgue hasta el timeout o continuación desde la dirección antigua. Cualquier variante es admisible, pero hay que conocerla de antemano.
5. Latencias y cortes. La disponibilidad básica y el tipo de anonimato los muestra un verificador de proxies, pero mide el tiempo de respuesta y la proporción de solicitudes fallidas con tu propio tráfico en la franja horaria en que planeas trabajar. Las cifras ajenas no ayudan aquí.
6. DNS e IPv6 en el cliente real. Comprueba por dónde salen las consultas DNS y si el proxy evita la ruta IPv6. Hazlo con el navegador o la biblioteca que vas a usar, no con una utilidad aparte.
7. Límites, tráfico y protocolos. Restricciones de tráfico, número de conexiones simultáneas, frecuencia de cambios, compatibilidad con HTTP y SOCKS5, UDP si hace falta.
8. Reglas de uso. Qué permiten las condiciones del servicio y la legislación de tu jurisdicción, qué acciones llevan a bloquear la cuenta en el proveedor. Probar recursos ajenos sin permiso no entra en esta lista.

Puedes pasar esta lista con cualquier servicio del catálogo de proxies móviles. mobileproxy.space, por ejemplo, ofrece los tres modos del artículo: cambio de IP por enlace o API, rotación automática cada N minutos y sin rotación, con puertos por HTTP y SOCKS5:

mobileproxy.space: proxies móviles y residenciales4.776

Proxies móviles en SIMs reales por país y operadora, paquetes de ancho de banda residencial, más líneas de servidor y backconnect. Paga con tarjeta, SBP o cripto.

176 paísesCódigo promocional

5,90 US$

day

Visitar el sitio

09Qué conviene comprobar en primer lugar#

La rotación de IP cambia el punto de salida a internet, y solo eso.

Las conexiones pueden cortarse si la rotación afectó su ruta anterior; para las conexiones nuevas y las ya abiertas, el comportamiento de la puerta de enlace puede diferir. Las cookies, la autorización y la huella del navegador viven en el cliente y no dependen de la dirección, mientras el sitio no decida reaccionar a ella.

La dirección pública compartida sigue siendo una consecuencia normal del NAT del operador, y no promete ni unicidad ni anonimato. Si mantienes estos tres niveles separados, los proxies móviles dejan de ser un misterio, porque son una forma de mirar tu propio sitio y tus propias conexiones con los ojos de un abonado de la red celular, con todas sus particularidades, como la dirección real del operador, las reconexiones y el grupo limitado.

Conviene elegirlos para una tarea donde esa propiedad sea realmente necesaria, y comprobarlos en tu propio cliente antes de alquilar, no después.

10Preguntas frecuentes#