Sessões Proxy Sticky vs Rotativas: Guia Prático de Controle de IP

Sessões Proxy Sticky vs Rotativas: A Distinção Central

Se você já gerenciou um fluxo de scraping com múltiplas etapas — login, navegação, carrinho de compras, checkout — e perdeu tudo porque o proxy trocou o IP de saída no meio do processo, você já sentiu o problema na prática. A decisão entre sessões proxy sticky vs rotativas não é uma escolha estética; é a diferença entre um scraper que mantém estado e um que quebra a cada nova requisição.

Em essência, existem dois modos de operação:

• Rotativo (rotating): cada nova requisição HTTP sai por um IP residencial diferente. Ideal para coleta de dados públicos em alto volume, onde cada pedido é independente e você quer maximizar a distribuição de IPs.
• Sticky (sessão fixa): o proxy atribui um IP residencial e o mantém por um TTL configurável — tipicamente entre 1 e 30 minutos. Todas as requisições dentro dessa janela saem pelo mesmo IP, preservando cookies, tokens CSRF e estado de sessão.

A escolha errada custa caro. Rotação em um fluxo com estado resulta em sessão perdida. Stickiness em scraping de alto volume queima IPs mais rápido e reduz o throughput. Veja a comparação direta:

Por Que o Estado Vinculado ao IP Quebra Sem Stickiness

Muitos sites vinculam tokens de sessão ao IP de origem. Isso é uma medida anti-hijacking padrão: se um cookie de sessão for roubado, o atacante ainda precisa estar no mesmo IP para usá-lo. Para um scraper, porém, isso significa que qualquer rotação de IP no meio de um fluxo invalida o estado.

Exemplos concretos onde isso acontece:

• Logins multi-etapa: o site emite um token após o primeiro fator (senha) e valida o segundo fator (2FA) contra o IP que iniciou o fluxo. Se o IP mudar, o token é invalidado e o login falha.
• Tokens CSRF: formulários geram tokens CSRF vinculados à sessão do servidor, que por sua vez pode estar vinculada ao IP. Rotação entre o GET do formulário e o POST resulta em token inválido e 403 Forbidden.
• Carrinhos de compras: e-commerces frequentemente associam o carrinho ao IP + cookie. Trocar IP no meio do checkout resulta em carrinho vazio ou erro de sessão expirada.
• Paginação com cursores: APIs que usam cursor-based pagination às vezes validam o cursor contra o IP que iniciou a consulta. Rotação entre páginas = cursor inválido = resultados perdidos.

É exatamente por isso que sessões sticky residenciais são necessárias: elas garantem que o IP de saída permaneça constante durante todo o fluxo, preservando o estado no servidor de destino. Sem isso, qualquer fluxo com mais de uma etapa está fadado a quebrar.

Controle de Sessão no Nome de Usuário

O ProxyHat codifica o controle de sessão diretamente no nome de usuário do proxy. Isso significa que você não precisa de uma API separada para criar ou destruir sessões — basta mudar o formato do username.

Modo Rotativo (padrão)

Sem nenhum token de sessão, o gateway atribui um novo IP a cada requisição:

http://user:pass@gate.proxyhat.com:8080

Modo Sticky com geo-targeting

Para fixar um IP residencial nos EUA por uma sessão específica:

http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080

O token -session-abc123 cria uma sessão nomeada. Enquanto essa sessão estiver ativa (dentro do TTL), todas as requisições com o mesmo identificador sairão pelo mesmo IP. Mudar o identificador — por exemplo, -session-def456 — inicia uma nova sessão com um IP diferente.

Para fixar em uma cidade específica:

http://user-country-DE-city-berlin-session-abc123:pass@gate.proxyhat.com:8080

Consulte a lista completa de localizações disponíveis na página de localizações do ProxyHat.

Exemplos Práticos de Implementação

Python: Rotação por Requisição

Para scraping de dados públicos onde cada pedido é independente, use o endpoint rotativo padrão. Cada chamada sairá por um IP diferente:

import requests

proxies = {
    "http": "http://user:pass@gate.proxyhat.com:8080",
    "https": "http://user:pass@gate.proxyhat.com:8080",
}

urls = [
    "https://httpbin.org/ip",
    "https://httpbin.org/ip",
    "https://httpbin.org/ip",
]

for url in urls:
    resp = requests.get(url, proxies=proxies, timeout=30)
    print(f"{url} -> {resp.json()['origin']}")

Sem estado, sem sessão, máxima distribuição. Cada resposta mostrará um IP de origem diferente.

Node.js: Sessão Sticky em Fluxo Multi-Etapa

Para um fluxo que exige login, navegação e extração sequencial, fixe a sessão com um identificador único:

const fetch = require('node-fetch');
const { HttpsProxyAgent } = require('https-proxy-agent');

const sessionId = 'order-flow-' + Date.now();
const proxyUrl = `http://user-country-US-session-${sessionId}:pass@gate.proxyhat.com:8080`;
const agent = new HttpsProxyAgent(proxyUrl);

async function runFlow() {
  // Passo 1: Login
  const login = await fetch('https://api.exemplo.com/login', {
    method: 'POST',
    body: JSON.stringify({ user: 'me', pass: 'secret' }),
    headers: { 'Content-Type': 'application/json' },
    agent,
  });
  const cookies = login.headers.get('set-cookie');

  // Passo 2: Navegar para a página de dados
  const data = await fetch('https://api.exemplo.com/dashboard', {
    headers: { Cookie: cookies },
    agent,
  });

  // Passo 3: Extrair resultados paginados
  const page2 = await fetch('https://api.exemplo.com/dashboard?page=2', {
    headers: { Cookie: cookies },
    agent,
  });

  console.log('Fluxo completo com mesmo IP:', await data.text());
}

runFlow();

O mesmo sessionId garante que os três passos saiam pelo mesmo IP residencial nos EUA. Se você precisar de um novo IP para outro fluxo, basta gerar um novo identificador de sessão — nenhum cleanup é necessário.

Orientações Operacionais

TTL de Sessão

O TTL define por quanto tempo o IP fixo permanece ativo. TTLs curtos (5-10 minutos) são mais seguros porque limitam a exposição de um único IP. TTLs longos (30 minutos) são úteis para fluxos que exigem muitas etapas, mas aumentam o risco de o IP ser bloqueado antes do término. Ajuste o TTL conforme a complexidade do fluxo: um checkout de 3 passos precisa de menos tempo que um crawl de 20 páginas.

Reciclagem em 429/403

Quando você recebe 429 Too Many Requests ou 403 Forbidden em uma sessão sticky, o IP provavelmente foi sinalizado. A estratégia correta é descartar a sessão atual e iniciar uma nova com um identificador diferente:

import random, string, requests

def new_session_id():
    return 'sess-' + ''.join(random.choices(string.ascii_lowercase, k=8))

def fetch_with_retry(url, max_retries=3):
    for attempt in range(max_retries):
        sid = new_session_id()
        proxy = f"http://user-country-US-session-{sid}:pass@gate.proxyhat.com:8080"
        resp = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=30)
        if resp.status_code not in (403, 429):
            return resp
    raise Exception("Max retries exceeded")

Concorrência e Número de Sessões Paralelas

Quantas sessões sticky paralelas você deve rodar? Depende do alvo e do volume, mas algumas diretrizes práticas ajudam:

Para estimativas de custo, consulte a página de preços do ProxyHat e calcule com base no número de sessões simultâneas e no tráfego esperado. Uma sessão sticky consome o mesmo tráfego que uma rotação — a diferença está na reutilização do IP, não no custo por GB.

Quando Rotação Vence Sticky

Nem tudo precisa de sessão fixa. Para scraping de dados públicos em alto volume — páginas de produtos, resultados de busca, feeds públicos — a rotação por requisição é superior porque:

• Distribuição máxima de IPs: cada pedido sai por um IP novo, reduzindo a chance de rate limiting em qualquer IP individual. Com 100 IPs rotativos, você distribui 100 requisições sem repetição.
• Sem overhead de sessão: não há necessidade de gerenciar TTLs ou identificadores de sessão. O código fica mais simples.
• Maior throughput: sem a limitação de um IP fixo, você pode paralelizar agressivamente. Alcançar 1.500 requisições por segundo é viável com rotação, enquanto sticky limita você ao throughput de um único IP.

Se cada requisição é independente — sem login, sem carrinho, sem token CSRF — use rotação. Para entender como isso se aplica ao rastreamento de SERPs, veja nosso guia de rastreamento de SERP. Para scraping web de forma geral, consulte nosso guia de uso de web scraping.

Considerações Legais

Independentemente de usar sessões sticky ou rotativas, a legalidade do scraping depende do que você coleta e como. Alguns pontos críticos:

• CFAA (EUA): o Computer Fraud and Abuse Act pode aplicar-se a acessos não autorizados. O caso Van Buren v. United States (2021) restringiu o escopo da CFAA a acessos que excedem autorização expressa, mas o risco persiste em contextos com ToS restritivas.
• GDPR (UE): dados pessoais — incluindo IPs — são protegidos pelo Regulamento Geral de Proteção de Dados. Coletar e armazenar IPs sem base legal pode constituir violação, com multas de até 4% do faturamento global.
• ToS dos sites: muitos sites proíbem scraping em seus Termos de Serviço. Embora isso nem sempre seja juridicamente vinculante, violar ToS pode resultar em ações civis ou bloqueio de conta.
• robots.txt: respeitar robots.txt é uma boa prática e pode ser considerado pela jurisprudência como indicador de boa-fé técnica.

Consulte sempre um advogado antes de operar scraping em larga escala, especialmente se envolver dados pessoais ou acesso autenticado.

Principais Conclusões

• Rotativo = IP novo a cada pedido. Use para dados públicos independentes em alto volume (1.000+ requisições/hora).
• Sticky = IP fixo por TTL (1-30 min). Use para fluxos com estado: login, carrinho, paginação com cursor, checkout multi-etapa.
• Controle via username: -session-abc123 cria sessão; -country-US fixa geografia; combine ambos para sticky com geo-targeting.
• Recicle em 429/403: descarte o session ID e crie um novo para obter um IP limpo. Não insista com um IP bloqueado.
• Concorrência: 50-100 sessões paralelas cobrem a maioria dos casos práticos. Para volume extremo, prefira rotação pura.
• Legal: CFAA, GDPR e ToS importam. Consulte um advogado para operações de larga escala.

Para mais detalhes técnicos sobre configuração de proxies, autenticação e parâmetros avançados, consulte a documentação oficial do ProxyHat.