Pular para o conteúdo principal

Como Fazer Web Scraping Sem Ser Bloqueado: Guia Completo 2026

HT

Hinata Tomoda

Engenheiro web e analista independente

15 min de leitura

Para fazer web scraping sem ser bloqueado, respeite o robots.txt e os termos do site, limite as requisições a um ritmo humano com backoff exponencial, envie headers de navegador completos e realistas, mantenha cookies consistentes por sessão, distribua volume legítimo entre IPs residenciais rotativos e monitore os códigos de status — é nessa ordem que eu atacaria o problema.

Pontos-chave

  • A maioria dos bloqueios é autoinfligida: taxas de requisição irreais, headers incompletos e sessões inconsistentes são muito mais fáceis de sinalizar para sistemas anti-bot do que qualquer endereço IP.
  • Compliance vem primeiro — verifique o robots.txt e os termos de serviço antes de escrever uma linha de código, e nunca colete dados pessoais nem conteúdo atrás de login ou paywall.
  • Respeite respostas HTTP 429 e Retry-After com backoff exponencial e jitter; um scraper que recua com educação é bloqueado com muito menos frequência do que um que martela o servidor.
  • Proxies residenciais rotativos são uma ferramenta de legitimidade para volume, não um disfarce para acesso proibido — provedores sérios aplicam verificações KYC justamente para manter usos abusivos fora de suas redes.
  • Acompanhe continuamente sua taxa de sucesso, a distribuição de códigos de status e as impressões digitais das respostas; uma migração lenta de 200 para CAPTCHAs é o alerta mais precoce de que sua configuração precisa de ajuste.

Ser bloqueado não é falta de sorte. É a pilha anti-bot de um site identificando corretamente tráfego que não se parece com uma pessoa navegando — ou tráfego que o site pediu explicitamente para ir embora. Este guia cobre as práticas de engenharia que mantêm projetos legítimos de scraping (monitoramento de preços, acompanhamento de SEO, verificação de anúncios, dados de treinamento de IA, pesquisa de mercado) rodando de forma confiável, e é explícito sobre as linhas que não ajudamos ninguém a cruzar. Para o panorama completo de como o scraping funciona de ponta a ponta, comece pelo nosso guia de web scraping.

Comece pelas regras: robots.txt e termos de serviço

Antes de otimizar qualquer aspecto técnico, determine se você deveria estar fazendo scraping daquele alvo.

  1. Baixe e interprete o robots.txt. O arquivo na raiz do site declara quais caminhos estão fora dos limites para crawlers e frequentemente inclui uma diretiva Crawl-delay. Respeitá-lo é o sinal mais claro de que seu projeto opera de boa-fé, e a maioria dos frameworks maduros de scraping consegue aplicá-lo automaticamente.
  2. Leia os termos de serviço. Alguns sites proíbem acesso automatizado por completo; outros restringem usos específicos. Se as cláusulas de ToS são exigíveis varia conforme a jurisdição e o caso — nosso panorama sobre se web scraping é legal cobre as principais decisões judiciais — mas saber o que o site diz é uma obrigação básica, não um extra opcional.
  3. Prefira canais oficiais. Se o site oferece uma API, um feed de dados ou um programa de licenciamento que cobre seu caso de uso, use-o. É mais estável do que scraping e elimina o problema de bloqueio por completo.
  4. Delimite sua coleta. Colete apenas os campos de que precisa, apenas de páginas públicas, e exclua qualquer coisa que identifique indivíduos. Sob a LGPD, o GDPR e regimes semelhantes, dados pessoais carregam obrigações que a maioria dos projetos de scraping não está preparada para cumprir.

Nossa posição de compliance, dita com todas as letras: o ProxyFacts não fornece orientação para burlar paywalls ou telas de login, derrotar CAPTCHAs em escala via fazendas de resolução, coletar dados pessoais ou automatizar compras (bots de sneakers, cambismo de ingressos, criação de contas). Engenharia anti-bloqueio, como tratada aqui, serve para tornar confiável um acesso legítimo — não para obter um acesso que você nunca teve permissão de ter.

Entenda por que os sites bloqueiam scrapers

Sistemas anti-bot procuram padrões que nenhum humano produz. Conhecer as camadas de detecção mostra o que corrigir:

Camada de detecçãoO que ela procuraResposta típica
Análise de taxaRequisições demais por IP por janela de tempo; intervalos perfeitamente regularesHTTP 429, banimento temporário de IP
Inspeção de headersHeaders ausentes ou contraditórios; strings de User-Agent padrão de bibliotecaHTTP 403, dados-lixo silenciosos
Análise de sessãoCookies que aparecem e somem; IP mudando no meio da sessãoReverificação forçada, CAPTCHA
Fingerprinting de navegadorSinais coletados via JavaScript (canvas, fontes, handshake TLS) inconsistentes com o navegador declaradoDesafio de CAPTCHA, página de bloqueio
Análise comportamentalNenhum movimento de mouse, navegação instantânea, rastreamento em sequência perfeitaThrottling progressivo, armadilhas honeypot
Reputação de IPFaixas de IP de datacenter, listas de bloqueio de proxies conhecidos403 generalizado para sub-redes inteiras

Duas implicações seguem daí. Primeira: rotação de IP sozinha corrige apenas uma camada — um scraper com IP rotativo mas User-Agent padrão do Python continua sendo pego na camada dois. Segunda: as camadas se compõem — headers consistentes com sessões inconsistentes parecem mais suspeitos do que qualquer uma das falhas isoladamente. Trabalho eficaz de anti-bloqueio significa fazer cada camada contar a mesma história, verdadeira: um cliente razoável fazendo um número razoável de requisições.

Rate limiting e backoff: a correção de maior alavancagem

O jeito mais rápido de ser bloqueado é enviar requisições na velocidade máxima da sua conexão. A correção custa quase nada:

  • Defina uma linha de base conservadora. Uma requisição a cada poucos segundos por domínio é um ponto de partida sensato para a maioria dos sites. Se o robots.txt declara um Crawl-delay, trate-o como piso, não como sugestão.
  • Adicione jitter. Randomize o intervalo entre requisições (por exemplo, um atraso base multiplicado por um fator aleatório entre 0,5 e 1,5). Intervalos perfeitamente regulares são assinatura de máquina.
  • Implemente backoff exponencial. Em HTTP 429 ou 503, espere e tente de novo com atraso dobrado: 1 segundo, 2, 4, 8, e assim por diante, com um teto sensato. Se a resposta incluir um header Retry-After, obedeça-o à risca.
  • Orce a concorrência por domínio, não globalmente. Vinte workers concorrentes distribuídos entre vinte sites estão bem; vinte workers em um único site são uma rajada que parece um ataque.
  • Agende fora dos horários de pico. Rastrear um varejista durante seu pico de tráfego disputa recursos de servidor com clientes reais. Rastrear fora do pico é mais educado e menos propenso a disparar defesas baseadas em carga.

Um scraper que respeita essas regras muitas vezes não precisa de nenhum outro trabalho anti-bloqueio em jobs pequenos e médios. Tudo o que vem a seguir importa principalmente conforme o volume cresce. Se eu tivesse uma única hora para tornar um scraper mais robusto, ela seria gasta inteira nesta seção.

Envie headers realistas e consistentes

Os headers padrão de clientes HTTP anunciam exatamente o que você é. Corrija os sinais óbvios:

  1. Defina um User-Agent de navegador real — uma string atual de Chrome ou Firefox, não o padrão de uma biblioteca nem uma versão de navegador defasada há anos.
  2. Envie o conjunto completo de headers que aquele navegador enviaria: Accept, Accept-Language, Accept-Encoding e os headers de client hints Sec-CH-UA que o Chrome moderno inclui. Um User-Agent de Chrome sem client hints é uma contradição que sistemas de fingerprinting capturam.
  3. Mantenha os headers internamente consistentes. O Accept-Language deve corresponder à geografia que seu IP alega. Um IP residencial alemão pareado com um header de idioma solitário en-US é uma incompatibilidade.
  4. Defina o Referer de forma plausível. Páginas profundas de um site normalmente são alcançadas a partir de algum lugar, não invocadas do nada.
  5. Rotacione User-Agents com parcimônia e do jeito certo. Se for rotacionar, rotacione o pacote completo e consistente de headers junto — nunca misture o User-Agent de um navegador com os client hints de outro.

Se o alvo renderiza conteúdo com JavaScript e desafia clientes que não são navegadores, trabalhar só nos headers não basta; você vai precisar de um navegador headless de verdade, e nesse ponto uma API de scraping gerenciada costuma fazer mais sentido do que montar a stack por conta própria — operar navegadores headless em produção é o tipo de manutenção contínua que eu só assumiria com uma boa justificativa. Veja nosso comparativo de APIs de scraping versus proxies puros para saber onde a balança pende.

Gerencie sessões e cookies deliberadamente

Sites usam cookies para acompanhar a continuidade de um visitante. Scrapers são sinalizados quando essa continuidade quebra:

  • Aceite e persista cookies dentro de uma sessão lógica. Um cliente que recebe um cookie de sessão e nunca o devolve parece quebrado ou hostil.
  • Mantenha o IP e o cookie jar pareados. Um cookie de sessão que chega de três países em dez minutos é um viajante impossível. Se você rotaciona IPs, rotacione os cookie jars junto.
  • Combine o tipo de sessão com o trabalho. Tarefas sem estado — buscar milhares de páginas de produto independentes — combinam com rotação de IP por requisição, sem cookies persistentes. Fluxos com estado — paginar um conjunto de resultados de busca, percorrer uma listagem de várias páginas — precisam de uma sessão sticky em que IP e cookies ficam fixos durante todo o percurso.
  • Expire sessões como um humano faria. Ninguém navega em um único site continuamente por 72 horas. Aposente identidades de sessão após um tempo de vida plausível e comece de novo.

Os principais provedores de proxies residenciais expõem controle de sessão exatamente por isso. Segundo suas páginas de produto (consultadas em julho de 2026): a Oxylabs oferece sessões rotativas mais sessões sticky de até 24 horas; a Decodo (antiga Smartproxy) oferece rotação por requisição e sessões sticky de minutos até dias; a IPRoyal suporta intervalos sticky de até 7 dias; e a Bright Data oferece os modos sticky e rotativo. A janela de que você precisa depende inteiramente de quanto dura seu fluxo com estado mais longo.

IPs residenciais rotativos para volume legítimo

Quando um projeto legitimamente precisa de escala — digamos, monitorar 100.000 páginas de produto por dia ou verificar rankings de busca a partir de 20 países — um único IP não aguenta a carga sem exceder qualquer taxa razoável por IP. Distribuir requisições por um pool de IPs residenciais mantém a taxa de requisições por IP plausível para um humano enquanto o job agregado termina no prazo. IPs residenciais também carregam a reputação normal de consumidor, ao contrário das faixas de datacenter que muitos sites bloqueiam em massa — os fundamentos estão no nosso artigo explicando o que é um proxy residencial.

Os quatro provedores que acompanhamos publicam as seguintes capacidades relevantes (todos os números vêm de suas páginas de produto e de políticas, consultadas em julho de 2026; os tamanhos de pool são alegações dos fornecedores, não verificados de forma independente):

Capacidades anti-bloqueio dos principais provedores de proxies residenciais (dados publicados pelos fornecedores, julho de 2026)
OxylabsBright DataDecodoIPRoyal
Tamanho do pool (alegação do fornecedor)175M+ IPs400M+ IPs mensais115M+ IPs64M+ IPs
Janela de sessão stickyAté 24 horasSticky e rotativaDe minutos até diasAté 7 dias
Segmentação geográficaDe continente a CEP, coordenadas, ASNDe país a CEP, ASNDe continente a CEP, ASNPaís, estado, cidade
ProtocolosHTTP(S), HTTP3, SOCKS5HTTP/S, SOCKS5HTTP(S), SOCKS5HTTP(S), SOCKS5
Preço de entradaPlano mensal de 5 GB a 6 dólares por GBPay-as-you-go a 4 dólares por GB (promoção)Pay-as-you-go a 4 dólares por GB mais VAT1 GB pay-as-you-go a 7,35 dólares por GB
KYC / verificaçãoFormulário KYC para todo cliente, escalonamento baseado em riscoKYC com revisão humana, apenas empresas verificadasKYC e triagem antifraude no cadastroKYC terceirizado via iDenfy, em níveis

Repare na última linha. Todo provedor sério verifica seus clientes porque o negócio deles depende de manter abusos fora da rede. A Bright Data restringe o acesso à rede residencial a empresas verificadas que passam por um processo de KYC com revisão humana, conforme seu FAQ de KYC. A Oxylabs exige um formulário KYC de todo cliente no cadastro, com escalonamento baseado em risco, conforme sua política de KYC e segurança. A Decodo roda verificações antifraude automatizadas e KYC em todo cadastro e bloqueia ativamente alvos de alto risco, como bancos e venda de ingressos, conforme sua página de segurança e compliance. A IPRoyal executa KYC por meio do provedor terceirizado iDenfy, conforme sua política de KYC. Se o seu caso de uso não sobrevive à análise de compliance de um fornecedor, o problema é o caso de uso, não o fornecedor.

Visão do engenheiro (Hinata): Se eu estivesse desenhando um pipeline de monitoramento de preços hoje, ignoraria o tamanho do pool na primeira passada — os quatro provedores têm IPs de sobra para qualquer job legítimo — e compararia duas coisas: a janela de sessão sticky mais longa que meu fluxo exige e o custo por mil páginas úteis. A conta é rápida: com páginas de produto na casa dos 100 KB, 1 GB rende cerca de 10 mil páginas, então a diferença entre 4 e 7,35 dólares por GB fica abaixo de um dólar por milhar — raramente é o custo dominante. O que domina, na prática, é o retrabalho quando a taxa de sucesso cai. Por isso eu leria o rigor do KYC como sinal de qualidade, não como atrito: uma rede que filtra abusadores tende a ter IPs menos queimados, e isso vale mais do que qualquer desconto de entrada.

Orientações práticas de rotação para volume legítimo:

  • Dimensione o pool pela taxa, não pelo ego. O que importa é a quantidade de requisições por IP por hora permanecer plausível para um humano no seu alvo específico, não o número de pool estampado no marketing. A Proxy Market Research 2026 da Proxyway (dados coletados entre março e abril de 2026) aponta a mediana de pool residencial anunciado em 54M de IPs — todo grande provedor tem mais endereços do que qualquer job legítimo precisa.
  • Use segmentação geográfica com propósito. Se você monitora preços na Alemanha, solicite IPs alemães e envie headers consistentes com a Alemanha; se acompanha preços em marketplaces brasileiros como Mercado Livre ou Amazon.com.br, use IPs brasileiros com headers em pt-BR. Segmentação geográfica serve para ver o que usuários locais reais veem, não para driblar banimentos regionais.
  • Mantenha rotação e estratégia de sessão alinhadas, como descrito na seção de sessões acima.

Para critérios de escolha de provedor além do bloqueio — estruturas de preço, testes gratuitos, suporte — veja nosso comparativo dos melhores proxies residenciais.

Por que proxies gratuitos pioram o bloqueio em vez de melhorar

O atalho tentador falha diante das evidências. Um estudo acadêmico longitudinal de 30 meses com mais de 640.600 proxies gratuitos de 11 provedores, apresentado no NDSS MADWeb 2024, constatou que apenas 34,5% estiveram ativos em algum momento, identificou 4.452 vulnerabilidades distintas em IPs de proxy — incluindo 1.755 que permitiam execução remota de código — e flagrou 16.923 proxies manipulando conteúdo em trânsito.

Para o anti-bloqueio em particular, proxies gratuitos são contraproducentes: os IPs são compartilhados com todos os outros scrapers de camada gratuita atingindo os mesmos alvos, então já chegam queimados nas listas de bloqueio dos grandes sites. Você herda a má reputação alheia por cima do seu próprio risco. O argumento completo está no nosso comparativo de proxies gratuitos versus pagos.

Monitore sinais de bloqueio continuamente

Bloqueios raramente chegam de uma vez; eles escalam. Instrumente seu scraper para enxergar a escalada cedo:

  1. Distribuição de códigos de status por domínio. Uma fatia crescente de respostas 403, 429 ou 503 é o primeiro alarme. Alerte sobre tendências, não sobre falhas isoladas — se eu pudesse instrumentar uma única métrica, seria esta.
  2. Detecção de CAPTCHA e páginas de desafio. Muitos sites retornam HTTP 200 com uma página de desafio no lugar do conteúdo. Crie uma impressão digital das páginas de desafio (padrões de título, marcação conhecida) e conte-as como falhas, ou suas métricas de sucesso mentem para você.
  3. Anomalias de tamanho de resposta e de conteúdo. Uma página de produto que de repente retorna 5 KB em vez de 80 KB, ou cujo parsing extrai zero campos, provavelmente é uma página de bloqueio ou dados-isca.
  4. Mudanças de latência. Throttling progressivo — respostas desacelerando de 300 ms para 5 segundos — é um sinal de bloqueio suave que antecede banimentos duros.
  5. Taxa de sucesso por sub-rede de proxy e por sessão. Se as falhas se concentram em faixas específicas de IP, aposente essas faixas; se se concentram em sessões de longa duração, encurte o tempo de vida das suas sessões.

Quando os sinais disparam, a resposta correta é desacelerar e diagnosticar — não escalar a agressividade. Corte sua taxa de requisições pela metade, verifique se seus headers ainda correspondem a um navegador atual, cheque se o site mudou a estrutura ou os termos, e só então retome. Scrapers que reagem a bloqueios forçando mais convertem throttling temporário em banimento permanente.

O que deliberadamente não vamos cobrir

Algumas perguntas de anti-bloqueio têm respostas que não publicaremos, porque a técnica só existe para derrotar controles de acesso:

  • Burlar paywalls ou telas de login. Conteúdo atrás de autenticação tem acesso controlado por design. Automatizar um contorno a esse controle é acesso não autorizado, seja qual for a ferramenta.
  • Fazendas de resolução de CAPTCHA. Um CAPTCHA é um site dizendo não à automação. Resolução em escala industrial existe para atropelar essa recusa.
  • Scraping de dados pessoais. Nomes, e-mails, perfis e dados de contato carregam obrigações legais (LGPD, GDPR, CCPA) e potencial real de dano. Provedores sérios bloqueiam esses casos de uso em suas políticas de uso aceitável por bons motivos.
  • Automação de compras. Bots de sneakers, cambismo de ingressos e criação de contas em massa são os casos de uso que deram má fama aos proxies e que os programas de KYC dos provedores existem para filtrar.

Se um projeto precisa de qualquer um desses itens, ele não tem um problema de bloqueio; tem um problema de permissão, e nenhuma engenharia resolve isso.

Checklist: uma configuração anti-bloqueio ética

  • Leia o robots.txt e os ToS; confirme que os dados são públicos e não pessoais
  • Prefira uma API oficial ou feed quando existir
  • Faça rate limiting por domínio com jitter; obedeça ao Retry-After; recue exponencialmente
  • Envie um conjunto de headers de navegador completo, internamente consistente e atual
  • Persista cookies dentro das sessões; pareie cookie jars com IPs; expire sessões de forma plausível
  • Use IPs residenciais rotativos de um provedor que aplica KYC quando o volume genuinamente exigir
  • Ajuste as janelas de sessão sticky ao seu fluxo com estado mais longo
  • Monitore códigos de status, páginas de desafio, anomalias de conteúdo e latência por domínio
  • Reaja a sinais de bloqueio desacelerando e diagnosticando, nunca escalando

Conduzido assim, o anti-bloqueio não é uma corrida armamentista — é cortesia básica expressa em engenharia. Sites bloqueiam tráfego que se comporta mal; a correção durável é tráfego que se comporta bem. Para o contexto mais amplo sobre ferramentas, legalidade e arquitetura, continue com nosso guia completo de web scraping.

Perguntas frequentes

A taxa de requisições é o gatilho mais comum. Enviar requisições mais rápido do que qualquer humano conseguiria navegar, a partir de um único IP e com intervalos idênticos, é o padrão mais fácil de detectar para sistemas anti-bot. Reduzir o ritmo, adicionar jitter e respeitar respostas HTTP 429 com backoff exponencial elimina a maioria dos bloqueios de primeira camada.
Voltar ao guia completo

Artigos relacionados