Web scraping limitado? Resolvendo fingerprinting, bloqueios de IP, CAPTCHAs e login com várias contas

Quando um trabalho de scraping encontra 403, 429, um CAPTCHA ou falhas de login recorrentes, a resposta certa não é rotacionar IPs, mascarar impressões digitais ou tentar "imitar uma pessoa real". Esses sinais geralmente indicam que a frequência das requisições, o escopo do acesso, o método de autenticação ou o comportamento automatizado ultrapassou um limite que o site aceita. Forçar a passagem costuma escalar a restrição e ainda pode violar termos de serviço, contratos, direitos autorais ou regras de proteção de dados.

Um caminho mais estável é confirmar primeiro a autorização e as interfaces disponíveis, depois reduzir o tráfego, aplicar cache e backoff quando necessário, e reservar a automação de navegador para as páginas que realmente exigem renderização de JavaScript ou login humano. Trate um CAPTCHA como um sinal de pausa, não como um obstáculo técnico a ser quebrado.

Comece pelo sintoma para estreitar a causa

Sintoma	Causa comum	Resposta em conformidade
429 Too Many Requests	Requisições rápidas demais, paralelas demais ou repetidas	Reduzir a taxa, respeitar Retry-After, usar backoff exponencial
403 Forbidden	Caminho não autorizado, bloqueio de política, sessão ausente	Verificar permissões, termos, robots.txt e método de autenticação
CAPTCHA aparece	O site exige verificação humana ou bloqueia automação	Pausar a tarefa, fazer manualmente ou solicitar uma API
Login falha repetidamente	Cookies expirados, sessões sobrescritas, falha de autenticação	Usar OAuth oficial ou contas de serviço, organizar a passagem de sessão
A página tem conteúdo, mas o script não lê	Renderização JavaScript, carregamento assíncrono de API	Usar a API oficial; com permissão, renderizar no navegador e ler o DOM
Seletores param de funcionar de repente	Redesign do DOM, teste A/B, mudança de idioma	Usar localizadores semânticos, testes estruturais e alertas, evitar hierarquias fixas
Dados duplicados ou faltando	Paginação, cursores, fusos horários, janela de atualização	Criar chaves únicas, marca incremental e mecanismo de reexecução

Mude apenas uma variável por vez e mantenha logs. Se você troca IP, User-Agent, conta e parser ao mesmo tempo, pode até ter sucesso por acaso, mas não saberá qual mudança realmente resolveu.

Passo 1: confirme que você tem direito de coletar esses dados

Antes de começar, responda quatro perguntas:

1. Os dados são públicos, ou ficam disponíveis só após login, pagamento ou para determinados papéis?
2. O site oferece API, exportação, feed, webhook ou uma interface de dados para parceiros?
3. Os termos de serviço, robots.txt, contratos e a legislação local permitem o uso pretendido?
4. Os dados incluem informações pessoais, conteúdo protegido por direitos autorais ou outros campos sensíveis?

robots.txt é o mecanismo padrão pelo qual um site expressa a clientes automatizados quais caminhos permite ou proíbe. A RFC 9309 define a sintaxe e as regras de correspondência do Robots Exclusion Protocol e deixa claro que robots.txt não é uma autorização de acesso. Em outras palavras, ser permitido pelo robots.txt não lhe dá todos os direitos de copiar, tratar ou usar comercialmente os dados; caminhos proibidos não devem ser contornados por outra entrada.

Projetos empresariais devem documentar fontes de dados, a base do acesso, o uso, os campos, o prazo de retenção e o mecanismo de exclusão. Quando dados agregados resolvem o problema, evite coletar informações que permitam identificar pessoas.

Passo 2: priorize pontos de entrada estáveis

A ordem habitual de prioridade é:

1. APIs oficiais, webhooks ou exportações de dados;
2. feeds públicos, sitemaps ou arquivos em lote;
3. páginas HTTP comuns com permissão;
4. automação de navegador apenas quando for realmente preciso renderizar JavaScript;
5. páginas que exigem conta humana e interação, por último.

APIs costumam trazer definições de campos, paginação, limites de taxa e códigos de erro, o que barateia a manutenção em relação a analisar uma interface. Uma página web é uma superfície para olhos humanos; pode mudar a qualquer momento e não deve ser tratada como um banco de dados estável.

Se o site não tem uma interface adequada, contate antes o proprietário dos dados e explique uso, frequência, campos e escala comercial. Uma licença clara geralmente é mais barata do que uma longa briga contra restrições.

Passo 3: trate 429 e bloqueios de IP reduzindo carga, não escondendo a origem

Defina tetos de taxa e concorrência

Comece com um único worker e um intervalo generoso, e observe o tempo de resposta e a taxa de erro. Quando o servidor devolver Retry-After, espere exatamente esse tempo. Caso contrário, use backoff exponencial com jitter aleatório para que várias tarefas não tentem de novo ao mesmo tempo.

Uma política simples:

espera = min(teto, base × 2^tentativas) + jitter

Ao atingir o número máximo de tentativas, pare e dispare um alerta. Não entre em loops infinitos.

Cache e atualizações incrementais

Faça cache da mesma URL e, quando houver suporte, envie requisições condicionais com ETag ou Last-Modified. Registre a hora da última atualização ou um cursor para trazer só o que é novo ou mudou. Separar a tarefa completa da incremental diária reduz bastante o volume de requisições.

Identifique seu cliente de forma honesta

Um crawler em conformidade usa um User-Agent estável e real, declara seu propósito e fornece uma página de contato ou e-mail. Se passar por um navegador comum e trocar de identidade com frequência, o site terá mais dificuldade para diferenciar tráfego bom de ruim, o que aumenta a chance de bloqueio.

Se um IP específico for restringido, pause a tarefa e verifique a causa. Continuar rotacionando proxies para manter o acesso pode ser visto como contorno dos controles de acesso, não como solução.

Passo 4: lide com fingerprinting e análise comportamental

Impressões digitais de navegador combinam sinais como User-Agent, sistema operacional, idioma, fuso horário, resolução, Canvas e WebGL. O site também pode analisar o ritmo das requisições, os caminhos de navegação e o comportamento da sessão. A OWASP lista Fingerprinting, Scraping, CAPTCHA Defeat, Credential Stuffing e outros como categorias distintas de ameaças automatizadas, o que explica por que um site costuma combinar vários sinais para avaliar o risco de automação.

Em tarefas autorizadas, o objetivo não é produzir muitas identidades "humanas", mas manter o ambiente estável e explicável:

• usar ambiente fixo e autenticação normal para a mesma conta de negócio;
• manter os parâmetros do navegador coerentes com a região e o dispositivo reais;
• não modificar impressões digitais aleatoriamente para escapar de bloqueios;
• registrar a frequência de coleta, o ID da tarefa e o responsável;
• combinar com o site o número de contas, a concorrência e o escopo de dados permitidos.

Se o site ainda classificar mal uma tarefa autorizada, envie timestamps, User-Agent, IP de saída e amostras de requisição e peça para entrar em uma lista branca ou receber uma interface dedicada.

Passo 5: pare a automação quando aparecer um CAPTCHA

O CAPTCHA existe para confirmar uma pessoa ou bloquear automação suspeita. Não use OCR, serviços de resolução de CAPTCHA, plugins para burlar CAPTCHA nem qualquer outro meio de contorno automático.

O fluxo correto é:

1. pausar imediatamente a conta atual e a fila de tarefas;
2. salvar a frequência de requisições, os caminhos e o log de erros imediatamente antes do disparo;
3. uma pessoa autorizada faz a verificação necessária na página oficial;
4. conferir se as requisições estavam rápidas demais, se a sessão havia expirado ou se um caminho não permitido foi acessado;
5. para automação de longa duração, solicitar ao site uma API, uma conta de serviço ou uma lista branca.

Mesmo que uma pessoa resolva um CAPTCHA uma vez, isso não dá direito a enviar requisições automáticas ilimitadas depois. Corrija primeiro a causa.

Passo 6: trate logins e várias contas com permissões formais

Dados atrás de login são mais sensíveis do que páginas públicas. Prefira OAuth, contas de serviço, tokens de API ou permissões concedidas pela equipe oficial da plataforma. Não deixe um script guardar a senha principal de uma pessoa.

Quando a sessão de navegador for realmente necessária:

• uma conta de negócio legítima corresponde a um ambiente estável;
• armazene cookies criptografados, com expiração e possibilidade de revogação;
• ative MFA e não permita que a automação burle a verificação em duas etapas;
• proíba que várias pessoas redefinam senhas ou dupliquem cookies ao mesmo tempo;
• registre quem iniciou qual tarefa e quando;
• revogue o acesso imediatamente em caso de desligamento, fim de projeto ou mudança de papel.

Várias contas são permitidas apenas para contas que você realmente possui ou para as quais recebeu autorização. Quando o site limita uma entidade a uma única conta, o isolamento de ambientes não deve ser usado para burlar esse limite.

Passo 7: deixe o parsing de páginas dinâmicas mais resistente a redesigns

Use atributos semânticos e estáveis

Prefira títulos, cabeçalhos, atributos de acessibilidade e identificadores de teste públicos do site. Evite hierarquias frágeis como div:nth-child(7). Releia o DOM após um refresh da página, não presuma que um nó antigo ainda existe.

Separe extração da lógica de negócio

A camada de coleta apenas transforma a página em campos estruturados. A camada de validação verifica tipos, intervalos, chaves únicas e campos obrigatórios. Com essa separação, um redesign toca só o parser e não quebra a análise posterior.

Monte amostras e alertas

Guarde um pequeno número de snapshots HTML ou estruturais em conformidade como amostras de teste. Não armazene páginas de conta completas nem dados sensíveis. Monitore taxa de campos faltantes, contagem de registros, taxa de duplicação e títulos de página; quando houver desvio, pare de escrever em produção.

O papel adequado do PurpleMark no scraping autorizado

Quando uma equipe precisa manter ao mesmo tempo várias contas autorizadas, ambientes de clientes diferentes ou regiões distintas, ela pode usar o PurpleMark web app para criar um ambiente de navegador independente por conta de negócio e guardar ali os cookies correspondentes, a página que deve abrir após o login e a configuração de rede habitual. Reabrir esse ambiente leva o navegador de volta à última sessão e à página de trabalho, evitando que várias pessoas compartilhem um mesmo conjunto de cookies e poupando logins repetidos.

Quando as contas precisam ser separadas por cliente, plataforma ou região, os grupos de ambientes permitem organizar contas de negócio em pastas distintas, e as permissões de membros, o compartilhamento e a transferência definem quem pode abrir cada ambiente. O registro de operações guarda quando e por quem cada ambiente foi aberto ou alterado. Em caso de questionamento sobre um scraping autorizado, é possível rastrear rapidamente até uma conta específica e um responsável identificado.

O PurpleMark ajuda a equipe a manter "contas, ambientes, sessões e responsabilidade" em um único espaço de trabalho ao longo do tempo, mas não se destina a contornar bloqueios de IP, CAPTCHAs, limites de quantidade de contas ou as defesas antiautomação de um site. Primeiro obtenha a autorização, depois fale de automação.

Uma arquitetura de scraping mantível

Uma divisão útil em cinco camadas:

1. Planejamento: controla frequência, concorrência, prioridade de tarefas e pausa;
2. Acesso: API, HTTP ou sessão de navegador autorizada;
3. Parsing: transforma respostas em campos estruturados;
4. Qualidade: deduplicação, validação de tipo, alertas de campos ausentes e registro de versões;
5. Governança: permissões, origem, uso, prazo de retenção e exclusão.

Cada registro guarda a URL de origem, a hora da coleta e a versão do parser. Quando algo dá errado, é possível localizar e reexecutar os registros afetados em vez de refazer o site inteiro.

Perguntas frequentes

Rotacionar proxies resolve um bloqueio de IP?

Pode mudar o endereço de saída por um tempo, mas não resolve o problema de frequência, permissão ou comportamento. Rotacionar proxies para manter o acesso pode contar como contorno. Primeiro pare a tarefa, reduza as requisições e contate o site.

Dá para resolver um CAPTCHA automaticamente?

Não. Um CAPTCHA é um sinal para pausar ou para acionar uma pessoa. Para automação contínua, solicite uma API, uma conta de serviço ou uma lista branca.

Se o robots.txt permite, posso coletar sempre?

Nem sempre. robots.txt não é autorização de acesso; também é preciso considerar termos, direitos autorais, privacidade, contratos e o uso dos dados.

Um navegador anti-detecção torna o scraping "indetectável"?

Não há garantia, e esse não deve ser o objetivo. Ele é mais útil para separar sessões legítimas de contas e permissões de equipe, reduzindo confusões de cookies e erros de manuseio.

Encerramento

As restrições ao web scraping não são apenas um "problema de tecnologia anti-bot". 403, 429, fingerprinting, CAPTCHAs e limites de várias contas apontam todos para permissões, carga e gestão de identidade.

Uma abordagem estável sempre volta à API como prioridade, autorização clara, requisições comedidas, cache incremental, parsing testável e contas auditáveis. Quando aparecer um CAPTCHA ou um bloqueio, pare e corrija o processo, em vez de continuar escondendo a origem da automação.