¿La IP del proxy residencial no rota? Causas y soluciones

Configuraste un proxy rotativo, envías diez solicitudes, y todas devuelven la misma dirección de salida. La conclusión obvia es que la rotación está rota. Normalmente no es así. En la mayoría de los casos, la puerta de enlace está entregando direcciones nuevas exactamente como se solicitó, y algo entre tu código y ella está impidiendo que eso ocurra, y el culpable más común es una función de tu cliente HTTP que existe para hacer las cosas más rápidas.

Aquí están las causas en el orden en que merece la pena revisarlas, con la solución para cada una.

Primero, compruébalo correctamente

Antes de diagnosticar, asegúrate de que la propia prueba es válida. Una única solicitud por línea de comandos por invocación es la comprobación más limpia, porque cada ejecución es un proceso independiente sin estado compartido:

for i in 1 2 3 4 5; do
  curl -s -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/json \
    | python3 -c "import sys,json; print(json.load(sys.stdin)['ip'])"
done

Cinco direcciones distintas significa que la rotación funciona y que el problema está en tu aplicación. Cinco idénticas significa que el problema está en la configuración. Esa única distinción ahorra la mayor parte del tiempo de depuración, así que ejecútala primero.

Causa uno: un identificador de sesión en el nombre de usuario

La explicación más simple. Si tu nombre de usuario contiene un indicador sid, has solicitado explícitamente una sesión persistente, y mantener la dirección es el comportamiento correcto y no un fallo.

customer-USERNAME-country-us-sid-abc123    # persistente: misma IP por diseño
customer-USERNAME-country-us               # rotativo: IP nueva por solicitud

Esto detecta a quienes copiaron un ejemplo de la documentación, o construyeron el nombre de usuario con una utilidad que añade una sesión por defecto. Elimina el indicador sid, y el ttl junto con él, ya que el TTL solo tiene sentido junto a una sesión. La semántica está en sticky versus rotating y en la documentación de sesiones.

Una variante más sutil: tu identificador de sesión es constante cuando pretendías que variara. Si generas uno por tarea pero la tarea ejecuta muchas solicitudes, cada solicitud de esa tarea comparte una dirección, lo cual es correcto pero puede no ser lo que pretendías.

Causa dos: reutilización de conexión, la que atrapa a todo el mundo

Esta es la respuesta la mayoría de las veces cuando el bucle de curl anterior rota y tu código no.

Los clientes HTTP modernos mantienen las conexiones abiertas y las reutilizan, porque abrir una nueva conexión TCP y TLS para cada solicitud es lento. Cuando tu cliente reutiliza un túnel ya establecido hacia el proxy, la solicitud viaja a través de la conexión que ya está establecida, y esa conexión ya tiene asignada una dirección de salida. La rotación ocurre por conexión, no por solicitud enviada a través de una conexión existente, así que un objeto de sesión que mantiene un pool de conexiones enviará fielmente cada solicitud a través de la misma salida.

La solución depende de cuánto control quieras. O bien desactivas el keep-alive, o fuerzas una nueva conexión por solicitud, o haces que cada solicitud lógica use un cliente nuevo.

import requests

PROXY = "http://customer-USERNAME:PASSWORD@p.shifter.io:443"
PROXIES = {"http": PROXY, "https": PROXY}

# Reutiliza una conexión: misma dirección de salida en cada solicitud
s = requests.Session()
for _ in range(5):
    print(s.get("https://ipinfo.io/json", proxies=PROXIES).json()["ip"])

# Conexión nueva por solicitud: rota como se espera
for _ in range(5):
    r = requests.get("https://ipinfo.io/json", proxies=PROXIES,
                     headers={"Connection": "close"}, timeout=20)
    print(r.json()["ip"])

Lo mismo se aplica en otros lenguajes: un http.Agent con keep-alive en Node, un HttpClient compartido en .NET o Java, un pool de conexiones en Go. Si tu lenguaje tiene un cliente por defecto que agrupa conexiones, y todos lo tienen, esto es lo primero que hay que revisar en el código de la aplicación.

Merece la pena decirlo claramente: esto es una compensación y no un error. La reutilización de conexión es más rápida y económica. Si tu trabajo realmente quiere una dirección nueva por solicitud, pagas el coste de una nueva conexión cada vez; si no, la reutilización está bien y a menudo es preferible.

Causa tres: estás comprobando demasiado rápido, o el pool es más pequeño de lo que crees para ese filtro

Dos efectos relacionados.

Si has restringido el filtro de forma muy estrecha, a una ciudad pequeña o a un ASN específico, el conjunto de direcciones que pueden atenderte es mucho más pequeño que el pool general, así que la misma dirección reaparece legítimamente con más frecuencia. Eso no es un fallo, es aritmética. Amplía el filtro y la repetición desaparece.

Recuerda también que un pool residencial está formado por conexiones reales que van y vienen, así que ver una dirección dos veces a lo largo de muchas solicitudes es esperable y no sospechoso. La rotación significa que la siguiente solicitud se selecciona de forma independiente, no que una dirección nunca pueda repetirse. Si necesitas distinción garantizada para una carga de trabajo, eso es una restricción de diseño que hay que gestionar en tu propio código.

Causa cuatro: algo por encima está haciendo caché

Si estás probando a través de un navegador, una extensión, un ajuste de proxy a nivel de sistema, o una red corporativa, la solicitud puede no estar yendo por donde crees. Los navegadores en particular mantienen las conexiones abiertas de forma agresiva y las reutilizan entre pestañas, así que un navegador es el peor entorno para verificar la rotación. Prueba primero desde la línea de comandos, luego en tu aplicación, y solo después en un navegador.

De forma similar, si tu código establece variables de entorno de proxy además de pasar configuración explícita, una puede estar sobrescribiendo a la otra y enviando el tráfico a través de algo distinto a la puerta de enlace que configuraste.

Causa cinco: la dirección es la misma porque la solicitud nunca salió

Una comprobación directa que merece la pena descartar: si el proxy no se está usando realmente, cada solicitud informa de la misma dirección, es decir, la tuya. Confirma que la dirección que estás viendo no es la de tu propio servidor. Si lo es, la configuración del proxy no se está aplicando en absoluto, lo cual es un problema distinto y suele deberse a que falta una entrada https junto a la de http, o a un cliente que ignora la configuración del proxy para el esquema que estás usando.

Causa seis: una sesión persistente que aún no ha caducado

Si estás usando sesiones persistentes de forma deliberada y esperas que roten después de un tiempo, recuerda que la dirección se mantiene hasta que expira el TTL. La duración por defecto es de 120 segundos a menos que establezcas ttl explícitamente. Si quieres una dirección nueva antes, cambia el identificador de sesión en lugar de esperar, ya que un identificador nuevo significa una sesión nueva.

Ten en cuenta también que una dirección persistente puede caer antes de que expire su TTL si la conexión subyacente desaparece, ya que se trata de conexiones domésticas reales y no de infraestructura dedicada. Persistente significa mejor esfuerzo durante la duración solicitada, no una garantía.

Una ruta de decisión rápida

Ejecuta el bucle de curl. Si rota y tu código no, tienes un problema de reutilización de conexión, que es la causa dos. Si ninguno rota, comprueba el nombre de usuario en busca de un indicador sid, luego confirma que no estás viendo tu propia dirección, y después amplía cualquier filtro geográfico estrecho. Si rota con menos frecuencia de la que te gustaría, pero sí rota, estás ante un tema de tamaño de pool para ese filtro y no ante un fallo.

Para todo lo demás, el comportamiento circundante está documentado en how rotation works, y si las solicitudes están fallando en lugar de repetirse, why requests time out y fixing 407 errors cubren los dos modos de fallo más comunes.

La conclusión

Los problemas de rotación normalmente no son problemas de rotación. Prueba primero con procesos separados para establecer si la puerta de enlace está rotando en absoluto, y si lo está, revisa tu cliente HTTP, porque la reutilización de conexión es, con diferencia, la causa favorita: las solicitudes enviadas a través de un túnel ya abierto mantienen la dirección de salida que ese túnel ya tiene. Después de eso, comprueba si hay un indicador sid perdido, confirma que no estás viendo tu propia dirección, y recuerda que un filtro geográfico muy estrecho extrae de un conjunto mucho más pequeño, así que las repeticiones son normales. Las sesiones persistentes que mantienen su dirección están funcionando como estaba previsto, y cambiar el identificador te da una nueva inmediatamente.

El propio modelo de rotación, y los indicadores que lo controlan, se encuentran en la residential proxy network, donde el comportamiento de sesión es un parámetro por solicitud en lugar de un ajuste de plan, facturado per GB independientemente de la frecuencia con la que rotes.