Como Fazer Scraping de Sites Que Exigem Login: Sessões, Cookies e Sticky Proxies em Escala

Muitos dos dados que vale a pena coletar estão atrás de um login, e fazer scraping deles é uma disciplina diferente de fazer scraping de páginas públicas. No momento em que você se autentica, você deixa de ser um visitante anônimo e passa a operar uma conta, e contas sofrem limitação de taxa, desafios e banimentos de formas que requisições anônimas nunca sofrem. Todo o jogo muda de “gire livremente para que nenhuma identidade única se destaque” para “mantenha uma identidade estável para que a conta pareça um usuário real e consistente”.

Um aviso antes do “como fazer”: só faça scraping de dados que você está autorizado a acessar, suas próprias contas, dados de um parceiro que você tem permissão para extrair, uma API que você tem direito de usar. Dados de acesso logado são uma categoria legal e ética diferente de dados públicos, e se o scraping é legal depende fortemente dessa linha. Este guia parte do princípio de que você está do lado certo dela.

Scraping público gira. Scraping autenticado permanece consistente.

O instinto vindo do scraping público é girar tudo, um novo IP por requisição evita que uma única identidade se destaque. Atrás de um login, esse instinto é exatamente o oposto do correto. Agora você tem uma identidade persistente, a conta, e a consistência é o que faz ela parecer legítima. Uma conta que faz login a partir de cinquenta países em uma hora, ou que troca de IP no meio de uma sessão, não parece um usuário avançado. Parece comprometida, e é isso que dispara um bloqueio.

Então o scraping autenticado se resume a fazer bem duas coisas: gerenciar a sessão para permanecer logado com eficiência, e fixar cada conta a uma identidade estável e limpa, para que ela nunca pareça ter se teletransportado.

Gerenciando a sessão

Quando você faz login, o servidor devolve o estado da sessão, geralmente cookies, às vezes um token. O maior erro é fazer login novamente a cada requisição. A reautenticação é lenta, e uma enxurrada de logins é em si um sinal de alerta, endpoints de login limitam a taxa com rigor. Faça login uma vez, capture a sessão e reutilize-a.

Com um cliente HTTP simples, isso significa um objeto de sessão persistente que mantém o pote de cookies e usa o proxy:

import requests

proxies = {"https": "http://customer-USER-country-us-sid-acct42-ttl-600:PASS@p.shifter.io:443"}
s = requests.Session()
s.proxies.update(proxies)

# Log in once; the Set-Cookie response populates the jar.
s.post("https://example.com/login", data={"user": USER, "password": PW})

# Reuse the same session (and the same sticky IP) for every subsequent request.
r = s.get("https://example.com/account/data")

Dois detalhes importam além disso. Muitos sites exigem um token CSRF ou anti-falsificação por sessão, que você extrai de um formulário ou de uma página anterior e envia com ações de escrita, então leia-o a partir da sessão em vez de fixá-lo no código. E muitos sites, após o login, expõem uma API JSON limpa que o próprio frontend do site chama; observar a aba de rede geralmente revela isso, e acessar essa API autenticada diretamente com seus cookies ou token capturados é muito mais rápido e leve do que renderizar páginas novamente.

Fixe cada conta a um único IP estável e limpo

É aqui que a camada de proxy se justifica. Uma conta deve apresentar uma localização consistente, então cada conta recebe sua própria sessão fixa: ela sempre sai pelo mesmo IP residencial durante toda a vida daquela sessão, codificado aqui como o sid no nome de usuário. Girar IPs em uma conta logada é um clássico gatilho de banimento, porque a conta parece pular entre localizações no meio da sessão.

Três coisas fazem a identidade se sustentar:

• Correspondência geográfica. O IP deve corresponder a onde a conta normalmente opera. Uma conta dos EUA que de repente aparece em um IP alemão parece um sequestro de conta, e muitos sites respondem com um pedido de reverificação ou um bloqueio.
• Reputação limpa. Endpoints de login examinam a reputação do IP com mais rigor do que páginas públicas, porque é ali que ocorrem as tomadas de conta. Um endereço marcado recebe fricção extra, pedidos de 2FA, CAPTCHAs, telas de “confirme que é você”, antes mesmo de chegar aos dados.
• Uma conta, uma identidade. Se você opera várias contas, cada uma precisa de seu próprio IP fixo, não um compartilhado. Contas que fazem login a partir de um único endereço acabam sendo vinculadas e marcadas em conjunto. Esta é a versão em escala de conta da identidade em duas camadas que um navegador antidetecção trata em nível de dispositivo: conta distinta, IP distinto, e, se você usar um navegador, fingerprint distinta.

Escalando para muitas contas

O padrão escala mapeando cada conta à sua própria identidade estável e mantendo esse mapeamento. Pense em um registro: conta para sid fixo, conta para pote de cookies e, se você controla um navegador, conta para perfil de navegador.

# One durable identity per account: same sid -> same exit IP, own cookie jar.
def session_for(account):
    s = requests.Session()
    sid = f"acct-{account['id']}"
    s.proxies.update({
        "https": f"http://{BASE_USER}-country-{account['geo']}-sid-{sid}-ttl-600:{PW}@p.shifter.io:443"
    })
    load_cookies(s, account)     # restore persisted jar, or log in if absent
    return s

Depois, distribua a carga entre as contas em vez de pressionar uma única conta com força, e limite a concorrência por conta e por alvo, já que cada conta tem seu próprio limite de taxa. O princípio de balanceamento de carga se aplica, mas a unidade sobre a qual você distribui são contas, cada uma com sua identidade fixa, não IPs brutos.

Lide com os modos de falha

Três coisas dão errado, e cada uma tem uma resposta específica.

Expiração de sessão. Sessões expiram. Detecte isso, um redirecionamento para a página de login, ou um 401, e reautentique na mesma identidade, então retome. A regra crítica é não trocar de IP ao reautenticar; um novo login a partir de uma nova localização é muito mais suspeito do que a própria expiração.

Logout silencioso. Às vezes você recebe um 200 que na verdade é a versão deslogada da página, todo o visual público, nenhum dado da conta. Este é o primo autenticado de um bloqueio suave: valide que você ainda está logado verificando um elemento que só um usuário autenticado vê, em vez de confiar no código de status. Se o marcador exclusivo da conta desapareceu, reautentique antes de registrar linhas vazias.

Reverificação forçada. Um pedido de 2FA ou um desafio de “confirme que é você” geralmente significa que a identidade pareceu arriscada, muitas vezes porque o IP foi marcado ou a localização mudou. Um IP limpo, estável e com correspondência geográfica é o que mantém isso raro. Quando um desses dispara, trate essa identidade como sob suspeita e recue em vez de insistir.

Navegador ou HTTP para o próprio login

Combine a ferramenta com o login, não com o scraping inteiro. Um login de formulário simples que retorna cookies funciona bem com um cliente HTTP simples, capture os cookies, reutilize-os, mantenha-se leve. Mas páginas de login são frequentemente a parte mais fortemente defendida de um site, com desafios JS, redirecionamentos SSO, tokens dinâmicos e fingerprinting agressivo, precisamente porque é ali que ocorre a fraude. Quando o login resiste a um cliente simples, faça login com um navegador real (Playwright, Puppeteer ou Selenium), depois continue controlando-o ou exporte os cookies para um cliente mais leve para o trabalho em massa. É também aqui que o fingerprinting de TLS e HTTP/2 mais incomoda, então a fingerprint de rede de um navegador real muitas vezes faz a diferença na etapa de login, mesmo quando o resto do scraping funciona bem em um cliente simples.

Verifique antes de confiar em uma execução

Depois de autenticar, confirme duas coisas: que você realmente está logado (busque um endpoint exclusivo da conta e verifique um marcador de sessão autenticada), e que você está saindo pelo IP fixo esperado (uma verificação de eco de IP deve retornar o mesmo endereço durante toda a vida da sessão). Se o login “teve sucesso” mas o marcador da conta está ausente, ou o IP de saída está variando entre requisições, corrija isso antes de coletar qualquer coisa, ambos os casos estão cobertos nos guias de timeout e detecção.

Resumo final

Fazer scraping atrás de um login é uma questão de consistência de identidade, não de rotação. Faça login uma vez e reutilize a sessão em vez de reautenticar constantemente, fixe cada conta a um único IP residencial limpo, com correspondência geográfica e fixo, mantenha uma conta para uma identidade, reautentique na mesma identidade quando uma sessão expirar, e valide que você ainda está logado em vez de confiar em um 200. Escale adicionando contas, cada uma com sua própria identidade estável, não girando uma única conta entre endereços.

Acerte isso e a coleta autenticada se torna durável em vez de uma sequência de bloqueios. Um IP residencial limpo e fixo por conta é a base sobre a qual tudo isso se apoia, e o preço por GB permite que você opere muitas identidades de conta estáveis e pague apenas pelos dados que cada uma realmente extrai.