Resposta rápida
Como mantenho o mesmo IP de cidade para várias requisições?
As sessões fixas EuroCity Proxies mantêm um único IP de saída por até 30 minutos (o IP pode mudar antes, por exemplo se o dispositivo residencial ficar offline). Adicione -session-<id>-ttl-<minutes> a um nome de usuário de cidade, por exemplo USERNAME-country-fr-city-lyon-session-lyon1-ttl-10. A partir de outubro de 2026, o ttl pode ser definido em até 30. Use um session id por cidade e por tarefa.
Qual é a diferença entre nomes de usuário rotativos e fixos?
| Modo | Exemplo de nome de usuário | Comportamento do IP de saída | Indicado para |
|---|---|---|---|
| Rotativo | USERNAME-country-pl-city-krakow | Uma nova conexão geralmente recebe um IP diferente na cidade | Carregamentos de página independentes, um por conexão |
| Fixo, 10 minutos | USERNAME-country-pl-city-krakow-session-krk1-ttl-10 | Mesmo IP por até 10 minutos, mesmo em novas conexões | Uma verificação rápida: uma página, dois cliques, uma captura de tela |
| Fixo, 30 minutos | USERNAME-country-pl-city-krakow-session-krk2-ttl-30 | Mesmo IP por até 30 minutos | Um teste mais longo do seu próprio site, como um checkout em modo de teste |
O que uma sessão sticky faz?
Uma sessão sticky vincula um id de sessão a um IP de saída por um tempo definido. Toda conexão que usa o mesmo usuário, incluindo o mesmo id, sai por esse IP até o ttl expirar. O IP pode mudar antes, por exemplo quando o dispositivo doméstico por trás dele fica offline.
Sem um id de sessão, o gateway funciona no modo rotativo. Cada nova conexão recebe um IP do pool, geralmente diferente; para obter um novo IP a cada requisição, envie uma requisição por conexão (desative o keep-alive). A rotação serve para requisições independentes. Uma sessão sticky serve para uma sequência vista como um único visitante de um único lugar. Um exemplo é uma loja que guarda sua área de entrega em um cookie.
As sessões mantêm a cidade que você escolheu na lista de cidades; combine-as com o direcionamento por ASN e verifique a saída com o verificador de cidade do proxy. Os planos estão na página de preços.
Por que usar uma sessão por cidade e por tarefa?
Porque assim cada tarefa tem um início claro, uma saída conhecida e um fim limpo. Nomeie o id com a cidade e a tarefa: lyon1 para a primeira checagem em Lyon, krk2 para a segunda checagem em Kraków. Os ids de sessão aceitam de 1 a 32 letras ou dígitos.
Isso mantém os resultados legíveis. Quando uma página de Lyon parece errada, você sabe qual saída a serviu e pode verificar esse IP. Também evita que uma sessão de longa duração misture várias checagens, cookies e carrinhos no mesmo endereço. Quando uma tarefa termina, feche o cliente dela e inicie a próxima tarefa com um novo id.
Devo escolher ttl-10 ou ttl-30?
Escolha o ttl mais curto que cobre a tarefa: ttl-10 para a maioria das checagens, ttl-30 apenas para fluxos longos. Uma checagem de uma página de cidade, de um produto e de um horário de entrega geralmente cabe em dez minutos. Um teste do seu próprio checkout, com formulários e uma etapa de pagamento em modo de teste, pode precisar de trinta.
Não conte com o ttl inteiro. Leia o IP de saída no início e no fim da tarefa. Se ele mudou, o dispositivo ficou offline; repita a tarefa uma vez com um novo id. O máximo é 30 minutos, então divida trabalhos mais longos em várias tarefas.
Como o keep-alive muda o IP de saída?
O keep-alive mantém uma conexão aberta, e uma conexão mantém uma saída. Conexões HTTP/1.1 são persistentes por padrão conforme a RFC 9112, então os clientes as reutilizam a menos que recebam ordem de fechar.
- requests: um
Sessionreutiliza conexões do seu pool. A documentação do Requests descreve o keep-alive como automático dentro de uma sessão. - httpx: um
Clientmantém suas conexões abertas da mesma forma. - undici (Node.js): um socket ocioso fica aberto por 4 segundos por padrão (
keepAliveTimeout), mais tempo se o servidor enviar uma dica de keep-alive.
Com uma sessão sticky isso não importa: o id mantém o IP mesmo em uma nova conexão. Com um usuário rotativo, importa. Requisições enviadas por uma mesma conexão aberta compartilham uma saída. Para um novo IP por requisição, feche a conexão ou abra um novo cliente a 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)As sessões conseguem contornar os limites de taxa de um site?
Não. Sessões e rotação escolhem de onde suas requisições vêm; elas não mudam o que um site permite. Rode uma sessão por cidade e por execução, a uma taxa modesta. Rotação não é uma forma de contornar os limites de taxa de um site.
Se uma página falhar, espere e tente novamente uma vez depois. Se o site continuar recusando, pare e use a via oficial dele, como uma API ou um parceiro de dados. A Política de Uso Aceitável lista para que o serviço não pode ser usado.
Quanto tráfego as sessões sticky usam?
Uma sessão não custa nada por si só: você paga apenas pelos dados enviados e recebidos. O uso conta todos os dados enviados e recebidos pelo proxy (upload e download, cabeçalhos incluídos). 1 GB = 1.000.000.000 bytes. Tentativas de conexão que falham antes de chegar ao destino não são contadas. Uma checagem curta de cidade com uma página e duas consultas de IP geralmente usa poucos megabytes ou menos, dependendo da página.
O tráfego é compartilhado entre todas as cidades e sessões da sua conta. O tráfego pré-pago residencial e móvel rotativo nunca expira: os GB não utilizados ficam na sua conta até você usá-los. Os planos começam a partir de US$ 0,95 por 1 GB na página de preços.
Sessões sticky: perguntas
Qual é a sessão sticky mais longa?
Trinta minutos. Defina -ttl-30 no usuário. O IP ainda pode mudar antes se o dispositivo doméstico por trás dele ficar offline. Leia o IP de saída no início e no fim de cada tarefa.
Como consigo um novo IP na mesma cidade?
Mude o id de sessão, por exemplo de lyon1 para lyon2, e mantenha o restante do usuário. Com um usuário rotativo, abra uma nova conexão.
Dois scripts podem compartilhar uma sessão?
Uma sessão é identificada pelo seu usuário, id e ttl, então dois scripts que enviam exatamente os mesmos valores pedem a mesma sessão sticky. Verifique o IP de saída em cada script antes de confiar nele, e use ids separados para tarefas separadas.
Uma sessão sticky mantém a mesma cidade?
Sim. A cidade faz parte do usuário, e a sessão mantém um IP de saída do direcionamento dessa cidade. A disponibilidade das cidades varia; o checkout mostra o que está online.
Por que meu IP mudou depois de dois minutos com ttl-10?
Conexões domésticas ficam offline: um roteador reinicia, um dispositivo entra em suspensão, um provedor reatribui um endereço. A sessão então recebe uma nova saída. Repita a tarefa uma vez com um novo id; se acontecer em toda tarefa, escreva para o suporte com horários e IPs.
As sessões sticky custam mais que as rotativas?
Não. Ambas usam o mesmo tráfego por GB. Segmentação por país e cidade em todos os planos; nos Estados Unidos também por estado e CEP; segmentação por ASN sem custo extra. A disponibilidade de cidades varia.
Fontes (5)
- RFC 9112 HTTP/1.1, seção 9.3 Persistence — IETF (June 2022, checked 2026-10-18)
- Requests: Advanced Usage, Session Objects e Keep-Alive — Requests (checked 2026-10-18)
- undici Client: keepAliveTimeout (padrão 4e3 ms) — Node.js project (checked 2026-10-18)
- HTTPX: Proxies — Encode (checked 2026-10-18)
- Endpoint JSON do IPinfo — IPinfo (checked 2026-10-18)