Respuesta rápida
¿Cómo mantengo la misma IP de ciudad para varias peticiones?
EuroCity Proxies Las sesiones sticky mantienen una misma IP de salida hasta 30 minutos (la IP puede cambiar antes, por ejemplo si el dispositivo residencial se desconecta). Añade -session-<id>-ttl-<minutes> a un nombre de usuario de ciudad, por ejemplo USERNAME-country-fr-city-lyon-session-lyon1-ttl-10. A partir de octubre de 2026, el ttl puede configurarse hasta 30. Usa un id de sesión por ciudad y por tarea.
¿En qué se diferencian los nombres de usuario rotativos y sticky?
| Modo | Ejemplo de nombre de usuario | Comportamiento de la IP de salida | Ideal para |
|---|---|---|---|
| Rotativo | USERNAME-country-pl-city-krakow | Una nueva conexión suele obtener una IP diferente en la ciudad | Cargas de página independientes, una por conexión |
| Sticky, 10 minutos | USERNAME-country-pl-city-krakow-session-krk1-ttl-10 | La misma IP hasta 10 minutos, incluso entre nuevas conexiones | Una comprobación breve: una página, dos clics, una captura de pantalla |
| Sticky, 30 minutos | USERNAME-country-pl-city-krakow-session-krk2-ttl-30 | La misma IP hasta 30 minutos | Una prueba más larga de tu propio sitio, como un checkout en modo de prueba |
¿Qué hace una sesión sticky?
Una sesión sticky vincula un id de sesión a una IP de salida concreta durante un tiempo determinado. Cada conexión que usa el mismo nombre de usuario, incluido el mismo id, sale por esa IP hasta que expira el ttl. La IP puede cambiar antes, por ejemplo cuando el dispositivo doméstico que hay detrás se desconecta.
Sin id de sesión, la puerta de enlace funciona en modo rotativo. Cada nueva conexión recibe una IP del pool, normalmente diferente; para obtener una nueva IP en cada solicitud, envía una solicitud por conexión (desactiva keep-alive). La rotación es adecuada para peticiones independientes. Una sesión sticky es adecuada para una secuencia vista como un único visitante desde un único lugar. Un ejemplo es una tienda que guarda tu zona de entrega en una cookie.
Las sesiones mantienen la ciudad que elegiste en la lista de ciudades; combínalas con segmentación por ASN y comprueba la salida con el verificador de ciudades de proxy. Los planes están en la página de precios.
¿Por qué usar una sesión por ciudad y por tarea?
Porque así cada tarea tiene un inicio claro, una salida conocida y un final limpio. Nombra el id según la ciudad y la tarea: lyon1 para la primera comprobación de Lyon, krk2 para la segunda comprobación de Cracovia. Los ids de sesión admiten de 1 a 32 letras o dígitos.
Esto mantiene los resultados legibles. Cuando una página de Lyon parece incorrecta, sabes qué salida la sirvió y puedes comprobar esa IP. También evita que una sesión de larga duración mezcle varias comprobaciones, cookies y carritos en la misma dirección. Cuando termina una tarea, cierra su cliente y empieza la siguiente tarea con un id nuevo.
¿Debo elegir ttl-10 o ttl-30?
Elige el ttl más corto que cubra la tarea: ttl-10 para la mayoría de comprobaciones, ttl-30 solo para flujos largos. Una comprobación de una página de ciudad, un producto y una franja de entrega suele caber en diez minutos. Una prueba de tu propio checkout, con formularios y un paso de pago en modo de prueba, puede necesitar treinta.
No cuentes con el ttl completo. Lee la IP de salida al inicio y al final de la tarea. Si ha cambiado, el dispositivo se desconectó; repite la tarea una vez con un id nuevo. El máximo es de 30 minutos, así que divide el trabajo más largo en varias tareas.
¿Cómo cambia keep-alive la IP de salida?
Keep-alive mantiene una conexión abierta, y una conexión mantiene una salida. Las conexiones HTTP/1.1 son persistentes por defecto según RFC 9112, así que los clientes las reutilizan a menos que se les indique cerrarlas.
- requests: un
Sessionreutiliza conexiones de su pool. La documentación de Requests describe keep-alive como automático dentro de una sesión. - httpx: un
Clientmantiene sus conexiones abiertas de la misma forma. - undici (Node.js): un socket inactivo permanece abierto 4 segundos por defecto (
keepAliveTimeout), más si el servidor envía una indicación keep-alive.
Con una sesión sticky esto no importa: el id mantiene la IP incluso en una conexión nueva. Con un nombre de usuario rotativo sí importa. Las peticiones enviadas por una misma conexión abierta comparten una salida. Para una nueva IP por petición, cierra la conexión o abre un cliente nuevo cada vez.
# pip install requests
from urllib.parse import quote
import requests
HOST = "gw.eurocityproxies.com"
PORT = 7777
PASSWORD = quote("PASSWORD", safe="")
def session_for(country: str, city: str, task: str, ttl: int = 10) -> requests.Session:
user = f"USERNAME-country-{country}-city-{city}-session-{task}-ttl-{ttl}"
proxy = f"http://{user}:{PASSWORD}@{HOST}:{PORT}"
s = requests.Session()
s.trust_env = False # ignore HTTP_PROXY / HTTPS_PROXY set on your machine
s.proxies = {"http": proxy, "https": proxy}
return s
def exit_ip(s: requests.Session) -> str:
return s.get("https://ipinfo.io/json", timeout=30).json()["ip"]
tasks = [("fr", "lyon", "lyon1"), ("pl", "krakow", "krk1"), ("nl", "the_hague", "hag1")]
for country, city, task in tasks:
with session_for(country, city, task) as s:
start = exit_ip(s)
page = s.get("https://YOUR-SITE.example/", timeout=30)
end = exit_ip(s)
note = "same exit" if start == end else "exit changed: repeat once with a new id"
print(city, start, page.status_code, note)¿Pueden las sesiones saltarse los límites de tasa de un sitio?
No. Las sesiones y la rotación eligen de dónde vienen tus peticiones; no cambian lo que un sitio permite. Ejecuta una sesión por ciudad y por ejecución, a un ritmo moderado. La rotación no es una forma de saltarse los límites de tasa de un sitio.
Si una página falla, espera y reinténtalo una vez más tarde. Si el sitio sigue rechazando, detente y usa su vía oficial, como una API o un socio de datos. La Política de Uso Aceptable enumera para qué no puede usarse el servicio.
¿Cuánto tráfico consumen las sesiones sticky?
Una sesión no cuesta nada por sí misma: solo pagas por los datos enviados y recibidos. El uso cuenta todos los datos enviados y recibidos a través del proxy (subida y bajada, encabezados incluidos). 1 GB = 1.000.000.000 bytes. Los intentos de conexión que fallan antes de llegar al destino no se cuentan. Una comprobación corta de ciudad con una página y dos consultas de IP suele usar unos pocos megabytes o menos, según la página.
El tráfico se comparte entre todas las ciudades y sesiones de tu cuenta. El tráfico prepago residencial y móvil rotativo nunca caduca: los GB no utilizados permanecen en tu cuenta hasta que los uses. Los planes empiezan en 0,95 US$ por 1 GB en la página de precios.
Sesiones sticky: preguntas
¿Cuál es la sesión sticky más larga?
Treinta minutos. Configura -ttl-30 en el nombre de usuario. La IP puede cambiar antes si el dispositivo doméstico que hay detrás se desconecta. Lee la IP de salida al inicio y al final de cada tarea.
¿Cómo obtengo una nueva IP en la misma ciudad?
Cambia el id de sesión, por ejemplo de lyon1 a lyon2, y mantén el resto del nombre de usuario. Con un nombre de usuario rotativo, abre una conexión nueva en su lugar.
¿Pueden dos scripts compartir una sesión?
Una sesión se identifica por su nombre de usuario, id y ttl, así que dos scripts que envían exactamente los mismos valores solicitan la misma sesión sticky. Comprueba la IP de salida en cada script antes de confiar en ella, y usa ids separados para tareas separadas.
¿Mantiene una sesión sticky la misma ciudad?
Sí. La ciudad forma parte del nombre de usuario, y la sesión mantiene una IP de salida de la segmentación de esa ciudad. La disponibilidad de ciudades varía; el checkout muestra qué está en línea.
¿Por qué cambió mi IP después de dos minutos con ttl-10?
Las conexiones domésticas se desconectan: un router se reinicia, un dispositivo entra en suspensión, un proveedor reasigna una dirección. La sesión entonces obtiene una nueva salida. Repite la tarea una vez con un id nuevo; si ocurre en todas las tareas, escribe a soporte con horas e IPs.
¿Cuestan más las sesiones sticky que las rotativas?
No. Ambas usan el mismo tráfico por GB. Segmentación por país y ciudad en todos los planes; en Estados Unidos también por estado y código ZIP; segmentación por ASN sin coste extra. La disponibilidad de ciudades varía.
Fuentes (5)
- RFC 9112 HTTP/1.1, sección 9.3 Persistence — IETF (June 2022, checked 2026-10-18)
- Requests: Advanced Usage, Session Objects and Keep-Alive — Requests (checked 2026-10-18)
- undici Client: keepAliveTimeout (por defecto 4e3 ms) — Node.js project (checked 2026-10-18)
- HTTPX: Proxies — Encode (checked 2026-10-18)
- Endpoint JSON de IPinfo — IPinfo (checked 2026-10-18)